Peugeot-Onyx (concept car)

[Michael Lobko-Lobanovsky]

And the following is my problem. You see, ObjReader refuses to maintain stable flare sizes I'm reconstructing from the 64-bit MODELVIEW and flare mesh centerPoint and meshRadius... 

Strange. I do not see such a glitch in my 32-bit Objector in any OS I'm checking it under... The C code is absolutely identical... 

[Patrice Terrier]

I already reworked it, that way

Code: [Select]

    // Display FPS using GDImage bitmapped font.
    if (gP.nUseFPS) {
        if (nCount == 0) { nCount = GetTickCount(); }
        nFPS++;
        DWORD delta_ticks = GetTickCount() - nCount;
        if (delta_ticks > 999) {
            Path_Combine(zMsg, L"FPS ", STRL(nFPS));
            nFPS = 0; nCount = 0;
        }
        ZI_DrawGLText(gP.hGL, gP.glfont, 10, 5, zMsg, 0xFF00FF00);
    }
and renamed IPS to FPS, but i didn't posted my latest code... waiting for the new billboard

BTW i have also been working on the new material Light setting meta.
Using these predifined constants

Code: [Select]

WCHAR zColor[] = L"aliceblue,0xf0f8ff,antiquewhite,0xfaebd7,aqua,0x00ffff,aquamarine,0x7fffd4,azure,0xf0ffff,beige,0xf5f5dc,bisque,0xffe4c4,black,0x000000,blanchedalmond,0xffebcd,blue,0x0000ff,blueviolet,0x8a2be2,brown,0xa52a2a,burlywood,0xdeb887,cadetblue,0x5f9ea0,chartreuse,0x7fff00,chocolate,0xd2691e,coral,0xff7f50,cornflowerblue,0x6495ed,cornsilk,0xfff8dc,crimson,0xdc143c,cyan,0x00ffff,darkblue,0x00008b,darkcyan,0x008b8b,darkgoldenrod,0xb8860b,darkgray,0xa9a9a9,darkgreen,0x006400,darkkhaki,0xbdb76b,darkmagenta,0x8b008b,darkolivegreen,0x556b2f,darkorange,0xff8c00,darkorchid,0x9932cc,darkred,0x8b0000,darksalmon,0xe9967a,darkseagreen,0x8fbc8b,darkslateblue,0x483d8b,darkslategray,0x2f4f4f,darkturquoise,0x00ced1,darkviolet,0x9400d3,deeppink,0xff1493,deepskyblue,0x00bfff,dimgray,0x696969,dodgerblue,0x1e90ff,firebrick,0xb22222,floralwhite,0xfffaf0,forestgreen,0x228b22,fuchsia,0xff00ff,gainsboro,0xdcdcdc,ghostwhite,0xf8f8ff,gold,0xffd700,goldenrod,0xdaa520,gray,0x808080,green,0x008000,greenyellow,0xadff2f,honeydew,0xf0fff0,hotpink,0xff69b4,indianred,0xcd5c5c,indigo,0x4b0082,ivory,0xfffff0,khaki,0xf0e68c,lavender,0xe6e6fa,lavenderblush,0xfff0f5,lawngreen,0x7cfc00,lemonchiffon,0xfffacd,lightblue,0xadd8e6,lightcoral,0xf08080,lightcyan,0xe0ffff,lightgoldenrodyellow,0xfafad2,lightgray,0xd3d3d3,lightgreen,0x90ee90,lightpink,0xffb6c1,lightsalmon,0xffa07a,lightseagreen,0x20b2aa,lightskyblue,0x87cefa,lightslategray,0x778899,lightsteelblue,0xb0c4de,lightyellow,0xffffe0,lime,0x00ff00,limegreen,0x32cd32,linen,0xfaf0e6,magenta,0xff00ff,maroon,0x800000,mediumaquamarine,0x66cdaa,mediumblue,0x0000cd,mediumorchid,0xba55d3,mediumpurple,0x9370db,mediumseagreen,0x3cb371,mediumslateblue,0x7b68ee,mediumspringgreen,0x00fa9a,mediumturquoise,0x48d1cc,mediumvioletred,0xc71585,midnightblue,0x191970,mintcream,0xf5fffa,mistyrose,0xffe4e1,moccasin,0xffe4b5,navajowhite,0xffdead,navy,0x000080,oldlace,0xfdf5e6,olive,0x808000,olivedrab,0x6b8e23,orange,0xffa500,orangered,0xff4500,orchid,0xda70d6,palegoldenrod,0xeee8aa,palegreen,0x98fb98,paleturquoise,0xafeeee,palevioletred,0xdb7093,papayawhip,0xffefd5,peachpuff,0xffdab9,peru,0xcd853f,pink,0xffc0cb,plum,0xdda0dd,powderblue,0xb0e0e6,purple,0x800080,red,0xff0000,rosybrown,0xbc8f8f,royalblue,0x4169e1,saddlebrown,0x8b4513,salmon,0xfa8072,sandybrown,0xf4a460,seagreen,0x2e8b57,seashell,0xfff5ee,sienna,0xa0522d,silver,0xc0c0c0,skyblue,0x87ceeb,slateblue,0x6a5acd,slategray,0x708090,snow,0xfffafa,springgreen,0x00ff7f,steelblue,0x4682b4,tan,0xd2b48c,teal,0x008080,thistle,0xd8bfd8,tomato,0xff6347,turquoise,0x40e0d0,violet,0xee82ee,wheat,0xf5deb3,white,0xffffff,whitesmoke,0xf5f5f5,yellow,0xffff00,yellowgreen,0x9acd32,";
and the matching global meta
// #frontAll
// #frontAmbient
// #frontDiffuse
// #frontSpecular

