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/
