That looks fun, how does the actual code look like?
Can i simply Morph a Sphere into a Quad ?
Core-Dump said:
That looks fun, how does the actual code look like?
See the methods forceMorph() and mergeBuffers() at http://jmonkeyengine.googlecode.com/svn/trunk/src/com/jme/scene/MorphingTriMesh.java
Can i simply Morph a Sphere into a Quad ?
Sort of: yes, but probably not as simply as you are thinking. The general requirement for morphing, in all programs that I know of, is that the component meshes must all have the same number of vertexes. So that the Sphere vertexes gradually deform into the nearest Quad corner, and vice versa, you would need to do something like the following. Use a 3D program and start with a copy of the Sphere (the component that needs the most vertexes), and move the vertexes so that they make a quad. Save this quadified sphere as your quad morph.
Core-Dump said:
...
Can i simply Morph a Sphere into a Quad ?
I answered this, but thinking about this use case got me thinking of a way that this could be accommodated, and even eliminate the general (not jME-specific) requirement of matching vertex counts. The Morping classes could do as follows.
Find out which mesh has the maximum number of vertexes. Call this the as-is morph, since we don't need to change this morph. Now go through every other mesh:
- If the other mesh has the same vertex count as the as-is morph, then do nothing to it.
- Go through each vertex of this "other" mesh and make a mapping to associate each other mesh vertex with the as-is vertex which it is closest to (each as-is vertex can only be mapped to by other mesh once here).
[li]Now go through all unmapped as-is mesh vertexes. For each one, find the closest as-is mesh which has been mapped to, create a new other mesh vertex which duplicates the position of the other mesh vertex associated by this closest as-is vertex from the previous step.
Leaving out the straight-forward indexing work and copying over of normal and vertex color data along with the location data, this algorithm would result with every morph mesh having the same number of vertexes, and vertexes from higher-original-vertex meshes would converge to the appropriate locations as morph influences approach those other morphs.
Easier to do that than to explain it.
i don't really have a use case for morphing simple geometries, i thought it could be fun to play around.
So don't invest too much time in it, if its not on your todo list anyway 
Committed with rev 4553.
MorphingGeometries work with pixel coloring, texturing, and animations, including SkinTransferNodes (for runtime skin swapping), and can morph while motion animations run.
I've colorified the demo model (Suzanne). You can see the updated screen shots later today when I announce the imminent HottBJ exporter release supporting this new jME feature. I like to give out some candy (screen shots) with the announcements.
Blaine, you are unbelivable! Full of energy… Adding one feature after each other…
Great JOB! Can't say this often enough…
Keep on rocking
Simply fantastic!
Great job Blaine.
THATS AMAZING!!! YOURE A GOD! I have nothing else to say. Good job thats so damn cool.
We need this committed asap.
lanmower said:
THATS AMAZING!!! YOURE A GOD! I have nothing else to say. Good job thats so damn cool.
We need this committed asap.
I agree with him, great job! If you did not exist, we should invent you lol.
lanmower said:
THATS AMAZING!!!...
We need this committed asap.
Thanks. It is committed (note the prefix in the Topic title), and it is in the jME 2.0.1 distro.
there doesn't seem to be anything in the jmetest package in order to have a look at this in action…
ncomp said:
there doesn't seem to be anything in the jmetest package in order to have a look at this in action....
same thing I was thinking
ncomp said:
there doesn't seem to be anything in the jmetest package in order to have a look at this in action....
Correct. Use this WebStart launcher.
Use SHIFT+F7, click and drag the new widget toward an edge. Click in bg to get keyboard focus out of the widget entry fields. TAB twice (which will select the MorphingTriMesh Spatial) and you can then use the morph fields in the widget.
I'll add a jmetest demo when I finish other urgent work. Medium level Java developers can work from the documented API until then.
that works…
thanks…
ncomp said:
that works...
thanks..
I should also mention, for Blender users, that this feature will be covered by the incipient HottBJ Game Integration tutorial, if any demand is manifested.
mcbeth said:
ncomp said:
there doesn't seem to be anything in the jmetest package in order to have a look at this in action....
same thing I was thinking
Added. src/jmetest/renderer/TestMorph.java
blaine said:
I'd like to add direct support for morphing to jME. This is the most prominent, basic feature of Java3D which jME is missing, and it's particularly applicable to the gaming domain. Just as in Java3D, I'd like to add it to the base packages.
Morph has been deprecated in Java3D. In Java3D it makes more sense to implement it as an utility class. Now there is Morph code littered all over the core classes, and it suck.
Added. src/jmetest/renderer/TestMorph.java
Thx a lot! Could really need that...
HottBJ can write MorphingTriMeshes directly, eliminating the need for most of the custom coding on the jME side. HottBJ users should read the Morphs section of the Game Integration Features help page.