Jump to content
The Dark Mod Forums

Recommended Posts

I hope this isn't a useless thread, just thought it would be constructive to let everyone know about it. I was looking up some TDM related concerns, and accidentally stumbled across another fork of the idTech4 engine. It's called fhDOOM, and it seems to have a lot of neat graphical improvements over the stock engine.

 

eXistence/fhDOOM

 

There are definitely things in there that TDM could consider grabbing! Some important ones highlighted on their front page:

  • Modern renderer based on OpenGL 3.3 core profile. Any up-to-date engine should have this as a norm.
  • Parallax mapping. Not sure if we have this already... I only know the original engine had simple bump mapping.
  • Soft shadows. A heavily desired and long awaited feature.
  • Alpha textures affecting shadows. This allows light to shine through textured grates, which is a very beautiful improvement.
  • Soft particles. This one we already have now however.

An example of the old lighting system (ours) versus lighting with shadow mapping (fhDOOM):

 

 

 

shadowmapping2_off.jpg

shadowmapping2_on.jpg

 

 

 

As the obstacle to new features is almost always finding someone willing to code them, discovering those improvements for our engine is a goldmine... since unless they conflict with any of our changes, I assume they should be easy to just plug into the code. Can any of this good stuff please be considered for inclusion in TDM's version of the engine?

  • Like 2
Link to comment
Share on other sites

Yes, we've looked at that.

 

There are things in there that may come in handy.

 

And, yes... the Soft Shadows might be useful for transparent objects but as a "general solution" it's buggier than our own (work-in-progress) internal solution.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Yes, we've looked at that.

 

There are things in there that may come in handy.

 

And, yes... the Soft Shadows might be useful for transparent objects but as a "general solution" it's buggier than our own (work-in-progress) internal solution.

 

Oh... soft shadows are being worked on for TDM? Didn't know and it's definitely wonderful news!

 

Yeah, it would be lovely if a way to let transparent textures cast shadows would still be found. Of course there's the problem that TDM uses volumetric shadows... since lighting affects how enemies see you, a switch to shadow-mapping might break existing maps so it probably can't happen. I wonder if as an alternative, the shadow code could be tricked into interpreting alpha textures as geometry... I imagine that would be both tricky and costly.

 

Also... because I've actually been curious for ages now: Is parallax mapping something that TDM has? I know the stock idTech4 engine didn't have that, only simplistic bump-mapping. However if I look really close at the details of textures in TDM, I can almost swear I see a parallax effect... yet it's so discrete I can never put my finger on it :P

Link to comment
Share on other sites

No parallax mapping yet.

 

We could add a dedicated map type for it now to reduce the performance impact so the whole scene wouldn't need it.

Pretty easy but not a priority.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

No parallax mapping yet.

 

We could add a dedicated map type for it now to reduce the performance impact so the whole scene wouldn't need it.

Pretty easy but not a priority.

 

Ahhh, okay. Definitely hope it's added... parallax is a rather basic effect nowadays. Although the bump mapping is so well made I actually confused it with parallax on several occasions.

Link to comment
Share on other sites

I know that engine is the most modern but also more similar to the original one, it has full support for all vanilla idtech 4 features and tools, for example the vanilla GUI system, where all engines based on Doom 3 BFG source require Flash, at lest for fullscreen GUI's.

 

There's other stuff on it that is cool has well imo, support for Qt GUI based tools, for example the fhDoom engine light editor is made with it, and looks very nice imo, unfortunately is the only converted tool for now plus i don't know if you can do game based GUI's with it.

 

It also has direct support for GLSL shaders, their usage in materials is very similar to the ARB ones.

 