// #leftAll
// #leftAmbient
// #leftDiffuse
// #leftSpecular

// #rightAll
// #rightAmbient
// #rightDiffuse
// #rightSpecular

Thus
#frontAll aliceblue
will use the same 0xf0f8ff RGB color for the 3 front light parameters.

[Michael Lobko-Lobanovsky]

I already reworked it, that way

Your own way is not always the best way, you know. When in Rome, do as the Romans do. (c)   (let alone code elegance, now count how many if's there are in your solution and then count the same in everybody else's -- the one that I suggested. Oh c'mon Patrice, don't be so stubborn! )

... waiting for the new billboard

Your mockery is somewhat untimely, my friend. Look what your ObjReader stores in its mesh structures as meshRadius'es for the five exact same flare meshes you saw in the previous screenshot. 

Needless to say my Objector wouldn't permit itself such frivolities. Not in my presence. 

Thus
#frontAll aliceblue
will use the same 0xf0f8ff RGB color for the 3 front light parameters.

EXCELLENT!

[Patrice Terrier]

Look what your ObjReader stores in its mesh structures as meshRadius'es for the five exact same flare meshes you saw in the previous screenshot

I must say that i do not understand, nothing has been changed in this specific part of the code since the origine.
And this model has not been reworked into c4d, would be interresting to import/export inside of it, and see the result.

[Michael Lobko-Lobanovsky]

... nothing has been changed in this specific part of the code ...

I am not trying to blame you for this, Patrice.

Seriously, Objector uses the exact same C code in its calcMeshBounds() and everything's all right with it. There are evidently some other code permutations somewhere in ObjReader that affect the pMesh structure content adversely. We're using meshRadius'es in our mesh visibility checks. I'm currently trying to find out if ObjReader's C code might abuse the radius values in the process (Objector has its visibility checks written in assembly).

[Michael Lobko-Lobanovsky]

Oh, and I think there's no need for separate #frontAmbient, #frontDiffuse, etc. metacommands. Just let's have e.g.

#frontAll aliceblue

but for separate values lets have e.g.

#front aliceblue antiquewhite aquamarine

in the abmbient/diffuse/specular order.

I think this notation will match other statements of Wavefront Object vocabulary perfectly. 


P.S. Oh no no! Let them also stay for the cases e.g.

#frontDiffuse  255 255 0

where the per-component RGB's should be specified precisely! 

[Patrice Terrier]

OK, i shall use IsAlpha or something like that, to parse correctly the string

Added:
Ideally we should have a command to save the light settings into the mtl file...

[Michael Lobko-Lobanovsky]

Ideally we should have a command to save the light settings into the mtl file...

Actually I like the way you're thinking now, Patrice, and I'm glad I lived long enough to see it happen.

I've always told you that having these things just as toy renderers would be a waste of time and effort. They should be equipped with adequate (editing) instruments to adjust what we're seeing on our monitors and save our adjustments for future use.

