Tweaked SikkMods Parallax Occlusion mapping and used in DHEWM3

[HarrievG]

Hi @DanielGibson

I have been working with dhewm3 for a while now and have made some fixes (mostly in Tool land to support 4k / dpi awareness)
Now that i have fixed up the editors i started looking at materials, and found that with little tweaking, SikkMods pom method looks great and is very usable as a default interaction shader

I want to share an 4k screen compare with you, in case you would like to add my modified shader to the code base.
IMHO , since one of the goals of this repo is to get an awesome engine starting point, on which you can develop further, it might be valuable for others.

Besides the editor fixes, (which don't seem that important or difficult) i have extended the QGL implementation with a minimal subset to be able to use and compile GLSL without completely rewriting the backend.
I did this so i could run the original DHEWM3 impl with ARB , but still have IMGUI with GLSL at the same time. which works beautifully.

I expect not all is wanted upstream, so let me know what you want 👍

compare:(4k!)
www.vrknight.eu/d3compare

With kind regards,
Harry

[HarrievG]

I found that the 'upgraded' interaction shader actually does not play nice with gui models.
As long as it does not work as single drop in / replacement , i dont see a reason to further promote it ><"

Someone can drop a line If there is need for the other things i did in DHEWM3 , and i will put in time to make a pr.

1. 4k fixes in TOOL
2. Blender support for exporting with export .def tag
3. Collada import support (from rbdoombfg), comes with slightly modified irrXml.
4. ImGUI with minimal gl 2.0 and gl 3.0 QGL implementation

H.

[DanielGibson]

The screenshot doesn't look bad at all!

However, at least right now I'd be a bit hesitant about merging GLSL support and graphical improvements, for several reasons:

1. As you pointed out, it of course has to work also with GUI models
2. Any changes to the look of the game must be optional, so there should be a cvar to switch between the original look and the improved look
3. As I wrote in GLSL backend #15 (comment), I have vague plans for a BGFX rendering backend and BGFX also uses a dialect of GLSL. I think it would be unfortunate if mods started using GLSL shaders for the OpenGL backend that might then become incompatible when (if) dhewm3 gets a BGFX renderer (due to some differences between BGFX's dialect and "normal" GLSL, though even "normal" GLSL isn't 100% compatible between different OpenGL versions either, AFAIK).
   If I implement a BGFX backend (i.e. if I ever have enough time for that..) I plan to have conversion code for the old ARB shaders to GLSL which doesn't seem that hard; but as GLSL is much more complex I fear that trying to automatically convert between "normal" GLSL and the BGFX dialect would be more harder.

On the other hand, I'd really love to have ImGUI support, that'd be super handy both for crossplatform tools (I once implemented the Light Editor for D3BFG with ImGUI) and to implement a better settings menu that can be easily enhanced with new options that dhewm3 offers and original Doom3 didn't (so the original menu doesn't have them).

4K fixes for the Tools definitely sound useful; I'd probably merge them very soon.
Blender support might be nice as well, I don't have strong opinions about that. Probably depends on how much code and how invasive it is.
As far as I know Collada is not a very nice format and every tool implements it slightly differently, I don't think supporting it makes that much sense.

Cheers,
Daniel

[HarrievG]

Bgfx would be very nice to have. I was surprised how easy it was to use in IoQ3. (but that probable is because of the well made pre-make setup). Also it would make compiling dhew3 to wasm a bit more easy.
I understand that there is no use in submitting any GFx or rendering work if there are plans to replace the renderer. So (4.) is off table.

About collada:
I totally agree with collada not being nice, if it wasnt already implemented in rbdoombfg, i wouldn't even have attempted to integrate it. BUT, an easy to use mesh format is needed, LWO/ASE exporters are very rare these days. The choice to do it , for me, was made because i am aiming for a full workable model author flow in Blender 2.8+, and as long as collada is de 'default' export format it makes sense.
If you have any recommendations for replacing ASE/LWO with a more used and accessible format I will certainly replace collada with that. for now i will also keep the collada+irrxml local.

