Early WIP on v2.55

[Michael Lobko-Lobanovsky]

 

Of course there is no speed comparison with my nVidia ASUS Gamer computer.

That's most likely because your Transformer has no (or very little, like 256KB only) video memory at all, and there's no profit from using HW VBO's that are emulated transparently in the conventional RAM.

[Patrice Terrier]

My friend

zTrace in renderers.h at line 558 and 958 

There is a missing mesh display when loading a new model in the latest shaders/renderers.
Try with the attached Samourai project, at startup the face becomes visible only after the model has been moved.

Added:
I am writing the Material topic for the documentation.

[Michael Lobko-Lobanovsky]

Dear Patrice,

My renderers.h (including lerpReset()) that I sent you was taken as-is directly from my current WIP on mesh visibility. It bears traces of code that wasn't meant to be used in your OR. Please comment out the following:

1. In lerpReset():

........
    //gluLookAt(gP.rCameraPos[0], gP.rCameraPos[1], gP.rCameraPos[2],
    //    gP.rTargetPos[0], gP.rTargetPos[1], gP.rTargetPos[2],
    //    0.0, 1.0, 0.0);
........


2. In both drawUsingFixedFuncPipeline() and drawUsingProgrammablePipeline():

........
            //// MLL 01-01-2019: !!! TEMPORARILY DISABLED !!!
            //if (!isPointInBox(gP.rCameraPos, pMesh->meshAABB.min, pMesh->meshAABB.max)) {
            //    if (isSphereInFrustum(gM.frustum, pMesh->meshCenter, pMesh->meshRadius)) { // rough/quicker test
            //        //if (!isBoxInFrustum(gM.frustum, pMesh->meshAABB.min, pMesh->meshAABB.max)) // precise/slower test
            //        //    continue;
            //    } else {
            //        continue;
            //    }
            //} // mesh is assumed visible if camera is within its bounding box
            //meshesDrawn++;
........

3. And in both those functions (and everywhere else), everything that pertains to meshesDrawn.

The current camera setup is incapable of creating a usable frustum in real time. I'll have to add some parallel (probably OOP-ed) code that will take care of the necessary modelview and projection matrix transforms as planned to allow us to take advantage of early mesh culling to ease up rendering of high mesh count models. Our recent help system efforts have distracted me from this task I was preoccupied with on the new year's eve.

[Michael Lobko-Lobanovsky]

