Early WIP on v2.55

[Michael Lobko-Lobanovsky]

How can I make the splitter color exactly the gray right panel color? Is it an RGBA constant or a brush from the \Reader PNG/JPG images? How can I tile it with the CTLBACK.jpg skin? (I do not need translucency; it should be of the exact gray color the right panel uses)

[Patrice Terrier]

Easy

// Create a popup GDImage overlay window
HWND CreateSplitter(IN HINSTANCE hInstance) {
    RECT lpr; GetWindowRect(gP.hGL, &lpr);

    DWORD dwStyle = WS_POPUP | WS_VISIBLE;
    DWORD dwExStyle = WS_EX_TOOLWINDOW;
    HWND hWnd = CreateWindowEx(dwExStyle, GDImageClassName, NULL, dwStyle, lpr.left + Width(lpr), lpr.top, SPLITTER_WIDTH, Height(lpr), gP.hMain, 0, hInstance, NULL);
    if (IsWindow(hWnd)) {

        //Setup the custom color background here
        ZI_SetProperty(hWnd, ZI_GradientTop, ZD_ARGB(128, 0,255,0));
        ZI_SetProperty(hWnd, ZI_GradientBottom, ZD_ARGB(128, 0,255,0));

        ZI_UseWinLIFTbackground(hWnd, TRUE, FALSE);

The beauty of this API is that it would work also with a complex background, if you use it in the Callback WM_MOVING section

[Michael Lobko-Lobanovsky]

Awesome, thnx!

[Michael Lobko-Lobanovsky]

Patrice,

One of my recent renderers must have broken the global A2C -- it switches off permanently after 1 frame render.

To fix the problem, please add in renderers.h the following statements at the very end of both main render functions:

drawUsingFixedFuncPipeline()
........
            // Test rotation
            if (doRotate) { glPopMatrix(); }
        }
    }
    if (gP.nAlphaToCoverage) glEnable(GL_SAMPLE_ALPHA_TO_COVERAGE_ARB);
}

drawUsingProgrammablePipeline()
........
            // Test rotation
            if (doRotate) { glPopMatrix(); }
        }
    }
    if (gP.nAlphaToCoverage) glEnable(GL_SAMPLE_ALPHA_TO_COVERAGE_ARB);
    glUseProgram(0);
}

[Patrice Terrier]

Done, thank you!

[Michael Lobko-Lobanovsky]

Patrice,

Just for you to know what I'm currently doing, I'm busy studying and implementing PBR and (possibly) soft shadows in ObjReader.

It's all very intricate stuff and it isn't going to be very fast -- but I am progressing slowly but steadily.

Please also remind me of what Rxx version exactly your Cinema 4D is?

[Patrice Terrier]

Currently i am using C4D Prime version R17

I thought you were working on the splitter code, if not, i shall make a few changes 

Added
Please change this into constants.h

#define SPLITTER_WIDTH 7
//#define ClientW       1166 + 20 // 1188 //1024 + 164
//#define ClientH       600 + 20 + 73 // PAT: 10-10-2018
//#define ClientWGL     1032 + 20
#define ClientH       672
//#define ClientWGL     1042
//#define ClientW       ClientWGL + 136
#define ClientWGL     1042 - SPLITTER_WIDTH
#define ClientW       ClientWGL + 136 + SPLITTER_WIDTH

and add this at line 289 of globals.h
    long        usePal;        // PAT: 01-03-2018
    long        splitXoffset;  // PAT; 12-16-2018

    DWORD       aniTick;       // PAT: 02-04-2018

[Michael Lobko-Lobanovsky]

I actually made a few changes to your splitter code because as it is, it wouldn't respond to the mouse. Because of your constant HTCAPTION test, the mouse thinks it's always in the non-client area. Therefore the mouse events must be made non-client too. Another problem is the non-client mouse wouldn't generate NCxBUTTONUP events (except after an NCxBUTTONDBLCLK) because it's captured by the splitter dragging process, and I have to synthesize NCxBUTTONUPs myself to be able to detect end-of-dragging and resize gP.hGL accordingly. I can send you the code if you wish.

So, editing options are a vast area of activity and I decided to first implement our more immediate needs , which however also implies a substantial learning curve. The worst thing is PBR is relatively new, and there's little practical code available on the net. Nonetheless I was able to find some that we can use but, in its turn, it also requires our camera to be re-written to match the matrices the PBR shaders need.

Thus, there's much to be learnt and experimented on.

If you want, you can finish off the splitter yourself in the meantime, so that it would actually reshape gP.hGL reliably in windowed, full screen, and light panel modes. There's no need for a second gP.hGL at this stage because the first editing thing I'm going to add (mesh UV remapping) will use a 2D GDI, rather than OpenGL, window and drawing side by side with the existing gP.hGL.

[Michael Lobko-Lobanovsky]

My friend,

This is cool!

Actually I wanted gP.hGL to resize while splitting so that the model is always in view. But your scenario can work for us too if we stretch gP.hMain over two monitors for the model to be at least partially seen even when gP.hGL rolls to the left as-is. I'd like the editing operations to be visible in the model on the fly.

Now please make the splitter responsive to WM_NCLBUTTONDBLCLK in such a way that when it is double clicked in its rightmost position, it would snap to the viewport center, otherwise, to its rightmost position. If possible, make it slide smoothly rather than snap, similar to how the lighting panel slides in and out of view.

