Migration to FBO

[Patrice Terrier]

Mike

Ok, here are the latest changes i did to the project, altogether with the new rotate.png (to increase its visibility on all kind of background).

Does your sending me this mesh mean you don't want to experiment any further with your quasi alpha shadow's displacement relative to the model and would rather try true stencil shadowing solutions?

About the provided mesh it was just a first shot to see if this kind of decimation was enough to be used as a stencil shadow pass, obviously not

For now, the quasi alpha shadow's displacement is all what we need, for compatibity with the existing models, and because we do not have {yet} any extra environment around the model.

[Michael Lobko-Lobanovsky]

DL'ed OK, thanks!

Should the quasi shadow get split when the model is lit by more than 1 light? If yes, then should the split sub-shadows get tinted depending on the color of the other lights the shadowed areas still see as unobscured by the model?

[Patrice Terrier]

Should the quasi shadow get split when the model is lit by more than 1 light

The closer to real shadow, the better.
If we are outdoor, nothing could beat the sun brightness, but in a photo studio things could be different, i leave this to your appreciation...

About tinted shadow, i never thought of that

[Michael Lobko-Lobanovsky]

Probably this picture will give you a better idea of what it means in real world to be lit simultaneously with three differently colored light sources that have different space positions but are all directed to the center of the model exactly like our directional lights are.

In fact, we have no directional light falling from above on top of our cars, so our quasi shadow isn't realistic. OTOH we could somehow determine which of the lights is currently the brightest and displace our singular quasi shadow somewhat in the opposite direction. Needs testing to see if this would look convincing, especially if we decide to auto rotate our lights in real time... 

 

[Patrice Terrier]

Thank you for the head's up

OTOH we could somehow determine which of the lights is currently the brightest and displace our singular quasi shadow somewhat in the opposite direction

Or perhaps always use the Front ambient (indeed the leading lighting), except if it is being turned off...

PS: I am working on a glossy Bugatti Veyron...

[Michael Lobko-Lobanovsky]

Or perhaps always use the Front ambient ...

NO!

The ambient component is an OpenGL/Direct3D fake to emulate real world light scatter due to multiple reflections from the nearby objects' surfaces. No real world surface is completely black to absorb all the light that falls on it, so the effect of multiple reflections and resultant scatter is pretty strong. Look out of your window on a winter night and see how bright it is even when it's moonless. The light you're seeing is actually multiple reflections of Greṇble's (?) street lights between the low cloudy skies and the snow that covers the ground.

The main visual effect of ambient lighting is that it seems to come from nowhere in particular but rather from everywhere all around you, and as such, it cannot cast a distinctly directional shadow.

[Michael Lobko-Lobanovsky]

Hi Patrice,

Below please find my patch to allow for arbitrary GL_CLAMP_TO_EDGE mipmapping. It pertains to ObjReader v2.5 though the code already uses some changes that are going to be introduced in v3.0 WIP.

The logic is as follows:

• To clamp an arbitrary material's texture(s) to edge, use the keyword clamp immediately following map_Kd but before the texture name proper, e.g. map_Kd clamp tex00.png. Do not use the keyword with other texture types because it won't be recognized there. Yet when specified for map_Kd, it will automatically apply to the other textures in that material, if any.
• Clamped textures are mipmapped unless Mipmap textures is unchecked in the menu.
• Billboards are clamped on default and do not require explicit clamp. They are also mipmapped unless Mipmap textures is unchecked in the menu.
• Wallpapers are always clamped but never mipmapped, so do not use clamp for wallpapers at all.

Use your carousel model in both mipmapped and unmipmapped modes to see the difference clamping makes on the borders of textured quads.

[Patrice Terrier]

Mike

Thank you for this patch, i shall merge it with what i have done already (worked also on clamp, but will gladly switch to what you have done).

I twisted my right foot, thus i can't stay for too long in front on my computer (have to keep my leg horizontaly) ...

I shall come back to you once merged.

[Patrice Terrier]

Here is the merged patch with my own changes.

Thank you.

[Michael Lobko-Lobanovsky]

Thank you Patrice,

Everything works flawlessly for me here.

Why does the control panel just pop up when F1-ed but slide left out of view when closed with the panel button? Can it also slide into view from the left when F1-ed? I'd like it better that way.

If it can slide both in and out, then have you ever considered exponential sliding motion so that the panel would first start fast but would then decelerate exponentially as it moves to its finish position, either in to or out of view?

[Patrice Terrier]

Mike

Try playing with this in ProcessMenu

