Jump to content
The Dark Mod Forums

Recommended Posts

Posted

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).

  • Thanks 1

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...)

Posted

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.

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Posted
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:

splat2.thumb.jpg.9240bc751223810f7c7b19e50a07096c.jpg

 

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.

 

 

Posted (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 by VanishedOne

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Posted
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.

Posted
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.

Posted

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...

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

  • 1 month later...
Posted

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:

  1. Do not allow mappers to write custom GLSL.
  2. Allow writing custom GLSL and promise their maintenance. And as a consequence, most likely lock GLSL version forever?...
  3. Allow writing custom GLSL but warn that they can get broken during future engine updates.

 

  • Like 1
Posted
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.

  • Like 1
Posted
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.

Posted
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

  • Like 3

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.


×
×
  • Create New...