Individual Mesh Rotation

[Michael Lobko-Lobanovsky]

I wanted to do it for long

I'm very glad you finally did it — yourself. It means there are two OpenGL developers in this project — you and me, rather than me alone.

That was a pragmatic decision of my own.

I can hardly believe this. I lost my peace of mind, my rest, and my sleep. I do not know how I can carry on programming in C++. From my point of view as a compiler developer, this is an obvious compiler or probably C++ FPU math specification bug that must have been revealed years, if not decades, ago.

Is this the first time in your C++ practice that you encounter this particular kind of bug and use this very tactics to correct it?

We must compute the exact individual mesh centerpoint, based on the rotation axis being used.
We can't use the centerpoint computed by CalcMeshBounds.

No, this is not so. It is your code that yields illogical results, not mine — and I can prove it. Recalculation of AABB or sphere center point on the fly is ridiculous and never done. The tactics used in calcMeshBounds() is industry standard and may not be questioned. Please read further below.

Perhaps the problem is because we are using pointers ... code optimization performed by the compiler

No, it works in the exact same way with all project-wide and file-specific optimizations switched off. Moreover, it works the same also in Intel C++ compiler. (yes Patrice, the ObjReader solution can be recompiled as-is in the most recent Intel System Studio)

Because negate failed...

No, it does not fail. It does exactly what it is supposed to do.

Use zTrace() to check the values of pMesh->centerPoint[0] and rx in the Corsair model. (Y also fails while Z is correct, which results in visible eccentricity of the propeller)

pMesh->centerPoint[0] is -0.000127, and -pMesh->centerPoint[0] yields 0.000127 as expected.

rx = pMesh->centerPoint[0] > 0.0f ? -1.0f : 1.0f yields rx = 1.000000 and leads to non-reversal of the pMesh->centerPoint[0] sign, which is logically, trigonometrically, and spatially incorrect. In order to work as it "works", there must be a matching mirror bug somewhere that writes the center point X value into pMesh->centerPoint[0] selectively with a wrong sign.

Or such a situation may also occur if the [0,0,0] and pMesh->centerPoint[0,1,2] are in fact given in different coordinate systems, and pMesh->centerPoint should first be e.g. multiplied by the inverse modelview matrix prior to sign reversal, whereby your > ? : and * +/- 1.0f actually emulates such matrix multiplication.

This is why I was, and still am, asking you: where did you get that hack from? One must be very, very smart indeed to take such a "pragmatic decision" by intuition having very little practical OpenGL background...

[Patrice Terrier]

This is why I was, and still am, asking you: where did you get that hack from?

I already told you…

Would you like to have the latest WIP, or do you prefer to wait until i have fixed the mesh rotation offset. ?

[Michael Lobko-Lobanovsky]

I already told you…

Which means you are very, very smart indeed, my friend.

Would you like to have the latest WIP, or do you prefer to wait until i have fixed the mesh rotation offset. ?

You probably won't need to fix anything if I find the correct solution to the problem. I suspect that our model center point might also have certain eccentricity with respect to the ideal [0,0,0] in the world coordinates. If this is the case, then mesh coordinate negation might be imprecise, and the exact amounts of negative translation should in fact be the difference between the mesh and model center points rather than the inverse of mesh center point alone...

This may be a side effect of the model being scaled up or down when we're trying to fit it into our viewport.

[Michael Lobko-Lobanovsky]

I am sorry Patrice, it was my own fault. I missed one && gP.nRotation flag in the PPL renderer.

Please remove the donerotate flag because it is unnecessary.

[Patrice Terrier]

