Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!lll-winken!ames!sgi!shinobu!odin!cashew.asd.sgi.com!kurt
From: kurt@cashew.asd.sgi.com (Kurt Akeley)
Newsgroups: comp.sys.sgi
Subject: Re:  gl question - editing large objects
Message-ID: <11094@odin.corp.sgi.com>
Date: 30 Jul 90 15:48:12 GMT
References: <9007290220.AA17536@mcirps2.med.nyu.edu>
Sender: news@odin.corp.sgi.com
Reply-To: kurt@cashew.asd.sgi.com (Kurt Akeley)
Organization: sgi
Lines: 37

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