(The samurai's "pigtail" is gorgeous! )

[Patrice Terrier]

I have been thinking of another solution based on GDImage, if ever we couldn't get rid of the RTF oddities, that won't need further compression, because the file will be already using .png format and the compression is vey effective on text based document.

See the attached png that is only 274 Kb, while the original rtf is 776 Kb.

[Michael Lobko-Lobanovsky]

No Patrice,

This will probably be the smallest possible .PNG file that an ordinary user like me will consider perfect for a help file system. I don't think you'll be able to beat it in size losslessly as far as PNG's go.

[Patrice Terrier]

Your png file is really small. 

I did try HH, with a .chm file, and that seems to work well, except that it takes some time to render the full index, and the index is not redrawn correctly when moving the slider, we probably need to force a redraw.

I did download HelpNDoc 5, that seems to work very well, and i was able to import my WinLIFT and GDImage chm help files into it.
That is nice, because HelpMaker, that i have used to create them, doesn't exist anymore.

[Michael Lobko-Lobanovsky]

I wasn't planning to use HH's original Index/Contents tab control area as, unlike its browser window, it flickers like hell on HH window resize. That's because the child controls are originally placed inside the HH tab containers -- something I never do in my own apps. You simply can't suppress or override the tab container flicker by subclassing the control, and if you want to get a really flickerless behavior then you should minimize the tab container area to just a couple of pixels below the control's row of tabs, place its "child" controls beneath the tab row, and manipulate their visibility programmatically (possibly via Begin/EndDeferWindowPos if the number of "child" controls is significant) in response to the tab clicks.

HH.exe can open up individual topic files from the common .CHM archive on load if their names are specified in its command line. It is possible to reuse your skinned list view control for surfing the CHM help by restarting HH.exe as needed with a particular help topic while the HH window area redraw is blocked to make the restart unnoticeable and seemingly instantaneous.

I think that, unlike your full sized RichEdit help, it is more reasonable to make the HH window resizable by the splitter because it enables the user to both read the help guides and follow them immediately in the OpenGL viewport without toggling the help window first on and off all the time.

(Have you noticed the size and quality of PNG I appended to my previous post?)

Yes, the file is devoid of all metadata and thumbnail payload a PNG usually carries, and it has its color data reordered, optimized palette-wise and re-compressed at zlib compression level 9 (maximum). IIRC I already made you aware of all sorts of PNG optimizers available on the net. And while we're at it, it seems you can still find lots of sites on the net where you can download your HelpMaker v7.4.4 in case you don't have it installed on your box. As for me, I prefer to use Microsoft's original good old HTML Help Workshop to craft my help files.

[Michael Lobko-Lobanovsky]

Patrice,

Can you add and code a File->Reload->MTL file and File->Reload->Textures (in addition to File->Reload->Model) options to the main menu's File section? It will enable us to edit the material library and textures interactively (through the Edit->MTL file and Edit->Textures menus) in full entirety, not just the MTL light properties section, and thus extend ObjReader's useful capabilities still further?

In general, what's your attitude to extending ObjReader's capabilities from a pure viewer to some sort of an interactive editor?

[Patrice Terrier]

I think that, unlike your full sized RichEdit help, it is more reasonable to make the HH window resizable by the splitter because it enables the user to both read the help guides and follow them immediately in the OpenGL viewport without toggling the help window first on and off all the time

I shall try, but then we have to use one horizontal and vertical scrollbar, something that i didn't wanted to deal with.
Except if we go to a 100% graphic solution, using a GDImage graphic control, but then you will have first to teach me how to produce those tiny png file 
 

[Patrice Terrier]

In general, what's your attitude to extending ObjReader's capabilities from a pure viewer to some sort of an interactive editor?

If i remember well, that was the initial purpose of the slider, to see the editor asside the GL scene to make interactive changes

But i would like first, to complete OR's help, in one way or another.
If we go to a full graphic help solution (based on tiny png) then we could see the OpenGL scene, just like with the transparent control panel in HUD display mode.

[Michael Lobko-Lobanovsky]

I shall try, but then we have to use one horizontal and vertical scrollbar, something that i didn't wanted to deal with.

Yeah, I felt it might be a PITA...

Except if we go to a 100% graphic solution, using a GDImage graphic control ...

I have absolutely no objections, and if it works nicely, I'm ready to give up my HH obsession in favor of the common code.

... but then you will have first to teach me how to produce those tiny png file 

No problem, my friend. Catch the attached zip. It contains what I think is the best PNG optimizer around. It is free to use for any purpose though regretfully it comes without the source code. Exhaustive help is included in the zip though in most cases, a simple truepng /o max image.png command line yields the best results without additional headaches, trial and error.

[Michael Lobko-Lobanovsky]

If i remember well, that was the initial purpose of the slider, to see the editor asside the GL scene to make interactive changes

Excellent! But I think being able to use help alongside the OpenGL viewport alone would be a reason good enough to have introduced the splitter control. BTW have you managed to make the dotted button behave well under the Intel HD driver?

If we go to a full graphic help solution (based on tiny png) then we could see the OpenGL scene, just like with the transparent control panel in HUD display mode.

But on the right side of the main window.

[Patrice Terrier]

Thank you very much for TruePNG, that would be very handy for all kind of purpose(s)!

BTW have you managed to make the dotted button behave well under the Intel HD driver?

No, i haven't, because the intel driver is so slow compared to what i am accustomed to use with OR, and it draws a window border around the slider because it is a popup, probably because the option "move the window content" is disabled, due to the poor performance of the graphic card, and this is also probably the cause of the dotted button problem.

Added:
Yep, when the option "Show window content while dragging" is checked everything works much better in OR, and moving the slider get smooth!

[Michael Lobko-Lobanovsky]

You're welcome Patrice,

I'm glad you appreciated the benefits of using a PNG optimizer where necessary to keep the footprint of asset store to a minimum. We can probably reduce our \Resource subfolder to a fraction of its current size even if all its images are true PNGs rather than JPEG junk.

... poor performance of the graphic card ...

Intel HD graphics is not a discrete graphics card but rather a video controller integrated directly on the CPU chip. Due to the chip finite size, allowable power consumption and working temperature limitations, HD graphics has barely enough VRAM (ca. 256MB only IIRC) to support Windows/macOS/Linux aero compositing and standard video apps only thus leaving full featured 3D HW acceleration out of the question.

However Intel is expected to release their first discrete video card some time later this year. If it carries at least 2GB of VRAM and sells at a reasonably low price, I plan on buying myself one for test purposes to support my 3D hobbies. That's why I think it will be reasonable to support Intel graphics in ObjReader specifically despite it being so slow on the current CPU-integrated implementations with a view to their future range of discrete graphics HW.