Data model for reX-NG viewer
Ryan McDougall
internal data model for the viewer. Something where we could place our
knowledge about the world in a central place where various modules
could access it asynchronously. The Intel Smoke demo validated this
ideas somewhat by providing a publish/subscribe interface for sharing
tree data across threads.
However one of our programmers took me to task for misusing the term
"Scene Graph", which is technically a scene in final form meant for
the consumption of the render and no one else. I think this article
echos his concern:
http://home.comcast.net/~tom_forsyth/blog.wiki.html#[[Scene%20Graphs%20-%20just%20say%20no]]
The Smoke demo, I think, understands this concern somewhat, by
assuming each module will produce its own "scene", and the major
purpose of the model is not to define "one graph to rule them all",
but rather to provide a means of notifying subsystems when something
subscribed changes.
The article here http://www.beyond3d.com/content/articles/102 proposes
the use of 3 different graph structures, one for rendering, culling,
and animations. Perhaps we ourselves can find more possible data
structures.
I think it might make sense to have each module define for itself what
data it is interested in both consuming and producing, and only using
our framework for publishing/subscribing to interested models. Trying
to make an uberscene seems foolhardy.
Ideas or complaints?
Cheers,
Toni Alatalo
> I had previously mentioned my idea of a "universal scenegraph" for an
> internal data model for the viewer. Something where we could place our
> knowledge about the world in a central place where various modules
> could access it asynchronously. The Intel Smoke demo validated this
> ideas somewhat by providing a publish/subscribe interface for sharing
> tree data across threads.
>
'somewhat' indeed, referring to the clarification you wrote in what
followed.
that idea is also present in openviewer, where the World class is an
abstract model of the, well, world - all objects and their positions,
avatars etc. there we may be also seeing one pitfall of that approach,
as there is a lot of conversion going on - Dan was supposing that being
the performance bottleneck there even when loading actual scenes IIRC.
we haven't done any performance testing (yet) when looking at existing
viewers and OTOH GE architectures like the Smoke thing.
instead of converting everything to an abstract model, the Idealist
viewer just uses the Irrlicht (for scenenodes) data and LibOMV types
(for primitive data) directly.
on irc (#realxtend) there was some talk with Dan about possibly keeping
the data in the native format of an underlying library (e.g. Ogre), but
exposing it via a common interface for other components. there of course
the question would come: who owns what? (e.g. the 3d position of an
object). in the current open viewers we've looked at there is the
network lib and the local graphics engine both having it of course.
> The Smoke demo, I think, understands this concern somewhat, by
> assuming each module will produce its own "scene", and the major
> purpose of the model is not to define "one graph to rule them all",
> but rather to provide a means of notifying subsystems when something
> subscribed changes.
>
yep it has the notion of UniversalScene but components are free to do
whatever in their internal representations.
e.g. the AI system just keeps a kind of an 'influence map', of where
there is fire, so that the animals can avoid it. it does not need to
know all positions of all kinds of objects nor all the geometry. (i
didn't read how it does pathfinding but should be easy enough).
> The article here http://www.beyond3d.com/content/articles/102 proposes
> the use of 3 different graph structures, one for rendering, culling,
> and animations. Perhaps we ourselves can find more possible data
> structures.
>
interesting, will read.
AI code commonly has special data structures, but that is not a question
for the viewer really i suppose as bots etc. are probably more run on
the servers.
physics libs also have their own kind of geometry representations.
will be interesting to read how they talk about animation there.
> I think it might make sense to have each module define for itself what
> data it is interested in both consuming and producing, and only using
> our framework for publishing/subscribing to interested models. Trying
> to make an uberscene seems foolhardy.
>
publish-subscribe has seemed like a promising model, and has been
evangelized by some clever folks too. it felt like the only kind of nice
part of J2EE (as JMS), and a friend has been happy using his own
publish-subscribe system called Glassboard (a pure py thing, uses
pickles in a trusted env., very efficient for integrating e.g. his code
editor and a simulation running in Blender).
certainly something to consider, i'd say. and at least for me there's
still stuff to read in the Smoke demo, still don't know how exactly it
deals with geometry information.
> Cheers,
>
~Toni