ID Tech 4 Coding puzzle

nbohr1more

Newcomer
Hello,

The Dark Mod's new procedural model generator cannot currently scale Collision Models only standard geometry. The coder who is working on the problem has posted the code segment that currently does rotation and translation in response to a forum poster who questioned the difficulty of modifying the code for scaling size.

Feedback:

To be honest, don't understand the problem...

If you want to scale it by constant factor C isotropically then you can multiply everything with coordinate and scale sense by C and do nothing with things like normals. To my mind it should work correct.

The anisotropic scale is a bit worse. If you scale each vector (x,y,z) by factor (Cx, Cy, Cz), then each normal (Nx, Ny, Nz) should transform into (Nx/Cx, Ny/Cy, Nz/Cz). If there is a plane, then its normal is transformed as stated and its distance is not changed. Just remember to change it when you renormalize the normal (it does not have unit length no more).

In general case: there is a plane with equation in homogenous coordinates in form (Nx, Ny, Nz, d) dot (x, y, z, 1) = 0. You want to transform the world by multiplying it on the 4x4 matrix A. It is well known from shader programming (applying modelview transformation to normals) that the "plane vector" must be multiplied by inverse of transpose of A. So the new plane parameters are (A^{-1})^T * (Nx, Ny, Nz, d). The correctness can be checked by noticing that dot product of transformed plane vector on transformed point vector remains the same. Notice that combined rotation, translation and arbitrary scaling are included in this case.
I hope that I'm not mistaken about the formulas above :laugh: If you find a way to change all the coordinate parameters, then the formulas how to change them are indeed obtainable.


Response:


Here is the code for Rotation/Translation:

Code:
idTraceModel::Translate
============
*/
void idTraceModel::Translate( const idVec3 &translation ) {
        int i;

        for ( i = 0; i < numVerts; i++ ) {
                verts[i] += translation;
        }
        for ( i = 0; i < numPolys; i++ ) {
                polys[i].dist += polys[i].normal * translation;
                polys[i].bounds[0] += translation;
                polys[i].bounds[1] += translation;
        }
        offset += translation;
        bounds[0] += translation;
        bounds[1] += translation;
}

/*
============
idTraceModel::Rotate
============
*/
void idTraceModel::Rotate( const idMat3 &rotation ) {
        int i, j, edgeNum;

        for ( i = 0; i < numVerts; i++ ) {
                verts[i] *= rotation;
        }

        bounds.Clear();
        for ( i = 0; i < numPolys; i++ ) {
                polys[i].normal *= rotation;
                polys[i].bounds.Clear();
                edgeNum = 0;
                for ( j = 0; j < polys[i].numEdges; j++ ) {
                        edgeNum = polys[i].edges[j];
                        polys[i].bounds.AddPoint( verts[edges[abs(edgeNum)].v[
INTSIGNBITSET(edgeNum)]] );
                }
                polys[i].dist = polys[i].normal * verts[edges[abs(edgeNum)].v[
INTSIGNBITSET(edgeNum)]];
                bounds += polys[i].bounds;
        }

        GenerateEdgeNormals();
}



Now for Scale? :smile:

Do any of the Math-savvy folk here see an obvious solution?
 
A big reason for the creation of this system is of stretch the capability of the engine, using high-poly models for collision would probably defeat the purpose in most usage scenarios.

The Entity management system also works "on-the-fly" so invoking a "convert model to collision" would probably be too slow for real-time LOD.
 
Solved!!!

The forum poster who essentially asked "How hard could that be?" responded to the challenge with code patches.

@Davros: AFAIK Quake 3's LOD system is inside the renderer while this is being done by hooking into the Doom 3 renderer from the Game API interfaces in the SDK. Also, this is more than just LOD, it is a Procedural Content Generation system. You can read about it (and the discussion and review the patch code and view demo images ) here:

http://modetwo.net/darkmod/index.php?/topic/12107-announcement-lode-system/
 
Low FPS:

1) There are some poorly optimized models that will be reworked (two-sided instead of one-sided materials).
2) The large portions of the model constructor reside within the closed source executable and the profiler shows that the closed source portion is slow. The developer is currently creating his own constructor from scratch to improve this situation.
3) That scene is a little aggressive with the amount of vegetation in the far distance, most LOD'ed engines would've thinned things out a bit more.
4) Some models in that scene have no LOD versions

Even without improvements the current framework is still a great benefit for outdoor scenes (just not scenes as ambitious as that screen-shot). I think they are even reworking one of the Forest missions (that used a rotating visportal trick) to use this system also.

:D
 
Back
Top