Questions: By computational meshes, do you mean that objects in the scene
(maps, charts, visual representations) are calculated by a function or
functions, then output to the screen? What I am imagining here is an
algorithmic method of representing an object? Open Inventor supports nurbs,
would this work (so should nurbs be an optionally supported data
structure in VRML)? Could this be an animation node or some of the more
advanced nodes in Open Inventor? I see your point: 125,000 polygon
meshes is a lot to process, but the coming 3D graphics boards for the PCs
(such as 3DLabs) promise 200,000-300,000 polygons per second (obviously load
and processing time would be important here). However, is a 125,000
polygon mesh worth displaying? A 800x600 screen has 480,000 pixels, so are
we talking 4 pixels per polygon on average? Finally, is Open Inventor (the
program) just plain slow? Some of the real-time 3D APIs on the PC such
as Argonaut, Renderware, and Rendermorphics seem pretty fast to me, and could
handle shading well on a PC.
On Thu, 1 Dec 1994, Scott Nelson wrote:
> We would appreciate feedback on the following info. We are
> attempting to merge the new VRML spec into our existing
> PACT data system which is used for scientific data and
> 3D computational meshes (finite element, finite difference
> sorts of meshes).
>
> One thing that PACT lacks is the ability to describe solids.
> This is where VRML comes in to play. As an example, we
> constructed a VRML (actually an OpenInventor) file consisting
> of 120,000 mesh elements to get an idea of how quickly something
> like ivview could deal with it. Needless to say, it was VERY
> slow. This is why we would like to put VRML into PACT since
> PACT handles large meshes, vector fields, surfaces, etc. very
> well and there are numerous cross platform viewers available
> for the existing standard.
>
> The advantage that mesh viewers typically have is that they know
> that they are looking at a mesh. Thus, instead of displaying
> all 125,000 elements, they only worry about the small number of
> visible surfaces (meshes typically don't have things like transparency
> although we would like it).
>
> PACT (actually the PDB data subset) is freely available from the
> Lawrence Livermore National Laboratory at:
>
> phoenix.ocf.llnl.gov
>
> and is used in many projects, including the National Grid Project.
> The point that is missing is the ability to display the pre-
> meshed objects with the mesh (to see how well the mesher actually
> did). PACT also supports large quantities of data efficiently, for
> example:
>
> using ivview and a VRML file (actually OpenInventor) took about
> 3 minutes to display the 50x50x50 data set. Typical mesh tools
> do the same in seconds because they know more about the data.
>
> Thus although VRML is great for small virtual reality scenes, to display
> scientific 3D data sets along with data is cumbersum. What we would
> need to add to VRML is time sequencing (animation) so that the
> scene changes (based on the position of some slider which maps to
> a linear indexer). Perhaps this is what CVML promises??? Remember,
> out solids and meshs have to 'move' at the same rate (weather simulations,
> DYNA3D simulations of cars crashing into telephone poles, etc).
>
> Our final motivation is cross platform usability (UNIX, PC, MAC) in that
> everyone should be able to see basically the same scene but the
> UNIX versions would be shaded, the PC and MAC versions would be wire
> grids, etc. This is another 'benifit' of PACT, you can cheeply lump all
> of the descriptors into the file and let the user determine what level
> of detail to show. The alternative is to let the viewer extract a simplier
> level of detail from the data, which might be OK on a speedy system.
>
> Does anyone have an feedback on the above. We are hoping that someone
> more familiar with large solids data sets is already looking into this.
> Our main experience is in meshes (regular and non-regular), vector fields,
> molecular data, etc. Otherwise, we'll task ourselves to do it...
>
> Any info is greatly appreciated.
>
> Scott Nelson
>
> --
>
> +---------------------------------------------------------+
> |Scott D. Nelson B131 Rm2074 email:nelson18@llnl.gov |
> |Lawrence Livermore National Laboratory |
> |7000 East Ave., L-153 |
> |Livermore CA 94550 |
> +---------------------------------------------------------+
>
>