Early WIP on v2.55

[Michael Lobko-Lobanovsky]

Patrice,

I know it's usually annoying to wait and overtake, so here's an early beginning of our sync process. I'll be adding more features marked with TODO in the code, menus, and text below in the next few days:

Mods dated "MLL 10-18-2018:"

0.  Fixed clearing old geometry data on model reload
1.  Fixed mipmapping on texture reload
2.  Fixed material initialization for models with missing MAT files
3.  Fixed model and mesh rotation stop/resume/reset angles
4.  Fixed deletion of shader programs
5.  Fixed and refactored frenglish func names to common style
6.  Refactored PROPM structure into PROPM and RHANDL structures
7.  Refactored main and sub menus to allow new functionalities
8.  Isolated shaders and render procs into separate project files
9.  Removed lots of obsolete Mobj_xxx code
10. Added:
   - scene grid
   - TODO: inertial mouse
   - TODO: axis aligned bounding boxes
   - TODO: viewport tooltip to report material names under cursor
   - TODO: model Z rotation on Alt+LMB drag
   - flat shaders to support glShadeModel(GL_SMOOTH | GL_FLAT) (except normal map shader for now)
   - shader for discrete texture and geo inspection in design mode

I'm slow because I'm fixing everything that I find buggy or unhandy until it works and looks flawlessly by my standards. It involves a hellofalot of time and experimentation.

But many fixes and features are already working and ready for your criticism. Some provisions are already included in the code for the coming features too.

Please copy the files from the zip below into their respective project folders (same project paths considering the zip as the solution root) and let them overwrite the old files. Don't forget to add the two new files (renderers.h and shaders.h) to the project.

Do not attempt a usual merger as there are far too many differences. Just copy, recompile, and enjoy. And criticize if needed.

[Patrice Terrier]

The new features are great, some of them could be duplicated onto the control panel to ease the model inspection (i can do it if you want).

Thank you!

[Michael Lobko-Lobanovsky]

Thanks for the appreciation! I tried hard.

OK, I'm ready for work. Please post any comments or fixes you might have in this thread.

Let me finish the eye candies first and then we'll talk on how to refactor the GUI, OK?


