Early WIP on v2.55

[Patrice Terrier]

Everything seems to work fine, thank you!

The new "Smooth shading" option, showed me a small problem on my 3W_HR calandre

[Michael Lobko-Lobanovsky]

Thanks for the good news, Patrice!

Regretfully I can't yet provide flat shading in every fancy shader as many of them don't use the model's normals or specular lighting at all. But I've made provisions to add them at some future point in time when I figure out how to.

What can you say about our new global "hotkeys" that allow TAB-ing through the fancy and texture inspection modes, and ESC-aping from the tool windows, Z-axis rotation, design and fancy modes, and full screen (precisely in that order of priority)?

[Patrice Terrier]

Huh, i can't popup the toolwindow while pressing the cytl key 

Where does GP.bIsFunMode is being fired?

Added
found it
gP.bIsFunMode = gP.bSpecular | gP.bMinnaert | gP.bGooch | gP.bToon | gP.bXray | gP.bMicro;

[Michael Lobko-Lobanovsky]

Probably you missed something while merging?

Don't be in a hurry, check and re-check carefully in WinMerge. There's quite a lot of stuff to mod as compared to what we've had before...

[Patrice Terrier]

Looking closely at DetectHotKeys, i was able to understand how to use the TAB key.

I think there should be a furtive window to inform the user when he can "Press the TAB key to move to the next design mode"

I have an example of furtive window in the HUD controls project here
http://www.objreader.com/index.php?topic=26.0
(the one that displays the time)
And listen the sound used when the furtive window is open or closed.

[Michael Lobko-Lobanovsky]

Probably yes, but the arrow tab of that window should not stick from the outside into the viewport all the time. The tab (if the window is needed at all) should appear visible only when the cursor is somewhere near the viewport side where the window is supposed to slide in from.

I'd like to see that functionality in the lighting pane too, instead of the current F1 key. This way we could free F1 for its proper function -- to bring the help window on screen. IMHO  OR is already sophisticated enough to be supplied with an appropriate help system.

[Patrice Terrier]

There is also the concept of the toast window explained here:
https://doc.windev.com/?1000019358&name=toastdisplay_function

[Michael Lobko-Lobanovsky]

Yeah, I know this type of message windows. They are used extensively in the Code::Blocks editor that hosts my GCC. They slide up into view above the notification area on the right side of the taskbar and then disappear automatically.

We could have the same in the viewport sliding up into view on Ctrl press in the bottom right corner of the viewport and then sliding down and out of view completely after staying on screen for, say, 15 or 20 seconds.

[Patrice Terrier]

Here is an example of the furtive/toast window i have been working on.

The GDimage compositing build this kind of image on the fly, that can be used as a static window.

We can change everything, there is no limit to what we could put inside of the compositing

[Michael Lobko-Lobanovsky]

Hey Patrice,

OR doesn't seem to store the state of scene individual lights (on or off) into the MTL file, just #multilight or not.

Is it a bug or a feature?

[Patrice Terrier]

Correct, OR stores the color of the individual lights, and #multilight switch them ALL to On mode.
If we want to store the individual on/off lighting mode, then we should use another #meta, aka #individuallight (for example).

Working on the compositing of the new furtive/toast window, shows me a difference of behaviour between GDImage 32 and 64 that i have fixed, i am also adding a new button to test the toast window.

Because of the changes done to OR, you will have to sync with me once done.

Updated

[Michael Lobko-Lobanovsky]

If we want to store the individual on/off lighting mode, then we should use another #meta ...

From my standpoint, there are a few objections to the current syntax of #Light statements:

• They seem too verbose and superfluous. This set of statements:
  
  #Light frontAmbient 0 0 0
  #Light frontDiffuse 165 165 165
  #Light frontSpecular 127 127 127
  etc.
  
  is semantically equivalent to this one liner: #light front 0 0 0 165 165 165 127 127 127 etc. which would be much faster to swallow in one gulp when parsing.
• There's a set of four isLightX_On flags in global gP that follow the current state of scene lights at all times. We can use them to complete the preceding statement with yet one more boolean flag: #light front 0 0 0 165 165 165 127 127 127 0|1 to (re)store the light initial state at MTL load and save time.
• Camel case in the current #Light statements looks inconsistent with the predominantly lowercase tradition and case insensitivity of Wavefront OBJ material library syntax.
• #multilight should go as yet one more superfluous rudiment if the above paradigm is adopted. However Multiple light sources may stay in the menu as a handy shortcut.

Secondly, it seems weird that on clicking Reset scene lighting, OR currently resets the scene lights to some predefined default values rather than the initial states described in the MTL file. Moreover, Stray light intensity remains unaffected by the reset at all. I think the existing light arrays should include yet one more set that's loaded from the MAT file and used instead of the existing ref arrays to reset the light and light intensity states to. The existing ref arrays should be used to reset the scene lighting only when i) the MAT file has no specific light control section or is missing altogether, and ii) before initial model load and in between model reloads when no MAT file has yet been parsed.

I'd like to know your opinion on my suggestions.

[Patrice Terrier]

Yes, i agree with you, as long as it doesn't break the existing .mtl files 

I keep working on the toast window, shall send you something to play with later on today, altogether with new pandora and extra resources.

[Patrice Terrier]

Here is what i have done so far…

1 - OR_patch.zip (the changes done to support the new ToastWindow)
2 - pandora.zip (New FontStyle parameter added to ZD_GetTextBound, and ZI_CreateTextObject)
3 - resource.zip (to put into the Reader skin folder)

The Toast button is for test purpose only, so far the code timer has not been yet implemented.

To display a new Toast message just use something like this

WCHAR UseIcon[MAX_PATH] = { 0 }; Path_Combine(UseIcon, skSkinFolder(), L"bulb.png");
ToastWindow(UseIcon, L"Caption", L"first text line.\nsecond text line very long, very very long, i said very long!\netc.");

Of course we can use any other icon, like ICON_info.png or ICON_alert.png

I hope there is nothing missing in the zip(s) 

...

[Michael Lobko-Lobanovsky]

Thank you Patrice!

Need time to play with the new goodies.

See you tomorrow.