P.S. Tell you more.

Ultimately, we should also have a possibility to directly edit the material file in its other aspects, immediately discard the older material settings, reload the newly edited materials, and apply them to their respective meshes while the model stays on screen.

I think that when such an option is implemented, you'll be spending more time in front of your ObjReader than you're spending now in your C4D.

[Michael Lobko-Lobanovsky]

                 

ObjReader's original Mobj_bounds() initialization code caused FPU overflow that made both model and mesh radii undefined. One may not evaluate a float for > 3.40000009536743e+38f (a.k.a. FLT_MAX) or < 8.43000030517578e-37f (a.k.a. FLT_MIN).

My calcMeshBounds() was a literal replica of your Mobj_bounds() and quite naturally made the same mistake.

_____________________________________________________

(took me 18+ hours to isolate...    you owe me a few beers...  )

[Patrice Terrier]

Dear Mike, i am very glad you found it, because i wouldn't have been able to diagnose this myself 

In the original code Mobj_bounds was defined like this:

Code: [Select]

void Mobj_bounds(float rCenter[3], float &rWidth, float &rHeight, float &rLength, float &rRadius) {

    float rxMax = 8.43000030517578e-37f;
    float ryMax = rxMax;
    float rzMax = rxMax;

    float rxMin = 3.40000009536743e+38f;
    float ryMin = rxMin;
    float rzMin = rxMin;

    float rX = 0.0f, rY = 0.0f, rZ = 0.0f;

    long numVerts = Mobj_getNumberOfVertices();

    for (long nI = 0; nI < numVerts; ++nI) {
        rX = gtm_vertexBuffer[nI].position[0];
        rY = gtm_vertexBuffer[nI].position[1];
        rZ = gtm_vertexBuffer[nI].position[2];

        if (rX < rxMin) { rxMin = rX; }
        if (rX > rxMax) { rxMax = rX; }
        if (rY < ryMin) { ryMin = rY; }
        if (rY > ryMax) { ryMax = rY; }
        if (rZ < rzMin) { rzMin = rZ; }
        if (rZ > rzMax) { rzMax = rZ; }
    }

    rCenter[0] = (rxMin + rxMax) / 2.0f;
    rCenter[1] = (ryMin + ryMax) / 2.0f;
    rCenter[2] = (rzMin + rzMax) / 2.0f;

    rWidth = rxMax - rxMin;
    rHeight = ryMax - ryMin;
    rLength = rzMax - rzMin;

    rRadius = max(max(rWidth, rHeight), rLength);
}

However, in the calcMeshBounds version, we are using since 03-14-2016
rxMax = FLT_MIN
rxMin = FLT_MAX
And the constant values are defined into float.h, like this:
#define FLT_MIN          1.175494351e-38F        // min normalized positive value
#define FLT_MAX          3.402823466e+38F        // max value

Code: [Select]

/////////////////////////
// V I S I B I L I T Y //  // ML: 03-14-2016
/////////////////////////

void calcMeshBounds() {
    MobjMesh* pMesh;
    float rX, rY, rZ;
    long nI, nJ, nK;

    for (nI = 0; nI < gnm_numberOfMeshes; nI++) {
        float rxMax = FLT_MIN; // close to -INF
        float ryMax = rxMax;
        float rzMax = rxMax;

        float rxMin = FLT_MAX; // close to +INF
        float ryMin = rxMin;
        float rzMin = rxMin;

        pMesh = &gtm_meshes[nI];
        for (nJ = 0; nJ < pMesh->triangleCount * 3; nJ++) {
            nK = gnm_indexBuffer[pMesh->startIndex + nJ];

            rX = gtm_vertexBuffer[nK].position[0];
            rY = gtm_vertexBuffer[nK].position[1];
            rZ = gtm_vertexBuffer[nK].position[2];

            if (rX < rxMin) { rxMin = rX; } else if (rX > rxMax) { rxMax = rX; }
            if (rY < ryMin) { ryMin = rY; } else if (rY > ryMax) { ryMax = rY; }
            if (rZ < rzMin) { rzMin = rZ; } else if (rZ > rzMax) { rzMax = rZ; }
        }

        pMesh->centerPoint[0] = (rxMin + rxMax) * 0.5f;
        pMesh->centerPoint[1] = (ryMin + ryMax) * 0.5f;
        pMesh->centerPoint[2] = (rzMin + rzMax) * 0.5f;

        float rWidth = rxMax - rxMin;
        float rHeight = ryMax - ryMin;
        float rLength = rzMax - rzMin;

        pMesh->meshRadius = max(max(rWidth, rHeight), rLength);
    }
}

