Morph node implemented and committed to CVS. Minor related modifications made to some classes in com.xith3d.scenegraph.
Morph node test added as Xith3DMorphPyramid2CubeTest.bat and Xith3DMorphPyramid2CubeTest.java. This test is similar to Pyramid2Cube example from Java3D demos.
I tested only geometry and color morphing. Normal and texture coord morphing is also implemented but not tested. It would be great if someone will post here feedback regarding normal/tex coord morphing.
Yuri
Great job Yuri - could you please comment on how’s memory consuption compared to the Morph node in Java3d ( where that node was practically unusable) ?
Current implementation allocates one additional copy of geomerty arrays data passed to Morph constructor. This is not so memory-efficient, but allows to prevent multiple memory allocations during normal morphing process. This is only way to keep copy of the data because of they are stored in GeometryArrays as NIO buffers. This technique allows use on the same geometry in both normal shapes and morph nodes.
Normal morphing does not consume memory, because of data placed directly to NIO buffers which renderer implementation passes directly to OpenGL.
Morph node has special performance shortcuts for cases where the weights array contains only one, two or three non-zero values.
Xith3D implementation of Morph has no constraint on sum of weigts to be equal to 1.0, which allows some interesting morphing effects.
Yuri
What do you think about refactoring buildCompatibleGeometry into GeometryArray virtual method ? It could be useful for broader audience - and at the same time we can avoid instanceof if/else ladder.
BTW, can I go through source and try to refactor ‘if ( this instanceof SomeClass )’ in few places to overridden methods ? I know it is sometimes easier this way, but I doubt if there is any less OO syntax possible in java 
Yes, we can potentialy use something like duplicateNode(forceDuplicate).
[quote]It could be useful for broader audience - and at the same time we can avoid instanceof if/else ladder.
[/quote]
Agree. Let me check how we can do this without introduction of a new method, so we will stay compatible with Java3D and avoid this ‘if instanceof’.
Yuri
Morph node seems to work great. The MD2 loader is now ported over to Morph for its animation. The normals seem to work fine.
Nice work Yuri!
Kev
I am seriously thinking about implementing native-code-accelerated version of Morph node (which will use SIMD [SSE/SSE2/3DNow]) and placing it in xith-tk. But this is not a top priority for a moment.
Yuri
abies,
[quote]BTW, can I go through source and try to refactor ‘if ( this instanceof SomeClass )’ in few places to overridden methods ?
[/quote]
I just reviewed Java3D docs and think that we should add implementation of cloneNodeComponent(boolean forceDuplicate) and duplicateNodeComponent(NodeComponent originalNodeComponent, boolean forceDuplicate) to GeomContainer override them in TriangleArray, QuadArray etc. so the code of Morph.buildCompatibleGeometry(…) will transform to
private void buildCompatibleGeometry(GeometryArray a) {
setGeometry((GeometryArray) a.cloneNodeComponent(true));
}
Will be great if you can do this - just send patch file to Issues and I will review and apply it.
BTW, I think that for duplicating geometries we can treat GeomDataInterfaces as elementary types and duplicate them always (not taking care of forceDuplicate flag).
Also looks like we should introduce private no-parameter constructors in some classes (PointArray, LineArray etc.) to follow design of cloneNodeComponent(…).
Yuri
[quote]I am seriously thinking about implementing native-code-accelerated version of Morph node (which will use SIMD [SSE/SSE2/3DNow]) and placing it in xith-tk. But this is not a top priority for a moment.
[/quote]
Maybe opengl-accelerated one ? I think that ATI has explicit weight extension for it, while NV needs vertex program. This way, morph node could live in static GPU VBO, with interpolation done on the card.
[quote]Maybe opengl-accelerated one?
[/quote]
Would be a good addition. The only question is compatibility in this case, but this is a matter of testing.
If we will go to OpenGL-accelerated version, we will also need additional atom class for Morph, so this is more conceptual enhancement. With transforms executed on CPU we can keep the same shader for both Morph and Shape3D, which is easier for a moment, and we can postpone these enhancements a bit.
Yuri
Patch from Issue#37 already integrated into CVS. Thanks abies for this patch.
If you were instantiating directly some formerly abstract classes such as GeometryArray [i.e. those which were declared abstract in Java3D API], please note that they became abstract and now match Java3D API.
Yuri