Btw MirceaKitsune is just a technicality, but fhDoom has support for Parallax Occlusion Mapping or POM (off by default), that is a different tech from Parallax Mapping, that is a older and imo uglier technique (makes everything look like molten glass), POM is similar to Horizon Mapping for example. Also vanilla Doom 3 has support for POM as well but you need to install a modified ARB interaction shader, if i'm not mistaken SIKKmod has one, POM also requires a bump map (black and white texture) in the case of fhDoom that bump map most be put onto the alpha channel of the specular map, btw not confuse with the bump keyword for TDM materials that only convertes a bump map into a normal map.

  • Like 1
Link to comment
Share on other sites

not confuse with the bump keyword for TDM materials that only convertes a bump map into a normal map.

This keyword actually expects a normal map. Conversion is done via another command (normal iirc).

 

But as he says POM requires a heightmap (so an image that contains information about the height of a surface). This means that either each material that should use this effect would need this to be added, which is a lot of work, or the interaction shader would have to integrate over the normals to retrieve the neccessary informations, which is performance houngry.

 

Regarding the graty shadows. This can easely be faked with a proper light texture. We already have such textures for certain grates and windows, and it is easy to create on out of an existing texture. It would be easier to have the alpha-affected shadows, but it is not a big miss.

  • Like 2

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

That soft shadow technique looks cool at first, but it's not that good for character shadows in those screenshots. The question is, how it affects performance, since the lights will still be dynamic? I guess it's just some kind of shadow interpolation? Not that anyone's expecting a lightmapping system from TDM team, that's enormous task, and it would generate a whole host of other problems :)

 

Regarding the graty shadows. This can easely be faked with a proper light texture.

 

My thoughts exactly. But shadows using alpha channel could be useful for stuff like grass or leaves, since faking organic stuff is a bit harder.

Edited by Judith
Link to comment
Share on other sites

This keyword actually expects a normal map. Conversion is done via another command (normal iirc).

 

But as he says POM requires a heightmap (so an image that contains information about the height of a surface). This means that either each material that should use this effect would need this to be added, which is a lot of work, or the interaction shader would have to integrate over the normals to retrieve the neccessary informations, which is performance houngry.

 

Regarding the graty shadows. This can easely be faked with a proper light texture. We already have such textures for certain grates and windows, and it is easy to create on out of an existing texture. It would be easier to have the alpha-affected shadows, but it is not a big miss.

 

The normal map (texture_local.tga) holds all the information you need for both bump and parallax mapping, there's no need for a second texture. Every engine I can think of uses a single normal map for both bump and parallax. You can take Darkplaces / Xonotic for a quick example, which has both simple parallax mapping as well as refined relief mapping (it's based on idTech1 BTW).

 

That soft shadow technique looks cool at first, but it's not that good for character shadows in those screenshots. The question is, how it affects performance, since the lights will still be dynamic? I guess it's just some kind of shadow interpolation? Not that anyone's expecting a lightmapping system from TDM team, that's enormous task, and it would generate a whole host of other problems :)

 

 

My thoughts exactly. But shadows using alpha channel could be useful for stuff like grass or leaves, since faking organic stuff is a bit harder.

 

Actually I've seen a few cases where soft shadows were more performance efficient than hard shadows, though I imagine that's because they also activate a different rendering technique which is itself cheaper. In any case, a cheap way to blur shadows should easily be within the realm of possibility. I mean look at Tesseract engine (Cube2 fork): They even found a way to do realtime bounce lighting for static lights, at nearly no performance cost... yet more ideas to hint at :D

 

If there's anything I'm concerned about regarding soft shadows, it's the following question: Would it be possible to make the blur depend on the distance between the surface casting the shadow and the surface receiving it, so that they actually work as in real life? I imagine volume shadows ironically make this easier, since you can calculate the distance between two vertices and tell how much blur there should be at a given point. We'd actually be one of the few engines to have this lovely little addition, so it's surely a thought worth bringing up.

Edited by MirceaKitsune
Link to comment
Share on other sites

Still, it all comes down to how it's done. If it's lightmapping, you'll need to take care of shadow quality settings for brushes and meshes, and pk4 size will go up because of baked lightmaps. If it's still dynamic lightning, what's the performance hit, etc.

