[Bf-committers] Linux plugin (was: Re: NDOF -- new commit)
ettore_pasquini at 3dconnexion.com
Wed Aug 1 02:33:41 CEST 2007
On 7/31/07 4:41 PM, "Martin Poirier" <theeth at yahoo.com> wrote:
> Hi Ettore and Jean-Luc
> --- Ettore Pasquini <ettore_pasquini at 3dconnexion.com>
>> On 7/31/07 10:57 AM, "Jean-Luc Peurière"
>> <jlp at nerim.net> wrote:
>>> For when can you have your binaries ready ?
>> I have completed the linux plugin, it's available
> Following the readme, When asked to map the left and
> right buttons in the driver, I couldn't find any entry
> AP1 and AP2 in the drop down menu. Selecting Button 1
> and Button 2 seemed to do the trick though. (using
> driver version 1.2.11).
Thanks for letting me know. You are right. I just corrected that. I might
have had an experimental build of the 1.2.10 driver...
> The Transform implementation is really bugging me
> though because it floods the undo levels with
> infinitesimal steps. I'm thinking it would probably be
> easier and cleaner to just add Ndof as a special input
> in the Transform functions (on par with Numerical
> input) with the twist that you could use the device to
> initiate transform and the two buttons to
> confirm/cancel once done (this would give long nice
> atomic undo steps, like normal). The down side is that
> it could only do either translation or rotation at
> once (maybe it's an upside for others though).
> Sounds like a nice and easy project to do, so I'm
> putting that on top of my stack (should have some time
> in the coming weeks).
> Too late for SIGGRAPH, obviously, but release is still
> far off.
If I understand correctly, IMO this solution is the best for the user
because of the need to confirm or cancel what he just did - could be
stressing after a while.
I think it would be better if all this was automatic implementing maybe a
transaction mechanism, like:
- when entering transform mode, we open a new "transaction"
- user _continuously_ moves the cap as much as he wants
- once we detect a pause in user motion, we close the transaction. This will
result in one atomic undo step.
- we get ready for a new transaction.
Of course, I have no idea how the undo mechanism work in blender ,:-) so I
don't know how feasible this is. Basically we'd need a way to group each
micro-step in a sequence of steps and expose only the sequence.
Opening/closing the transaction is doable with proper timing, or even easier
with just observing for a all-zero vector.
Just my 2 cents...
More information about the Bf-committers