Hi Dirk,
thanks for the hints.
Today, i got cvs branch of opensg and rebuild all
(opt-version).
Than i inserted in the Turorial/10loading.cpp your
hints 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);
removed the NamedNodeFinder and tryed to load the
robot-scene.
But it isn't working on my computer
("Speicherzugriffsfehler").
system : Suse 9.1, 512 MB Ram, AMD XP 1700+
compiler: g++ 3.3.3
Is the RAM not sufficient? Should i used the
debug-version?
What can do to see this scene with opensg ? I need
this for collision-detection.
Thanks Tino
--- Dirk Reiners <[EMAIL PROTECTED]> schrieb:
>
> 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
>
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden:
http://mail.yahoo.de
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
