BRDF Explorer project

[manhnt9]

This issue is meant to discuss software functions of BRDF Explorer.

Rendering algorithms will be discussed in #276.

• [x] ~Include script file to clone my CEGUI branch as git submodule~
• [x] ~Apply @Florastamine's theme patch~
• [x] Push submodules online
• [x] Build CEGUI dependencies
• [x] Build CEGUI
• [x] Add new IrrlichtBAW example 13.BRDF_Explorer
• [x] Write CEGUI management class in ext namespace to init/destroy/render GUI
• [x] Install CEGUI headers to INSTALL_PATH/include/irr/ext/GUI/CEGUI
• [x] Port GUI
• [x] Relocate submodules into 3rdparty
• [x] Compile cegui ext as static lib
• [x] Build dependencies on Linux instead of requiring user to install via apt
• [x] Refactor Helpers by @Florastamine
• [ ] Implement IrrBAW CEGUI texture loader in ext namespace
• [ ] Patch CEGUI to upload sRGB (issue #263)
• [x] Render a simple model
• [x] Solve comment https://github.com/buildaworldnet/IrrlichtBAW/pull/291#discussion_r282012784, https://github.com/buildaworldnet/IrrlichtBAW/pull/291#discussion_r282012245

[manhnt9]

Note: For cloning CEGUI on Windows, Python folder should be added into PATH environment variable. For example it's OK if you can call python from CMD. Python 2 is required for this script to treat Mercurial repo with Git.

Asking approval from @devshgraphicsprogramming and @Crisspl, or else we can download a latest, compressed CEGUI branch before building from these links, but that's a little hard for updating CEGUI.

[devshgraphicsprogramming]

Python 2 (I have 3 but cmake is not finding it) seems to be necessary for some of our SPIR-V dependencies to not create disturbing errors when building with MSVC ( #269 ).

I'm all for Python 2 being a dependency, but please please please make CMake on Windows find it if its installed.

If possible I'd use and require Python 3 instead of 2 and solve #269 with Python 3, not 2.

CEGUI submodule can be a 3rdpart module in ./ext/cegui/3rdparty/ that is conditionally updated by CMake script only if the option is specified that we build the examples (there should really be extra cmake option switches for certain examples that rely on big extensions with dependencies).

P.S. Actually having python as a dependency is totally cool as we plan to do #92 ;)

[devshgraphicsprogramming]

Write main code file to render the GUI, load a simple model

I don't know where you want to discuss the Functionality-but-not-strictly-Rendering aspects of the task, but generally I would expect this issue to cover the parts of the BRDF Explorer LaTeX specification that are functionality.

Speaking of which I would want the intial sample to handle model loading and have a "stub" graphics-pipline reconfiguration function which actually gets triggered (for cases when we change "heavy" material parameters, such as the parameter source [texture vs constant] and BRDF type ).

[devshgraphicsprogramming]

One more note, everything to do with the BRDFExplorer should be statically linked into the binary, we don't want a massive folder of dlls to be necessary.

You have my permission to make irr::ext::cegui as a static library with its own build target, if necessary.

Furthermore, if CEGUI needs some skin, font atlas, or other resource that comes from a file which is not "required for BRDFExplorer only". I think the defaults/built-ins should be "resource compiled". Here's a script that supposedly does so https://github.com/vector-of-bool/cmrc

Again, the XML layout of the GUI specific to BRDFExplorer needs not be embedded in the executable, but the reusable parts I would resource compile into irr::ext::cegui. https://github.com/vector-of-bool/cmrc

[manhnt9]

I will update my Windows environment (includes MSVC) and test if Python 3 can be used with the Mercurial script.

About the static linking, I've done it before in my engine so I can guarantee. But I suggest we do static linking for Windows only since it doesn't benefit Linux much.

[manhnt9]

About CEGUI resource, the reusable part will be stored on my CEGUI branch too so we don't need to duplicate those files in irrbaw.

Resource distribution can also be in a single .zip file (with/without password protection) like in @Florastamine's releases before. Do you really want to compile resources into exe?

[manhnt9]

After reviewing the CEGUI data, I see that there're data which isn't general enough to get accepted into CEGUI's original branch, so it won't stay in my branch too. I'll manage a separate Git repo of the CEGUI data instead since we'll both use them. Nice CMake code to have CEGUI+Data in a build process will be provided.

[devshgraphicsprogramming]

Stuff like the skins (reusable part) etc can go into ./media/ I'm not completely 100% resource compiled ;)

[manhnt9]

OK, will have them here.

Update about Python and Mercurial bridge stuff. I will configure on my machine to push from my local cegui to a git repo. So I can have single local and 2 different remotes (bitbucket hg and git). It makes the submodule much easier since I realized that in order to clone from Mercurial:

• Python must be installed
• A script must be included in irrbaw repo
• PATH environment variable (both Linux and Windows) must be modified for git to find that script

So instead I'll push cegui to a git repo, have done it before and it has perfect sync.

In short, these 2 submodules will be added:

• CEGUI
• CEGUI datafiles to be installed in irrbaw's media folder

Both git repos are maintained by us on GitLab.

[manhnt9]

Wasted half a day to try Hg-Git. Met errors on both Windows & Linux. Tags failed = not pushed anything. Issue reported: https://bitbucket.org/durin42/hg-git/issues/276/failed-to-push-tags

Tried again with this: https://github.com/frej/fast-export. Now I have 2 separate cegui folders and have keep then in sync with single command.

Repos are online at: https://gitlab.com/InnerPieceOSS

Integrating submodules into example app.

[manhnt9]

[manhnt9]

CEGUI dependencies now can be downloaded, built and installed to CEGUI. Will write build script for CEGUI tomorrow.

[manhnt9]

Base project is created. I will spend the day mostly for studying GUI implementation by @Florastamine.

[manhnt9]

I ported the main window GUI, but fails to compile (https://github.com/buildaworldnet/IrrlichtBAW/issues/294) so I'm waiting for the fix. Next is to port color picker and finalize UI then we can start rendering. Hopefully in this week. P/S: Doing some overall maintenance and test more on both platforms actually.

[manhnt9]

I meet this on Windows, git doesn't recognize new submodule.

[manhnt9]

Thought it was a folder so I ignored submodule before. Solved that issue.

[devshgraphicsprogramming]

Install CEGUI headers to INSTALL_PATH/include/irr/ext/CEGUI

I thought you meant only the CEGUI extension's headers, i.e. the headers which are supposed to be public in irr/ext/cegui (required for compilation of binaries and libraries using it)

[manhnt9]

ext will only help you set up. In order to develop GUI, you'll have to use CEGUI API too.

[devshgraphicsprogramming]

ok, but then: INSTALL_PATH/include/irr/ext/CEGUI is for your own headers INSTALL_PATH/include/irr/ext/CEGUI/some/other/path is for cegui's headers

[manhnt9]

Some initial render, still has layout bug of my port I guess. Will have more updates soon.

[manhnt9]

Ah the layout is fine, just lacking windows because those are still not ported. Great! Also task list is updated.

[manhnt9]

This could be a bug actually, I double-checked it in CEED. It should be like this (screenshot from CEED). Gonna have fully working main layout first before continuing. What should be done next is to compile the old GUI demo, disable some code and compare with irrbaw app.

[manhnt9]

Fixed by @devshgraphicsprogramming 's suggestion on Discord. This is about OpenGL/Vulkan NDC. Mouse input works, will test key input too.

[devshgraphicsprogramming]

@manhnt9 does this help you with your Saga3D renderer?

[manhnt9]

Oooh, absolutely. Thanks for reminding me about that. I don't remember solving any NDC issue and also my GUI is disappearing somehow. Gonna revisit it soon.

[manhnt9]

Mouse and key are working fully.

[manhnt9]

All Sliders, Click to browse events and File Dialogs are working.

[manhnt9]

Dropdown works.

[manhnt9]

GUI is 99% done. Next step is to re-test as much as possible and do the rendering. Then connect GUI data to graphics pipeline.

[manhnt9]

All GUI controls are tested, working well. Gonna test on Windows.

[manhnt9]

I'm gonna refactor the build process for CEGUI first then solve pending comments later.

[manhnt9]

We have perfect build now, Debug/Release works, CEGUI projects are built before building IrrExtCEGUI. Also found a bug about disappearing cursor in file dialog and fixed it. App has 2 overlapping cursors, CEGUI cursor and native cursor. Native cursor is now only visible for file dialog.

[manhnt9]

Base project is considered done to me. From now we can add new code consistently. CEGUI's dependencies will be upgraded later when the Ext is widely used in examples then I'll change it to submodule instead of download and build from .zip. Hope that by the time CEGUI is already moved to Git too.

[devshgraphicsprogramming]

so do we close this issue?

[manhnt9]

Still have sRGB tasks left.

[manhnt9]

Next week I'll merge with the loaders, write the image codec for CEGUI, make CEGUI upload textures in SRGB format.

[devshgraphicsprogramming]

Maybe we should remove the following from the checklist

More rendering features based on #276

so at least we can close issues

[devshgraphicsprogramming]

if IrrBaW will provide texture loading abilities to CEGUI can we kick out STB, etc?

[devshgraphicsprogramming]

can you guys manage to fix the crash when the titlebar of the color picker is double-clicked? (or at least disable any sort of reponse to a double click)

[devshgraphicsprogramming]

@Crisspl would it make sense to get around our texture flipping issues with:

• [ ] Implement IrrBAW CEGUI texture loader in ext namespace ?

Then we kick out STB and not build the CEGUI texture loading lib.

@Crisspl and @Przemog1 at your leisure:

• [ ] Patch CEGUI to upload/use sRGB textures (issue #263) right now its rendering with sRGB "reinterpret_cast'ed" as linear, outputting into an SRGB framebuffer . I don't know how much easier the above point would make that.
• [ ] Patch the CEGUI color picker to not fucking crash when double clicked

The last two things would be modifcations of the CEGUI submodules which would have to be diff'ed (with your favourite diff tool) into a .patch file that we submit to @manhnt9's branch of CEGUI (since his git repo is kind-of a mirror of a mercurial repo, yes CEGUI people use Hg)

[Crisspl]

would it make sense to get around our texture flipping issues with: Implement IrrBAW CEGUI texture loader in ext namespace

You'd have to elaborate. The only solution im almost sure will work is to separate CEGUI textures and irrbaw textures on the level of GL objects. Still i can't be 100% sure because it also became apparent that this weird behavior affects also textures that cegui doesnt even know about (but simultaneusly there are some shared between irrbaw and cegui). However it worked (textures wasnt flipped) when there was only GUI - no irrbaw textures were shared with cegui nor created at all

[devshgraphicsprogramming]

To be fair I don't even know how on earth CEGUI could flip textures in the main render window.

It does make most sense for CEGUI textures and our own textures to be separate objects. (Unless we provided our own GUI Renderer to replace OpenGL core one)