Link to comment
Share on other sites

Shadow maps do well where there are few large static lights.

 

Stencil shadows do well where there are lots of small dynamic lights.

 

The costs of both have come down and Shadow Maps cover most of the conventional uses

so they are the most widely used but Stencil Shadows can still win in certain scenarios.

 

Shadow Maps in modern engines often have vastly complex LOD and visibility schemes which

make large shadow coverage render with the most texel data for the least cost but such schemes

don't map well to moving light sources so moving lights are usually tied to more simplistic shadow map

generation that doesn't have as much optimization and will drive up shadow cost quickly when more

lights are added.

 

Doom 3 is an exaggerated use case with lots of small lights and moving light sources in a dark space station.

TDM isn't quite optimally matched to this use-case but we do have some similarities with our use of small radius

candle illumination. The Shadow Map variants of Doom 3 are mostly relying on brute force hardware improvements

since the original release or the extra overhead afforded by the BFG engine's optimizations.

 

(Someone recently figured out how to do tiled shadow maps which would theoretically alleviate most of these issues.

http://hd-prg.com/tileBasedShadows.html )

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Well, in practice it's not quite like that. If you open any UT3 or Gears of War map, you'll see tons of static lights, whether it's larger area lights, fake bounce lights, or light sources like lamps, with materials faking things like pulse or flicker. Dynamic lights are almost never used, except for flashlights or vehicles maybe.

 

That said, I always kind of liked stencil shadows. There was something nice about them in Thief 3, and in the whole engine, however broken. I can back to playing T3 though, because of the movement. TDM really spoiled me on that front ;)

Edited by Judith
Link to comment
Share on other sites

(Someone recently figured out how to do tiled shadow maps which would theoretically alleviate most of these issues.

http://hd-prg.com/tileBasedShadows.html )

 

Wai.. wait, hold up a second. This guy managed to copy shadow information into cubemaps?! That's freakin brilliant. I always had been a fan of pre-baking shadows into single channel, lightmap textures. The problem had always been that foreground elements (the proposed shadow caster) being covered by the baked shadow map. Only solution there was having the shadow casted (projected lightmap texture) and then a second fast light to illuminate the front of the actual object in question. That ended up being how I did these soft shadows...

 

 

showerscene_2016-05-03_18.45.46_zps2tvhd

 

 

But again, that's TWO lights to accomplish one instance of soft shadowing. It only is worth while for really moody shots that are secluded. So the usefulness of that method is how much do you want certain lighting scenarios to pop? Honestly though nbohr1more, I'm very curious about that new lighting method you brought up. Not asking if it's ongoing, but what are the possibilities you see in that being adapted to the engine personally?

 

EDIT: Also that parallax mapping would be dope considering how much time I spend on highpolys and heightmaps. ;)

Edited by Epifire

Modeler galore & co-authors literally everything

 

 

Link to comment
Share on other sites

 


The normal map holds all the information you need for ... parallax mapping

 


the interaction shader would have to integrate over the normals to retrieve the neccessary informations, which is performance houngry

;)

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

The normal map (texture_local.tga) holds all the information you need for both bump and parallax mapping,

 

That is not totally true, specially for techniques like POM, some engines do use a single normal map for everything but what they do is, one, they put the bump map on the alpha channel of the other textures (diffuse or specular) or the normal map it self, two, they put extra height info in the blue channel of the normal map, normally the blue channel has a small amount of height info, or no info at all, is just full white ( that is how the blue channel is represented in photohop, could look different on other tools), if i'm remembering correctly idtech 4 normal maps have a full white blue channel, meaning they have no usable height info on the blue channel, you can see if this is true by looking at a vanilla Doom 3 normal map in photoshop for example, other times, you can see right away that the normal map has extra info, because it looks strange not like a "normal" normal map should look, for example Penumbra Overture has some normal maps with obvious extra info they look different from the rest.

 