Code: [Select]

    case MENU_LIGHTSETTING: // PAT: 01-30-2018
        if (IsWindow(gP.hOverlay)) {
            long OverLayVisible = IsWindowVisible(gP.hOverlay);
            GetWindowRect(gP.hGL, &lpr);
            if (OverLayVisible) {
                for (long w = OVERLAY_WIDTH; w >= 0; w-=1) {
                     MoveWindow(gP.hOverlay, lpr.left, lpr.top, w, Height(lpr), true);
                }
                ShowWindow(gP.hOverlay, SW_HIDE);
                SetWindowPos(gP.hOverlay, HWND_NOTOPMOST, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE); // PAT: 02-12-2018
            } else {
                //MoveWindow(gP.hOverlay, lpr.left, lpr.top, OVERLAY_WIDTH, Height(lpr), false);
                ShowWindow(gP.hOverlay, SW_SHOW);
                if (gP.nIsFullScreen) { SetWindowPos(gP.hOverlay, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE); } // PAT: 02-12-2018
                for (long w = 0; w <= OVERLAY_WIDTH; w++) {
                    if (w % 20 == 0) {
                        MoveWindow(gP.hOverlay, lpr.left, lpr.top, w, Height(lpr), false);
                        WindowRedraw(gP.hOverlay);
                        gP.redraw = -1; gl_DrawScene();
                    }
                }
                MoveWindow(gP.hOverlay, lpr.left, lpr.top, OVERLAY_WIDTH, Height(lpr), true);
            }
            SetFocus(gP.hGL);
            gP.redraw = -1; // Redraw the OpenGL scene
        }
        break;

[Michael Lobko-Lobanovsky]

Hehe Patrice,

Thank you! This is what I ended up with in v3.0 WIP:

Code: [Select]

    case MENU_LIGHTSETTING: // PAT: 01-30-2018
        if (IsWindow(gP.hOverlay)) {
            GetWindowRect(gP.hGL, &lpr);
            if (IsWindowVisible(gP.hOverlay)) {
                for (long w = OVERLAY_WIDTH; w > 0; w--) {
                    MoveWindow(gP.hOverlay, lpr.left, lpr.top, w, Height(lpr), false);
                }
                SetWindowPos(gP.hOverlay, HWND_NOTOPMOST, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_HIDEWINDOW | SWP_DEFERERASE); // PAT: 02-12-2018
            } else {
                ShowWindow(gP.hOverlay, SW_SHOWNOACTIVATE);
                if (gP.nIsFullScreen) { SetWindowPos(gP.hOverlay, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE | SWP_DEFERERASE); } // PAT: 02-12-2018
                for (long w = 0; w <= OVERLAY_WIDTH; w++) {
                    if (w % 30 == 0) {
                        SetWindowPos(gP.hOverlay, 0, 0, 0, w, Height(lpr), SWP_NOZORDER | SWP_NOMOVE | SWP_NOACTIVATE | SWP_DEFERERASE);
                        WindowRedraw(gP.hOverlay);
                    }
                }
                MoveWindow(gP.hOverlay, lpr.left, lpr.top, OVERLAY_WIDTH, Height(lpr), true);
            }
            SetFocus(gP.hGL);
        }
        break;
The code seems to run both ways with more or less equal speed, and it doesn't shift the focus off the main window so vividly. Of course it blocks model rotation for a split second while sliding in or out but that's not so annoying after all. Also, sometimes the tooltips appear behind the control panel buttons while in full screen mode, but this may be due to my monitors having several macOS-ish sliding dockbars where I store a number of my everyday tools. Those also fight for being at HWND_TOP from time to time so the occasional glitches may be attributed to them but anyway these are minor artifacts because fullscreen isn't used so very often IMO.

[Patrice Terrier]

Mike

I did put your "ended up" into mine.

The go.hTip gives you the real handle of the tooltip window, you can use it to force its topmost order.

I am doing this already into the ToggleFullScreen subroutine into Main.cpp.

Code: [Select]

if (IsWindow(go.hTip)) { SetWindowPos(go.hTip, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE); } // PAT: 02-12-2018

[Michael Lobko-Lobanovsky]

Ah yes,

Adding your line like this did the trick of keeping the tooltip in front of the control panel buttons while in the fullscreen mode!

Code: [Select]

........
                }
                MoveWindow(gP.hOverlay, lpr.left, lpr.top, OVERLAY_WIDTH, Height(lpr), true);
                if (IsWindow(go.hTip)) { SetWindowPos(go.hTip, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE); } // PAT: 02-12-2018
            }
            SetFocus(gP.hGL);
        }
        break;

[Patrice Terrier]

Ok, i have updated the source code.