[xinf] Xinfinity scenegraph

[Daniel Cassidy]

On 12/22/06, daniel fischer <dan at f3c.com> wrote:
> thanks for your thinking. From reading (superficially) over your description, i
> cannot quite see the difference to what i do now,

Well, it's not supposed to be dramatically different; quite the
opposite. I just want to check that nobody sees anything in my
fundamental assumptions that is going to close doors for us.

What *is* dramatically different is that I'd like to see this stuff
implemented in the player itself, in C, for speed, and xinfony's high
level API more or less directly wrapping to a fairly-high level
representation in the player.

However, for some reason some of the rationale for the seperation of
xinfony/xinferno/xinfinity is only just starting to defuzz in my
brain, and I suspect that you will feel I've just uttered the most
utterly daft thing you've ever heard :).

(Oh, I'm probably confusing things by talking about 'classes'. For
some problems talking in terms of classes and objects makes sense to
me even when the target language is C. The implementation does then
tend to look distinctly OOP-style as a result.)

> except the idea of a "Canvas" (that corresponds to what flash calls
> "cacheAsBitmap", no?),

Not really, because the aim isn't caching but to abstract away the
fairly common case of rendering to a buffer. Like all Planes, the
Canvas can be included directly within a scenegraph in which case it
has the effect of 'flattening' its contents; alternatively it can be
used for (dynamic) texture mapping.

> the use of the z-axis for drawing order (had that in mind but it didnt become
> neccessary yet).

The rationale for doing it this way is that a 2D-only implementation
(e.g. for PDAs or OLPC) becomes identical to the 3D implementation
except for disallowing certain operations.

That said, if you're only doing 2D, using the z-axis for drawing order
is a bit limiting compared to Flash's implementation, because the
z-axis exists per rendering context, whereas Flash's z-order exists
per movie clip. I confess I'm not 100% happy about that.

> I'm currently using display lists intensely to avoid having to redraw the
> complete scene from the CPU for each frame. Actually, since 0.0.1, every
> "Object" (Scene, in your terminology?) occupies two display lists- a wrapping
> one, and one for the transformation- so the transformation can be
> manipulated independently.

My inclination is to do something almost exactly like this. Each Scene
will have references to two display lists; one for the transformation
and one for the scene itself. If a display list becomes invalid, its
reference gets set to null. Then, on the next frame, any null display
lists are reconstructed. Each display list is thus reconstructed at
most once per frame.

That said, is there actually any real advantage in storing the
transformation in a display list? Being only one matrix
multiplication, involving a matrix which is likely to change quite
frequently, I fear it might actually slow things down...

> My use of display lists has the advantage that i can redraw individual
> elements of the graph without even touching the others. Adding/Removing a
> child to/from a group is simply redefining the group. This is mostly what the
> xinferno "protocol" (the Renderer interface) is modelled after with its
> startObject/endObject/showObject parts.

I'm not sure what you mean here? This should be possible with any
representation of the scenegraph?

> Another issue i can think of for a good scenegraph is backface culling (is that
> what it's called- removing invisible surfaces at the back of objects?), and likely
> likely quite some other issues.

Backface culling sounds about right to me. These sorts of topics are
in the 'not absolutely essential in an initial implementation' folder
for now, though I do want to make sure I don't make them impossible to
implement through poor design :).

> So much for my first thoughts. I think your use of the term "Scene" might be
> a bit misleading, i'd expect a Scene to be a complete, well, scene. An
> individual Node should be called "Node"?

Think tree structures. The root node of a tree is conceptually both
the whole tree and just a single node; therefore it makes sense to
name that type 'Tree'. If you cut off one branch of the tree, what you
have is still a Tree, so it make sense to call that a Tree too.

But yes, it is a bit confusing. I am *extremely* fussy about
classnames, and troublesome classes tend to get renamed five or six
times before I'm completely happy. Scene has already been renamed
twice, and it'll probably be renamed again :). I'm not happy with
'Object', 'SceneObject', 'Node' or 'SceneNode', though.

> Please go on thinking, i might well be trapped in some philosophy that doesnt
> make so much sense at all :)

It actually probably makes more sense than me. I don't pretend to be
an expert on 3D graphics, but I don't see that as a big problem. A
month ago, I wasn't an expert on XPath, and a few months before that I
hadn't written a line of ActionScript in my life :).

> Oh, but just one more (maybe obvious) advantage of my displaylist idea
> (ignoring the mentioned problems): object reuse. even complex objects can be
> cloned (attached to a different parent, thus with a completely different
> transformation) virtually without CPU cost.

Here be dragons if you implement containers as display lists that call
other display lists...

Regards,
Dan C