hover_guard

[Patrice Terrier]

The accrobatic contortions are over, here is the final version.
This one uses one more mesh and a new texture set to achieve the extra rotations.

Thank you again for your help and suggestions.

[Michael Lobko-Lobanovsky]

Good morning Patrice,

Hope you slept well.

0. First of all, implement the code as I described earlier and enjoy the results.

1. Now goto the MobjMat definition in globals.h and change it as follows:
........
    float rotate[7];  // MLL: 01-29-2019 glRotatef(rSpeed, rX, rY, rZ)+lbound(rock)+ubound(rock)+init(rotangle)
........

2. In mobj.h, fix material initialization (!!!) in Mobj_importMaterials() and Mobj_importGeometryFirstPass() to reset the new rotate[6] element to 0.0f.

3. In mobj.h, fix Mobj_importMaterials() as follows:
........
            } else if (strcmp(szBuffer, "#rotate") == 0) { // PAT: 06-05-2018
                fscanf(pFile, "%f %f %f %f %f %f %f", &pMaterial->rotate[0], &pMaterial->rotate[1], &pMaterial->rotate[2],
                    &pMaterial->rotate[3], &pMaterial->rotate[4], &pMaterial->rotate[5], &pMaterial->rotate[6]); // MLL 01-29-2019:
                pMaterial->rotangle = pMaterial->rotate[6];
                saturateVec3(&pMaterial->rotate[1]); // MLL 06-13-2018: saturate rotation axes to +-1.f
........

4. In Main.cpp, fix ResetCamera() as follows:
........
        if (gM.numberOfMeshes) { // PAT: 01-01-2019 avoid subscript out of range
            MobjMesh* pMesh = &gtm_meshes[0];
            for (int i = 0; i < gM.numberOfMeshes; i++, pMesh++) { // MLL 10-18-2018: reset mesh rotation angles
                pMesh->pMaterial->rotangle = pMesh->pMaterial->rotate[6]; // MLL 01-29-2019:
            }
        }
........

5. In renderers.h, use the following shorter and faster code in the both drawUsingXXX() render procs:
........
        if (gP.bRotation) { // MLL 06-13-2018: regardless of visibility!
            float* rotate = pMaterial->rotate, *rotangle = &pMaterial->rotangle; // cache
            if ((*rotangle += rotate[0]) > 720.0f) // pure rotation & rocking
                *rotangle -= 720.0f;
            if (rotate[4] != rotate[5]) { // rocking only
                if ((*rotangle > rotate[5]) || (*rotangle < rotate[4])) {
                    rotate[0] = -rotate[0]; // flip sign
                    *rotangle += (2.0f * rotate[0]); // fix angular position
                }
            }
        }
........

6. And finally, use the following meta in the wip mat library to test the latest mods:
#rotate -1 0 1 0 315 405 360



Now you can start enjoying yet better results.

[Patrice Terrier]

Thank you for your efforts, that works very well!

I have added this at line 1630 in mobj.h
                fscanf(pFile, "%f %f %f %f %f %f %f", &pMaterial->rotate[0], &pMaterial->rotate[1], &pMaterial->rotate[2], &pMaterial->rotate[3], &pMaterial->rotate[4], &pMaterial->rotate[5], &pMaterial->rotate[6]); // MLL 01-29-2019
                if (pMaterial->rotate[6] == 0.0f) pMaterial->rotate[6] = pMaterial->rotate[4] + (pMaterial->rotate[5] - pMaterial->rotate[4]) / 2.0f;
                pMaterial->rotangle = pMaterial->rotate[6];

[Michael Lobko-Lobanovsky]

I have added this at line 1630 in mobj.h

Oui, vous avez raison, mon ami!

But please make it *0.5f rather than /2.0f. No speed compromises!

[Patrice Terrier]

The first post of this thread has been updated with a new zip.

[Michael Lobko-Lobanovsky]

Wow-wow-wow, hold on a little!

The two bottom green lights are still a little off their respective shadow spots!!!

[Patrice Terrier]

I think i have fixed the light offset, however there is still a small glitch if you look the turret rotation from the bottom, this is because i was too lazy to rework the missing symmetry. 

The zip has been updated.

[Michael Lobko-Lobanovsky]

Thank you, Patrice!

The eccentricity of bottom turret is not so much noticeable and we can live with it, I think.

[Michael Lobko-Lobanovsky]

By the way, what about:

1. A matching #translate, both global and local? The global one could help implement such effects like e.g. idle hovering of the craft in the air...

2. Interpolated propagation of the camera along a closed trajectory described by a set of Bezier control points around the model or along a route in the streets of a city model or in the corridors of a mansion?

The effects are called cinematics, i.e. pre-programmed animation of the model's (or models') geo in the scene. (simple as it can be in our case...)

[Patrice Terrier]

#translate, yes that could be a nice addition, i already tought of it to create simple up or down effect, and cinematic sounds also good to me.

About cinematic, does that means that we should use a specific mesh to create the path or the Bezier curve ?

[Michael Lobko-Lobanovsky]

#translate, yes that could be a nice addition, i already tought of it to create simple up or down effect, and cinematic sounds also good to me.

OK, I'm going to work on both #translate and #scale to complete the classic "holy trinity" of options. I'll open separate WIP topics on them. I'm finding these options an interesting challenge and a good excuse for my persistent procrastination regarding frustum culling, FBO, and PP.

About cinematic, does that means that we should use a specific mesh to create the path or the Bezier curve ?

Cinematics means any pre-programmed animation of models or meshes. It's like running a movie film through your Monroe projector on your screen. Thus, an animated view of your steam-punk hover_guard is already a cinematics of sorts.

OTOH the pre-programming of camera trajectory around the scene is called camera path editing. Ideally it would require a dedicated WYSIWYG editor to be integrated in ObjReader but we can subside to just adding an invisible d 0 "mesh" called, say, campath similar to how you create your shadow meshes for your models using your C4D editor. We can have this "mesh" written verbatim into the OBJ file (it is invisible, after all) or we can later on comment it out manually using hashtags, but it isn't absolutely necessary.

Additionally, we can have one more invisible "mesh" called e.g. camtarget to define the orientation (view vector) of camera towards the points of interest as it moves along its path. (re. gluLookAt() in gl_DrawScene())

Alternatively, we can use Wavefront OBJ vp u [, v[, w]] statements (see the format specs if you still have them ) to define this "mesh" as a Bezier curve in an absolutely legit way. I do not know of any contemporary 3D editor/viewer that's capable of reading the OBJ format advanced statements like Bezier curves or B-splines etc., so they will all safely omit them reading in our modded models.

The campath and camtarget mesh vertices will be read into their respective separate arrays of points to control the 3D Bezier loop for the camera to follow in real time at a given velocity.