Subject:
|
Re: Maximum depth of ldraw models?
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Fri, 8 Sep 2006 06:56:23 GMT
|
Viewed:
|
2367 times
|
| |
|
|
The thread seems to be splitting from the original point,
It is a fact that OpenGL generally places a depth of 16 on any transforms. If an
LDRAW model in MPD format was presented to OpenGL as a raw data block I suspect
that OpenGL would easily hit the 16 levels as many of the individual bricks
exceed 4 levels of depth plus there is model itself.
Additionally there is the computational time to display such a format which
would be significant as each triangle on each brick would need to be completely
parsed so like many I tend to flatten all data at brick level.
> > I tested the performance of, and saw a decent gain from flattening part
> > geometry. (Perhaps 15% in BrickDraw3D for QuickDraw3D or OpenGL.)
>
> Okay... 15% speedup is substantial... that means that it's better to
> pre-transform the subfiles when generating the operations for the
> current file. I won't worry about the maximum depth any more then.
During my initial experiments with MBC I found gains from flattening the models
at brick level, but I don't remember by what margin.
> > What this means is that when a part is prepared into a drawing list, it is not a
> > list of calls to primitives with a transformation, but instead the primitives
> > are copied out and all coordinates pre-transformed, all the way down. (With the
> > exception of studs and changes of color.)
MBC creates seperate drawing lists for each brick variation, so each list
contains the complete data for both the colour and the studs.
> How does a renderer know which parts are studs anyways? Are the
> filename(s) for studs manually hardcoded into the renderer?
In MBC's case "Yes"
> > Or, a part is created as a single mesh
> > with an attempt to join triangles into triangle mesh and to join line segments
> > into line primitives.
In MBC's case "Yes" again for recognised defined primitives.
> >
> > This can speed up rendering by eliminating a large number of camera stack
> > operations, eliminating duplicate vertices, and by increasing the memory cache
> > hit rate, at the cost of a reasonable amount of extra memory used.
>
> Hmmm... I can't see any way of using compiled vertex arrays for an
> object without potentially decoupling the order of opengl operations for
> the object from the actual order of ldraw commands as they appear in the
> DAT file. That would make editing awkward, wouldn't it?
My philosophy has been that MBC is a model editor using bricks therefore only
flatten to that level. Decoupling the data below this level within the rendering
engine is therefore a matter for the developer to deal with.
MBC 1 and 2 use OpenGL lists to display the bricks, the lists are compiled
directly when parsing the LDRAW dat files. To draw a brick merely required
setting the OpenGL matrix and calling the appropriate list. This made for easy
coding and display but the drawing process is entirely connected to OpenGL.
However, OpenGL is well optimised for depth calculation and only objects that
will appear infront of the current depth buffer are passed to the engine for
rendering. Therefore any application that presents the data to OpenGL in a
closest to furthest order will likely draw more quickly than an application that
presents the bricks in random order. This would require some preprocessing of
the data and MBC doesn't have this optimisation.
Another big speed hit for OpenGL is the colouring of rendered surfaces. This is
determined by the "normal" vectors. If all of the normal vectors are in the same
plane, you have a flat surface and consequently the entire triangle (or quad) is
one colour.If on the other hand the normal vectors differ you're simulating a
curved surface (such as a stud) and therefore the colour of the triangle (or
quad) will change over the surface - this requires additional calculations to be
made by OpenGL.
Therefore if the flat surfaces were presented first in a front to back order,
then the curved surfaces in the same way, rendering would be quicker.
To draw using OpenGL one can either send the draw commands individually
(slowest) or link the commands into a OpenGl list (much faster) or present
vertex arrays to OpenGL (in my experience faster again).
MBC 3 renderes using vertex arrays and is able to decouple the curved surfaces
from the flat surfaces during rendering (but as yet I haven't done this). In my
experience vector arrays also respond well to hardware acceleration with the
right graphic card (20 - 30% faster rendering). My experience is the biggest
current bottleneck is getting the data into OpenGL.
Interestingly platform upgrades made problems go away, for example drawing the
Imperial Star Destroyer on my 3 year old computer requires a couple of seconds
for a redraw so rotating the model is done on wireframe, yet my new computer
will draw the ISD in less than 0.1 seconds and can rotate a fully rendered model
in real time.
Where I'm going with this is I thing drawing the studs seperately to the model
has significant advantages but always we need to be careful of over optimising
our code to any particular rendering style as OpenGL is evolving and so are the
computer platforms and as a result the bottlenecks are constantly changing.
|
|
Message is in Reply To:
 | | Re: Maximum depth of ldraw models?
|
| (...) Okay... 15% speedup is substantial... that means that it's better to pre-transform the subfiles when generating the operations for the current file. I won't worry about the maximum depth any more then. (...) How does a renderer know which (...) (18 years ago, 7-Sep-06, to lugnet.cad.dev)
|
11 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
