wave@media-lab.MEDIA.MIT.EDU (Michael B. Johnson) (07/25/90)
I have a question for the gl wizards here:
I have a reasonable sized 4D (a 4 processor 240GTX) that will
be connected to a very fast computer (a CM-2) that will be generating
geometric data that I want display and interact with on the 4D.
Conceivably, I could have any sort of geometry data (spheres,
points, polygons, etc.), but just as an example, let's say I have
some triangle mesh: I have vertice info, normal info, and color
info. Also for this example let's say this fast computer is writing
this information to a file. So, if I want to get this data up
on the 4D and interact with it, the most straightforward way seems
to build a gl object and then display it. There is enough example
code that show how to interact with data sets that cobbling together
a rudimentary interface is just an afternoon. Now we get to the
hard part (at least to me...). The fast computer that is generating
the geometry information is pretty fast - every few seconds or so
it can generate and write as a file onto the SGI more geometry data.
These are large datasets - since a 4D can render (supposedly) a
100,00 triangle mesh a second, let's say it's a 10,000 triangle mesh.
If I had a machine that could display them fast enough, I could easily
generate larger interesing data sets, or more of them more quickly.
This geometry data is another timestep of the object we're looking at.
Consequently, I don't really want to build another object, I just want
to edit the one I just made. Let's say that after the initial
geometry data is set up, the connectivity of my triangle mesh doesn't
change - just some scalar that we associate with color does. Now, my
understanding of how I would build that object in gl in the first
place would be something like this:
gl_obj = genobj();
makeobj(gl_obj);
shademodel(GOURAUD);
bgntmesh();
c3f(c1);
n3f(n1);
v3f(v1);
c3f(c2);
n3f(n2);
v3f(v2);
c3f(c3);
n3f(n3);
v3f(v3);
/* add as many more triangles as we have here... */
endtmesh();
closeobj();
I also realize that I can put tags in there so that I can edit the object,
the manual says (16-10 Graphics Library Programming Guide IRIS-4D Series):
"If you have to edit graphical objects frequently, you should build your
own custom data structures and traversal routines, rather than use
graphical objects. The editing routines that follow are best suited for
infrequent and simple editing operations."
Given that I want to do frequent regular editing of a graphical object,
what are my alternatives? If, for example, I wanted to change the
vertice and normal info without changing the color? I don't understand
how this can be done efficently in gl.
I won't go into more detail for fear of boring people. I would be happy
to give all sorts of details over the phone or through e-mail.
To conserve network traffic, please respond via e-mail, rather than posting.
Thanks.
--
--> Michael B. Johnson
--> MIT Media Lab -- Computer Graphics & Animation Group
--> (617) 253-0663 -- wave@media-lab.media.mit.edukarron@ACF4.NYU.EDU (Dan Karron) (07/25/90)
My understanding that graphical objects are not the way to go since the new cpus can keep up with the graphics pipeline. Is it correct to say that the entire compiled objects part of the gl is obsolete ? Are there any specific instances where you should use it ? dan.
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") (07/25/90)
I never use the object commands (until recently, when it was the easiest way to do things and then it only had transformations in it). The way I read the manuals the object commands were kept for backward compatability and would be slower than just executing the drawing commands. I use mainly FORTRAN, but, this is what I do. I store the information in arrays and use do loops, etc. and plot the information. If you change the array information you don't have to do any object edits. I suppose in C it would be easier to create data structures that would make things easier, but I am still a novice C programmer. -- Brent L. Bates NASA-Langley Research Center M.S. 361 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") (07/25/90)
I've been given the impression that the objects part of the gl is obsolete. The only case in which I make an object, the object contains trasformation information. I then use the object in a mapw2 to map screen coordinates to world coordinates. -- Brent L. Bates NASA-Langley Research Center M.S. 361 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
robert@texas.esd.sgi.com (Robert Skinner) (07/27/90)
In article <9007251346.AA24480@acf4.NYU.EDU>, karron@ACF4.NYU.EDU (Dan Karron) writes: |> My understanding that graphical objects are not the way to go since |> the new cpus can keep up with the graphics pipeline. |> |> Is it correct to say that the entire compiled objects part of the gl is |> obsolete ? Are there any specific instances where you should use it ? |> |> dan. Compiled objects are not obsolete. In fact, the 3.3 release now lets you use the 'fast path' routines, bgnpolygon, v3f, endpolygon, etc. in objects. The point is that compiled objects have to be very general to handle every imaginable way that a customer might want to use them. As a result, the way they are almost certainly not as efficient as if you did it yourself. I would venture to say that there is *absolutely no way* that editing objects and redrawing will be as fast as doing all the drawing yourself for this particular application. In fact, editing objects will be more work. You not only have to build the object, you have to manage a mapping of vertices to edit points in the object. For each vertex that changes, you have to make 3 or 4 calls to edit that vertex in the object. If you do it yourself, you redraw by calling the drawing commands you used to build the object. You change the vertex information, then redraw. You will have to store the static color information (if I remember your problem correctly) but that's a pretty simple 2D array. And you aren't using any more memory, because the GL object would store it in your host memory anyway. As a matter of fact, the GL object would use more memory, because it would have to store a token that indicates that you were calling cpack() on the color data, and there would also be a token stored for the v3f command. Then there is the extra overhead for the (probably) linked list that the GL object is stored as. And there's probably overhead for each edit point. You'll find you need less code without editing objects and it will run faster. Robert Skinner robert@sgi.com Well you run and you run to catch up with the sun, but it's sinking; racing around to come up behind you again
bam@rudedog.sgi.com (Brian McClendon) (07/27/90)
In article <9007251346.AA24480@acf4.NYU.EDU> karron@ACF4.NYU.EDU (Dan Karron) writes: >My understanding that graphical objects are not the way to go since >the new cpus can keep up with the graphics pipeline. > >Is it correct to say that the entire compiled objects part of the gl is >obsolete ? Are there any specific instances where you should use it ? > >dan. Here's the story: The main advantage of objects (aka display lists) is their ability to draw quickly once generated. In a large program with hundreds (or thousands) of lines of rendering code, its much easier to generate an object with the complex code and view it with a tight loop of callobj()s than it would be to tune the rendering code up to the speed of the graphics. On a GT/GTX it was discovered that there was no reasonable way to make v3f() object-able without impacting its immediate mode performance. This caused the GT version of the GL Reference Manual and GLPG to have words to the effect that objects were heading for obsolescence. This is no longer true. With 3.3, we discovered a way to use the shared library jump table to make all of the high performance routines object-able without slowing their immediate mode performance. On the VGX in particular there are a couple of cases where objects draw slightly faster than the best immediate mode code (slightly = <20%). To meet the performance of the GT/X and VGX graphics, immediate mode code should have no more than 3 lines of MIPS assembly for each call to v3f/c3f/n3f (and equiv). This applies for "fast path" quads and tmeshes where fast path is a single-infinite-light, flat-or-gouraud, ~50-pixel-tri-or-~100-pixel-quad. More options will slow down graphics to the point where more MIPS code can fit in without degradation. On a Personal Iris, the balance is more in favor of the CPU, but if you want your code to remain graphics limited when you move up to faster graphics hardware, keep the above in mind. Editing objects always has been, and probably always will be slower than users would like. The main question is: how much editing are you going to be doing? If you change most of your scene every frame, objects probably aren't a good idea, but if you keep most of your scene constant or change it infrequently then objects could be used to your advantage. Experimentation is the best way to find out if its right for your application. ---------------------------------------------------------------------------- Brian McClendon bam@rudedog.SGI.COM ...!uunet!sgi!rudedog!bam 415-335-1110 -----------------------------------------------------------------------------
kurt@cashew.asd.sgi.com (Kurt Akeley) (07/27/90)
no, it is not the case that GL objects are obsolete. (although it was
reasonable to conclude this, based on the lack of development attention
that they received prior to the 3.3 release.) in the 3.3 release
objects have been extended to include ALL the new drawing commands,
such as bgnpolygon(), c(), n(), v(), t(), and endpolygon(). the
execution performance of objects is now very high, in some cases slightly
higher than can be achieved by immediate-mode calls.
however, the editing performance of objects is poorer than ever, as
a result of some arcane interactions between shared libraries and
code caches. thus (for now) rule one:
if performance is an issue, use GL objects only for data that
never change.
in general, we continue to encourage you to program using the immediate
mode capabilities of the GL. immediate mode coding supports interractive
graphics driven by changing data. that's the way we like to do graphics.
however, there are some cases where GL objects may be preferred to GL
immediate mode:
1. given our renewed comittment to GL objects, their performance is
likely to track the inherent performance of new machines, whereas
your immediate mode code may not (due, perhaps, to subtle issues
like quad-word alignment, which change from machine to machine, and
which we can handle in our object storage format). if your code
basically views static objects, it may port better if it is object
based.
2. in upcoming releases DGL and GL will be better integrated, and GL
programs will more often be run across networks (as in the X model).
because objects are stored and traversed on the server, rather than
on the client, objects will typically execute faster than immediate
code when client and server are different machines.
finally, while GL objects are not being obsoleted, other parts of the
current GL
will be. these include (definitely) all the old-style drawing commands, such
as pnt, move/draw, pmv/pdr/pclos, poly/polf, and (likely) the old-style pixel
commands, such as readpixels/writepixels and readRGB/writeRGB.
-- kurtktl@wag240.caltech.edu (Kian-Tat Lim) (07/27/90)
In article <9007251346.AA24480@acf4.NYU.EDU>, karron@ACF4 (Dan Karron) writes: >Is it correct to say that the entire compiled objects part of the gl is >obsolete ? Are there any specific instances where you should use it ? I believe that objects are necessary to get the most benefit out of DGL, the distributed GL library. Objects may be stored on the display server and redisplayed with one call, minimizing traffic over the net. Then again, how many people are actually using DGL? [This is not purely rhetorical.] -- Kian-Tat Lim (ktl@wag240.wag.caltech.edu, KTL @ CITCHEM.BITNET, GEnie: K.LIM1)
markov@praxis.cs.ruu.nl (Mark Overmars) (07/27/90)
One of the things that would make the use of objects a lot more interesting (according to me) would be the possibility to save them in files and to read them in later. Just adding two routines in the Graphical Library to load and save objects would mean that you only have to define your objects once. This would normally reduce the size of your programs (when they use basic objects) considerably. You could make a simple library of all the objects you need. Mark Overmars
joe@etac632 (Joe Fulson-Woytek) (07/27/90)
In article <10946@odin.corp.sgi.com> kurt@cashew.asd.sgi.com (Kurt Akeley) writes: >no, it is not the case that GL objects are obsolete. (although it was >reasonable to conclude this, based on the lack of development attention >that they received prior to the 3.3 release.) in the 3.3 release >objects have been extended to include ALL the new drawing commands, >such as bgnpolygon(), c(), n(), v(), t(), and endpolygon(). the >execution performance of objects is now very high, in some cases slightly >higher than can be achieved by immediate-mode calls. > While this part is good news, I have a philosophical problem with the following: > >in general, we continue to encourage you to program using the immediate >mode capabilities of the GL. immediate mode coding supports interractive >graphics driven by changing data. that's the way we like to do graphics. > This implies, to me at least, that SGI considers the use of objects as being wrong, simply because they like to do graphics without them. This reminds me of the SGI course I took a couple of years ago when the instructor said noone should ever use color map mode. I don't think vendors should tell customers that it is wrong to use a tool the vendor supplies (I can understand a vendor saying not to use a tool someone else supplies). Another common vendor mistake is to think that how the vendor uses their own product is how the customer is going to use it. I would urge SGI to continue providing a range of graphics tools and supporting them without making judgements on how or if those tools should be used. (Recommendations for how to use a tool are, of course, appropriate and desired). Joe Fulson-Woytek
sergio@sergio.uucp (Sergio Perrone/30000) (07/28/90)
In article <2912@dftsrv.gsfc.nasa.gov: joe@etac632.gsfc.nasa.gov (Joe Fulson-Woytek) writes:
:I have a philosophical problem with the
:following:
::
::in general, we continue to encourage you to program using the immediate
::mode capabilities of the GL. immediate mode coding supports interractive
::graphics driven by changing data. that's the way we like to do graphics.
::
:This implies, to me at least, that SGI considers the use of objects as
:being wrong, simply because they like to do graphics without them. This
:reminds me of the SGI course I took a couple of years ago when the instructor
:said noone should ever use color map mode. I don't think vendors should
:tell customers that it is wrong to use a tool the vendor supplies (I can
:understand a vendor saying not to use a tool someone else supplies). Another
:common vendor mistake is to think that how the vendor uses their own product
:is how the customer is going to use it. I would urge SGI to continue
:providing a range of graphics tools and supporting them without making
:judgements on how or if those tools should be used. (Recommendations for
:how to use a tool are, of course, appropriate and desired).
:
:Joe Fulson-Woytek
Good heavens. Aren't we being a bit uptight about this? Objects aren't
'wrong'; they're just (quite obviously) not designed for graphics which are
going to change over time. It'd be silly to do graphics in object mode
if you expect to have to modify the objects, when it's just as simple to
use regular, ordinary data structures and subroutine calls.
And besides, you ain't hearin' SGI policy on this here net, just like you
ain't hearin' IBM policy right now.
--- Marc Andreessen, IBM AWD Austin, sergio@sergio.austin.ibm.com ---
--- Words and ideas contained herein are independent of IBM policy. ---karron@MCIRPS2.MED.NYU.EDU (07/29/90)
Thanks for your considered reply. >however, the editing performance of objects is poorer than ever, as >a result of some arcane interactions between shared libraries and >code caches. thus (for now) rule one: > > if performance is an issue, use GL objects only for data that > never change. > What do you mean, exactly, by "data that never change"s ? What about a fixed geometry object that will have different reflectance properties, or a moving light source ? dan. +-----------------------------------------------------------------------------+ | karron@nyu.edu Dan Karron | | . . . . . . . . . . . . . . New York University Medical Center | | 560 First Avenue \ \ Pager <1> (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> <your-number-here> | | (212) 340 5210 \**\__________________________________________ | +-----------------------------------------------------------------------------+
kurt@cashew.asd.sgi.com (Kurt Akeley) (07/30/90)
In article <9007290220.AA17536@mcirps2.med.nyu.edu>, karron@MCIRPS2.MED.NYU.EDU writes: |> Thanks for your considered reply. |> |> >however, the editing performance of objects is poorer than ever, as |> >a result of some arcane interactions between shared libraries and |> >code caches. thus (for now) rule one: |> > |> > if performance is an issue, use GL objects only for data that |> > never change. |> > |> |> What do you mean, exactly, by "data that never change"s ? i don't have an exact definition, so i'll try a different tact. what i mean is: 1. don't ever call editobj(). 2. don't repeatedly call makeobj() to accomplish object editing. |> |> What about a fixed geometry object that will have different reflectance |> properties, or a moving light source ? |> if the fixed geometry object has only a single reflectance property, that property can be changed outside the GL object definition itself, and it's ok to use a GL object. if the geometric object requires multiple reflectance properties, however, it should either be broken up into multiple GL objects or drawn in immediate mode. same goes for the light source, which is positioned by the ModelView matrix that exists at the time the light source is bound. it's ok to include the lmbind call in an object, but not the code that changes the ModelView matrix. -- kurt