Re: [Plib-devel] ssg Leaf call backs

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

> "Curtis L. Olson" wrote:
> > It would be convenient to be able to attach pre/post draw call backs
> > to branch nodes as well as leaf nodes.  ssg allows me to do this now,
> > but it never calls the functions attached to branches, only leaf
> > nodes.

Steve Baker writes:
> The trouble is that leaf nodes are not rendered in order - even though
> I don't (yet) sort by material property, I do render translucent leaf
> nodes after all the opaque nodes.
> 
> Hence, if a branch node were to contain both translucent and opaque
> leaves, there would be no good time to call the callbacks.
> 
> In future (when I get around to some material sorting), this would be
> an even bigger problem.

Hmmm ... my sky implimentation depends on certain parts of it being
drawn in a particular order.  I might be able to fudge a few things,
but I'm not sure if that would always work.

It's nice to be able to turn off depth testing and draw the dome first
as sort of a clear screen operation.  The sun halo needs to get drawn
before the sun or it could end up overdrawing it.  It would be nice to
draw the planets and stars after the moon is drawn so that we don't
have to see stars showing through the dark side or the shadows of the
moon.  The sky will likely be drawn out towards the far clip plane
where the z buffer typically gets very inaccurate, so it's nice to be
able to depend on drawing order and not the z-buffer.

1) Perhaps a branch could have a marker that says below this point
process things in exact order.

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.  This
would be one way to ensure that the sky would be drawn before anything
else ... at the expense of a few extra state changes (negligable?)
because of state->force() which is called at the start of each
ssgCullAndRender().

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.

4) Or, perhaps you could suggest ways to make sure the sky gets drawn
properly in the face of arbitrary reordering.

I can see problems with (1).  A global sort/do-not-sort flag on each
scene graph (2) would probably be the quickest easiest solution and
has minimal impact on existing users.  (3) would probably be the most
generalized solution, but could also add a lot of complexity to ssg's
internals.  (4) would involve extra work on my part so that's
definitely a last resort. :-)

> It *definitely* doesn't work - even now - because of the
> transparency thing - and even if you are getting away with it right
> now, I can promise to break your code sometime in the future.

Yes, that is why I'm not marking my transparent sky bits as
setTransparent() because it fouls up the sort order

> > Or we could be wasteful and attach the callback to every leaf node in
> > a sub tree, but I'd rather not do that either, but it would be the
> > safest I suppose.
> 
> Yep.  I guess that's what you need to do.  :-(

It's tempting to write a lazy state manager for all the states I need
to use that ssg doesn't exert influence over.  But that would be
really ugly (tm).

> ...or call the per-branch callbacks multiple times - once for each batch
> of its child nodes.  That would be pretty ugly to implement.
>  
> > Right now the things I'm interested in doing with callbacks is to set
> > blend modes and depth testing.  In some cases here it's just fine to
> > set these on a per leaf basis, but in other cases it would be nice to
> > be able to set these on a per-subtree basis.
> 
> Sounds like I need to dump those things into ssgState so that they can
> be done without callbacks.

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 )

Between this, and providing a way to guarantee drawing order, my sky
will be in good shape.

Regards,

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