next »

[maguila007]

Hi

I creates a TriangleArray with vertices coords, normals, and texture coordinates.
Then I creates a Shape3d with Appeareance and Texture ( using DefaultNodeFactory ) and loads the TriangleArray to the scene.

Everything works fine, the vertices, normals, texcoords, lights, but... when I watch the mesh from above it just dissapear from screen.
And It 's not a light problem of the example, because I have a box next to the mesh and id doesn´t dissapear.

What can it be? A problem in my vertices coords? The way I creates the TriangleArray? Some polygon attribute?

Thanks

[kukanani]

Hey, welcome back Maguila!  OK, so maybe you were never gone from Xith, but we haven't heard from you on the forums for a while...

[Marvin Fröhlich]

I creates a TriangleArray with vertices coords, normals, and texture coordinates.

I'm not sure, if this might be something, that you did wrong (I would have no idea, what in this case). But vertices are composed of coodinates and optionally normals, tex-coords and colors. Just to make sure, you understood that correctly.

Then I creates a Shape3d with Appeareance and Texture ( using DefaultNodeFactory ) and loads the TriangleArray to the scene.

Don't use DefaultNodeFactory. It is a utility class for the model loaders (IIRC TDSLoader and MD2Loader have one each). I'm not sure, if the resulting Appearance will have good settings this way.

Everything works fine, the vertices, normals, texcoords, lights, but... when I watch the mesh from above it just dissapear from screen.
And It 's not a light problem of the example, because I have a box next to the mesh and id doesn´t dissapear.

What can it be? A problem in my vertices coords? The way I creates the TriangleArray? Some polygon attribute?

Did you try to display the shape's bounds (with setShowBounds( true ))?

One thing is very important. You must either fully define the GeometryArray (the TriangleArray in your case) BEFORE you apply it to the Shape3D or invoke updateBounds() after you manipulate the Geometry or reapply it to the shape through shape.setGeometry( shape.getGeometry() ), which would have the same effect. At least showing the bounds will tell you, if everything is fine with the bounds.

Marvin

[maguila007]

Thanks a lot!!!!

I was not doing the updateBounds() in each "prepareNextFrame" call.

Well... now that everything works fine, I am glad to say that the TriangleArray was an AnimatedModel, loaded with my own file format.

I needed to have a simple animated model (for a personal work), so I created my own file format for frame animation (not skeletal, like Collada, but don´t worry I am still working on Collada).

If somebody need a simple and fast model to play many animations, just tell me.

I have done the following things:

1) two 3ds Max Scripts to export the mesh and many animations. I am planning to port them to blender. They are very simple.

2) The exporters creates 2 types of XML files, one .mesh file, and many .anim files. They have a very simple and intuitive format, because the most difficult part for me was to make the Max exporters, so I only exports raw data.

3) Then I have a Java utilty that merges one .mesh file, one texture, and many .anims files in a binary file.
If doing the blender's exporters is too complicated, I can do a special merging tool for blender, and makes exporters even more simpler.

4) Finally I have a xith's loader that creates a model with the binary file I created in step 3.


The mesh, the texture and the animatios seems to works fine.
However it´s a very simple file format and it will never be as good as COLLADA.

It's not commited to xith yet.

Bye

[Marvin Fröhlich]

I was not doing the updateBounds() in each "prepareNextFrame" call.

Updating the bounds each frame is quite expensive. I would suggest to do the following:

• Calculate the bounds of the model (-part) for each animation.
• Compute a bounding Sphere or AABB, that surrounds them all.
• Then save this result to your final model file.
• Load the "scheduling bounds" from the model file and apply them to the Shape3D and disable the shape's bounds-auto-computation.

This way the mesh's shape will always be inside the bounds, no matter which animation is being played. And the bounds don't need to be expensively recomputed each frame.

Additionally you should consider to not deform the TriangleArray itself, but put the model parts into different TransformGroups. This way you can make use of optimizations like VBOs or DisplayLists and let the hardware apply the animation to the modelparts. I would expect it to be much faster.

Marvin

