I also feel like this is one of the more confusing aspects of OSG and
I've tried to wrap my brain around it occasionally for a few years. I
get it and then promptly forget again.
Anyway, I believe (and please only attribute as much weight as _that_
deserves) that the reason strings are used is because it makes it easier
for users to define their own render bin types without collisions. Any
sort of enum system would cause issues if two add-ons happened to use
the same underlying "int", for example. Whereas, "MyEffect1" and
"YourEffect1" wouldn't. To me the problem would seem to be "how to
define a render bin type ID that doesn't easily conflict with others
while also being easy to write out to a .osg file."
Also, I believe there is more to a render bin than just the sort order.
It's just that the two default render bins happen to be named for
their sort behavior because that is their purpose. I sort of vaguely
recall that one could specify z-buffer write modes, background fill,
etc... but this may all have moved in a different direction with the
recent camera stuff.
Perhaps sorting and render order is all that is left but I have my doubts.
-Paul
Paul Martz wrote:
The present situation is too confusing for me to even hazard a suggestion
for improvement. I agree with Robert, though, this could use a revamp.
Seems to me there should be a bin number, and a sort mode for each bin. (If
two bins have the same number, the draw order would be undefined.) Not sure
anything else is needed, though I imagine RTT complicates things somewhat.
-Paul
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Terry Welsh
Sent: Thursday, March 08, 2007 3:04 PM
To: [email protected]
Subject: Re: [osg-users] render bin numbers and names
Well, it's easy enough to replace the hardcoded values in
StateSet.cpp with these:
enum RenderBinNumber{
STANDARD_OPAQUE_BIN = 0,
STANDARD_TRANSPARENT_BIN = 10
}
I'm not sure if anything can or should be done about bin
names since I don't understand all their uses well enough.
For example, what happens if you have one node in bin 5 with
name "RenderBin" and another node in bin 5 with name "DepthSortedBin"?
I also don't understand why there need to be string
comparisons in the code when we could just use int
comparisons. Could the SortMode enum values in RenderBin
replace all bin name std::strings? This would probably mean
phasing out bin names by overriding functions like
setRenderBinDetails with a new function that takes two ints
instead of an int and a std::string.
Any other ideas about this anyone?
- Terry
On 3/8/07, Ulrich Hertlein <[EMAIL PROTECTED]> wrote:
Farshid Lashkari wrote:
10. Should these be #defined or enumed in some header file so
that more complicated bin arrangements can be future-proof and
easier to design just by looking at the headers?
This is a good idea. You should probably add these
definitions in
the header file for StateSet.
...
The bin name specifies what type of bin to put it in.
For example,
the default "RenderBin" uses state sorting to render drawables
with the same bin number. The "DepthSortedBin" sorts
drawables by their depth.
On the same note wouldn't it make sense to also add #defines for
these two names? Like STATE_SORTED_BIN and DEPTH_SORTED_BIN?
This whole area could do with a revamp, but we can probably do
something modest to help in the this case. #define's won't cut it
though as this is compile time, and what Terry is after is
ability to
define the bin number at runtime.
The runtime setting is actually already fully support, just not via
the convenience functions for OPAQUE and TRANSPARENT_BIN hints.
Perhaps a global variable and methods for setting the value of bin
would be sufficient. Perhaps one could just set the bin number
directly via the prototype in osgUtil.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
