Hi Terry,
On Thu, 2005-04-21 at 14:36 -0500, Terry Welsh wrote:
> >From the tutorial and example programs, it appears there are two ways
> to assign materials in OpenSG: either assign them to each individual
> Geometry node or make a Node with a MaterialGroup core. Assigning
> materials to every Geometry node seems a bit cumbersome to me. I'm
> told the MaterialGroup core is dangerous because it overrides
> materials beneath it on the graph. Please correct me if any of this
> is wrong.
Nope, that's correct.
> When I speak of materials, I'm not just talking about traditional
> OpenGL material properties but also textures and shaders. I believe
> this is the same way OpenSG thinks about materials.
Yes and no. Currently almost everything is Chunk-based, which is very
close to OpenGL. But I don't think that's the best way to think about
it, I would like to see the Material as more of a black box (to abstract
away things like multi-pass, multi-stage, system-dependent stuff etc.).
> Anyway, I'm accustomed to the model used in other scenegraphs where
> you can assign individual material properties (not just complete
> materials) to any node,
Hm, which one might that be... ;)
> and those properties affect all nodes beneath
> them. So the material properties closest to the geometry leaf nodes
> are the ones used, unless some override method is in use. I always
> found this method of assigning materials very easy to use, so I was
> wondering if there is a similar method in OpenSG that I just don't
> know about or if there is a plan to make one.
There isn't one right now. I've been thinking about adding one, but I
haven't come up with a satisfying approach yet.
The obvious way would be to just have a set of active chunks during
traversal and add/subtract from the set when encountering either a Node
with Materials or a StateGroup (or whatever you want to call it). There
could be some performance issues with keeping track of all those groups,
but I guess with enough optimization that wouldn't be a big issue.
Sorting becomes more expensive as you can't use a single key any more,
but you could probably fix that by sorting only on a few critical Chunks
(GLScry is showing some interesting results for different state
changes), or using pipeline buffers for state change minimization.
What most people want this for is changing the rendering characteristics
of a part of the graph (doh!). But in general, especially if shaders are
involved, these changes cannot be mapped 1:1 to OpenSG state.
Transparency is the most common one, but with multiple passes wireframe
or color changes become interesting, too. As long as you're happy to
manage all the details yourself (which I know you probably are), you can
manage, but as a general solution for people who just want to have it I
don't see this as a good path.
My current idea is to have manipulators that can be put at certain nodes
that are collected during traversal and are available to the
shaders/materials to deal with. Implementation has not started on this,
though.
Dirk
--
-- Dirk Reiners OpenSG Forum [EMAIL PROTECTED]
-- The OpenSG Open Source Scenegraph: http://www.opensg.org
-- Join the list at http://lists.sf.net/lists/listinfo/opensg-users
-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