void normalizeVec(float v[4]) {
    float mult = 1 / sqrtf(v[0] * v[0] + v[1] * v[1] + v[2] * v[2]);
    v[0] *= mult;
    v[1] *= mult;
    v[2] *= mult;
    v[3] *= mult;
}

void Mobj_CreateFrustum(float frust[6][4]) {
    long nI;
    float proj[16];
    float modl[16];
    float clip[16];
    float m0, m1, m2, m3;

    // Get current matrices
    glGetFloatv(GL_PROJECTION_MATRIX, proj);
    glGetFloatv(GL_MODELVIEW_MATRIX, modl);

    // Combine them (mult *modl* by *proj* into *clip*)
    for (nI = 0; nI < 4; nI++) {
        m0 = modl[nI * 4 + 0];
        m1 = modl[nI * 4 + 1];
        m2 = modl[nI * 4 + 2];
        m3 = modl[nI * 4 + 3];
        clip[nI * 4 + 0] = m0 * proj[0] + m1 * proj[4] + m2 * proj[8]  + m3 * proj[12];
        clip[nI * 4 + 1] = m0 * proj[1] + m1 * proj[5] + m2 * proj[9]  + m3 * proj[13];
        clip[nI * 4 + 2] = m0 * proj[2] + m1 * proj[6] + m2 * proj[10] + m3 * proj[14];
        clip[nI * 4 + 3] = m0 * proj[3] + m1 * proj[7] + m2 * proj[11] + m3 * proj[15];
    }

    // Build frustum
    frust[0][0] = clip[3]  - clip[0];
    frust[0][1] = clip[7]  - clip[4];
    frust[0][2] = clip[11] - clip[8];
    frust[0][3] = clip[15] - clip[12];
    normalizeVec(&frust[0][0]); // normalize here for sphere test!!!

    frust[1][0] = clip[3]  + clip[0];
    frust[1][1] = clip[7]  + clip[4];
    frust[1][2] = clip[11] + clip[8];
    frust[1][3] = clip[15] + clip[12];
    normalizeVec(&frust[1][0]); // normalize here for sphere test!!!

    frust[2][0] = clip[3]  + clip[1];
    frust[2][1] = clip[7]  + clip[5];
    frust[2][2] = clip[11] + clip[9];
    frust[2][3] = clip[15] + clip[13];
    normalizeVec(&frust[2][0]); // normalize here for sphere test!!!

    frust[3][0] = clip[3]  - clip[1];
    frust[3][1] = clip[7]  - clip[5];
    frust[3][2] = clip[11] - clip[9];
    frust[3][3] = clip[15] - clip[13];
    normalizeVec(&frust[3][0]); // normalize here for sphere test!!!

    frust[4][0] = clip[3]  - clip[2];
    frust[4][1] = clip[7]  - clip[6];
    frust[4][2] = clip[11] - clip[10];
    frust[4][3] = clip[15] - clip[14];
    normalizeVec(&frust[4][0]); // normalize here for sphere test!!!

    frust[5][0] = clip[3]  + clip[2];
    frust[5][1] = clip[7]  + clip[6];
    frust[5][2] = clip[11] + clip[10];
    frust[5][3] = clip[15] + clip[14];
    normalizeVec(&frust[5][0]); // normalize here for sphere test!!!
}

long isSphereInFrustum(float frustum[6][4], float center[3], float radius) {
    long nI;

    for (nI = 0; nI < 6; nI++) {
        float distance = frustum[nI][0] * center[0] + frustum[nI][1] * center[1] + frustum[nI][2] * center[2] + frustum[nI][3];
        if (distance < -radius * 0.5f) return 0;
    }
    return 1;
}
/////////////////////////

I already come accross this bug a few time, with the mesh becoming invisible...
I can make a video to show you how to replicate the problem with Tron.obj when swaping the Y,Z axes.
The front light become invisible when zooming in.

What are the new values you use now ?

[Michael Lobko-Lobanovsky]

