John W. Barrus wrote:
> It was very difficult to write enough detail about such a large system in
> the space allotted to the articles. If you have specific questions, please
> ask me and if I can't answer them myself, I will pass them on to the
> appropriate person here at MERL.
Agreed. I think everyone who has seen the article was very favorably impressed;
no knocks intended by my post and I really hope none taken !! Plus, as you
mention, you had a lot of stuff to cover as the scope of the work was huge. I
was very impressed.
> Rendering is always done locally and in this case only on SGI machines.
> The geometry database starts out undistributed and is distributed as needed
> as objects are put into the scene.
Anim looks very interesting; for me at least distribution of rendering databases
is very interesting; I'd like to see more details/pointers to it posted (or, if
anyone has pointers on other work on distributing rendering dbs, those would be
much appreciated !). I'm not familiar with it, I'll ask a few questions to be
routed appropriatly ...
Does each machine have a seperate copy of the database (thus the data is
replicated on each machine), or is there one distributed database which is
shared across the machines, with each machine implementing some protocol which
allows it to serve up the parts of the db it owns to the others, and access the
parts which are distributed on the other machines ?? (and there is thus no real
data replication).
It strikes me that the replicated solution is more suited to getting better
frame rates on complex dbs across a laggy network with lots of users because
when you render, you render from a local db and don't have to ask remote dbs for
info, but that the non-replicated solution is much easier to implement ... in
particular, you don't have to worry about implementing crazy synch-lock stuff to
ensure that time-sequence-important world-db modifications are kept in step with
each other ... so users see the same thing happening and interactivity in
particular would seem to proceed in a simpler manner. The main problem I see
with the non-replicated solution is that it won't scale, because the more
machines which are rendering from the db, the more messages fly about, etc, etc.
Is this why the system described suffered from scalability problems possibly ??
I have been wondering how much of "not seeing the same thing" (or rather. not
seeing the same thing at the same time -- more accurate) is acceptable. This is
in some sences a **really** dumb question, but one with a lot of relevance once
you start thinking about how to deal with synching replicated rendering
databases over a laggy net; and scalability while preserving interaction. It
goes to the heart of the problems of replicating and synching world-dbs over a
number of machines, and how this relates to interactivity. Or lack of it .. etc.
Did whatever scheme anim implemented for distribution of the rendering db
provide reasonable performance for the "new" version; or have you replaced it
with another rendering database distribution scheme ? If so, could you detail
what you are doing in this respect .. ? And any opinions you/the MERL group in
general have in this regard .. ?
> We are close to completing the follow-on work which we would like to talk
> about in much more detail in a month or so.
Can't wait. Keep up the excellant work !!
> Feel free to continue to ask questions.
Many Thanks !
-- Mike