Why wouldn't you download my code?


(I asked about your C4D version because I suddenly came across an open-source library that loads modern C4D models up to version R20.0 in any viewer/editor without needing an original C4D installation.)

[Patrice Terrier]

I have downloaded your code, but there is not much i could use from it with the changes i have done. 
 
What to do of the splitter control in case of full screen mode?

My opinion is that we must hide it, and display only the main GL control (as it is right now), and use edit mode only in window mode.

Note: You can capture all the mouse messages you need for the splitter in DetectHotKeys bypassing the Windows message cracker.

[Michael Lobko-Lobanovsky]

1. No problem, use just what you need or nothing, but please make it respond to a double click as I described.

2. There's no need to intercept anything in DetectHotKeys. Your message listener works OK but there won't be any client mouse messages there or elsewhere as long as you return HTCAPTION alone in your hit test handler; all the messages will be non-client only. So, the double clicks I'm talking about will be non-client as well.

3. I agree to hiding the splitter in full screen but when quitting full screen, the split window configuration should be restored.

4. Lastly, whenever the mouse button is released over the splitter, keyboard focus should be shifted programmatically over to gP.hGL immediately else we can't use ESC or CTRL until we click on gP.hGL. To implement this, you should intercept WM_NCLBUTTONUP (see item 2) but you won't be able to because Windows doesn't generate this message when the mouse is captured. And it is captured when the splitter is being dragged. So, you will have to synthesize it like I'm doing in my code, and then handle it in its own handler in the message listener as appropriate.

[Michael Lobko-Lobanovsky]

No problem sync'ing, just will need a little more time to respond.

Why RTF and not a regular CHM?

[Michael Lobko-Lobanovsky]

No, for me the light panel and toast window pop up outside of gP.hMain when I press F1 and/or switch to a fancy mode when the splitter is moved anywhere to the left.

The keyboard focus is not returned to gP.hGL or gP.hMain (either will do) when the splitter is released.

Why do you make the splitter crawl upon the left side border of main window? Let it stop at the border like my splitter does. It's sufficient to shift gP.hGL completely out of view.

[Patrice Terrier]

Why do you make the splitter crawl upon the left side border of main window? Let it stop at the border like my splitter does. It's sufficient to shift gP.hGL completely out of view.

because we have to give the whole viewport for the next gl control, other we loose the width of the splitter

Also we couldn't compute anymore F1 and the ToastWindow on the size of the OGL control because of the offset used.
I am fixing this right now.

For the toastwindow we must use this at line 122
    RECT rw; GetWindowRect(gP.hGL, &rw);
    long y = rw.bottom - UseH;

    // PAT: 12-16-2018 we must align on main window rather than OGL control, in case we change size
    rw; GetWindowRect(gP.hMain, &rw);
    rw.right -= skGetSystemMetrics(SK_CXFRAMERIGHT) + (ClientW - ClientWGL) + SPLITTER_WIDTH * 2;

    long x = rw.right - UseW;


For MENU_LIGHTSETTING in line 1919 of ProcessMenu
    case MENU_LIGHTSETTING: // PAT: 01-30-2018
        if (IsWindow(gP.hOverlay)) {
            GetWindowRect(gP.hGL, &lpr);
            GetWindowRect(gP.hMain, &rw);
            lpr.left = rw.left + skGetSystemMetrics(SK_CXFRAMELEFT);
            lpr.right = rw.right - (skGetSystemMetrics(SK_CXFRAMELEFT) + skGetSystemMetrics(SK_CXFRAMERIGHT) + ClientW - ClientWGL);
            if (IsWindowVisible(gP.hOverlay)) {

and in line 1496 of ProcessMenu
    RECT rw, lpr;

The keyboard focus is not returned to gP.hGL or gP.hMain (either will do) when the splitter is released.

This is done in DetectHotKeys at line 2557

    if (gP.useSplitFrame == 2) { // PAT: 12-16-2018
        if (!ZI_IsLButtonDown()) {
            gP.useSplitFrame = 1;
            ZD_SetObjectFrameToUse(ID_SPLITTER_VERT, gP.useSplitFrame, true);
            PutFocusOn(gP.hGL);
        }
    }

I have another solution, using a hidden window just to get the correct anchor resizing of the control, working exactly like the previous OGL window before the splitter code, and using this hidden window just to put everything at the right place as it was before.
And that would probably make our life much easier than having to perform convoluted computation.
This Template window could be created in the gP.hGL creation process.

[Michael Lobko-Lobanovsky]

... other we loose the width of the splitter

I can live with it, my friend. Can't you?

Also we couldn't compute anymore F1 and the ToastWindow on the size of the OGL control because of the offset used.

Compute it relative to the gP.hMain frame rather than gP.hGL.

This is done in DetectHotKeys at line 2557
    if (gP.useSplitFrame == 2) { // PAT: 12-16-2018
        if (!ZI_IsLButtonDown()) {
            gP.useSplitFrame = 1;
            ZD_SetObjectFrameToUse(ID_SPLITTER_VERT, gP.useSplitFrame, true);
            PutFocusOn(gP.hGL);
        }
    }

Fine!

I have another solution, using a hidden window ...

That's probably feasible unless it gives us yet more PITA with keyboard focus...