Hi Patrice,

I'm also glad we've killed that beast of a bug!

Two answers:

The short one: just use a pair of reasonably large and small values. I'm currently using -/+ 1,000,000.0f (w/o comma separators). I've never seen a vertex whose coords would exceed, say, -/+10,000.f on any axis even in the world coordinate system. This is usually the maximum setting of view frustum's far Z plane when observing vast 3D terrains with distant oceans and mountains.

The long one:

-- ObjReader's code is built around floats. Objector's 100% compatible C code is built around doubles. This is because it's tightly interleaved with high-level interpreted BASIC procedures for non-time critical parts of the program flow. BASIC interpreters historically use doubles for their floating point calc, and FBSL is no exception to this rule.

-- FPU casts in C are very costly because they aren't just textual preproc directives. Each such cast is rather coded by the compiler into a chain of FPU instructions to be executed by the FPU module on the processor's VLSI chip at run time.  (so use floating-point casts sparingly in your C code if you're after the fastest code possible!)

-- Consequently, Objector uses a double-precision set of C trig library and OpenGL functions like sin(), cos(), glNormal3d, glVertex3d, etc. where ObjReader would use single precision glNormal3f, glVertex3f and sinf(), cosf(), etc. overloads.

-- Mobj-bounds()'s original 8.43000030517578e-37f/3.40000009536743e+38f (FLT_MIN/FLT_MAX) are perfectly OK for Objector that runs in double precision but appeared too much for the FPU under the MS VC compiler digesting the ObjReader's sources.

-- Apart from different value ranges for single and double precision, the compiler may choose different sets of FPU instructions to machine-code the C sources with. FBSL's C JIT compiler prefers to use the faster set of FPU instructions that neglect FPU overflows and automatically and transparently recover the FPU state back to normal after the overflow occurs. Apparently the MS VC compiler prefers to follow another strategy under similar circumstances.

Seriously, a bug of such type would be difficult to crack for a casual C programmer. We are lucky to have a compiler developer in our ranks, even if for just one such latent bug in the entire set of ObjReader sources.

[Michael Lobko-Lobanovsky]

And yes, please show me that glitch in WIP Trone.

I will probably also use that opportunity to explain why we're seeing so much z-buffer fighting in nearly every model exported as-is to OBJ files from LightWave, 3DS Max and other professional 3D editors.

P.S. No need for the video, Patrice. I'm seeing this glitch here too once my Y/Z axes are swapped in ObjReader or Objector alike. I'll look into a possible cause and will come back later with my findings. Evidently there's some spatial parameter or calc we overlooked to refresh after swapping the "up" direction. By the looks of it, it is our visibility code that mistakenly switches this mesh off.

[Patrice Terrier]

Thank you for the heads up!

I am still working onto the new mtl lighting material, and took the decision to use these:

#Light frontAll 1 2 3
#Light frontAmbient aliceblue
#Light frontDiffuse antiquewhite
#Light frontSpecular 255 255 240

they are all prefixed with #Light to easily detect that it is a lighting parameter.

Added:
I shall have to move the new color macro definition into mobj.h, to setup lightings from the mtl file.

Question:
why do you divide the byte color by 256 rather than 255?
r / 256.0f;
for example if the red byte is 255, the float value should be 1.0f rather than 0.9960937f

[Michael Lobko-Lobanovsky]

... took the decision to use these:

That's a very wise decision. I like it.

I shall have to move the new color macro definition into mobj.h, to setup lightings from the mtl file.

Do as appropriate to make the new code work with minimum mods to the rest of project. When we have nothing else to do, we'll reshuffle the declarations and implementations in such a way that everything that is OBJ format specific will go into mobj.h, and everything that pertains to the bare-bones loader and renderer will be grouped in Main.c. And then we'll be ready to start a new m3ds.h include file and add it to the project.

why do you divide the byte color by 256 rather than 255?

Because I have a good friend of mine who has grinded his teeth against colors and their properties and who's gonna correct me patiently whenever he notices occasional flaws in my code.

... 1.0f rather than 0.9960937f

... and to whom I'm gonna give a helping hand too by silently reducing, from time to time, his wild floating point numbers (0.9960937f) to within the permissible ranges (0.996094f).

[Patrice Terrier]

I think i have sorted it out, give me some more time to make sure of that.