[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fwd: VRML Interactive Tutorial @ Lighthouse 3D]




[archiving to BMG list for posterity.]

-------- Original Message --------
From: Seth Teller <seth@graphics.lcs.mit.edu>
Subject: VRML Interactive Tutorial @ Lighthouse 3D
To: William Leiserson <wml@graphics.lcs.mit.edu>, Sean Markan
<markan@MIT.EDU>


will/sean,

this is a followup to a discussion will and i had
today about how to produce a single VRML/inventor
file with all contents of all campus buildings --
that's a lot of geometry! -- without choking the
viewer on a reasonable graphics machine.  we
discussed making the terrain and building exterior
geometry display unconditionally, while making the
building interior geometry display conditionally
upon the proximity of the observer.  imagine, say,
a sphere or bounding box around each building (ex-
panded by some margin, say 50 meters).  entrance
into this region could enable the aforementioned
geometry.

i think the proximity sensor in VRML does exactly
what we want:

<http://www.lighthouse3d.com/vrml/tutorial/index.shtml?proxi>

there may still be an expensive "parse time" if
the switch is traversed before it's triggered.
i recommend putting the "guts" of the building
in a separate file (or at a separate URL), and
putting the include file/include URL directive
entirely *inside* the scope of the proximity
sensor.

hopefully, that will mean that the loading of the
building interiors, and the attendant expensive I/O,
will happen only when the user enters the proximity
region.

it may be possible to do more sophisticated things,
if the VRML viewer (possibly) or inventor viewer
(unlikely) supports parallel threads.  for example,
imagine two proximity sensors around every building:
a large bbox triggers parsing and loading of the
building contents, without display.  this could be
a DEF of a unique name to the geometry.  a smaller
bbox could USE the (guaranteed to be defined) DEF.

this would prevent a nasty "hiccup" that would happen
if, upon crossing the threshold of the single proximity
bbox in the example given in the tutorial, all the
geometry implicated would have to be synchronously
loaded by the single VRML viewer thread.

anyway, lots of interesting challenges to think about.
as we make ug2iv smarter -- eventually adding the
ability to emit VRML as well as inventor -- let's
keep this in mind.

prof. t.