swarm-support
[Top][All Lists]
Advanced

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

Re: Swarm and OpenGL & Re: help us design nonprofit org funding mechani


From: Scott Christley
Subject: Re: Swarm and OpenGL & Re: help us design nonprofit org funding mechanisms
Date: Sat, 29 Mar 1997 13:58:31 -0800

At 01:40 PM 3/29/97 -0700, glen e. p. ropella wrote:

>I would suspect that we'd want to use as much as possible.
>Of course, since Patrick has already started on the 3D stuff,
>alot depends on what he contributes back.  The answer I'm hoping
>from you is "as much as you want."  Can we link directly to your
>3d library and just call functions?  Or do we have to have GNUStep
>running underneath?

Well the problem with 3D object hierarchies just like GUI hierarchies is
that once you pick one then you cannot easily change to another.

And yes you would need some sort of OpenStep implementation running
underneath but not necessarily GNUstep.

The idea behind my 3D hierarchy (though its not complete) is to allow
different rendering backends to be plugged in.  So you work at the object
level, build up primitive types, scene graphs, etc then pick a rendering
engine.  There are three "levels" that I want to support: high-end,
middle-end, and real-time.  High-end would be something that could generate
photo-realistic images.  Middle-end is a trade-off between looks and
efficiency, something that would be good for interactive modelling or demos;
we support this middle-end by using OpenGL.  Real-time where essentially we
have a DOOM like engine where we toss away looks for as much speed as possible.

Allowing such capability is not easy because each rendering engine has its
own API which has to be dealt with, so I want to take the approach where we
use the RenderMan interface, and that is translated, emulated, or ignored!
by the real rendering engine.  For example the real-time engine may toss
lighting and shading functions and do its own thing.  It would not be a
requirement that the underlying engine implement all of RenderMan, just that
there is good documentation so designers know the trade-offs.

Now it maybe that if we create this RenderMan to rendering engine functional
layer that Swarm could use that to take advantage of different rendering
engine, but not utilze the object hierarchy above it.  But personally, there
is such a close connection between the simulation model and the scene graph
that it seems wasteful not to make this part of the complete model.

Scott

ps: I should point that a good simulation engine with 3D capabilities
becomes a serious contender in the vworlds arena.  I'm on a vworlds business
mailing list and most of these "executive types" are clueless about the
proper way to tackle VR (not that I'm great or that there aren't people who
know alot, but some of the comments...)  They tend to think its all an issue
of textures, bitmaps, and as much network bandwidth as you can squeeze.
They miss the more important areas of simulation and algorithmic modelling.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]