Re: [Plib-devel] ssg Leaf call backs

[Curtis L. O. <cu...@me...>]

Steve Baker writes:
> Many, many moons ago, you asked me if I thought putting the sky into
> SSG was a good idea - and I said then that you'd probably be better
> off to do it in OpenGL because it needs some rather wierd tricks.
> 
> My Simulator visual system that I work on in my 'paying job' does
> the sky in OpenGL - simply because Performer can't hack doing things
> in fixed orders.

Yup, I remember that but let me present an opposing view point.

For someone like you with immense OpenGL experience what you suggest
is a viable option and probably the best choice for maximizing
performance and quality.  If, in the process, you'd accidentally get
your opengl state out of whack, you have enough experience to look at
the result and [hopefully] immediately determine what you screwed up.
Then it would be a pretty easy fix for you.

Then there is the rest of us, many of which are just starting out with
opengl, or don't have a deep level of understanding of opengl
textures, blending, alpha_test, colors, lighting, fogging, what
activates them, why they work, what they look like when something is
messed up, etc.

My little excercise of building the sky in ssg has forced me into
understanding a lot of these things at a much deeper level which is
good for me, but I'm by no means and expert.  [yet] :-)

However, the average person just starting out with opengl games, sims,
visualization, likely wouldn't understand all the underlying nuances
of one or more of the states and blend functions I use to create the
sky.  Providing the sky in raw, hand crafted opengl might yield
extremely strange results for them if they blindly plug it in and the
sky finishes and leaves things in some weird state.

By building the sky in ssg, developers that are newer to opengl would
have a much better chance at dropping it into their scene graph and
having it just work.

> Anyway, perhaps what we need to look at here is the possibility of
> adding some kind of ssgNoSortBranch node type that promises to
> draw things in a specific order...I don't really like that because
> it implies considerable nastiness when I *DO* get around to doing
> material sorting.

Yes ... this seems like a less generalize solution.

> The 'official' way to do this stuff in SGI's Performer scene graph
> API is to allow the user to define their own sorting 'buckets'
> analogous to SSG's "opaque" and "translucent" buckets.  You can then
> tell Performer what order to render the buckets.  Material sorting
> then happens only within one bucket.

Yes ... that's essentially option (3) in my previous message, except
attaching the hint to the state which makes a lot more sense now that
I think about it. :-)

> In that way, you could put the first pass of the sky in bucket
> zero, the second pass into bucket one, the rest of the scene
> into bucket two except for the translucent polygons in bucket
> three.

This imposes additional work on the application writer, but it's all
fairly straight forward and could be explained in the sky
documentation.

> That might get a tad complex and would have to be rewritten
> when I get around to doing material sorting anyway.  Once
> we have material sorting, the simplest fix will be to simply
> tell SSG which order the materials are to be rendered in - then
> you could pick special materials for the sky and tell them to
> render first - in whichever order you need.

This sounds like a pretty good long term solution.

> So...what should be done right now?
> 
> Nothing.  At present, child nodes are rendered in order except
> where there are translucent ssgLeaf nodes.

Yes, things can be made to work right now.

> Hence, right now you can get away with it - and I'll promise to
> provide an 'ssgState::renderPriority()' call in the future
> when material sorting gets implemented.
> 
> Another possibility would be to put each phase of the sky rendering
> into a separate ssgScene and just call ssgCullAndDraw for each one
> in turn.
> 
> Ugly - but do-able right now and not likely to break in the future.

And you pay a slight penalty in additional unneeded state changes
since you call state->force() at the start of each ssgCullAndDraw().

> > 1) Perhaps a branch could have a marker that says below this point
> > process things in exact order.
> 
> I don't like that.

Agreed, but I was just brain storming ...

> > 2) Perhaps the sky could be implimented as a separate ssg scene graph
> > that is marked as do not sort anything in this scene graph.
> 
> Same problem...unless each phase is a separate scene graph (as I suggested
> earlier).

Yup ...

> > 3) Perhaps we could assign sorting hints to each leaf node (such as an
> > integer value).  ssg could sort by this hint first, and then do
> > whatever it wanted to do for all the nodes with the same sorting hint.
> 
> Well, not on each leaf node - but perhaps on each ssgState.

Yes, good point ... attach the hint/bucket to each ssgState.

> > It would be great if ssg could handle a few more state types.  The
> > primary things I am interested in now are:
> > 
> > GL_DEPTH_TEST
> > GL_FOG
> > glBlendFunc( SRC, DEST )
> 
> Yep.  I'll look at doing this.  It shouldn't be too tricky.

Great, thanks!

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org