From guest Tue Jun 7 06:47:57 1994 Date: Tue, 7 Jun 94 15:47:40 +0200 From: matomira@lig.di.epfl.ch (Fernando D. Mato Mira) Message-Id: <9406071347.AA01270@ligsg16.epfl.ch> To: info-performer@sgi.sgi.com Subject: windows / NURBS Reply-To: matomira@epfl.ch Status: O Hello, I have two questions. When are we getting: a) The ability to open/destroy windows arbitrarily at runtime? b) NURBS Thanks Fernando D. Mato Mira Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch From guest Tue Jun 7 12:57:27 1994 Message-Id: <9406071957.AA13960@surreal.asd.sgi.com> To: matomira@epfl.ch Cc: info-performer@sgi.sgi.com Subject: Re: windows / NURBS In-Reply-To: Your message of "Tue, 07 Jun 94 15:47:40 +0200." <9406071347.AA01270@ligsg16.epfl.ch> Date: Tue, 07 Jun 94 12:57:18 -0700 From: Jim Helman Status: OR > 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@surreal.asd.sgi.com 415/390-1151 From guest Tue Jun 7 13:31:53 1994 Message-Id: <9406072031.AA21080@sgi.sgi.com> From: Robert Rossow Subject: Nurbs... To: info-performer@sgi.sgi.com Date: Tue, 7 Jun 94 16:38:07 EDT Mailer: Elm [revision: 66.25] Status: OR I believe that the ability to use NURBS to define geometry within Performer would be extremely beneficial. I understand that these cannot be dynamically tesselated (to a particular view) because of the expense in CPU time. It would be quite helpful if instead the NURBS could be tesselated according to a user-specified chord-height tolerance during initialization; before the real-time simulation loop is entered. If this were the case, many more models would become available, and the user could be relieved of both the tesselation and texture/normal specifications on a per-vertex basis. Also, the levels of detail could be specified by adjusting the chord-height tolerance. Sounds too good to be true. What do you think? Robert Rossow rossow@gsc.gsi.com From guest Thu Jun 9 13:51:10 1994 From: hill_b@ameig1.navsea.navy.mil (Brian Hill) Message-Id: <199406092200.AA13153@ameig1.navsea.navy.mil> Subject: Re. NURBS too! To: info-performer@sgi.sgi.com (Performer list) Date: Thu, 9 Jun 94 17:00:45 CDT X-Mailer: ELM [version 07.00.00.00 (2.3 PL11)] Status: OR Robert Rossow wrote in a previous message related to NURBS > > I believe that the ability to use NURBS to define geometry within > Performer would be extremely beneficial...... > ... > ... > If this were the case, many more models would become available, > and the user could be relieved of both the tesselation and > texture/normal specifications on a per-vertex basis. > ... > Sounds too good to be true. What do you think? > As a related matter, almost all of my geometry originates as an engineering CAD model (ie NURBS) that has to be converted with a combination of automatic and manual techniques. There are times when I don't need to develop a pituresque model using exotic texturing and materials, I only need a functional rendering. It would be nice to be able to load the original IGES NURB data into Performer. How about an IGES loader for Performer????? Thanks, =================================================================== Brian Hill | Advanced Marine Enterprises, Inc.| CSD Section Chief | Suite 1300 | (703)415-3080 | 1725 Jefferson Davis Hwy. | hill_b@ameig1.navsea.navy.mil | Arlington VA, 22202 | =================================================================== From guest Thu Jun 9 17:21:15 1994 id AA29386; Thu, 9 Jun 94 17:20:25 -0700 Date: Thu, 9 Jun 1994 17:20:23 -0700 (PDT) From: Robert Russ Sender: Robert Russ Reply-To: Robert Russ Subject: Re: Re. NURBS too! To: Brian Hill Cc: Performer list In-Reply-To: <199406092200.AA13153@ameig1.navsea.navy.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: O Hi all, my $0.02 on the nurbs thingy: The current loaders (ie: for .sgo, .obj, .dxf, etc) are all for handling polygonal data exclusively for a seemingly very good reason: Performer eventually needs polygons to render and reading in polygons is fairly straight-forward - the readers are fairly "dumb" in that they don't interpret data, only read it in and translate it to the data structure Performer needs. On the other hand, a nurbs -> poly's reader requires some smarts to translate the surfaces into polygons. Important issues pertaining to subdivision levels, error factors for resolving the surfaces to polygons, limitations of the target machine, etc are all important in determining exactly how to represent a spline model with polygons. We've found it to be much more beneficial to go into a program and somewhat manually convert spline models to polygons based on the above concerns. We use Alias for all of our VR stuff and have written a .tri reader (.tri is a triangle file format Alias creates) which works quite nicely. Although this isn't as automated as a "spline file reader", it seems to me that this would be a rather complex issue to automate well. Rob -------------------------------------------------------------------- Robert H. Russ russ@sdsc.edu 3D Computer Animation / Post Production OFC: (619) 534-5030 Visualization Technology Group LAB: (619) 534-5162 San Diego Supercomputer Center FAX: (619) 534-5152 -------------------------------------------------------------------- On Thu, 9 Jun 1994, Brian Hill wrote: > Robert Rossow wrote in a previous message related to NURBS > > > > I believe that the ability to use NURBS to define geometry within > > Performer would be extremely beneficial...... > > ... > > ... > > If this were the case, many more models would become available, > > and the user could be relieved of both the tesselation and > > texture/normal specifications on a per-vertex basis. > > ... > > Sounds too good to be true. What do you think? > > > As a related matter, almost all of my geometry originates as an > engineering CAD model (ie NURBS) that has to be converted with a > combination of automatic and manual techniques. There are times > when I don't need to develop a pituresque model using exotic > texturing and materials, I only need a functional rendering. > It would be nice to be able to load the original IGES NURB data > into Performer. How about an IGES loader for Performer????? > > Thanks, > > =================================================================== > Brian Hill | Advanced Marine Enterprises, Inc.| > CSD Section Chief | Suite 1300 | > (703)415-3080 | 1725 Jefferson Davis Hwy. | > hill_b@ameig1.navsea.navy.mil | Arlington VA, 22202 | > =================================================================== > > > > > > >