Hi,

Not quite. The VRML Loader uses MaterialGroups to simulate Shape nodes,
and has a Geometry below each of these. So for a flat VRML file you will
have one Group node at the top, which has a bunch of MaterialGroup
nodes, which have one Geometry each.

If you have a single node in your VRML file, you will get one Group with
one MaterialGroup and one Geometry.

Jeez, I forgot about that MaterialGroup in VRML... But basically the "problem" is the same, isn't it?

Thus, I suppose if the scene is rendered from viewpoints where only small fractions of one part (one node) are visible, any acceleration of the scenegraph-based view-frustum-culling will become rather small or will even slow things down.

Not sure what you mean here. Actually these are the situations where the
vf culling really helps, because only a small part of the graph is
rendered.

If you have a single node in your file you're right, vf culling works on
a node level and thus can't do anything.

Yeah, that's what I originally meant...Take for instance a door's car modeled as a bunch of triangles which build up one node only. If the camera sees only a few triangles, let's say from the upper corner of the door, the whole door will be rendered.

You can use the SplitGraphOp, that subdivides all Geometry nodes that
have more than a threshold number of triangles. The break-even point
depends on your system and the model, as a (very rough) rule of thumb
I'd try between 1k and 10k triangles per node (don't forget to run a
StripeGraphOp afterwards).

Okay, thanks for the hint; I'll take a look at that...

Note that this actually changes the graph. There is no way to do this
hidden from the user.
That won't be that much of a problem because once the graph is restructured/split, all further computation might benefit from the finer-grained graph, too. And for the beginning the main user will be me anyway in my case...;)

The OpenGL community has (finally!) come up with a useful proposal for
rendering to texture, see www.opengl.org "Request For Comment:
EXT_render_target proposal". Once this proposal is finalized and
implemented, this will make sense.

Hmm, seems like this might take a while... So it won't work for me...:(

Currently there is no good way yet. I have just gotten some code that
uses Pbuffers, which AFAIK currently is a requirement for fp render
targets, but it's not integrated yet.

The use of pbuffers is what I have heard of before, too. I assume this will be the "best" way to get things done right now...



Thanks a lot,
Matthias




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to