POM is disabled by default in fhdoom and i'm sure is because Doom 3 lacks good height info on its normal maps alone but i do recall some old shader mods for Doom 3 were POM like tech was used (steep parallax mapping i think it was) and they converted the normal maps some how and the tech looked good enough.

 

btw this is a nice read:

https://www.katsbits.com/tutorials/textures/understanding-oblivions-parallax-maps.php

Edited by HMart
Link to comment
Share on other sites

Interesting. I wonder if a simple solution could be to just generate a grayscale texture from the normal texture on map load, though I seriously don't imagine it's that easy. Putting the bumpmap in the alpha channel or the normal texture would make sense as an alternative in that case.

Link to comment
Share on other sites

Interesting. I wonder if a simple solution could be to just generate a grayscale texture from the normal texture on map load, though I seriously don't imagine it's that easy. Putting the bumpmap in the alpha channel or the normal texture would make sense as an alternative in that case.

 

It's much easier to generate normal from a heightmap (same as bumpmap) than the opposite. The major difference being that normals data is dealt to convey edge details, whereas the B&W bumpmap is just used to calculate low to high areas.

 

I wish we could use alphas for more than just opacity. As far as I know, the engine doesn't support much else for alpha masks. Otherwise I would have been packing my speculars with my normals this whole time. If the system could be modified that would be a different story. But I highly doubt it's as easy as copying and pasting new code in.

Modeler galore & co-authors literally everything

 

 

Link to comment
Share on other sites

Interesting. I wonder if a simple solution could be to just generate a grayscale texture from the normal texture on map load, though I seriously don't imagine it's that easy. Putting the bumpmap in the alpha channel or the normal texture would make sense as an alternative in that case.

 

 

It's much easier to generate normal from a heightmap (same as bumpmap) than the opposite. The major difference being that normals data is dealt to convey edge details, whereas the B&W bumpmap is just used to calculate low to high areas.

It's not neccessarely easier to create the normal from height then vice versa. You get the normals by differentiation and the height via integration. The problem with the later is that you don't have a unique solition there, so you have to work with assumptions. Depending on those the results may vary.

 

It would be possible to create the height maps during map load, but depending on how many textures are used this may take some time. In gimp it takes roughly 1-2 seconds to convert the normal map to a height map. So I would guess that for an average map the loading time would increase by 1-2 minutes or even more on low spec machines, which is not feasible.

 

Processing the integration in the shaders during runtime would not impact loading times but is performance houngry.

 

