Peugeot-Onyx (concept car)

[Patrice Terrier]

This is my next 3D challenge...

[Michael Lobko-Lobanovsky]

... without post processing i have to figure out for the best way to do it.

Post-processing is the ultimate goal yet there's a hint on how it  can be approximated for the time being.

Apart from the ambient, diffuse and specular illumination components we're using on our materials in both ObjReader and Objector, there's also the so-called emissive lighting component that defines if the material is supposed to look as if it would emit its own light (like e.g. red-hot or molten metal) and if yes, then how intense such emission should be and what color it should have. The material emissive color is not affected by the colors of scene lights nor does it light or colorize the other objects on the scene.

GL_EMISSION is handled through its own color array exactly like the other GL_AMBIENT/DIFFUSE/SPECULAR color components. For glMaterial(...,GL_AMBIENT,...), glMaterial(...,GL_DIFFUSE,...), glMaterial(...,GL_SPECULAR,...) to have any effect on the actual material color, the scene must also explicitly define the corresponding light sources (lights). For glMaterial(...,GL_EMISSION,...) to work, lights are not needed nor taken into account when OpenGL calculates the material's final color to render if the GL_AMBIENT/DIFFUSE/SPECULAR components for the material and corresponding lights aren't used/defined or are set to 0.

Some Wavefront Object dialects define this component through the material's Ke parameter. There may even be a separate dedicated emissive texture assigned to the mesh material via a map_Ke statement, that would define the mesh's "light emitting"/"glowing" regions against its other parts which are illuminated with the regular scene lights and own colors and thus don't appear glowing/neon-lit/red-hot/whatever. Google for the GL_EMISSION constant for further reading on this illumination component.

When the ordinary ambient, diffuse and lighting illumination of the scene isn't too bright and intense, OpenGL material emission color might be sufficient even to emulate genuine volumetric glow of GLSL post-processing shaders for simple alpha textured models or meshes.


FFP:



PPL:

[Michael Lobko-Lobanovsky]

Merci beaucoup Patrice!

Now I have something to have fun with for the coming New Year holidays. 

[Patrice Terrier]

Mike--

I am thinking to add a simple demo mode into ObjReader to perform auto-giration of the model (0-360) using
glRotatef(rangle, 0.0f, 1.0f, 0.0f);

That would help to create smooth video presentation of the model, your thought ?

See the attached video example 

Added:
I have attached the latest Main.cpp that allows the use of the new "Demo mode".
You can also use either '+' or '-' to speed up or slow down the rotation.
Next effects, could be light rotation and/or color change.

By the way, i think i have completed the model by now, i am just waiting to see your own glow effect before posting the official version ...

[Michael Lobko-Lobanovsky]

I am thinking to add a simple demo mode into ObjReader to perform auto-giration of the model (0-360) using
glRotatef(rangle, 0.0f, 1.0f, 0.0f);

Good idea, actually.

That would help to create smooth video presentation of the model, your thought ?

You mean, what would help? First, disable Vsync, if any, and thus allow the viewer render the scene at the fastest FPS rate it can deliver for a given model depending on the CPU calc power and the model's geo complexity, and second, choose the smallest corresponding rotation angle per frame. The simpler the model, the smaller the angle and the smoother the visible rotation. OpenGL is always one big compromise between what the PC can deliver and what you'd like to see.

At any rate, disabling Vsync will dramatically increase both CPU and GPU load for the models of such complexity, Patrice. That's why they will never be used without prior polygon crunching (i.e. simplification and re-triangulation) in real-time gaming contexts.

I have attached the latest Main.cpp that allows the use of the new "Demo mode".
You can also use either '+' or '-' to speed up or slow down the rotation.

Thanks, I will recompile my ObjReader to incorporate the rotation effect.

Next effects, could be light rotation and/or color change.

Would be nice to have such options too.

i am just waiting to see your own glow effect before posting the official version ...

