Note that axis move and axis scale are already implemented if you use the blender like keyboard shortcuts (g + x will move along the x axis). so you might want to rely on this when implementing it with axis picking.
While adding axis x,y,z for scale and rotate tool i noticed that the value of modification are based on screen coord, unlike the move tool which use 3D position of the “cursor”.
So i plane to let all tool use the same way (as movetool), kind of a pickManger providing several mode and values. Such as difference of position (and angle) between cursor and selection …
IMO screen position for scale is fine.
For move what’s actually used is an invisible plane perpendicular the the camera direction that goes through the moved object origin. Then the position is computed by ray-casting against this invisible plane.
This allows to move an object in a parallel plane in respect of the camera view.
Of course if x,y, or z are typed, the plane is oriented toward that axis.
For scale, it’s not really necessary to go through this hassle, IMO. scaling in 2D is fine even for non uniform scales.
Im rewriting the moveManager to become a pickManager, it’s will be used by all the tools (moving, rotating and scaling), it will provide “pick” informations such as startWolrdPosition, sartOffset, finalOffset, absoluteTranslation, the quaternion rotation between the start and final offset. The main goal of doing this way is to be able to add “local” or “world” transformation without editing tools code. It’s almost done, i still need to do the rotating tool and fix a bug with the scaling axis.
Maybe this manager will go into the SceneEditTool in order to be available for every tools.
Hey, you seem to dive pretty deep into this. As its still in a relatively unclean state and nobody is really working on it at the moment feel free to enhance it. There is still plans to change the whole editor part of the SDK to something of an SPI that would work for editor plugins outside of the SDK (other editors, in-game editors etc.) but having some clean code will certainly help for that as well.
Service Provider Interface. It would be an interface that any editor can implement to then support editing plugins. So all editor plugins that would then extend the jme3 scene editor could be run in games, other IDEs etc. if theres a SPI layer for these.
As it is now, the SDK plugins are completely separate, the (Simple)SceneComposer was never meant to be a large editor plugin for scenes, just an example implementation for such an editor. Given how many people expect it to be something similar to e.g. the UDK editor however we thought of this way of having one scene editor that would be extensible through plugins which in turn work similar to jME AppStates so that you basically work on the GL thread instead of managing the awt and gl thread yourself like you do in normal SDK plugins.
What about the short cuts? in what space do they transform? Until now axis restriction was done in world space. And without axis restriction it was in camera space.
now right clicking will cancel the current transformation (for the Scale, Rotate and Move Tool).
In order to looks like the selectTool shortcuts.
I also improved these tool feedback as it’s easier to start the transformation (its start on the first click instead of the first dragg).
But i just noticed that the rotate tool isn’t doing it right for Global or Camera option, I’ll need to fix this before starting the modify the SelectTool.