🚀 go-pugleaf

In article <1993Jan21.052834.29868@cc.gatech.edu>, zundel@cc.gatech.edu (Eric Zundel Ayers) writes:
|> 
|> 1) In a scene with  160 spheres, rendering takes from 3 - 9 seconds,
|>    and rotations in the renderer take between 5 and 10 seconds. 
|>    This is on the edge of what we have defined as "interactability"
|> 
|> 2) In a scene with 1200 spheres (which is not uncommon in the kind of 
|>    data we are working with right now) Times increase to well over a
|>    minute to render but still around 10 seconds to rotate.  
|> 
|> 3) In a scene with 2500 spheres, the renderer has lots of problems,
|>    with rendering time increasing exponentially for each attempt to
|>    render the same scene.(first 2 minutes, then 4 minutes, then 8 minutes...) 

Spheres take a long time to draw, regardless. If you want interactivity
in rotating 2000 spheres, you're going to need a graphics controller with
hardware for fast sphere rendering. 

Does SGI have anything like this? In the Reality Engine or something? I'm
not intimate with the different levels of graphics boards on SGI just yet.

The only system I've used that actually has this is a Stardent 750 with
G3 graphics board (hardware spheres, multipass transparency, and texture
mapping). The sphere hardware came from older Stellar workstations.

On my Stardent system, I can rotate a 2000-sphere molecule as if it was in
my hand.
-- 
----------------------------------------------------------------------
Scott Ferguson                        Exxon Research & Engineering Co.
Project Engineer                      New Jersey
----------------------------------------------------------------------
"When I was your age son, dogs didn't even have the right to vote!"
(J. Seinfeld)

In article <1993Jan21.052834.29868@cc.gatech.edu> zundel@cc.gatech.edu (Eric Zundel Ayers) writes:
>Is it possible that the renderer module for Explorer 2.0 will be 
>substantially quicker than the current version?   Is it possible that there is a quicker renderer with less features
>available (or could one be made available?)

Geometry transmission time from one module to another has been one focus of
the 2.0 effort.  Performance has been improved in this area.  Actual rendering
performance has also been improved for certain primitives and situations.
Another source of inefficiency is the amount of memory that the Render module
chews up; this has also been addressed.

>The pick-box is nice,
>but we'd like to get information about the original geometry from the
>renderer, such as  "spheres 34, 35, and 36 are in the selection set"
>and then, say,  perform an operation that makes those spheres transparent.

The 2.0 beta contains a new picking scheme for Render that should provide
you with the information you want.  You can label objects in your module
and have those labels returned to you in the pick information.

Roy Hashimoto
hashimoto@sgi.com

In article <1jmom9INN7ld@fido.asd.sgi.com> hashimoto@sgi.com (Roy Hashimoto) writes:
>In article <1993Jan21.052834.29868@cc.gatech.edu> zundel@cc.gatech.edu (Eric Zundel Ayers) writes:
>>Is it possible that the renderer module for Explorer 2.0 will be 
>>substantially quicker than the current version? 
>
>Geometry transmission time from one module to another has been one focus of
>the 2.0 effort.  Performance has been improved in this area.  Actual rendering
>performance has also been improved for certain primitives and situations.
>Another source of inefficiency is the amount of memory that the Render module
>chews up; this has also been addressed.

I have just looked at a visualization done with AVS similar to some of the 
ones we have been working with Explorer.  AVS includes a slider to
control tessellation, and by adjusting this, we were able to watch
a molecule made up of around 200 spheres rotate nicely, with about
1/2 seconds between re-draws (Running on a DECstation 5000).  
Our visualizations haven't come close to that, using Explorer.
You would think that changing the complexity of spheres would make a 
drastic difference for transformations, but it doesn't seem to.  I added a 
dial on my module to change complexity, but I think it would be a handy 
addition (or at least as a decoration to) the the Renderer.

Of course, the AVS renderer is assuming that you want all of your
spheres to have the same complexity.  Although I haven't tried it myself, 
I suppose Explorer would allow many spheres with different levels 
of complexity which might come in handy to someone.

>>The pick-box is nice,
>>but we'd like to get information about the original geometry from the
>>renderer, such as  "spheres 34, 35, and 36 are in the selection set"
>>and then, say,  perform an operation that makes those spheres transparent.
>
>The 2.0 beta contains a new picking scheme for Render that should provide
>you with the information you want.  You can label objects in your module
>and have those labels returned to you in the pick information.
>
>Roy Hashimoto
>hashimoto@sgi.com

This sounds like just what we need, (if it doesn't cost us in performance!)

Someone suggested that we would need faster hardware for better
performance in rendering spheres.  Is the DEC station hardware
really faster than SGI hardware?

Thanks for the info!
Eric.
Eric Z. Ayers
zundel@cc.gatech.edu
Graphics, Visualization, and Usability Center (GVU)
Georgia Institute of Technology, Atlanta, GA 30213 USA