When (and if at all) I succeed, you will have to re-release your ObjReader again and, possibly, review the concept of other models as well. So the Onyx model isn't going to be in permanent stasis either.

[Michael Lobko-Lobanovsky]

No Patrice,

You won't be able to produce smooth animation with ca. 3.5M polies to dynamically process AND draw in each render frame. The renderer obviously lags behind your timer simply rejecting the extra draw calls its OpenGL buffers aren't ready to process because they are still drawing the frame that was requested three or four calls before.

By the looks of it, the real FPS rate in your ObjReader while animating the Onyx model isn't higher than some 10 or 12 frames at the most regardless of timer settings.

Rendering the same model in my Objector that delivers the maximum un-Vsync'ed FPS rate possible for a given model by invalidating the canvas immediately after draw in the WM_PAINT event, proves that fact. Objector has a somewhat faster render function written entirely in assembler, yet its historical readings are documenting the real FPS rate for this model at 10 or 11 frames per 1000 milliseconds. (see my screenshot below)

More or less smooth animation requires at least 30 frames per second. 24 FPS as in the cinema movie is the absolute minimum.

My compliments on the model's headlight glow. You did the absolute best that could ever be done with the materials and render techniques available.

[Patrice Terrier]

Mike--

Thank you for the feedback.

I can realy see a huge difference between running it on my I5 ASUS Transformer, and my gaming ASUS G752VY.

On the gaming machine everything is smooth, even at the lowest rotation angle step of 0.25°.

I have already decimated some of the hidden meshes, but i shall see if i can do it further more.
I shall create UV's coordinate in c4d to be seen only from front, i don't know if that could make any difference.

Added
Currently on my ASUS G752VY, the frame rate i have with this model is 17 FPS, while it is twice as big with most of my other models.

Updated
While the maximum FPS could be 66, it has been limited to 34, to be more cooperative with the other applications, if i drop the limitation (and after a tedious work of decimation) i got a FPS of 21-22, instead of 17.

Currently the model has these values
Vertices 1939151
Triangles 3304388
Meshes 69
Materials 49
Indices 9913164

[Michael Lobko-Lobanovsky]

Triangles 3304388

300K tris is a win indeed! Congrats!

... i am just waiting to see your own glow effect before posting the official version ...

Patrice,

You're probably underestimating the importance of the task. I think it's more urgent at this moment than decimation, or auto-rotation, or both taken together.

Surprisingly enough, when I looked again into my Objector code after a year or so of near total oblivion, I found out it's been having everything it needs for cheap GL_EMISSION to work for at least 2 recent years.

Please take a look below.  GL_EMISSION is the material color property that doesn't depend on the material's or scene lights' other colors or intensity. That's what makes it particularly suitable for cheap glow emulations. But I'm sorry to say your current alpha glow texture is absolutely inadequate to implement GL_EMISSION up to its full potential.

I'm hereby proposing a deal as follows:

1. You generate an alpha texture véritable enough to pass for a headlight flare in your existing ObjReader/Onyx and map it appropriately to your headlight glow meshes. (I think this and this may help you do just that)

2. As soon as you send me one of those that I can accept, I'll send you back the Mobj/Main sources equipped to use GL_EMISSION for you to bring the model and its textures to perfection.

I am not talented enough to do that as easily as you undoubtedly can.


Is it a go?

P.S. I planned to attach a min. Objector.exe setup for you to test your glow texture attempts with but unfortunately, my sources somehow refuse to compile into a standalone exe. I.e. it works OK when JIT compiled directly to memory (my usual code test mode) but crashes on model load when compiled to a static exe ...

P.P.S. The below renders were made with the following glow material settings:

newmtl glowing
Ka 0 0.8 1
Kd 0 0.8 1
Ks 0 0.8 1
Ke 0 0.8 1
map_Kd glowing.png
Ns 512
d 0.7
illum 2

