Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

11991 Posts in 1587 Topics- by 3508 Members - Latest Member: NevilleKemp

26. May 2012, 03:20:25 pm
Xith3D CommunityGeneral CategorySupport (Moderator: Marvin Fröhlich)Improve model renderer
Pages: [1]
Print
Author Topic: Improve model renderer  (Read 375 times)
davicente
Just dropped in

Offline Offline

Posts: 10


View Profile
« on: 21. September 2010, 08:44:01 am »

Hi all:

I have a rendering problem. I´m loading several 3D models (DAE) and it works correctly. But when I increase the number of models (about 50) it renders very slowly.
Is there some way to improve the rendering of models?
Is it possible to reduce the quality of the images to improve the rendering times?
Most of my models are the same repeated. I have tried to load ones and render it in differents positions, but it doesn´t show anything. Does it have sense and it could improve the render times, or it is an stupid thing?

I know these are a lot of questions. I have loaded the models in Google Earth, and it´s incredible how good it renders them, and it uses opengl supposedly. I suppose it works with some intermediate model to optimize the rendering (and it works very good).

Regards
Logged
Marvin Fröhlich
Xith Lord
Administrator
Guru
*****
Offline Offline

Posts: 4381


May the 4th, be with you...


View Profile
« Reply #1 on: 21. September 2010, 11:39:30 am »

You can used shared instances of models. See the getSharedInstance() method on the Model class.

To reduce the quality you have to compute a lower poly model in your 3D modeller. You can use a LODSwitch (or how it is called) to switch between different low/high poly versions of your model by camera distance automatically. Xith3D doesn't currently feature CLOD. So it cannot do the poly-reduction for you.

Marvin
Logged
badboyboogey
Enjoying the stay
*
Offline Offline

Posts: 40



View Profile
« Reply #2 on: 21. September 2010, 07:58:29 pm »

One method i've been using  for static geometry, (that is quite literally geometry that doesn't and never will move like walls and floors)
is to make 1 big GeometryArray to hold the data rather than using shared Geometry.

My world holds around 30000 objects to describe a dungeon, if I use Shared Geometry for the static objects I get about 30 fps.
So I bundled all geometry with the same Face types (mainly Quads for me) and Appearance into very large QuadArray, obviously offsetting the coordinates to give each object the correct position. I now get around 550 fps!
Obviously the less TransformGroups the renderer has to iterate through the better.
Logged
Marvin Fröhlich
Xith Lord
Administrator
Guru
*****
Offline Offline

Posts: 4381


May the 4th, be with you...


View Profile
« Reply #3 on: 21. September 2010, 08:35:09 pm »

One method i've been using  for static geometry, (that is quite literally geometry that doesn't and never will move like walls and floors)
is to make 1 big GeometryArray to hold the data rather than using shared Geometry.

This annuls the frustum culler and is hence a bad idea.

I don't know, what this has to do with shared geometry. Well, I also don't know your dungeon Smiley.

Let's say, you have 30000 objects, of which some are walls and others are torches or furniture, etc. Then you should not model each quad of the walls as its own Geometry and Shape. It's always a trade off. Create each furniture as its own shape and pieces of the walls as separate shapes (not each quad, but larger pieces). Limit the size of each object to 4096 vertices. This is the range, where a vertex buffer operates optimally. It depends on the size and detail level, how many vertices you should put into one Geometry.

The Frustum Culler must have a chance to do its job. 550 FPS may sound like a lot, but I am sure, you can get much more, if you carefully group quads and give the Frustum Culler the chance to sort out large parts of the world at an early stage in the rendering process.

Also use sub groups to group nearby objects, that are likely to be rendered all or none, but don't use 50 levels of grouping. Groups and sub groups are a scenegraph's strength.

I also suggest to use triangles instead of quads, which the GL can do a lot faster. And use strips instead of plain triangles. This saves data and is faster.

Use display lists, where ever possible. For the static parts of a world, this will always be possible. If using display lists, the geometry type doesn't even matter.

Don't put the static objects into TransformGroups, but use StaticTransform to statically move them into place.

If you have some tunnels in your dungeon, you could also consider to use a Switch group and decide on application level, which large groups of objects are seeable from the current position. This will gain a lot of FPS.

These are the simple parts of scenegraph optimization, though you need some careful adjustments to make it optimal. But don't cheat the scenegraph and deny it doing its job, by using one big geometry and letting the graphics card render everything always.

The problem with TransformGroup is, that they may be optimized and don't calculate the inner matrices every single frame, if they remain static, but the metrices need to be sent to the GL, which can mean a lot, if there are a lot of them, which are not sorted out early.

Good luck with optimization. And please report back, what it gave you.

Marvin
Logged
davicente
Just dropped in

Offline Offline

Posts: 10


View Profile
« Reply #4 on: 22. September 2010, 10:40:00 am »

Thanks to both for the answers.
I will try with your 2 proposes:
- Shared instances of models
- Reduce quality with your method.

Thanks again
Logged
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic