Open dhewg opened 12 years ago
I would like to do it next time I have time, might pick it up this evening.
Any idea whats not working/not finished in it? I played with it and it seemed to work just fine.
Alright, I have identified some differences/flaws which I want to correct. (I first updated to his latest versions of the shaders your patches were missing)
1) Specularity looks sketchy compared to arb2
3) Optimize, optimize, optimize
4) Custom render passes
5) Hook up with a high resolution timer to tell how long renders are taking
Btw the commit is at 2bfe28dcb2c2c00732d03d50a523023e6b55428d (With the modifications)
Here's a newly released branch with both GLSL and ES 2.0 renderer:
FYI, my tree has been renamed and moved to https://github.com/omcfadde/dante
GLSL backend is implemented with some minor missing features (i.e. shaders for heatHaze, heatHazeWithMask, etc.) There may also be other bugs. Hopefully I will have time to fix them soon.
Is there someone working on merging dante's modifications?
Not that I know of. Plus what's there to merge? It's not 100% working yet.
heathaze and multitexture and such will need to be implemented for that to happen
Why does one need GLSL backend precisely ? ARB shaders can be made using RenderMonkey and FX Composer afaik. Where it's ARB or GLSL, one still needs to know what to do and how to do it.
ARB is outdated and basically coding assembly, GLSL is more like coding C.
Oh, I am aware of that. But isn't it irrelevant when using above mentioned tools for share creation ?
Even if you use some kind of shader compiler to compile down to ARB, arb is still limited in terms of available features/limits. FX Composer can be used to create CG shaders, which can then be compiled down into ARB only if you use the feature sets available in ARB. GLSL is the more modern solution, even if some shader languages compile down to ARB still...and even then..you are coding in CG..not GLSL..two totally separate shader languages.
It's possible for the GLSL compiler to generate much more efficient code for whichever hardware you happen to be running. While both ARB programs and GLSL shaders may be compiled to the same intermediate representation internally, GLSL is able to provide a significantly more context information which the compiler can use to generate more efficient code.
Many so called high-level optimizations that are possible when compiling from GLSL are simply not possible, or are prohibitively difficult with lower level languages (or intermediate representations thereof.)
You are comparing apples and oranges when talking about GLSL shaders vs. ARB fragment and vertex programs, and I generally do not like the "C vs. assembly" comparison, but in this case the example is quite apt; the C compiler will eventually use the assembler, but not before it's had a chance to make many optimization passes at the high level. The assembler may then perform further low-level optimization on the IR before finally emitting machine code.
andre-d, heat haze will be coming; I have some work on a local branch, but it's not release ready yet.
RaynorPat has a new branch with Mh's VBO Cache and GLSL ported from BFG:
Did you see that his fork is no longer on Github ?
This one is:
https://github.com/raynorpat/Doom3
however, it seems that he also has a deferred shading branch
https://github.com/raynorpat/dhewm3
too.
Just a note here: if this (or any other new rendering-backend) is gonna happen eventually, I'd like
@DanielGibson the second point: translation of ARB to GLSL is an interesting problem on it's own. Are you aware of any existing tooling that does this?
I searched for a bit and only found people asking the same.
I'm not, but it doesn't seem like a super hard problem to me? ARB assembly seems to be pretty limited (even more so when assuming that the relevant shaders only use the core instructions and not nvidias extensions), it'd probably be possible to just translate it line by line to equivalent GLSL (and then add some "static", most probably game-specific, GLSL code before and possibly after that for passing in/out vertex data and uniforms).
One problem seems to be that finding documentation and tutorials/examples on ARB assembly is kinda hard; here are a few sources I found when researching this a while ago though:
Despite doing this (minimal) research I haven't looked into how to actually do this though, so if you or someone else wants to do it, that'd be great! :-) Probably a good starting point on the C++ side of things is an existing "modern" OpenGL renderer that uses GLSL (with rewritten shaders), I'd probably use the one from D3Wasm (https://github.com/gabrielcuvillier/d3wasm).
Thread with beard... @coreyoconnor Why not to just use renderer from Doom 3 BFG for dhewm3 ?
@motorsep that doesn't really bring the compatibility piece for mods still using custom ARB shaders
@motorsep that doesn't really bring the compatibility piece for mods still using custom ARB shaders
What if someone writes a parser to convert ARB to GLSL on the fly? :)
@motorsep
Interesting project right? A C++ library providing source to source translation of ARB to GLSL. Would be useful outside of doom 3 as well I bet.
The specs for ARB_vertex_program and ARB_fragment_program contain a grammar of the language.
If you can live with only the interaction shader being drawn with GLSL this might interrest you.
This will override the ARB2 assembly shaders with GLSL if your card supports it. The benefit is that we can still use things like sikkmod (tested), and the internal GLSL interaction shader looks better than sikkmods. One downside though is that we cannot use sikkpins parallax shader unless we create a cvar for turning of GLSL completely, since sikkpins parralax shader is an interaction shader.
This code was originally by michael hiney, but it had a few bugs that i been working over the years to iron out, since im not very well versed in shaders it took longer than i expected but it works rather well now.
Next thing would be GLSL for the stencil shadows, though if we want to still be able to use things like sikkmods soft shadows, it will be nessesary with a cvar to turn it of.
Ported my work on the hybrid GLSL / ARB2 backend and uploaded a 32 bit windows build here.
not much improvement speedwise, maybe 1 fps, it might actually gain more with things like sikkmod. Also ported a few things from darkmod like SSE enhanced matrix operations, still need to get the SMP code ported and then there is also the SSE enhanced Culling code from darkmod.
R_testGLSLInteractions is on by default, but if you want to toy with seeing the differences between the two render backends just set it to 0 ( you might not actually see much since its pretty close to the original ARB2 based renderer in regards to the overall look, the GLSL backend is a bit crisper though ).
However, there is no Sikkmod for dhewm3 because the C++ code is not released under GPL?
You're the only one who cares.
Yes, but I'm running this project.
I have sikkmods game code, i doubt that it was intentional that it was not released under GPL since i been doing collaborate work with sikkpin some years back and he newer expressed any resentment against anyone using the game code. However im not sure where he resides these days since i been on hiatus due to bad health for several years, so contacting him might be hard.
Code is still worthwhile if not for other reasons than that it gives us more options. Newer coders might be more into GLSL than assembler these days anyway :)
I definitely care. Don't let the negative folks discourage you :)
And yea, I'm still thinking an ARB to GLSL translator would be a valuable product. Too bad I'm full with other stuff :(
I think you're confused, @coreyoconnor .
I'm all for implementing Sikkpin's code. If he didn't want this, he wouldn't have published it.
Well to be sure theres no problem, and i doubt that... i contacted sikkpin via his old information on insideqc. Lets see if he still reads the PM's there.
So for the heck of it i tried building sikkmods game dll with the sdk, and it runs quite good here with the hybrid code. But tbh my gfx card while last last gen still has the muscle to run the newest games with playable fps ( AMD R9 390 ), so it might not be the best pointer, biggest fps hog seems to be the parallax interaction shader ( need to run the game with GLSL off for that one ) and soft shadows. These two rip about 20 -> 30 fps alone. There are also better options for softshadows today since we can now access the depthbuffer in Doom3 ( this feature was added to darkmod some years back by me and SteveL ).
SSAO runs fine on this card maybe 1 -> 2 fps less.
Ported AVX and AVX2 from darkmod to my test engine ( not dhewm based ) and it gives a neat boost ( around 8 -> 10 fps ).
Also started porting the SMP code ( so far only the async thread timer update code has made it in ) but atleast that takes care of the microstutter sometimes noticed.
The timer now uses microseconds instead of milliseconds so resolution had to be changed from 16 ms to 3 ms or it would cause double frames.
Don't get me wrong, I'm all for GLSL support, I'm just skeptical about Sikkmod - but we can have one thing without the other!
Would be cool if you could reach Sikkpin - I tried contacting him via E-Mail twice (I think) but never got any answer :-/ The last "public record" of him is that he logged into moiddb in 2012: https://www.moddb.com/members/sikkpin it's like he vanished afterwards
If he didn't want this, he wouldn't have published it.
It's not that easy. Under SDK license the code could only be used in noncommercial Doom3 Mods. Under GPL it can be used for anything, as long as the product's source code is available - including commercial games (and there are commercial games using GPL'ed id Software engines, e.g. SteelStorm or the Blendo Games). We don't know how Sikkpin feels about his code potentially being used for commercial projects (without him getting any money for it), so I don't think it's OK to just put it under GPL. Unless he agrees or has agreed to it in the past - I couldn't find anything on that matter, but Doom3world is down and much of it is missing on archive.org, so no idea..
Well he spent some time on insideqc after doom3world went down, but that is also some years back. I pretty much got his permission to use his shaders as i saw fit, though we newer discussed any commercial projects.
So im as curious as you if he answers.
But i guess the problem lies in the game code ?, allthough by default it should follow id's licensing.
Yes, the problem is the game code. And id's default licensing was the SDK license - this was way before Doom3's source code was released under GPL. So to use old mod's source code with a GPL source port like dhewm3, the code must be re-licensed under GPL (specifically the flavor Doom3 uses, which is GPLv3 with some additional clauses from Zenimax). Re-licensing means that everyone who contributed C++ code to the mod must agree that it's released under GPL - I was able to get that OK from several mod teams for https://github.com/dhewm/dhewm3-sdk, but there were also people who didn't want their code to (potentially) be used in commercial games...
If there is GLSL backend, I am sure it would be easier to find someone to write new GLSL shaders than look for Sikkpin for permission to use his mod in Dhewm3
I remember Sikkmod required a lot of asset adaptation to properly work with shadows, like adding a duplicated mesh in each md5 file with a shadow material for self shadowing and such, and a lot of .mtr overrides.
Not an ideal approach for a graphical enhancement, but that's just me.
Well no reply from him yet but lets see.
Atm the backend only handles the interactions for bump / specular / diffuse so it should be relatively easy to write new shaders for it, though it would be limited what you could do ( parallax occlusion mapping in GLSL is one example that should be possible ).
At some point im going to try and port more stuff from darkmod like framebuffers / depthbuffer access / and expand the GLSL capability to also include material shaders and shadows, but that might take a while since im pretty much retired as a coder, and only dabble in it from time to time to keep my skills.
Sikkmod was just an example to show that the backend could handle mixing in with older mods without to much trouble, and granted it uses some nasty workarounds, but at the time we did not have access to the engine code so i think sikkpin made as good a job as he could with the limitations at the time.
Well, if shaders will be written from scratch, why hold on to ARB shaders at all?
Just a compatibility question really, fhDoom while fully GLSL driven still does not play the expansion because of missing shaders and since im no shader guru that part is more upto the userbase that has experience with coding in glslang.
Id rather not break the code for the dhewm maintainer so im going for the baby steps approach atm. When im satisfied things work without problems ill upload a patch he can yank in to the engine if he feels the need is there :)
there is a reason I recommend using RBDoom 3 BFG's renderer - it has all GLSL shaders.
Tbh my intentions with this was mostly to get a working hybrid backend going which daniel could then build on, i newer had any intention of doing a full GLSL backend since it seems daniel cares about old mod compatibility which this one provides.
Im retired, but over the time i made a few neat things that might benefit others, but Im not going to turn it into a full time job again no matter who cries. :P
Im simply getting to old for the kind of workload such an undertaking would require, and as you seen i had my fair share of bedcare in the hospital wards ( broken back "10 years walking around or trying to since i could only go about 100 meters, before the doctors noticed" -> kidney stones "twice now and more to come" -> gall stones "luckily only once but damn" -> nerve damage "irreperable damage because of the broken back" you name it... ).
Ill still provide tidbits that might come in handy from time to time though.
since it seems daniel cares about old mod compatibility
... which is a complete dead end, especially because of insisting doing things by the book. I seriously doubt the amount of old mods supported by dhewm3 will even grow beyond what it supports at the moment, because everyone moved on well over a decade ago.
Noone discurages anyone from updating anything :) if the demand is there it will come.
That said there exists a number of engines that have much more modern capabilities, fhDoom for instance or RBDoom both support GLSL fully and have shadowmaps and whatnot.
If one prefers the older tech 4 engine fhDoom is the way to go, otherwise RBDoom or motorseps steelstorm engine are pretty nice.
I cannot speak for cross compatibility though, but from what i heard both engines can be built on linux as well.
fhDooms main problem atm is the lack of shaders for the expension ( it pretty much only plays Doom3 at the moment but looks good ), RBDoom has a nasty bug with HDR and SSAO which causes black splotches on AMD cards if both are on, but it can play both Doom3 plus the expansion and has a good deal of shaders for experimenting on.
fhDoom has parallax mapping but no SSAO, and parallax mapping is of by default because some of Doom3's heightmaps are bad causing glitches like we seen in sikkmod with sliding textures on some environments.
Darkmod also has enhanced capabilities like full GLSL capability and to top that off it can also still use some of the older ARB2 shaders, but you cannot play Doom3 with it anymore since it is now a total conversion of the old thief game.
Some features from it can be ported to other Doom3 engines though and im toying with that atm.
if the demand is there it will come
Demand won't come until a mod that grabs people's attention does.
Well darkmod certainly did just that :) it won an award. Sadly it is not usable as is for Doom3 because of the many changes to the engine. The source is open though, so anyone could create a mod with it. At times i wished i had any skill whatsoever in mapping, i allways wanted to create a game from scratch.
Unfortunatly i cant draw anything without breaking both pen and paper hehe. I do have an idea for a game, but it would require someone with skills in mapping / modelling as the only other thing i could contribute besides code would be sound ( old guitar and bass player ).
Just out of curiosity, have you tried the mod redux ?. It updates Doom3 graphics somewhat using nothing but optimized shaders / corrected materials / HD textures, and a special handcrafted version of the old venom menu. It looks rather good but loading time is slow as molasses.
Its actually a pity that it is a mod because it would have been a nice update to Doom3 itself.
Revelator, is really cool what you are doing of porting some TDM features, it has a lot of goodies, maybe this could open the doors for some devs to enhance the engine a bit, if not in dhewm 3 maybe in some other fork.
fhDoom is very nice, but sadly the developer has gone silent and work on it stalled some time ago.
There're two GLSL branches floating around: 1) https://git.iodoom.org/~raynorpat/iodoom3/raynorpats-glsl_iodoom3/commits/master and a continuation 2) https://github.com/LogicalError/doom3.gpl/commits/master
Both are based on different trees, and I merged those a while back on top of my tree: http://static.hackmii.com/dhewg/0001-Add-GLSL-backend.patch
My lack of GL foo is disturbing, but maybe someone wants to finish this backend?