['n ddrylliog]

maguila, very good that you do the announcement here it relieves me from a bit of "communication" work.

So for the Blender scripts, well we'll see but I think it'd take time to learn the Blender Python API so maybe asking to the guy who did the md2/etc scripts to do that, or maybe taking inspiration from the md2 script itself, well we'll see it's not a priority for me for now. I'm rather keen on COLLADA just now.

[maguila007]

This way the mesh's shape will always be inside the bounds, no matter which animation is being played. And the bounds don't need to be expensively recomputed each frame.

Thanks for the tip. I just have finished and It increase a little the FPS.

Additionally you should consider to not deform the TriangleArray itself, but put the model parts into different TransformGroups.

I don't understand this tip very well.
I am currently doing:

Code:

triangleArray.setCoordinates( 0, vertexBuffer );

every frame.

And I am using VBOs optimization, but I suppose it's not doing too much.
What's the difference beetween VBOs and DisplayList?

[Marvin Fröhlich]

Additionally you should consider to not deform the TriangleArray itself, but put the model parts into different TransformGroups.

I don't understand this tip very well.
I am currently doing:

Code:

triangleArray.setCoordinates( 0, vertexBuffer );

every frame.

And I am using VBOs optimization, but I suppose it's not doing too much.
What's the difference beetween VBOs and DisplayList?

There are basically two ways to transfer the vertex information to the graphics card.

• send each coord, normal, tex-coord and color separately between a glBein() and glEnd() pair
• build a vertex array and send all information at once

Xith always uses the second one.
Further there are three ways to handle the vertex arrays.

• send them each frame again and again
• store them on the graphics card's VRAM in a so called VBO (vertex buffer object)
• store everything in a Display List

I might imagine, that sending the vertex information only once over the bus to the graphics card, storing them in the VRAM and just telling the graphics card to use them is much faster then sending them each frame again. But if the vertex information changes, the vertices have obviously to be sent again, even if they are stored in a VBO or DisplayList. And of course building the VBO or compiling a DisplayList is a little overhead. So, if you're using VBO optimization and then changing the vertex information, the VBO has to be recreated, which will result in a loss of performance. A DisplayList is never recreated, so you won't even see an effect of the animation, if you're using animations the way you do.

As a result, you should use Optimization.NONE, if you're directly manipulating the vertex information. But if your animation is defined by an affine transformation, that influences certain vertex groups, you should put these vertices in a separate shape and put this shape in an own TransformGroup. Then you can use VBOs or DisplayLists for these shapes and let the hardware transform the vertices.

What you're currently doing is manipulating the vertices on the CPU, but not on the GPU. The GPU can do this much faster and the vertices would not have to be send over the bus each frame and can be stored in a VBO or compiled into a DisplayList.

Please ask, if I wasn't clear enough.

Marvin

[hawkwind]

experiment...experiment....I have run with Optimization.NONE,/ VBO / DISPLAYLIST and see the following for a fix place in my scene, with zero animations, vertex modification whatever.

NONE   = 37 frame
VBO    = 31 frame
DSPlst = 39 frame

For my clarification does moving a shape with a transform affect the various optimizations??  Will a rotating object visible or culled affect the optimization performance??

[Marvin Fröhlich]

experiment...experiment....I have run with Optimization.NONE,/ VBO / DISPLAYLIST and see the following for a fix place in my scene, with zero animations, vertex modification whatever.

NONE   = 37 frame
VBO    = 31 frame
DSPlst = 39 frame

Well, sometimes it depends. But from a certain amount of vertices, NONE Optimization should always be way slower. How many vertices does your test scene have? And of how many shapes does it consist? Is the whole scene always inside the frustum?

For my clarification does moving a shape with a transform affect the various optimizations?? 

If the transformation is done through a TransormGroup (transformation matrix), the optimization is not influenced. If the transformation is done through StaticTransform, the vertices are directly manipulated (each frame) and therefore a not-NONE Optimization will be slower than NONE.

Will a rotating object visible or culled affect the optimization performance??

If a shape is culled out of the scene (outside of the frustum), the performance is not influenced by its Optimization setting, since it is not rendered at all.

Marvin

[maguila007]

Please ask, if I wasn't clear enough.

Thanks for the explanation!
That´s why I love 3d programming. There´s always something new to learn about.

As a result, you should use Optimization.NONE

What about

Code:

OptimizationUSE_VBO_FOR_TEXTURE_COORDINATES

?
I only sets the texture coordinates once, when I load the model, and they won´t change later.

[Marvin Fröhlich]

What about

Code:

OptimizationUSE_VBO_FOR_TEXTURE_COORDINATES

?
I only sets the texture coordinates once, when I load the model, and they won´t change later.

Should be ok, then.

Marvin