Re: hiccupping for new objects/textures

[Keith W. <kw...@cs...>]

I'm not sure what you mean by current transform.  If you are referring to
constant changes to the objects, then bear in mind that the objects are
static after their initial creation.  Tile objects don't move or change
shape of course.  As for the hope of using large numbers of objects with
little speed cost, I'd love to find a way, so I'm not trying to argue with
you, but I honestly didn't quite understand your paragraph below.  I have
directly observed major speed enhancements by reducing the number of
objects, so what is there to dispute then?

If you're saying there is a cleverer way to use many objects and that I
don't know how to do it, then cool, I' love to figure it out, but...

I'm just not that adept at this stuff.  In what sense are my objects in a
common coordinate system, or not in common coordinate system?  The entire
world is a common coordinate system isn't it?  What difference does it
make if they aren't changing in scale, position, or rotation over time?
What are the "global settings" you refer to?  You see my confusion.  :-)

As an example, when this came up in the past, someone pointed me to the
QutGeom program and demonstrated that they had created the world (a 3D
grid of cubes) with various methods of grouping and that the grouped
methods were much faster.

So I'm not following why you think it shouldn't be much faster, since it
clearly is.  Sorry, I just don't understand.

On Fri, 23 Jul 2004, Roger Holmes wrote:

> It could be the calls to the system to change the current transform
> which were slowing you down. Yes that will be slower, but if you make
> them all in a common coordinate system and no other global settings
> change
> then I doubt you would see a factor of between 2 and 8 then. Suppose
> you lose
> 5 percent in speed, wouldn't it be worth it to save a hiccup?
>
> Roger.
>
>
> On Friday, July 23, 2004, at 05:13  pm, Keith Wiley wrote:
>
> > No, we (the group) settled this a few weeks ago.  Someone (or multiple
> > someones) told me that the number of unique trimeshes that are
> > submitted
> > definitely matters.  I subsequently verified that this is definitely
> > true.
> > Take a given scene with a number of redundant objects (with varying
> > translation, scale, rotation, whatever) and render it as a set of
> > individual objects.  Then do the same but first union all the objects
> > into
> > a single huge trimesh.  The second method renders much faster, between
> > 2
> > and 8 times faster in my experience.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

________________________________________________________________________
Keith Wiley                                kw...@cs...
http://www.unm.edu/~keithw                 http://www.mp3.com/KeithWiley

"Yet mark his perfect self-contentment, and hence learn his lesson,
that to be self-contented is to be vile and ignorant, and that to
aspire is better than to be blindly and impotently happy."
                                           --  Edwin A. Abbott, Flatland
________________________________________________________________________