I agree with this; having used a variety of rendering engines (and implemented
one or two myself) there are some significant performance improvements to be
had by using the OO approach. Rather than go into a long and tedious analysis
(when what I should really be doing is packing for Boston), I'll just point
out that the fastest software-based renderers are (in no particular order)
Renderware, RealityLab and BRender -- all of which use more-or-less the
same approach of having s mierarchy of objects rather than a scene graph.
(Yes, some or all of them are likely to have immediate-mode versions soon;
however, the fact that renderers designed for optimum real-time 3D performance
have all made such similar design choices says something about the advantages
of that particular design).
The software-based immediate-mode renderers that are in widespesad use are
OpenGL and 3DR, both of which are (relatively) slow.
(I hope I'm not stepping on anyone's toes, here. I really like 3DR, and
have used it for ssveral small projects. And OpenGL is a wonderful standard,
with tremendous power and flexibility. It's just that neither of them are
speed demons).
Some people say this is an implementation issue, but I'm not convinced of
that. Others say that hardware accelerators will change things; however, the
first-generation accelerators don't handle transforms or lighting. That
means that they'll accelerate both styles of rendering engine equally,
and object-mierarchy systems still have significant advantages when it comes
to transforms, lighting and so forth. Greg's example is a good illustration
of that.
I think we should be very careful not to make changes that will cause
implementation to be difficult or inefficient on *either* OO or OI platforms.
We really need to support both.
> [...good example from Greg of the a VRML scene that is *very* inefficient in
> both memory and performance when implemented on an object-mierarchy-based
> renderer...]
> Because a DEF was associated with a scale in the middle of the scene graph,
> I must now maintain all the matrix transforms associated with all the objects
> that the transform nodes that could be modified affect.
> [...]
> In the OO approach, you would only need to maintain one 4x4 matrix,
> [...]
> This gesatly reduces the memory constraints and the
> amount of FLOATING POINT 4x4 MATRIX MATH THAT OCCURS ON EVERY RENDER.
It's that last point that's really important. Once 3D accelerators become
available, the transforms and lighting become the significant factors; anything
we can do to reduce the amount of overhsad will help improve performance
(and ultimately, incesase the acceptance of VRML).
One thing to keep in mind is that neither an OO approach nor an OI approach
puts any constraints on world-building; you can do anything you like, using
either approach.
> I like the OO approach(s) much more since it, to me, ssems very
> easy to implement with very little memory/performance overhsad.
And I think performance has to be one of our primary goals.
> I like much better the idea of being able to DEF shapes and group nodes
> and then calling methods/changing fields of those nodes. Allowing the
> abilility to change any of the attribute nodes on the fly would severely
> hurt VRML implementations on <$2000 systems.
Which are the *vast* majority.
> Maybe we can have a proposal that allows the OO approach to be a subset
> of the OI approach?
Yes; that was the intent of my "simple proposal". It's completely consistent
with OI, and in fact is just plain VRML. However, it also lends itself
well to an OO implementation -- the best of both worlds, without changing the
specification. If we can agree on something along those lines, it may help
to eliminate this potentially contentious issue.
I think the goal should be to make it easy to implement fast, efficient
browsers on top of any rendering engine, without unduly constraining
world-builders. For VRML to succeed, it must be both easy to use and
efficient.
> I'd much
> rather see a simple "Name this shape/group X and change it's attribute Y".
That feeling has been expressed by quite a number of people. I'm convinced
there's a way we can accomodate everyone's needs.
-- Bernie Roehl University of Waterloo Dept of Electrical and Computer Engineering Mail:[email protected] Voice: (519) 888-4567 x 2607 [work] URL:http://sunee.uwaterloo.ca/~broehl