They help increase the glow material overall brightness against the other materials as the scene illumination brightness rises from 0 to 255/255 (0% to 100%). When the light intensity is nil then only Ke is seen, when it is 100% then the other K components add their cyan too. Thus the glow material stays just as bright against the other materials in the scene as it appeared in total darkness. But alas, the configuration of alpha mask is totally wrong and unrealistic for a car headlight flare...

[Michael Lobko-Lobanovsky]

Hi Patrice,

Is this flare above supposed to have another glow mesh geometry, not the one that's implemented in your last wip model? If the flare somehow fits in the existing glow mesh, can I have it too?

I've done most of coding and I'm planning to send you the files soon. But that's not going to be all. I'm also planning to add a simple extra dialog window for some interactive lighting adjustments. You'll see what and how the dialog gadgets tend to control, and then you'll (hopefully) re-implement the same functionality in your main window control pane using your skinned controls. Most of these options work for me through hotkeys in my Objector.

[Patrice Terrier]

Another one, using AlphaToCoverage

[Michael Lobko-Lobanovsky]

A2C may yield unwanted step-like transparency gradations rather than smooth transition gradients though of course the edges will be absolutely invisible against any backgrounds and colors and under any illumination intensities.

At any rate, you'll have more options to try when GL_EMISSION is there. I have updated the loader and renderers but I also would like to add a few lighting options. I couldn't physically manage to complete all that "in one sitting".

I'm a little overloaded with real life work after 4 days of holidays but my mods to ObjReader are materializing little by little. I'll send them to you in a day or two, as soon as I'm ready.


P.S. I also squeezed another 3 extra FPS for Onyx out of ObjReader renderer. I'm having now a stable 14FPS rate verified by Fraps.

[Michael Lobko-Lobanovsky]

Patrice,

Here is a new WIP, with further decimation ...

Thanks, the flares look great! Watch them also in an A2C GL_EMISSION color...   (screen 1 below)

... reworked A2C materials

See the A2C transparency gradation steps I noted before? Of course they aren't noticeable at a distance thanks to your outstanding skills, but they're there nonetheless. They aren't your fault, they are inherent in the A2C dithering method. (screen 2 below)

Ideally it would be nice to apply A2C only to a specific material...

I've been talking about this all the time ever since we started. And not only A2C but also other features like face culling, both-sides lighting, multiple per-material colored light sources, etc. -- everything that's extra to the Wavefront Object vocabulary can be controlled by #metacommands placed inside the newmtl definitions, in which case they would only affect this particular newmtl. The #metacommands at the very top of .mtl where no newmtl is yet defined could stay global just the way they are now.

And yes Patrice, we will need billboard flares badly for our FFP mode where post-processing is impossible by OpenGL design. Billboard flares aren't post-processed; the size and orientation of their respective quads is simply and easily recalculated in real time every time the cursor button-down drag mode movement is detected.

To increase the FPS while in "Y rotation mode", try this...

Great! This yielded yet 1 more extra FPS for Onyx. Now I'm seeing 15FPS as reported by Fraps in the FFP mode. My video chips are a little less powerful than your gaming laptop's video card, hence a somewhat lower overall FPS rate.

Fraps is pretty exact, non-intrusive, both 32 and 64 bit friendly, and works for OpenGL and DirectX equally well. I can't use my GeForce Experience reliably with my SLI-bridged video cards under Windows 7 because it's glitchy when working with more than 1 card simultaneously. (screen 3 below)

a simple FPS counter, when using rotation

You might but SetWindowText() is usually too heavy for OpenGL to synchronize itself with when drawing very complex geometries. Generally it isn't recommended except in simple low-poly renderers. My Objector's renderer draws its gadgets in OpenGL and luckily allows me to add one or two FPS counters alongside a hellofalot of other stuff and still stay basically compatible with your FPS readings, even if all this data would only be relevant in the yet-unimplemented editing mode of Objector operation.

