Re: windows / NURBS

New Message Reply Date view Thread view Subject view Author view

Jim Helman (jimh++at++surreal)
Tue, 07 Jun 94 12:57:18 -0700


   
> a) The ability to open/destroy windows arbitrarily at runtime?

This is complicated when multiprocessed because it requires creating
and destroying multiple processes and the associated software
pipeline. It's not on the list now. If and when depends on demand.
Is this important to people?

> b) NURBS

NURBS aren't usually regarded as useful for maximum performance
rendering.

There are two sides to NURBS: tessellation and evaluation. In
OpenGL, the GLU library does the tessellation on the host CPU and
then calls OpenGL gfx commands to have the graphics hardware
evaluate them. Because the tessellation is very CPU intensive, the
gfx pipe is left idle during this computation and that means NURBS
cannot come close to peak gfx performance. The high-performance
path to NURBS rendering would have one or more processes, doing the
tessellation and sending the rendering process functions and points
for evaluation.

As for NURBS and Performer, if you have your own tessellation code,
you could either tessellate at load-time or do it at run-time using
user data and callbacks in the scene graph. In either case, the
DRAW process could just send down points for evaluation. If anyone
has an interest in this, I'd like to hear why NURBS are important
to you in real-time rendering.

rgds,

-jim helman

jimh++at++surreal.asd.sgi.com
415/390-1151


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:19 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.