Subject:
|
Re: 3D Transformations Architecture Question
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Fri, 13 Jul 2007 05:45:50 GMT
|
Viewed:
|
2245 times
|
| |
|
|
In lugnet.cad, Jeff Boen wrote:
| |
In lugnet.cad, Travis Cobbs wrote:
I understand about creating a transformation matrix, a camera matrix and a
projection/perspective matrix. I understand about compositing them all for a
final drawing transformation/2D projection. I have all of those routines
built and I know how to get the objects drawn on screen. I’m more concerned
with the most efficient way of generating/storing the data to get to the
point of drawing.
|
Sorry. I guess I didn’t fully understand why you wanted to do the
pre-multiplies. Hopefully this reply will be closer to what you are looking
for.
LDView 1.0 did exactly what you suggest. It calculated the final coordinates
for every single triangle, quad, and line in the entire model. It then stuck
all this in one giant display list. It worked, but it didn’t work well. And it
used a LOT of memory. This behavior continued through LDView 2.x.
In LDView 3.0, I completely rewrote my graphics engine. It flattens the
geometry of parts such that every part is a single object, but it leaves
everything else alone, and stores the matrices for everything, and then goes
through the process I described in my previous post to draw things. And
remember, LDView is a viewer that doesn’t allow for ANY changes in geometry.
Depending on the memory usage setting (low, medium, high), it either uses no
display lists at all, display lists for the parts but nothing else, or display
lists for everything (although the display lists above the part level simply
call out to the part display lists). It uses a lot less memory (varying from
about half to 1/10th or even less), and it runs faster (although I’m using
different OpenGL primitives inside the display lists, so it’s tough to judge the
performance change).
To put things into perspective, Orion’s model of the Imperial Star Destroyer
(which contains 3020 of the 3104 parts in the actual set) runs in LDView 3.2B1
at right around 30fps when memory usage is set to high (using 73.5MB), and runs
at pretty much the same speed when memory usage is set to medium (using
73.25MB). Setting memory usage to low drops the memory usage down to 61.5MB,
but it also drops the frame rate down to about 7.5FPS. Load the same model up
in LDView 2.03 and it runs at about 12FPS (using 239.25MB).
| |
My question is whether or not calculation of those matrices and their final
transformation on all objects in the scene for any change is wise since
software of this type tends to have few simultaneously moving parts. It’s
great for FPSs where everything is in motion (via motion of the camera/player
POV) and needs to be updated constantly, but in a CAD environment when you
have 100 objects on the screen and are only rotating 1 of them on 1 axis (or
worse, just translating it) while the other 99 are static seems like an awful
lot of muls (via matrix compositing) for data which is not changing. I’m
wondering whether or not it’s better to not only store the last version of
the trans/cam/proj matrices but also any object vertex data which is not
modified by the latest change as well.
|
Well, I can get 30FPS drawing all the geometry for 3000 parts, and doing the
matrix multiplies for all of them on the fly also. And if you have any
duplication of objects (which you may not; LEGO is obviously rather specialized
in that sense), you’d have to make copies in order to calculate the final
geometry. So I’d say that there’s really not much point in pre-transforming the
geometry. And if you expect on the order of 100 objects in the scene, the
matrix multiplies are likely to use a tiny fraction of the time spent for each
frame.
I would suggest either not storing the trans/rotate/scale info for the objects
except in their matrix, or having a flag that knows when the matrix needs to be
regenerated. In other words, either use the matrix for everything, or only
generate the matrix when you need it after something has changed.
One last thing. My understanding is that the OpenGL (or DirectX) driver is
likely to do the matrix multiplies completely on the CPU. In other words, they
aren’t hardware-accelerated, because the driver needs to know the result, and
the round trip to the graphics card takes longer than just doing the multiply.
But they do apparently have highly optimized matrix multiplication routines, so
they happen really fast. Your own matrix multiplication routine is likely to be
significantly slower, unless you use one written by someone else (that takes
advantage of any possible special CPU instructions that might help out).
--Travis
|
|
Message has 2 Replies:
 | | Re: 3D Transformations Architecture Question
|
| (...) Well thanks for spoiling my day :) I tried orions file and discovered a design flow in my new LD4DStudio renderer. It looks like this: (URL) seems Orion uses the rotation matrix to mirror some parts, this totally F-ups my normals :( And there (...) (17 years ago, 13-Jul-07, to lugnet.cad)
| | | Re: 3D Transformations Architecture Question
|
| (...) Thanks Travis, that's *exactly* the info I was looking for. I think I'm going to go ahead and store each object's matrix, as well as the camera and projection matrices, updating any of them only when adjustments are made to the appropriate (...) (17 years ago, 13-Jul-07, to lugnet.cad, FTX)
|
Message is in Reply To:
| | Re: 3D Transformations Architecture Question
|
| (...) Travis, Thanks, but that answer is exactly what I was trying to avoid in this discussion. I understand about creating a transformation matrix, a camera matrix and a projection/perspective matrix. I understand about compositing them all for a (...) (17 years ago, 13-Jul-07, to lugnet.cad, FTX)
|
8 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
|
|
|
|