Blender support:
It is not a lot of code, grunt of it is managing the pipe streams for the subprocess. Its very 'bare-bones' all it does : it starts up a interactive python console, and executes a list of python expressions which are generated in respect to the commandline that is used in the def's export tag. Which will come down to 4 expressions with an installed md5 exporter plugin in blender.
I have made it in such a way, that the original maya code path is still functional. As user you can give an preffered Graphics Software Tool type which is Blender OR Maya.
All changes reside in anim_import , which it should be implemented in game and d3xp. Maybe we can change that? I dont see a reason, why exporter functionality is overridable by game/mod impl. ?!
I also have to add that it is win32 only (but so are all tools..).

I will create a pr for the 4k fixes soon. !

[turol]

If you have any recommendations for replacing ASE/LWO with a more used and accessible format I will certainly replace collada with that. for now i will also keep the collada+irrxml local.

GLTF is becoming the standard interchange format for 3D models.

[RobertBeckebans]

The good thing about my DAE implementation is that it just works and you don't need to whole Assimp monster in your project. You can export it from Blender and even 8 years later without changing the implementation in RBDOOM you have the model ingame including proper material setup.

However the problem comes down with editors. DarkRadiant doesn't support DAE. It's no problem if you want to use the D3Radiant as it is. Turol is also right with the assumption that glTF 2 becomes the new standard interchange format. Probably all new engines by graphics programmers who write a renderer from scratch use it. glTF 2 also comes with a regression library where you can test your importer against it. It is very likely that I will write support for it in RBDOOM-3-BFG and TrenchBroom this year.

But HarrievG also has a point. It is tedious work to use ASE/LWO with Blender because those formats are really outdated and it just sucks if you want to use the newest bleeding edge Blender version and your custom scripts break every 6 months. That was the main reason to write the DAE importer because it was maintained by the Blender devs and it is faster than the alternatives because it uses C++ instead of Python.

[DanielGibson]

Aren't there simpler formats to replace ASE/LWO (which are only used for static meshes in Doom3, AFAIK)?
Couldn't even OBJ suffice for static meshes?

[RobertBeckebans]

OBJ is good enough if you don't need vertex colors so you can't do any terrain blending like in those hell maps.
OBJ is also what I use currently to get all model data into TrenchBroom and I'm also going to add OBJ support to RBDOOM-3-BFG.

Justin added OBJ support to his IcedTech port: https://github.com/jmarshall23/IcedTech/blob/master/code/Engine/model/Model_obj.cpp

[HarrievG]

On ModelFormats:
To me, it doesnt add any value to add OBJ as long as collada is there. Also having no option to vblend is a step back.
Also as RB said, his dae impl just works. the irrxml is small, so i would say, as long as there is nothing else (glTF 2 is actually a good option, ill try to remember it for future use) lets go with DAE.
And besided that, i am wondering where the blender subprocess is going to take me :)

Thanks for the input guys!

After reading the comments here (thx again) my plan is to update my https://github.com/HarrievG/d3wasm/tree/upstream branch with the changes above but in a flexible way:
Because model format, and qgl impl, are likely to change, i have put all of it behind seperate cmake options (commited) and code defines so that it will be easy to try , take out or replace. These all should be easy to use starting points for extension.

I will do this step by step, so that it will be possible to integrate each item mentioned seperately, or have the easy choice of not taking it. This will all take some time, so keep an eye out on my upstream branch if you want to know where i am at.

I think it will take me a couple of weeks , tops , to get it in.

There are some things i am encoutering which i cannot take out easily (its more like putting it back) without breaking my build. i will mark them so it can be discussed ( maybe fix some errors on my side ?! :P )

Thx all! Lets see where we can take this :)

[HarrievG]

Oh i mean , all the debatable stuff is behind options, the dpi awereness will go in as default ;)

[HarrievG]

My first pull request with only DPI/4K fixes is out