Post-Processing

[Patrice Terrier]

Mike

Ok, i did further test, and with half the speed (IPS) then the mouse is much more responsive.
This is the exact same problem i had years ago in BassBox, when using mouse interaction with some of my visual plugins.

You can check this by yourself if you try to pan the model like crazy with the right mouse button, using the current code.
Then make another test, trying with this:

Code: [Select]

    if (AnimDelay == 0) { AnimDelay = gP.AniTick + TIMER_DELAY; }
    //if (gP.AniTick >= AnimDelay) { // MLL 02-14-2018: else it's 2 ticks too much! 999 and 0 below makes 1000.
    if (gP.AniTick > AnimDelay) { // IPS code
        AnimDelay = 0;
        gl_DrawScene();
    }

    //if (ReportDelay == 0) { ReportDelay = gP.AniTick + 999; } // MLL 02-14-2018: be consistent!
    //if (gP.AniTick >= ReportDelay) { // MLL 02-14-2018: else it's 2 ticks too much! 999 and 0 below makes 1000.
    if (ReportDelay == 0) { ReportDelay = gP.AniTick + 1000; } // IPS code
    if (gP.AniTick > ReportDelay) {                            // IPS code
By me the difference is obvious, this is the exact reason why i was first thinking of an "overclocking" option.

Most intensive 3D graphic applications are limiting themselves to 30 FPS for the same reason.

I think that we must be pragmatic and do our best to preserve the user interaction, your thought ?

Added:
I just read your previous post right now
wglSwapInterval(2) call and you'll get your stable 30 frames per second legally
Yes, perhaps wglSwapInterval(2) is the solution, i never used it so far.
Looking on how to use it.

[Michael Lobko-Lobanovsky]

I rather used the 360^o button on the LS panel for this demo implementation. Feel free to accommodate it to the Y rotation mode checkbox. I don't think we really need it to duplicate the button anyway.

30FPS is the default, 60FPS is "turbo". Have Fraps running and try to drag-and-rotate the model at the default setting. You'll see the FPS rate never exceeding 30. Switch on the "turbo" mode by clicking the 360^o button on the LS panel and watch the maximum rate climb up to 60FPS. Same applies to the Y rotation mode.

Search for MLL 02-18-2018: to see my mods.

The CPU/GPU load/system responsiveness is still dependent on: (in the order of importance)
-- poly count
-- default/maximized/full screen window size
-- visible distance to model
-- "illuminate both sides" setting
-- PPL or FFP
-- number of material textures (and consequently, number of texture lookups in the shaders)
-- backface culling
-- etc.

______________________________________________

P.S. Can we have an event fired when the nVidia/ATi icon is clicked in the main window caption? I'd like to see it pop up a small message box (similar to About...) to display some basic info on the current OpenGL video driver.

[Michael Lobko-Lobanovsky]

 

OMFG!!!

It isn't textures -- same thing seen untextured too!

I swear I didn't touch the shaders; that must be something related to either VBO's or IBO... I'll look into the matter tonight. Any glitches seen in the other models?

[UPD] It seems to be related to fast trig func approximations and needs further investigation...

[Michael Lobko-Lobanovsky]

No, the approximations aren't the immediate cause. They do have a very slight effect in the overall look of normals+tangents because they are used in both calculations and thus add up to each other, but not to such an extent as to make vast areas of adjacent polies unrenderable like this. My investigation is still in progress...

[Patrice Terrier]

Can we have an event fired when the nVidia/ATi icon is clicked in the main window caption? I'd like to see it pop up a small message box (similar to About...) to display some basic info on the current OpenGL video driver.

Here is the code to be completed

LRESULT CALLBACK WndProc(IN HWND hWnd, IN UINT uMsg, IN WPARAM wParam, IN LPARAM lParam) {
    long nW = 0, nH = 0, K, nMeshCount = 0, nValue = 0, nStatus = 0;
    HWND hCtrl = 0;
    MINMAXINFO* pMM;
    NMLISTVIEW* ptNMLV;
    NMHDR* ptNMHDR;
    WCHAR zTxt[MAX_PATH] = { 0 };
    POINT p = { 0 };
    RECT rc = { 0 };
    static long nSmoothMode;

    switch (uMsg) {

    case WM_NCLBUTTONDOWN:
        GetWindowRect(GetDlgItem(hWnd, IDC_GRAPHIC_CARD), &rc);
        p.x = LOINT(lParam); p.y = HIINT(lParam);
        if (PtInRect(&rc, p)) {
            wcscopy(zTxt, L"\nPut your message there");
            skDialogInfo (L"Graphic card", zTxt, L"");
        }
        break;

My investigation is still in progress...

I am crossing my fingers, for a solution that would preserve the use of VBO 

[UPD]
It seems that the new Q_fabs used to compare to epsilon, has an impact, restoring the original fabs code works better, however not perfect.

[Michael Lobko-Lobanovsky]

Here is the code to be completed

Thank you! I will use it when I'm through with the Ramjet glitch.

... preserve the use of VBO

There is no stopping VBO usage nor is there any alternative, just as there is no alternative to perpetual code optimization to make the render procs run faster and faster. Everybody else can do it, which means we will be doing the same eventually. And nobody is immune to mistakes. Professionalism means not being able to write bugless code, which is unrealistic, but rather being able to isolate the bugs promptly and eliminate them efficiently.

Re: UPD

Yes, I noticed it too. But I have a strong feeling that, once the true cause of the bug is eliminated, the approximations will resume their respective places in the code.

[Michael Lobko-Lobanovsky]

IT WAS ALL BECAUSE OF MY OWN INATTENTIVENESS AND NOCTURNAL LIFESTYLE!   

I was typing the new VBO glXxxPointer() calls by hand rather than copy-pasting them from the old VBA version and I overlooked that, though we're passing tangents to the shader as simple tex coords, we are storing them as float[4], rather than usual float[2], arrays.

To cut it short, leave all of the approximations alone exactly as they are in my code. They've got nothing to do with the glitch. Now goto Mobj_DrawUsingProgrammablePipeline() in mobj.h, scroll it down ca. 2/3 of its length, and fix the following:

........
            if (gnm_hasTangents) {
                glClientActiveTexture(GL_TEXTURE1);
                glEnableClientState(GL_TEXTURE_COORD_ARRAY);
                //glTexCoordPointer(4, GL_FLOAT, nVertexSize, Mobj_getVertexBufferTangent());
                glTexCoordPointer(4, GL_FLOAT, sizeof(MobjVertexT), (GLvoid*)32); // MLL 02-08-2018: 32 byte offset to 1st tangent
            }
........


That'll do the trick.

[Patrice Terrier]

Mike

Are you sure that you didn't change anything else, because that fix doesn't work by me with RAMJET 

[UPD]
That seems to work by me, only if i restore the original epsilon value, aka:
if (Q_fabs(rExtent) > 0.000001f) rScalingFactor = rScaleTo / rExtent; // MLL 02-09-2018: compare to epsilon!

Added
While RAMJET is working fine with epsilon 0.000001f, i still have problem with another new model. It always look good in FFP mode, and has several black sections in PPL.

More
Looks like using bump mapping could be the problem.

[Patrice Terrier]

Here is a single mesh to check with.

REM OUT map_bump from the mtl file, and switch to PPL mode, then it works correctly.

Conclusion, the problem occures only when bump mapping is used.
Mobj_generateTangents() ?

[Michael Lobko-Lobanovsky]

Yes. Tangent generation occurs only for the materials that have normal maps and thus use the gnm_NormalMappingShader program in Mobj_DrawUsingProgrammablePipeline(). Materials without normal maps use the gnm_BlinnPhongShader program that neither expects nor needs tangents when in the Mobj_DrawUsingProgrammablePipeline() mode. Finally, the concept of tangent space doesn't even exist in the context of immediate mode FFP.

[Michael Lobko-Lobanovsky]

OK Patrice,

So here come my tangent misalignment fixes.

All the approximations and epsilons are in their proper places, and a couple more added. A few superfluous statements have also been fixed. Everything seems to be running faultlessly for me now.

Your GPU button event code will go into v3.0. Please don't delete that message from the board yet; I'll do it myself when the time comes.

Let my comments stay in the sources for a while longer. We may clean them when the code proves to be safe and stable.

Enjoy!

[Patrice Terrier]

Thank you very much my friend !

Everything looks perfect with this fix.

Now i can complete my work on the "millenium falcon"

[Michael Lobko-Lobanovsky]

However could you review this post (feel free to edit anything you want).
http://www.objreader.com/index.php?topic=2.msg2627#msg2627

[UPD]

Patrice,

I made some slight grammar corrections in a few sentences but as far as the technical content is concerned, there's nothing much to add or alter.

[Michael Lobko-Lobanovsky]

The background texture issue is FIXED.

Patrice, your ZI_DrawGLText() was unbearably heavy for my CPUs. It kept eating up to 30% of their usages even when FPS was on but there was nothing loaded in the viewer.

Now the usage is no more than 1% extra as compared to FPS off. Some extra GPU is no wonder because when FPS is on, the viewer enters a continuous render mode where it always has something sizable to draw -- the wallpaper quad, as a minimum -- and that's what accounts for the GPU usage. So, I removed the "extra CPU/GPU" notification from the menu.

Please put the new PNG in \Reader  and recompile with the new Main.cpp and mobj.h. Now v2.5 Stable may go public. (hopefully )


P.S. The trailing argument in your Mobj_CreateGLTextureFromFileEX() is not a yes/no Boolean as the gP description erroneously states, but rather something that can have at least 5 different values in the 0 to 4 range. Can we have these values gathered into an enum with meaningful names to prompt the developer with what to expect from the function?

[Patrice Terrier]

Mike

My ZI-DrawGLText must deal with any kind of string and color, moreover all my applications are now using native UNICODE strings that must be first converted to CHAR to deal with OpenGL.

Code: [Select]

MLL: removed from prying eyes of nosey peepers. ;)
However for the specific case of FRAPS, of course we can make it very simple.
I even have a function to display TTF private fonts that is even more complex, however very handy (Chart3D).

BTW: We could rem out all the code related to the creation of the "TREBUCHET MS" font, if we don't need it anymore, however i must make sure first that we won't use it in the future...