No, having the info stored in heightmaps is definetely the way to go. This would also add the benefit that skilled image artists could lay hand on them to improve them, as the automatically created ones may not neccessarely be perfect. (The gimp one seems ok and allows for tiling, but I don't know how the result would look like in game)

 

However, even with the heightmaps it would be important to judge on how high the performance effect is. And it should be possible to disable it if it eats a lot.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Last time I saw parallax effect in action, it made all things look like jelly. I don't think it's a standard effect in games, even nowadays it's used rather sparingly, as it's another texture, or at least additional channel for your GPU to process. IMO, more often you'll see mixed modeling/texturing techniques, like ground textures + clutter parts modeled on geometry and using the same material, because it looks better and it doesn't require additional texture.

 

On my list of priorities, it would be more useful to add a fresnel effect for example, in a form of material stage keyword, so we don't have to use a program.

Edited by Judith
Link to comment
Share on other sites

 

It's not neccessarely easier to create the normal from height then vice versa. You get the normals by differentiation and the height via integration. The problem with the later is that you don't have a unique solition there, so you have to work with assumptions. Depending on those the results may vary.

 

It would be possible to create the height maps during map load, but depending on how many textures are used this may take some time. In gimp it takes roughly 1-2 seconds to convert the normal map to a height map. So I would guess that for an average map the loading time would increase by 1-2 minutes or even more on low spec machines, which is not feasible.

 

Processing the integration in the shaders during runtime would not impact loading times but is performance houngry.

 

No, having the info stored in heightmaps is definetely the way to go. This would also add the benefit that skilled image artists could lay hand on them to improve them, as the automatically created ones may not neccessarely be perfect. (The gimp one seems ok and allows for tiling, but I don't know how the result would look like in game)

 

However, even with the heightmaps it would be important to judge on how high the performance effect is. And it should be possible to disable it if it eats a lot.

 

I'm more speaking from conversion in texture creation. I can't speak for anything the engine could devise. Most stencil brushes and detail maps work as heightmaps to start with which are then converted to normal data to combine with baked out normals. Now when I think of parallax affects, I primarily think of faked image warp/depth affects. This would be useful in some detail heavy materials that are trying to pull across a lot of protruding shapes. I don't ever recall it being a lightweight process though, so it would be overkill to see extensive use where it's not crucial.

Modeler galore & co-authors literally everything

 

 

Link to comment
Share on other sites

I briefly checked with the Xonotic crew about this in IRC. Turns out the Darkplaces engine does in fact generate parallax information from the normal map alone! Also I've never seen parallax affecting performance on my hardware, except for the relief mapping option but even that was on my old video card... therefore this approach might be a problem on older hardware only.

 

Also it's fair to mention that some normal map textures in Xon do contain a grayscale bump map on the alpha channel too. So other engines might indeed be using this approach, and some textures are prepared for this use case. For that reason, I'd support TDM taking this approach itself for the implementation.

 

Lastly, I can confirm the jelly effect: Parallax does often make things look stretched and molten! However this can be prevented if the texture is high-res enough, the effect isn't overdone, and the implementation is good. So I'd say it's something to be on the lookout for, but definitely not a reason to ignore this important improvement.

  • Like 1
Link to comment
Share on other sites

I'd support TDM taking this approach itself for the implementation

Do you have any sources, links etc...? Would be interesting to see the exact algorithm used.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Do you have any sources, links etc...? Would be interesting to see the exact algorithm used.

 

Not really... like I said the engines I know of use the normal map for everything. I'm sure there are countless FOSS engines that can offer us an example though. Like I said, fhDOOM mentions parallax mapping on its page, so definitely a great place to look and see how they did it!

Link to comment
Share on other sites

MirceaKitsune please don't take this wrong but can you be more specific, what kind of Parallax Mapping are you referring to?

From your comments and reference to fhDoom I think you are speaking of POM (Parallax Occlusion Mapping) but removing the Occlusion part from the name, so confusing me, it may seam like is just a different name for the same thing but is not, they are different things, not only on visuals but also on performance, where PM (like i said a older tech) runs as fast as normal mapping today, POM (a modern evolution of PM) is much slower, from my experience slower than real tessellation! (GPU's are faster at rendering triangles than pixels), second where PM viewed at grassing angles looks really bad imo, looks like molten glass, POM looks fine (if using a good bump map) viewed from any angle, the only diference in visuals of POM from Dx11 Tessellation, is that it doesn't change the silhouette of objects wheres real Tessellation does.

Example of PM from Fear

http://www.ixbt.com/video2/images/tech_fear/fear_pm_03.jpg

bad PM viewed from extreme grassing angle

http://www.gatheryourparty.com/wp-content/uploads/2013/02/2013-01-05_00014.jpg

POM viewed from grassing angle

https://i.ytimg.com/vi/bfS4J65fXJY/maxresdefault.jpg

Very nice imo example of POM

https://forums.unrealengine.com/attachment.php?attachmentid=14135&d=1413290592


About POM against Tesselation (Displacement mapping)

http://www.d3dcoder.net/Images/Samples/ParallaxDemo.jpg

 

 

PS. Sorry if i look like i'm "showing off" my knowledge or something but graphics tech was always a subject that fascinated me.

Edited by HMart
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...