Re: [Plib-devel] ssg Leaf call backs

[Steve B. <sjb...@ai...>]

"Curtis L. Olson" wrote:

> 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.

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.

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.

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.

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.

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.

So...what should be done right now?

Nothing.  At present, child nodes are rendered in order except
where there are translucent ssgLeaf nodes.

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.

> 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.

Yep.

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.

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

I don't like that.
 
> 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).

> 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.
 
> > 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

That's certainly OK for now.  The setTransparent flag is only used
for sorting.

> 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.
 
> Between this, and providing a way to guarantee drawing order, my sky
> will be in good shape.

OK.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)