[Patrice Terrier]

Mike

Thank you for the report.

To display FPS i shall use what i have done so far in my OpenGL plugins, to avoid the use of SetWindowText.

So far i have been able to decimate a little more the model without noticeable quality loss.
I reworked again the flare to get the attached result, that i think looks quite realistic while in A2C mode.
The model must be seen very closely to see the A2C artefacts, but then they are plainty of other small defaults that become visible at this level of magnification.

About bilboarding i wrote a generic function into GDImage for that purpose, you can see it in action in my 3D Chart demo project here: http://www.objreader.com/index.php?topic=17.0
I shall see if we can use it also with ObjReader.
In the 3D Chart project the first row of buble spheres are indeed bilboarded quads

About FRAPS i don't think that it is working on Windows 10; but i can use the one provided by nVIDIA until we have our own tomorrow

For the fun of it, i have attached a screen shot to show you the matching C4D's project. As you can see, there is a lot of imagination effort to do, just to figure what would be the result once rendered into ObjReader...

[Michael Lobko-Lobanovsky]

I shall see if we can use it also with ObjReader.

It can be a good place to start with per-material #metacommands:

-- add a bool isBillboard property directly to your MobjMat structure
-- use #billboard metacommand just under its newmtl flare definition in the .MTL file
-- set isBillboard = true if the above #metacommand is read by Mobj_importMaterials() when importing this particular material
-- rotate the flare additionally in response to if (pMaterial->isBillboard) as appropriate in an extra call directly from Mobj_DrawUsingFixedFuncPipeline() just before the flare material is drawn

and you can do similar things for any other non-Wavefront material property (A2C included) used on a per-material basis via its respective #metacommand.

( Haven't seen my own 3D editors' development screens in years )

[Patrice Terrier]

Mike

Here are the 2 GL functions i am using into GDImage to perform point billboarding.

Code: [Select]

void GL_BillBoard () { // dllexport
    // Create MultMatrix
    float mm[16] = {1.0f, 0.0f, 0.0f, 0.0f,
                    0.0f, 1.0f, 0.0f, 0.0f,
                    0.0f, 0.0f, 1.0f, 0.0f,
                    0.0f, 0.0f, 0.0f, 1.0f};

    float m[16]; glGetFloatv(GL_MODELVIEW_MATRIX, &m[0]);
    // Convert to OpenGL matrix notation
    mm[0] = m[0];
    mm[1] = m[4];
    mm[2] = m[8];
    mm[4] = m[1];
    mm[5] = m[5];
    mm[6] = m[9];
    mm[8] = m[2];
    mm[9] = m[6];
    mm[10] = m[10];
    glMultMatrixf(&mm[0]);
}


Code: [Select]

void GL_ChartPoint (IN float Radius, IN float rValue) { // dllexport
    glPushMatrix();
       glTranslatef(0, rValue, 0);
       long nJ;
       // Pre-computed circle.
       static long nDone;
       static vector<float> sint;
       static vector<float> cost;
       if (nDone == 0) { nDone = -1; CircleTable(sint, cost, -32); }

       // Always show it in front of the camera.
       GL_BillBoard();

       glBegin(GL_TRIANGLE_FAN);
          glNormal3f(0.0f, 0.0f, 1.0f);
          glTexCoord2f(0.5f, 0.5f);
          for (nJ = 32; nJ > -1; nJ--) {
             glTexCoord2f((cost[nJ] + 1) * 0.5f , (sint[nJ] + 1.0f) * 0.5f);
             glVertex3f(cost[nJ] * Radius, sint[nJ] * Radius, 0.0f);
          }
       glEnd();
    glPopMatrix();
}

Now i have to look back into my 3D Chart project, to remember the best way to use it

To display the FPS i shall use my ZI_DrawGLText.
Better to re-use the code from the existing DLL rather than writing a new one.