Hi Tino,
On Fri, 2005-01-14 at 07:56, Tino S. wrote:
> Hi,
> i have tryed to load a scene (~9 MB ) with the
> scenefilehandler.
>
> http://www.fpk.tu-berlin.de/~tino/scene.wrl.bz2
>
> But OpenSG cant show this file. The CosmoPlayer have
> no problem.
> Can you have a lock at this file and the source code?
> Do you have any idea?
the file works fine for me, it's just very slow.
If you're running on Windows make sure you don't use the MS STL, as it
is incredibly slow for large files. Use the STLport version instead.
In general the model is not a good case for a scenegraph, as it has a
lot (72000) of very simple objects (cubes), and each of them has a
transformation matrix. This puts a medium amount of stress on the
graphics card and a lot on the CPU.
By default OpenSG uses 2x2 polygons for each cube side (to make lighting
look not totally flat), which for your scene ends up being 3.4 MTris.
Even turning it down to 1x1 is 860 KTris. That's not nothing, but not a
spectacular amount either.
The larger problem is the number of small objects, though. 72000 objects
means 72000 display lists or draw calls, each for only 12 tris. In
addition to that, each node has a (different) matrix, so there needs to
be a matrix change for each 12 tris, which kills the pipeline and
performance. On the scenegraph side, 72000 objects also have noticeable
overhead, for traversing, accumulating matrices and doing frustum
culling and draw tree creation.
Unless you want to manipulate the individual cubes, it makes sense to
combine them into fewer objects (like, 1 ;). You can do that using the
MergeGraphOp, like this:
#include <OpenSG/OSGGraphOpSeq.h>
#include <OpenSG/OSGMergeGraphOp.h>
GraphOpSeq *graphop = new GraphOpSeq;
graphop->addGraphOp(new MergeGraphOp);
scene = SceneFileHandler::the().read(argv[1], graphop);
This will automatically merge whatever you load. Loading will take more
time (using the optimized library makes a difference), but rendering
will be much faster (for your test scene on my system a factor of ~100).
If you need the model again it makes sense to do the conversion once and
write the model out as .osb, which is much faster to load.
In the current version your model triggers a bug in the MergeGraphOp,
though. I fixed and submitted it, it should work now.
Your file is a little weird, in that none of the objects have an
Appearance, which threw the tool off a little (and looks a little weird,
as no colors are set).
The scene looks like a robot cell, is that what you're trying to do?
Looking at it I would guess that a large number of the objects (like the
dt_sf45[abc]_* groups or their transforms) are a single piece that could
be merged, and that just happens to be many, many parts because it was
modeled as a large number of NURBS surfaces there were exported
individually. You can run the GraphOp on a subtree of the graph, the
only problem is knowing which subtree. That might extractable from the
name, but I don't know enough of the details to make a sound judgment
about that.
Hope it helps
Dirk
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