Not perfect yet (i couldn't mix several rotate axis altogether), however it is much better!

Test.mtl

Code: [Select]

#Light frontAmbient 0 0 0
#Light frontDiffuse 165 165 165
#Light frontSpecular 127 127 121

#Light leftAmbient 0 0 0
#Light leftDiffuse 127 127 121
#Light leftSpecular 127 127 121

#Light rightAmbient 0 0 0
#Light rightDiffuse 127 127 121
#Light rightSpecular 127 127 121

#wallpaper @background.jpg

newmtl sphere
#rotate 5.0 0.0 1.0 0.0
Ka 1 1 1
Kd 0.80000001192093 0.80000001192093 0.80000001192093
map_Kd engine.png
Ks 1 1 1
Ns 50
illum 7

newmtl tron
#billboard
ka 0.0 0.0 0.0
kd 0.75 0.75 0.75
ks 0.75 0.75 0.75
ke 1 1 1
ns 52
illum 2
d 0.999
map_kd logo.png

newmtl hex
ka 0.75 0.75 0.75
kd 0.75 0.75 0.75
ks 0.75 0.75 0.75
ke 0.75 0.75 0.75
ns 2
d 0.25
illum 2
map_kd hex.png

newmtl logol
ka 0.15 0.15 0.15
kd 0.75 0.75 0.75
ks 0.75 0.75 0.75
ke 1 1 1
ns 52
d 0.99
illum 2
map_kd logol.png

newmtl logor
ka 0.15 0.15 0.15
kd 0.75 0.75 0.75
ks 0.75 0.75 0.75
ke 1 1 1
ns 52
d 0.99
illum 2
map_kd logor.png

newmtl lens
ka 0.15 0.15 0.15
kd 0.75 0.75 0.75
ks 0.75 0.75 0.75
ke 1 1 1
ns 52
d 1.0
illum 2
map_kd lens.png

newmtl bordure
ka 2 2.8 3
kd 0 0.8 0.9
ks 2 2.8 3
ke 0 0.8 0.9
ns 52
illum 3
refl steel3.png

newmtl spot
ka 1 1 1
kd 1 1 1
ks 1 1 1
ke 0.5 0.5 0.5
map_kd spot.png
ns 2
illum 2

newmtl eye
ka 0.15 0.15 0.15
kd 0.75 0.75 0.75
ks 0.75 0.8 0.9
ke 0.5 0.8 0.9
map_kd eye.png
ns 2
illum 2

newmtl head
ka 0.15 0.15 0.15
kd 0.75 0.75 0.75
ks 0.75 0.8 0.9
ke 0.5 0.8 0.9
map_kd head.png
ns 2
illum 2

newmtl dash
ka 0.15 0.15 0.15
kd 0.75 0.75 0.75
ks 0.75 0.75 0.75
ke 0.75 0.75 0.75
map_kd dash.png
ns 2
illum 2

newmtl queue
ka 2 2.8 2.9
kd 0 0.8 0.9
ks 2 2.8 2.9
ke 0 0.8 0.9
map_kd tail.png
ns 2
illum 2

newmtl flares
#alphatocoverage
ka 0 0 0
kd 0 0.8 0.9
ks 0 0 0
ke 1 1 1
map_kd flares.png
ns 2
d 0.985
illum 2

newmtl glow
ka 0 0.08 0.9
kd 0 0.8 0.9
ke 0 0.8 0.9
ks 0 0.8 0.9
ns 512
illum 3
refl glow.jpg

newmtl moyeu
ka 2 2 2
kd 0.75 0.75 0.75
ks 2 2 3
ns 512
illum 3
refl steel3.png

newmtl phare
kd 0.15 0.15 0.15
ks 1 1 1
ke 0.21176470816135 0.54117649793625 0.89803922176361
ns 512
illum 3
refl color.png

newmtl visiere
kd 0 0 0
ks 0 0 0
ke 0.35 0.4 0.5
ns 2
d 0.6
illum 3
refl color.png

newmtl alu
ka 0.117 0.117 0.117
kd 1.0 1.0 1.0
ks 1.0 1.0 1.0
ns 912
d 1.0
illum 3
refl black.png

newmtl bike
ka 0.65 0.65 0.75
kd 0.0 0.35 0.75
ks 0.75 0.75 0.75
ns 512
illum 3
refl black.png

newmtl tire
kd 0 0 0
ks 0.15 0.15 0.15
ns 512
illum 3
refl black.png

newmtl engine
#rotate 7.5 0.0 0.0 1.0
ka 0 0 0
kd 0 0.4 0.45
ks 0 0 0
ke 0 0.8 0.9
illum 2
ns 2
map_kd engine.png
map_bump engine_bump.png

newmtl helmet
ka 0 0 0
kd 0.25 0.25 0.25
ks 1 1 1
ns 512
illum 3
refl black.png

newmtl glass
ka 0.15 0.15 0.9
kd 0.0 0.8 0.9
ks 2 3 3.5
ns 512
d 0.5
illum 3
refl steel6.png

newmtl stick
ka 0 0 0
kd 0.5 0.5 0.5
ks 0.75 0.75 0.75
illum 2
ns 52
map_kd stick_kd.png
map_bump stick_bump.png
map_ks stick_ks.png

newmtl body
ka 0 0 0
kd 0.35 0.35 0.35
ks 2 2 2
map_kd body_kd.png
map_ks body_ks.png
map_bump body_bump.png
illum 2
ns 512
refl black.png

newmtl body_glow
#alphatocoverage
ka 0 0.08 0.9
kd 0 0.8 0.9
ke 0 0.8 0.9
#ks 0 0.8 0.9
illum 2
ns 10
d 0.99
map_kd body_emss.png

newmtl bande
ka 0 0.08 0.9
kd 0 0.8 0.9
ke 0 0.8 0.9
ks 0 0.8 0.9
illum 2
ns 10

And here is the code being used to produce the attached video

Code: [Select]

            if ((pMaterial->rotate[0] != 0.0f) && gP.nRotation) {
                glPushMatrix();
                pMesh->pMaterial->rotangle += pMesh->pMaterial->rotate[0];
                float rx = pMesh->centerPoint[0]; if (pMesh->pMaterial->rotate[1]) { rx = -rx; }
                float ry = pMesh->centerPoint[1]; if (pMesh->pMaterial->rotate[2]) { ry = -ry; }
                float rz = pMesh->centerPoint[2]; if (pMesh->pMaterial->rotate[3]) { rz = -rz; }
                glTranslatef(rx, ry, rz);
                glRotatef(pMesh->pMaterial->rotangle, pMesh->pMaterial->rotate[1], pMesh->pMaterial->rotate[2], pMesh->pMaterial->rotate[3]);
                glTranslatef(-rx, -ry, -rz);    //glTranslatef(pMesh->centerPoint[0] * rx, pMesh->centerPoint[1] * ry, pMesh->centerPoint[2] * rz);
            }

[Michael Lobko-Lobanovsky]

What about inclined axes of rotation though?

[Patrice Terrier]

What about inclined axes of rotation though?

This is the reason why i wrote not perefect 

However it solves already most of my needs.

[Michael Lobko-Lobanovsky]

OK OK I ain't criticizing.

BTW you may want to reduce pMesh->pMaterial->... to pMaterial->... in your rotation code because it is cached locally in both procedures. This saves a lot of indirection stuff that would otherwise resolve to quite a number of extra machine code instructions. As tested, the result is reliably the same.

[Patrice Terrier]

you may want to reduce pMesh->pMaterial->... to pMaterial->...

Done, thank you.

[Patrice Terrier]

That deserve a new version #2.52 

[Michael Lobko-Lobanovsky]

Yes.

And I'm also waiting for a family of spaceships with their antennas gloriously a-spinnin'.

[Michael Lobko-Lobanovsky]

And a 3D Rubik's Cube game.

[Patrice Terrier]

Helios, would be a good candidate.

But that means much mesh editing 

[Michael Lobko-Lobanovsky]

But that means much mesh editing 

... undoing your previous mesh/material mergers.

[Patrice Terrier]

So far i can rotate correctly only individual meshes, not a group of meshes that sould act as a single one (because they should use the same center point).

See the attached video.

That means we should compute an extra centerpoint for a group of meshes acting as a single entity.
And find an easy meta syntax to use in the mtl file.