Hello everyone. I’m porting code over from another application I’d written originally piggy-backing on the Processing library to JMonkeyEngine. The code for this application relies on a custom scene graph I’d written which supports affine matrix transformations.
I would like to apply the same matrix transformations to JME’s Geometry objects. However, using the Transform class in conjunction with the fromTransformMatrix() method seems to decompose any matrix passed in into separate Rotation, Scale and Translation objects, discarding things like shear (which are important to my application).
Is there any simple way to manually force JME to use my transformation matrices as specified within its own scene graph, such that shear is preserved?
JME is a game engine and not really a general “do any kind of graphics” engine. So it makes certain tradeoffs for speed/performance. This is one of those things.
Non-uniform scaling is not really supported, either, except at the lowest level.
Is there any way to access this lowest level without making changes to the library itself?
I notice that the Geometry class has a computeWorldMatrix() method. The matrix seems to be computed by composing the Geometry’s localTransform object with its parent’s worldTransform object. If I extend the Transform class to be backed by the custom matrices computed elsewhere in my program, and extend the Spatial and Geometry classes to use my exted Transform class, would this be sufficient to get affine transformations working, or is this likely to bite me in some unanticipated way?
Some things likely use the components directly and would mess up.
You might be better off continuing to use your custom scene graph, really… or write your own Geometry subclass that overrides everything to do with transformation and then only do your odd transforms at the “lowest level”, ie: geometry.
When I say non-uniform scaling is only supported at the lowest level I mean it is accumulated separately from rotation and then applied only at the geometry level. So if you give non-uniform scaling to a parent node and then rotate the child you will get very strange results.
Non-uniform scaling is only really supported at the geometry level and I guess only because it’s convenient to reuse a box and scale it non-uniformly, etc.