» Tutorial Geometry Morphing CPU
This site relies heavily on Javascript. You should enable it if you want the full experience. Learn more.

Tutorial Geometry Morphing CPU

French | Russian | Japanese | Italian

the cpu based approach

as you may have already heard already. when morphing geometry it is necessary to have two 3d models that do not only consist of the same number of vertices. those vertices should also be indexed (ordered) the same way. if one of those prerequisites is not met you can still morph the models and may even get more interesting results.

creating equally indexed 3d models with your favorite modelling software is a task of its own. for this tutorial we will just morph between two primitive cones that ship with vvvv. and patch we do:

preparing the morphtargets

first build a patch that simply renders two cylinders on top of each other. a red one and a green one. one straight. the other upside down. our two morphtargets. patch until you have something like pictured below.

note the Camera (Transform Softimage) and AspectRatio (Transform) nodes that are not essential here but are just a good idea to have anyway.

when hovering the cylinders output you see that its connection to the GouraudDirectional (EX9.Effect) is a mesh connection. a mesh consists of a vertex- and an index buffer. whereas the indexbuffer in vvvv is represented as a simple spread the vertexbuffer is kind of a container for several components making up the geometry. connecting a VertexDeclaration (EX9.Geometry Mesh) node to the cylinder and hovering its output shows you what vertexcomponents our cylinder consists of: there are Position, Normal and TextureCoordinate values in the cylinder mesh. other meshes can include other components.

now there isn't yet a node in vvvv that would just take 2 meshes and a morph-factor and do the work for us. and since there will probably never be such a node (because it is a boring thing to implement) and since you want to know how everything works anyway we now just patch exactly what such a node would do.

accessing the vertexbuffer

therefore we need a node to access all the components of a mesh so that we can patch the morphing manually. see the patch below how we can use a Mesh (EX9.Geometry Split) followed by a VertexBuffer (EX9.Geometry Split) to read out all the vertex data. the patch also demonstrates that this process can be reversed. Mesh (EX9.Geometry Join) followed by a VertexBuffer (EX9.Geometry Join) assamble the cylinder back to a valid mesh for the GouraudDirectional (EX9.Effect) to render.

note the indexbuffer coming out of Mesh (EX9.Geometry Split) being directly connected to Mesh (EX9.Geometry Join) and the vertexbuffers position and normals components handed over from the splitting to the joining VertexBuffer node.

doing the morph

seeing this you may have already figured out how we have to go on now. we are only missing the morphing part between the two VertexBuffer nodes. split the green cylinders vertex-data as you did with the red one and use a simple InputMorph (Value) for the morphing.

since the color is not a component of the vertexbuffer but a parameter for the effect you have to do the morphing for the color separately with an InputMorph (Color) node. dragging the inputmorph's value between 0 and 1 now results in a smooth blend from a regular red cylinder to an upsidedown green cylinder. questions?

with this approach all the calculation of the morphed positions and normals is done on the CPU. also a new vertexbuffer and/or mesh is created every frame the "Apply" pin is 1 on the respective nodes which costs some time.

this poses no problem as long as you are working with relatively small meshes. if you get the feeling that everything is getting a bit slow read on about the cooler gpu based approach.


see what happens if you have two models that do not correspond in vertexcount and indices. double click the first Cylinder node and replace it with a Teapot (EX9.Geometry) node. instant media art!

anonymous user login


~14h ago

joreg: another release candidate is out for the weekend: beta36-release-candidate #vvvv please test and report!

~2d ago

microdee: I realized that I will just do those updates on separate branches, Still stay tuned...

~2d ago

microdee: I'm making mp.* packs CI and release friendly. Meanwhile vpm downloads might not work with them for a bit. Stay tuned...

~2d ago

~3d ago

karistouf: thank you joreg

~3d ago

joreg: good to hear!

~3d ago

Xini: the old problem was the renderer on a second screen freezing when fullsize, under certain conditions which i can't remember now...

~3d ago

Xini: @joreg now i got hold of a projector and i tested, should be fine! :D @joreg

~4d ago

joreg: i'm not exactly sure what "old problem" you're talking about. have you tested if it still exists?

~4d ago

Xini: tx @joreg . Do you think it's better for me to install a 32bit version of vvvv, or is there another workaround for that old problem?