Subject:
|
Re: Mac Brick CAD and the Imerial Star Destroyer
|
Newsgroups:
|
lugnet.cad.dev.mac
|
Date:
|
Mon, 17 May 2004 22:45:58 GMT
|
Viewed:
|
2098 times
|
| |
|
|
In lugnet.cad.dev.mac, Travis Cobbs wrote:
> One thing I've forgotten to mention in my previous replies is that it's really
> unfair to compare the performance of an editor (MBC) with a viewer (LDView),
> even if both are running on the same machine. A viewer doesn't have to worry
> about adding, removing, and moving pieces on the fly, so in theory can make
> optimizations that can't be made in an editor.
>
> As a consequence, despite how my previous posts may have appeared, I'm really
> not trying to compare the performance between the two. However, having said
> that, many optimizations are appropriate to both an editor and a viewer.
>
> --Travis Cobbs
Travis,
Generally I have to agree with you:
According to the Apple literature non-OpenGL aware graphics cars (such as the
Rage128) gain significant benefit from vertex arrays but with OpenGL aware
graphic cards (such as the 9000Pro ) this isn't necessary. My internally defined
parts don't use vertex arrays.
All OpenGL drawing calls are to GL_QUADS, GL_LINES and GL_TRIANGLES. To minimise
the number of OpenGL calls in the list I internally resolve all vertexes into
thier final coordinates then call OpenGL with these coordinates.
I agree that the most efficient way of displaying a model is to make 1 big list
and fire it at OpenGL but as you say, if you're going to edit the model, then
this just isn't practical.
I elected to define each brick with its colour in order to minimise as much as
possible the OpenGL calls during rendering. It would be necessary to define each
colour in a different list.
Likewise, I've read that calling OpenGL lists from within an OpenGL list isn't
as efficient as drawing the object directly, so therefore I don't cull and
define primitives as lists during parsing. This means that each time a primitive
is referenced (which is not internally defined) it is re-accessed from disk and
reparsed. If I was to pre-cache the primitives internally in my application,
then it is likely that I could shorten loading times significantly.
To be honest, I'm not overly concerned with the load times, they should be
shortened but this is a one-time event, the inconvienence is minimal.
Actually most of my view is in the rendering where faster systems have very
little real advantage over slower ones. When I've run performance measuring
tools on the application during rendering, OpenGL accounts for about +95% of the
system usage. Based on this, calling the bricks, loading and defining the
matricies then calling the display list isn't much of a resource hog.
Right now, I genuinly wonder if I'm getting hardware acceleration in OpenGL.
Andrew...
|
|
Message has 1 Reply:
 | | Re: Mac Brick CAD and the Imerial Star Destroyer
|
| (...) Maybe you're running into one of those weird oddities of the Apple opengl drivers. For example rendering to the GL_FRONT buffer really renders to a hidden back buffer. There are times where this setup causes you to use triple buffering, which (...) (20 years ago, 17-May-04, to lugnet.cad.dev.mac)
|
Message is in Reply To:
| | Re: Mac Brick CAD and the Imerial Star Destroyer
|
| One thing I've forgotten to mention in my previous replies is that it's really unfair to compare the performance of an editor (MBC) with a viewer (LDView), even if both are running on the same machine. A viewer doesn't have to worry about adding, (...) (20 years ago, 17-May-04, to lugnet.cad.dev.mac)
|
19 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
