[Enhancement] Graphics improvement #145
Comments
|
For once, all those mods have ARB shaders. Doom 3 BFG needs Cg shaders and it has entirely different rendering pipeline, so directly porting ARB shader into Cg won't work. Why would you think this engine needs to compete with, let's say Unity/UE4, and attract developers? |
|
it does, but not on the technical level. |
|
I think it should compete with UE4 or Unity as it's only decent gpl licensed engine out there. that's why the id software released it, to win the war against engine selling companies. no gamer would buy an engine but they definitely will buy the assets for nice experience. focusing only on doom3 is not going to give anything nice out. i read that you are working with your own fork for steelstorm2, motorsep. that's cool, maybe i buy your game :) but i have to also remind you about the gpl license when working with the said game, if one statically links against gpl code, one has to license the linked object also under gpl. so let's all work towards common goal here, please? |
|
@kortemik Yeah, I am well aware of GPL license as I already released one game using GPL engine on Steam. Just don't see what's there to link statically or dynamically to the engine - it's self contained engine and doesn't really need anything to be linked to it (I am not using any 3rd party libs that aren't GPL or comply with GPL). Obviously you haven't dug BFG engine much - it has quite complex code base (although clean enough and understandable) and there aren't too many programmers out there with skills and time to put into this engine with no returns (it's quite hard to find skilled programmers for a paid position to work on GPL engine). I personally planning on learning UE4's Blueprint, in case I will be having same issues I have now (namely finding programmer for BFG engine/gameplay code), and post-Phaeton (working title was Steel Storm 2) I am going to switch to UE4 most likely (maybe even for Phaeton's chapters past Chapter 1). I do like this engine, and stood by GPL engines like Darkplaces and idtech 4 / Doom 3 BFG, but at the end of the day it hurts development a lot using these, when it's almost impossible to find contractors for these engines. 99.5% of artists / programmers / level designers refuse to work with these engines. .5% who use these engine work on their own hobby projects. |
|
If I recall correctly, BFG did have an ARB 2 fallback but I'm not sure any fork version uses it. That said, it is possible to covert ARB shaders to GLSL which is what BFG's primary render mode uses AFAIK. Right now, there is a fork of RBDOOM-3-BFG which has glossmap support and rim lighting: https://github.com/cs121/TECH4-BFG so that's a start... |
|
@motorsep i personally see the problem as this: the current state of idTec4BFG is bit hard to comprehend for most of the gaming motivated programmers. However if we continue to work with it and release our findings publicly there will be more and more people with competence around it. ID didn't release too much of documentation for using it because either they do not have anything they could share or they did think that the sdk info at http://www.iddevnet.com/doom3/ would be sufficient enough. Their way of work has been quite different from majority of open source business as well as the code is more or less in form of "this is what our in-house is" so I don't wonder why there are no skilled people around it yet. Let's transform it into state of decent open source model and in no-time there will be skilled people. I also read you had a good success around with SWF guis and revamped tools. Would you mind if I asked to put pull request for it? I am working around the header unwinding with assist of dhewgs code. |
|
@nbohr1more Did you look into his code? It seems bogus. I didn't find anything about rim lighting except cvars added. His gloss shader needs alpha channel in specular image. BFG has no alpha in its specular image because they are DXT1 compressed. |
|
@kortemik It's not idTech4BFG, it's Doom 3 BFG. "idTech X" didn't get assigned to it because it's not a new engine, and it's not an old engine. It's not hard to comprehend if a programmer worked on other engines. It is hard to comprehend for out of college students who spent their time working with very basic OpenGL exercises and Unity engine (not to mention people having hard time with any of the idtech 4 engines, unless they modded Quake and other iD games). With UE4 business model, there is no reason to use BFG. None. By the time UE4 is well rounded and polished, DX11 hardware will be prevalent on Steam. Therefore people don't want to work on BFG engine because they feel it doesn't add any value to their portfolio. I did, and no, no pull request will come to this fork. When I am ready, I will release source to its own branch. Then people can either add to it, or get from it and add to RBDoom3BFG. |
|
I don't see a point in a method of working closed gpl source until release because sooner or later one of our commits will cause a nice amount of work in merging and I'd say it's not really counted in as contributing which would be beneficial for all of us |
|
I though it wouldn't be too hard to include those shaders since the source is already available. I know ARB is not the best option but the shaders were already written and they work on DOOM 3. Also both ARB and CG shaders are old, CG is not maintained by NVidia and ARB was "replaced" by GLSL, so the best would be to have everything in GLSL, I don't know how hard/time consuming it would be though. Like the work that was done on Darkplaces engine, why not improve the graphics for this engine? |
|
@kortemik Are you suggesting I should keep compliant to RBDoom3BFG source? I don't think so. As a matter of fact, Storm Engine 2 and RBDoom 3 BFG are already less compatible and only will become less compatible in the future. I have no reason to keep it compatible. |
|
@motorsep I am suggesting just that if you ever want users for your engine the time would be now to have it open. Otherwise there will be rest of us working on something else which is going to be awesome in different way and perhaps with longer lifespan. I have seen both edges of the gpl blade already :) |
|
@johnyukon ARB shader were never released for Doom 3 GPL. So you can't even use ARB shaders outside of Doom 3. It's a nightmare to debug and there are a very few OpenGL programmers who bothers with ARB shaders. Cg shaders are used in doom 3 BFG for a simple reason - write once and engine will compile it for all supported platforms. Kinda like in UE4, where you make shaders with nodes and noodles, and not in GLSL code. Darkplaces is a "baby" of Lordhavoc. He wanted to learn engine programming, so he took Quake and began the process. 12 years later, we have DP engine with all its bells and whistles. Old school. There are no programmers like Lordhavoc, who is willing to grab BFG engine and make it better. For once, it won't become any better than UE4 and CryEngine 3 and Unity. If a developer has no experience modding Doom 3, and graphics/performance isn't an issue, going with Doom 3 BFG would be nuts. Poor decision, uneducated choice. |
|
@kortemik I am not sure if I care for my engine to be used. I am being realistic and seeing how much time and money I already put into the engine, going with UE4 would be a sane choice, if I knew UDK well. I just never used it, and my art pipeline is tied up to idtech X. |
|
"There are no programmers like Lordhavoc, who is willing to grab BFG engine and make it better. For once, it won't become any better than UE4 and CryEngine 3 and Unity." maybe there are or even if there are no other such a guru there are still teams with way greater resources than he has. It's the mentality of open source. I am planning to stick with this engine, no matter what you say. Why? Because of what i already said above and because of cross-platform support. |
|
UE4 runs on Windows, Mac, Linux, Android, iOS, SteamOS, PS4, XB1. |
|
@motorstep: I believe this is what you are looking for... https://github.com/cs121/TECH4-BFG/blob/chris/neo/renderer/RenderProgs_GLSL.cpp |
|
@nbohr1more Yeah, and you look at history, then load the source, all you will see is: if (r_useRimLighting.GetBool() ) //CHRIS |
|
OK, I see that he's just using the Half Lambert lighting from Treb and that already has a term for Rim light:
So the only thing he has above that currently is the (questionable?) glossmap work... |
|
maybe we can collectively work on enhancing the engine while we get more experience at it. personally I don't know how to add a new glsl shader to the engine. in fact I tried and failed miserably :) but I would like to know more about it. I would love to learn such things. |
|
@nbohr1more If tr3b added rim lighting with shadow maps, why didn't he exposed it via cvar nor had screenshots? Have you tried it in action? |
|
@BielBdeLuna I offered several times to the community to join my team. No one cared. Doom 3 community is not willing to work cooperatively on someone's project (worth mentioning Quake's community is about the same nowadays). It's a community of individualists who want to work on their own projects only. Although it could be true for any community nowadays (every one is an indie bound to make a million dollars with their games). I almost wish indie game dev never happened in the scale it happened. |
|
that's a problem for indie privative developers, not for open ones, not everyone is bound to make a million dollars with their games. I shared my knowledge when you asked for the portal-sky thingy. so don't put all of us in your labels. |
|
Having it open source makes no difference. There is only 1 project based on doom 3 that managed to attract developers (and most of them didn't come from d3w) - The Dark Mod. On the contrary, look at iodoom3 - stillborn open source project. It's just something about Doom 3 and its followers. |
|
Anyways... I did some search for shaders and methods that can improve the graphics:
There are many more implementations around, but I'm only getting the ones that looks best. |
|
The advantage of Doom 3 BFG engine is that it doesn't need DX11 hardware to run. If you want to add DX11 exclusive features and limit user base, might as well just jump on UE4 - $19 get you everything and more than you can ever have in D3 BFG engine. |
|
@motorsep those improvements could be done conditional on the renderer and with opengl. Please leave the advertisement of Unreal Engine for Epic Games. It's their job, not yours, and even if it was yours, this is not the right place for it :) I hope you understand. |
|
It's a common sense. And apparently common practice in FOSS communities - asking mindlessly to replicate what's already out there in a better form and shape. As I was told so many time, inquiring in the past about a way lesser advances, but more useful features - if you want it badly - source is open, grab it and do it yourself. |
|
And sometimes you have to replicate what's already out there, because |
|
Of course you didn't read what Epic said about their code - you can learn and use that knowledge to implement your own stuff (engine), as long as you don't copy/paste the code ;) |
|
I thought the vanilla doom 3 code had a lod system on the models with the older tessellation system, my mistake. And gpu tessellation could be used as a global LOD system but it from what I've seen using other engines it make more sense for performance to apply and adjust tessellation to models and leave things like bsp brushes alone and use parallax mapping on them. You would have to divide a brush up so many times to get the effect that parallax mapping can fake without as much of a performance hit. |
|
Seriously?! http://en.wikipedia.org/wiki/Tessellation_(computer_graphics) I've yet to see a game where tessellation was used for lower iterations of LOD. It's mostly used to generate more detailed mesh from existing one. DX11 hardware is required (mostly higher spectrum of modern GPUs), which significantly cuts down your userbase. POM taxes your system badly, I am not sure where "without as much of a performance hit" comes from. Are you guys all with 4+ core CPUs and latest GPUs with 256+ bit VRAM bus? |
|
I'm running a AMD FX CPU, Firepro GPU and 16gb of ram for content creation. When that being said I know gaming performance is not as good as a radeon or geforce GPU, the firepro was cheaper and performed better for what I could afford to fix problems in the maya and mudbox viewports, as I'm back in college. I do have another computer for playing my games which has a geforce gtx 550ti. If you attempt to apply tessellation to something like a BSP brush, which for 1 plane say the ground, you have 1 polygon surface which is 2 tris. When you break that up in tessellation can cause cracks in the surface, in order to fix those gaps and give a better visual look to the surface you'd have to break it up even more or apply addition code fixes to minimize the cracks and make the surface whole, which greatly lowers the performance compared to just applying a parallax map. Yes both do affect the performance but it's about weighting which one is the greater of the 2 evils on performance for the geometry and quality you are looking for. Here is an article taking about tessellation performance and cracks in unreal which happens in both udk and unreal 4. Here is an article taking about dx11 features in the crytek engine and reason Also another link talking differences in tessellation methods and cracks. I haven't used or experimented much with the crytek engine so I'm not sure how they are doing the LOD tessellation on surfaces like the water. http://www.behardware.com/art/imprimer/838/ |
|
lol.. How about checking Steam hardware survey and understanding what majority of people game on? Tessellation was not designed for brushes, it was designed for polygonal models. And displacement is != POM. Displacement deforms actual tessellated geometry. POM is fake (can be a good one, depending on implementation), but also performance taxing. |
|
I understand what the majority of people currently use as a gaming system. Console commands could be added placed to switch between a opengl3 and opengl4(dx11) mode or turn off tessellation. I brought up tessellation as a possible feature. BielBdeLuna and I were discussing the applications of tessellation and the differences. The term brush may have been a wrong choice of word, any large polygon surface can have problems with tessellation. |
|
nevermind tesellations for the moment, we have to find a way to convert the models into somewhat brushes, discard so many func_static, and use those entity slots for actual entities that do something other than be there. if we could separate the model that the game displays as "the map" and the actual map (the polygons that actually are used to calculate the portals, and visibility), and even use several models for different portal sections of the map and somewhat bind those models to the portals, then we could do some LOD processing to the actual map models not the func_static ones. with this separation we could have also vertex painting effects on the "brushes/models", this and instancing would be really neat in order to do bigger cities using a lot of repetition of the assets. |
|
Would that require the creation of a different map file format for the reading of two different map types? |
|
yes, the development of a next gen map format. that would be an evolution of what already it's there but with some more info for the engine to play with. |
|
I implemented a PBR approach in e9e0fd3 |
|
The PBR mostly affects the specular lighting as the diffuse lighting is still Lambert or the optional Half-Lambert. It is not really physically correct with r_lightScale 3 as the default setting which is passed to the diffuse and specular modifier. However it is a start for people who want to create new content and want to see how PBR can be implemented with Doom 3. |
|
interesting |
|
how does it work. how do we use it? |
|
I think you need PBR compatible assets... care to post an example material Tr3b? Going back to the ambient. I've always wondered about the implications of adding SSAO as part of the ambient light interaction rather than as a post process since each ambient light is additive and you could get some interesting obscurance patterns by having brighter ambients overlap darker ones and modulate the amount of AO where brighter. And while I'm back-tracking. I think it might be possible to take a high resolution normal map baked for a low-poly mesh programmatically color adjusted in the shader to keep from deforming when the underlying model is tessellated. You would simply map a relative color inversion per-poly. I wonder if anyone has tried that? |
|
If you want PBR in a total conversion then you need to replace // HACK calculate roughness from D3 gloss maps with values from a texture that has PBR values for roughness. These values can be grabbed from glossmaps. |
|
if we include a new "glossmap" as a new material token which references either RGB (all channels the same image, which in my opinion would be quite a waste) or graysacle (just a single channel image) and passes it to the shader would it affect the *.bimage format? |
|
We implemented gloss in Storm Engine as standalone RGB image (same as specular). |
|
but that's not the point, it can be included as a token in the material, with more or less difficulty, but does it affect the *.bimage file? |
|
why do you care about .bimage ? It's just a container. Set you your gloss image properly and that's it. |
|
but that's what Robert said, that changing *.Bimage was problematic if we included the gloss-map as an alpha. so still if we doesn't do it as a alpha channel but as an independent image. does it affect the format of *.Bimage? that's the question |
|
It is no issue as independent texture. Even if you provide RGB channels as Or you go even further and use the compact model of UE4 and replace the 2014-09-29 22:00 GMT+02:00 Biel Bestué de Luna notifications@github.com:
|
|
"I don't think graphics are the most important aspect of a game but it's needed to compete with proprietary engines and attract developers." I disagree, I'm very happy that doom3bfg runs mostly flawless on linux and other operationg systems and probably will another 100 years just like quake/II/II and doom^^ I'm not too much into graphics improvements and even prefer to turn off soft shadows. |
|
@rudl I agree with you on that one, however, you have to consider that these guys aren't making a game, but rather improving their software development skills in real-time rendering :) Plus, nowadays there are certain minimum expectations for graphics. So a few extra optional effects is a good thing to have. Shadow mapping is a needed feature (although the current one requires to be optimized as it's not usable in the current state unless you have powerful PC). You could work around not having shadow mapping by using low poly shadow meshes, but that's just royal p.i.t.a. when it comes to animated characters :/ Even with all the features from all moderns engines, combined, BFG engine can run for 100 years, like Quake, because hardware is improving. So what's novelty and slow today, will be a norm and fast tomorrow. |
|
who is not making a game? |
|
Any interest in trying Penumbra Wedges just for shits and giggles: http://www.terathon.com/gdc05_lengyel.pdf ? It would be cool to compare. |
|
Yea I totally agree with nbohr1more, the semi-penumbral might even suit the On Mon, Nov 3, 2014 at 1:47 AM, nbohr1more notifications@github.com wrote:
|
|
Just for you guys to know! A new low level API called Vulkan from Khronos Group may replace OpenGL, and is being used in Source Engine 2. Check it out: |
|
Vulkan will be made ready to the public in October or something like this, Valve is using it already because they are a member from Khronos, only after the specification is out can we start using it. I think Robert already said he is interested in Vulkan. I think SPIR-V is already out isn't it? Would it be wise to start a GLSL exporter for SPIR-V if RbDoom3BFG already has a CG to GLSL exporter? |
|
We should wait for Vulkan and see how it works. I have read on the Internet that recent versions of OpenGl add some features that greatly improve performance, getting closer to Vulkan's. As Vulkan is a lower level API (runs closer to hardware) it will require more coding compared to OpenGL, also we already have access to a lot of OpenGl resources (code/documentation) around in the Internet, see bellow. Please see https://github.com/tobspr/RenderPipeline/, its for Panda 3D (panda3d.org), and runs on OpenGl 4.x. |
|
There will be at least three versions of Vulkan, yo uwill be able to use Vulkan as a simple Graphics library like OpenGL, but if you want to go further down in the drivers code you can, so let's wait and see before judging it. |
I see graphics are already being improved, we have better shadows now.
There are many mods created for DOOM 3 that may help in this task because they already have shaders and other stuff:
http://www.moddb.com/mods/sikkmod
http://www.moddb.com/mods/perfected-doom-3-version-500
http://www.moddb.com/mods/parallax-mapping-mod-10
http://www.moddb.com/mods/g-t-x-d3
http://doom3.gamebanana.com/gamefiles/3756
There are probably many other mods around but I think that the most famous one is sikkmod. It comes with source code.
Also I don't know if this might help, but the Tesseract engine, based on cube 2 engine, implements some neat graphics effects, like real time global illumination:
http://tesseract.gg
I don't think graphics are the most important aspect of a game but it's needed to compete with proprietary engines and attract developers.
The text was updated successfully, but these errors were encountered: