nbohr1more Posted March 5, 2020 Report Posted March 5, 2020 Back when we were first discussing this topic, I proposed the concept of abstracting shaders that were intended to be light reactive. The idea would be to break our light interaction into multiple parts and leave a stub where a custom shader can process any light reactive stages. The engine split process of these special light integrated shaders the same way it splits light processing for the "spectrum" keyword. Sikkpin had a Doom 3 repo where he was working on a similar design (which, in turn, was inspired by how the Prey engine works). 1 Quote 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...)
VanishedOne Posted March 6, 2020 Report Posted March 6, 2020 I'm glad to hear it's been thought about. I linked above to your 2017 exchange with rich_is_bored, where there seemed to be doubt about vertex shaders' capabilities in light-interactive geometry. For a use case like blending textures, we don't even need to move vertices around, just to calculate a pixel colour from the textures before feeding it to the lighting system. And currently what we have is the vertexColor/inverseVertexColor set-up, which requires a material stage for each texture to be blended, so I'd have imagined blending within a shader might be faster. Quote Some things I'm repeatedly thinking about... - louder scream when you're dying
jonri Posted March 6, 2020 Report Posted March 6, 2020 4 hours ago, duzenko said: I hope you don't want your material to interact with lights. It's possible with blend modulate but I advise against using it due to massive performance cost of multi-pass rendering That's exactly the result I was looking for, blend modulate did it: Too bad it can't be done without killing performance, it would be interesting if a custom shader could be plugged in at an earlier stage. I assume the vertex color blending support doesn't have the same performance issue, because its functionality is in a pre-defined shader that's called in the correct place? Looks like there's a fair amount of interesting stuff buried in some of the old threads here, thanks for pointing those out. I guess I just answered this question from 2015 Anyways, it's not that important to me, I was just playing around to see what was possible. I'd be happy to help out where I can, though, if any work happens in this sort of direction. Quote
VanishedOne Posted March 6, 2020 Report Posted March 6, 2020 (edited) If I understand it correctly, vertexColor/inverseVertexColor literally works by multiplying the texture colour by the vertex colour or its inverse. So e.g. where the vertex colour is mid-grey, both your diffusemaps will be multiplied by 0.5, and the multipliers always sum to 1, so the overall brightness level looks correct. For a material that blends different diffuse, normal and specular maps there can be six stages instead of three. In Doom 3 there are materials that blend two textures evenly (the point of the vertex colour feature is to do it unevenly) and even fade from one to the other over time, by fading the RGB multiplier for one of them from 0 to 1 and for the other from 1 to 0: I pasted an example into https://bugs.thedarkmod.com/view.php?id=5044 Edited March 6, 2020 by VanishedOne Quote Some things I'm repeatedly thinking about... - louder scream when you're dying
duzenko Posted March 6, 2020 Author Report Posted March 6, 2020 3 hours ago, HeresJonny said: Too bad it can't be done without killing performance, it would be interesting if a custom shader could be plugged in at an earlier stage. Single-pass multi-map render is possible and can be added to TDM. It's just that nobody has bothered with it yet. (Even though everyone is clenching teeth about how slow and old-looking the game is). Quote I assume the vertex color blending support doesn't have the same performance issue, because its functionality is in a pre-defined shader that's called in the correct place? If you ask me, vertex color is a hairbrained hack that only made sense on DX7 hardware. It has per-vertex precision, i.e. you need to triangulate your surface into many small poly's while custom shader allows a better result with just a single quad. As for performance, your three-map blending will need three passes with vertex color, while custom shader does it with two. Goes without saying, that you need to pre-bake your blending into vertices somehow, compared to blend texture here. You decide what's easier. Quote
duzenko Posted March 6, 2020 Author Report Posted March 6, 2020 7 hours ago, nbohr1more said: Back when we were first discussing this topic, I proposed the concept of abstracting shaders that were intended to be light reactive. The idea would be to break our light interaction into multiple parts and leave a stub where a custom shader can process any light reactive stages. The engine split process of these special light integrated shaders the same way it splits light processing for the "spectrum" keyword. Sikkpin had a Doom 3 repo where he was working on a similar design (which, in turn, was inspired by how the Prey engine works). What about passing additional inputs to that universal shader? All inputs need an explicit reference in GLSL, and a corresponding C++ linking code. Not as easy as it sounds... How I would approach it is, add a standard shader for this, or simply add an option for multiple diffuse maps to our interaction shader. Another option would be allowing lights to have a custom interaction shader in their material. Quote
VanishedOne Posted March 6, 2020 Report Posted March 6, 2020 Regarding comparisons between HeresJonny's shader demo and the vertexColor set-up, the latter lets you blend pairs of diffuse and specular textures using a pair of normal maps as appropriate, so replicating that in a shader would take more than just an option for multiple diffuse maps. If they hadn't gone the vertexColor route, I imagine this is the sort of thing id might have introduced an image program for (c.f. addnormals() and so on). The thing is, though, blending two sets of textures via a monochrome mask is one thing we might want to do: it gets us to where we can blend the same number of textures we can now but with greater precision. Then we might want to blend three texture sets using an RGB mask (one of my links above involved RGB vertex blending). Or blend based on the height and slope of terrain. Or... Quote Some things I'm repeatedly thinking about... - louder scream when you're dying
stgatilov Posted April 10, 2020 Report Posted April 10, 2020 Given that there is a discussion about interior mapping, I'd like to return to the question of maintenance of custom GLSL shaders. Right now I see choices: Do not allow mappers to write custom GLSL. Allow writing custom GLSL and promise their maintenance. And as a consequence, most likely lock GLSL version forever?... Allow writing custom GLSL but warn that they can get broken during future engine updates. 1 Quote
duzenko Posted April 10, 2020 Author Report Posted April 10, 2020 2 hours ago, stgatilov said: Allow writing custom GLSL but warn that they can get broken during future engine updates. I would go that way 2 Quote
New Horizon Posted April 10, 2020 Report Posted April 10, 2020 8 hours ago, stgatilov said: Allow writing custom GLSL but warn that they can get broken during future engine updates. I would say this route 1 Quote
jonri Posted April 10, 2020 Report Posted April 10, 2020 9 hours ago, stgatilov said: Allow writing custom GLSL but warn that they can get broken during future engine updates I'm fine with this, with a couple conditions: We make a reasonable attempt not to break things in an update without a good reason Breaking changes get documented in the beta release notes so fixes can get applied before the final release If this is going to be officially "blessed" we'll want a wiki page detailing how to use it. I can probably help out with that if needed. 1 Quote
nbohr1more Posted April 10, 2020 Report Posted April 10, 2020 To be honest, something as good as the interior map shader should be part of the core project and get updated anyway... Quote 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...)
stgatilov Posted April 10, 2020 Report Posted April 10, 2020 1 hour ago, HeresJonny said: We make a reasonable attempt not to break things in an update without a good reason Breaking changes get documented in the beta release notes so fixes can get applied before the final release Unfortunately, it is usually some minor changes which should not break anything but still break. We have just finished migration from ARB, and thank god there were no custom shaders (well there was one, but its absence would go unnoticed even if we did not convert it). 26 minutes ago, nbohr1more said: To be honest, something as good as the interior map shader should be part of the core project and get updated anyway... Yes, this is what I think too. Now it seems to be in prototype phase, but if it shows no issues and is popular, then it's better to integrate it directly into the engine. After a good enough design proposal, of course. Quote
duzenko Posted April 10, 2020 Author Report Posted April 10, 2020 23 minutes ago, stgatilov said: Unfortunately, it is usually some minor changes which should not break anything but still break. We have just finished migration from ARB, and thank god there were no custom shaders (well there was one, but its absence would go unnoticed even if we did not convert it). Yes, this is what I think too. Now it seems to be in prototype phase, but if it shows no issues and is popular, then it's better to integrate it directly into the engine. After a good enough design proposal, of course. Surely merely allowing custom shaders enables mappers to experiment with it and come up with ideas that can be incorporated in core later 3 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.