(IronMan's occlusion looks terrific!!! My congratulations! )

[Patrice Terrier]

I am trying to deal with the case or name changes, to see what is really new in the code

Generally i prefer to put all my properties in lowercase to avoid remembering where to put the upper cases 
I was accustomed for years to use non-case sensitive programming languages

and looks flawlessly by my standards

Fortunatly i shall have to do this check only once, since starting from now i shall use your preferences

[Michael Lobko-Lobanovsky]

I'm used to camel case in the C sources, and my gradual change from Mobj_FooBar to fooBar also helps me to intuitively keep track of what code I've already worked on vs. that not yet touched by me.

Another reason to use camel case in mobj.h is to keep track of which functions are fundamental (Mobj_xxx) vs. those that are auxiliary helper routines (camelCase). Also, I'm not very fond of underlining names and labels because it makes them far longer to type than they really should be.

Then, why I'm moving certain functions out of mobj.h is because they are not specific to the OBJ format but rather belong to the OR's own framework regardless of what particular format it's going to display now or in the future.

And finally, I just like the code being kept in separate relatively small and functionally complete files. I'll be also moving all texture handling routines out of mobj.h into a separate dedicated textures.h file. (it may require adding a few function prototype headers at the top of mobj.h though)

Generally i prefer to put all my properties in lowercase to avoid remembering where to put the upper cases 
I was accustomed for years to use non-case sensitive programming languages

While we're at it, did you know that OR is case sensitive regarding material names? It refuses to apply the material if its name case in the MAT files differs from that in the OBJ file. This is one thing I'd like to ask you to fix in the sources now if you don't mind...

[Patrice Terrier]

OR also doesn't accept to use a fully qualified path, perhaps we should be more permissive (as long as the target file exist) ?

did you know that OR is case sensitive regarding material names

This is because of this in Mobj_importGeometrySecondPass

        case 'u': // usemtl
            fgets(buffer, sizeof(buffer), pFile);
            sscanf(buffer, "%s %s", buffer, buffer);
            //name = buffer;
            iter = m_materialCache.find(buffer);
            activeMaterial = (iter == m_materialCache.end()) ? 0 : iter->second;
            break;

I am not comfortable with the use of iterator myself, and the problem is that find in the class map is always case sensitive. 

 

[Michael Lobko-Lobanovsky]

This isn't the only weird thing about C++ std::vectors. You're using them unsparingly, but have you ever checked how actually spacious the vectors are to reach their .end or .size? You'll be surprised but the actual .size of texture vectors we iterate through many times in search of duplicates varies somewhere between 17500 and 45000 elements on my PC! There is no way to limit the size of memory C++ allocates for its std::vectors nor is there any way to deallocate it when no longer needed.

No wonder texture creation takes probably up to half the overall time the model loads...

Anyway, we need case-insensitive materials and other labels used throughout MAT and OBJ files. Do whatever you see fit but please fix that preternatural glitch.

Fully qualified paths would also be welcome, and even more so because they are allowed by the Wavefront OBJ format.

Tip of the Day #2: did you know that OR allows more than one word long material names? IIRC one of your latest models contains and actually displays the material(s) whose name is xxxx_yyyy zzzz. (I'm sure that was a typo but it somehow worked in both MAT and OBJ nonetheless )

[Michael Lobko-Lobanovsky]

Probably the names should be lowercased before they go into the material cache?

[Patrice Terrier]

Please see above, post #6, about: gl_LoadModel

[Michael Lobko-Lobanovsky]

Please, check the case of gP.modelpath into the gl_LoadModel procedure, it should be gl.modelPath with the new PROP member name.

OK thanks!

Why did you use (+Alt) in this
            wcscopy(szCaption, L"  Mouse buttons:\n- Left(+Alt), rotate.\n- Right, pan.\n- Wheel, zoom.");

Alt+LMB will allow the model to be rotated with the mouse not only around X and Y axes like it does now, but also around Z. This label, together with the two new textures in the \Release\Reader subfolder and two new functions commented out in renderers.h, is a provision for this new functionality I'm working on right now.

Pressing Alt will show the target ellipse on the screen as in the snapshot below, whereby you'll be able to rotate the model:
-- by dragging anywhere inside the ellipse with LMB down exactly as you do now
-- strictly around X only when the left mouse button is pressed in the yellow boxes and then dragged
-- strictly around Y only when the left mouse button is pressed in the cyan boxes and then dragged
-- strictly around Z only when LMB'ed and dragged anywhere outside the ellipse.

The ellipse will disappear again when you release the Alt button.

Also change the version number to 2.55, see my Main.cpp sync in the attached zip file.

Will do, thanks again!

[Michael Lobko-Lobanovsky]

Regarding (+Alt), I just thought we can also use it for many other purposes in the future, so it will probably be not so wise to spring up the ellipse every time the Alt button is pressed...

Alternatively we can use the letter Z as sort of a hotkey to initiate Z-axis rotation and show the ellipse in response, inviting the user to start this operation. Z is rare to use as a hotkey because there are few words to start with it, but in this case it will be kind of meaningful and appropriate.

What's your opinion?

Please, check the case of gP.modelpath into the gl_LoadModel procedure, it should be gl.modelPath with the new PROP member name.

Why, everything's all right with the gP.modelPath case in both Main.cpp (yours and mine) and mobj.h, and the project compiles fine for me...

[Patrice Terrier]

Here we are…

Put the "trebuc.ttf" font into the Reader folder.

For now, and for test purpose the toolwindow is currently visible at startup, but it should start hidden and get visible only when the Ctrl key is being used (not done yet).

[Michael Lobko-Lobanovsky]

Excellent!

In the meantime, here are a few lightweight fancy mode shaders with hardcoded parameters. I'm going to merge your tool window and then re-send the mods to you.

Thanks a million for your help!

[Patrice Terrier]

Thanks a million for your help!

Thanks to you, for all the great work you are doing on the new features, but we are partners aren't we, and this project is the result of our common work, that is a real pleasure to work with you, and see OR becoming better and better.

About the new Tool window i did it using the WinLIFT features, because i thought it was easiest for you to customize things from the standard ToolProc callback, rather than using a transparent overlay and a GDImageCallBack.

[Michael Lobko-Lobanovsky]

... i thought it was easiest for you to customize things from the standard ToolProc callback ...

You guessed right. GDImage remains a Pandora box for me. But I think that once we get it all up and running, we can discuss moving the toolbox functionality over to the overlay(s) just to maintain the uniformity of OR controls.