GLSL custom shaders - a mapper wanted.

[duzenko]

I want 2.07 to support custom GLSL shaders, even if experimental.

For now it will be of limited use due to interaction shaders being locked to standard only (for reasons of compatibility with existing missions).

One particular place where we could apply a custom shader could be the skybox.

We have standard sky materials with multiple stages, that cause massive fillrate overdraw. If we could reduce those to a single material, the performance be could significantly improved.

Another possible application is complex water surface, but that's more complicated to achieve.

 

I am looking for a mapper who will be working on a test/demo map with a skybox material that combines multiple translucent textures. The old-fashioned way would be to split each texture in a separate material stage while this time they will be all fed to a customer shader in one material stage.

 

Ideas on going beyond the simple blending are welcome.

 

Any volunteers?

[Spooks]

Sure, I'll volunteer. I've been slacking on participation in the community so this should be nice. I have intermediate - but not expert - knowledge of skyboxes and very little knowledge of shaders, but I know enough to be able to type in a texture map into a tex shader input field in the .mtr, lol.

 

Shoot me a PM if you want, I'll be available this Fri and Sat and free on Sun and Mon.

[RPGista]

Nice. I wonder if this feature could help with our fog + skyboxes issues? Will be good to see what you guys come up with.

[duzenko]

Sure, I'll volunteer. I've been slacking on participation in the community so this should be nice. I have intermediate - but not expert - knowledge of skyboxes and very little knowledge of shaders, but I know enough to be able to type in a texture map into a tex shader input field in the .mtr, lol.

 

Shoot me a PM if you want, I'll be available this Fri and Sat and free on Sun and Mon.

Would you upload or attach a simple .map and an .mtr where the material is defined.

Then I add a shader and link it to the material.

[Spooks]

Alright, here are the map and material file. I'm working off the root, so just place them in <root>/maps/skybox_demo and <root>/materials respectively, no need for an FM folder for two loose files. I've put in the tdm_foggy skybox prefab, a fairly standard skybox, then replaced the sky dome inside it with one textured with the "textures/darkmod/nature/skybox/glsl_shader_demo" custom material. The contents of said material are a copy of the twinkle_stars material, you can empty it and set up the shader program inside as you want.

 

The map has a foglight and a transparent alpha-test decal, so you can visually see if there are any problems with those.

 

skybox_demo.map.txt

skybox_demo.mtr.txt

[duzenko]

I'm starting with this and will try a simple shader next

textures/darkmod/nature/skybox/glsl_shader_demo
{
	translucent
	diffusemap textures/darkmod/nature/skybox/starry1_stars
	{
		blend add
		program	skybox_glsl

		fragmentMap		0		textures/darkmod/nature/skybox/starry1_clouds
		fragmentMap		1		textures/darkmod/nature/skybox/starry1_stars
		fragmentMap		2		textures/darkmod/nature/skybox/thunderclouds
	}
}

[duzenko]

WIP. Svn rev 7702.

textures/darkmod/nature/skybox/glsl_shader_demo
{
	translucent
	diffusemap textures/darkmod/nature/skybox/starry1_stars
	{
		blend add
		program	skybox

		fragmentMap		0		textures/darkmod/nature/skybox/starry1_clouds
		fragmentMap		1		textures/darkmod/nature/skybox/starry1_stars
		fragmentMap		2		textures/darkmod/nature/skybox/thunderclouds
	}
}

[Spooks]

 

WIP. Svn rev 7702.

 

As a heads-up, if you want feedback on a particular build of the shader, you're going to have to be attaching the glprog here too, as I don't have access to SVN. e: and I should know if there are any SVN-specific dependencies that would make it look wrong on stock 2.06, I assume not.

Edited September 21, 2018 by Spooks

[nbohr1more]

You'll need to supply binaries Duzenko

 

I'll post some at Moddb tonight.

[duzenko]

Duly noted. Not that I upload binaries to svn, ever.

There's nothing to test yet, just beeping progress to outer space hehe.

[nbohr1more]

Here is a package.

 

https://drive.google.com/open?id=1-_d3KRXrmhJtKoVoXzf4JEk9vQbC5hzg

 

I am reluctant to upload this to Moddb until the rendering scissor bug that is cutting off the tops

of helmets is fixed.

 

 

It doesn't happen all the time but it's pretty glaring when it happens.

[duzenko]

Here is a package.

 

https://drive.google.com/open?id=1-_d3KRXrmhJtKoVoXzf4JEk9vQbC5hzg

 

I am reluctant to upload this to Moddb until the rendering scissor bug that is cutting off the tops

of helmets is fixed.

 

Cull_head_bug.jpg

 

It doesn't happen all the time but it's pretty glaring when it happens.

That's on my short list too.

[duzenko]

Please test and advise

https://drive.google.com/file/d/1ezaziu8U6k05aWfMA610wXrWo4jlpbzy/view?usp=sharing

 

Please note the spectrum keyword. It totally disables interactions with whatever lights are in the skybox, as they aren't welcome here.

[Spooks]

Spectrum doesn't seem to do much, commenting it out still doesn't make light interact, that might be due to blend add but I don't remember if that's how it worked. Getting ahead of myself, I was unable to make it show up with the .exes from the binaries provided above, but the notools.exe did it, so yes, okay.

 

Initial tests: some materials cannot be loaded in the shader, I checked the example materials and a cobweb mat that worked, they all had the translucent keyword, is this the determinant? Transparent decal materials with alpha test did not work, neither did regular brick textures. But then, a glass crack decal with 'translucent' did not work, yet graffiti/cockwit worked.

 

Any uses for the flags in the vertexParm line? The first value seems to do something but it's very hard to tell what.

 

The images seem pre-programmed to scroll, and I see each stage has its own scroll direction and speed, one of which being static. It might be useful to give some kind of control to that via the vertex parameters. What about the opacity?

 

Could there be more than 3 fragment maps? Is that a hard limit?

 

---

 

I initially thought straight up image maps would get plugged into the shader, but materials is way better for multiple reasons. Why no light interaction, though? If materials are being blended, there might be interesting effects that may be achieved with normal maps, like clouds reacting to moonlight inside the skybox. Would it be hard to do inside the shader?

 

Related to that, you said multi-stage materials caused a lot of overdraw, but this shader still displays mats instead of image maps. Does the simple fact that all of the materials are rendered through a shader (inside a single material) nullify that? I don't particularly need to know why, but rather if it is truly more efficient.

[duzenko]

Spectrum doesn't seem to do much, commenting it out still doesn't make light interact, that might be due to blend add but I don't remember if that's how it worked. Getting ahead of myself, I was unable to make it show up with the .exes from the binaries provided above, but the notools.exe did it, so yes, okay.

 

Initial tests: some materials cannot be loaded in the shader, I checked the example materials and a cobweb mat that worked, they all had the translucent keyword, is this the determinant? Transparent decal materials with alpha test did not work, neither did regular brick textures. But then, a glass crack decal with 'translucent' did not work, yet graffiti/cockwit worked.

 

Any uses for the flags in the vertexParm line? The first value seems to do something but it's very hard to tell what.

 

The images seem pre-programmed to scroll, and I see each stage has its own scroll direction and speed, one of which being static. It might be useful to give some kind of control to that via the vertex parameters. What about the opacity?

 

Could there be more than 3 fragment maps? Is that a hard limit?

 

---

 

I initially thought straight up image maps would get plugged into the shader, but materials is way better for multiple reasons. Why no light interaction, though? If materials are being blended, there might be interesting effects that may be achieved with normal maps, like clouds reacting to moonlight inside the skybox. Would it be hard to do inside the shader?

 

Related to that, you said multi-stage materials caused a lot of overdraw, but this shader still displays mats instead of image maps. Does the simple fact that all of the materials are rendered through a shader (inside a single material) nullify that? I don't particularly need to know why, but rather if it is truly more efficient.

Sorry, I didn't understand some parts of your post.

 

The material load errors in the console aren't related or caused by custom GLSL, no?

 

The vertex parm there passes current time to shader that it uses for scrolling. You can pass anything else, as long as it's supported by the material parser.

 

Texture limit is 8.

 

You can use the material with interactions if you want. But any light interaction goes out of scope of this thread.

You can pass any texture to the shader, including normal maps. What the shader does with it, simulating interactions or whatever, is the mapper's choice. You can control opacity and everything else a shader can do.

 

You would have to elaborate on the last paragraph, I totally don't get it.

[HMart]

I think he is asking if using a shader that calls many materials is really faster than using a normal material with multiple stages.

[Spooks]

The material load errors are when I try to replace the example materials in the fragmentMap fields with other ones from the mod. Some refuse to load, you can see it visually as well as in the console. I'm saying the shader doesn't display certain materials when they're used in it.

 

You say controlling opacity, simulating interactions, etc. is the mapper's choice? How is it the mapper's choice, are they to edit the shader themselves?

 

Yes, pretty much what HMart said.

[duzenko]

Umm

Do you guys confuse materials with textures?

The fragmentMap keyword takes a name of a texture (i.e. a .tga, .jpg, .dds, etc). Not a material name.

		fragmentMap		0		textures/darkmod/nature/skybox/starry1_clouds

The starry1_clouds here is an actual .tga.

So the shader can't be "calling many materials".

 

 

You say controlling opacity, simulating interactions, etc. is the mapper's choice? How is it the mapper's choice, are they to edit the shader themselves?

Exactly. What some mappers did with ARB shaders before.

[Spooks]

Yeah, I'm sorry. I checked and it loads image maps. It's just that the material and diffuse map names are often the same names, and for some reason I misremembered image maps being declared with their file extensions in the material files, which is why I made the assumption. Shows how long I've been away from editing. The console log messages even say "couldn't load image" but I didn't pay attention.

 

Apart from the blunder, the potential flexibility still bothers me. How much could an end-user (a mapper as opposed to a coder) affect the properties of the shader through editing the properties in the material file?

[duzenko]

Apart from the blunder, the potential flexibility still bothers me. How much could an end-user (a mapper as opposed to a coder) affect the properties of the shader through editing the properties in the material file?

You can feed the input data through vertexParms.

All actual operation is done inside the shader and you (mapper) have full control on what happens there.

[HMart]

Umm

 

Do you guys confuse materials with textures?

 

The fragmentMap keyword takes a name of a texture (i.e. a .tga, .jpg, .dds, etc). Not a material name.

 

No not normally, but believe it or not, in all honesty I did knew those fragmentMaps calls were texture calls, I've used ARB/GLSL shaders before, i was just telling you what he asked has you didn't understood the question.

 

To be fair to Spooks, making materials that call a shader is not something that a person working with idtech 4 do all the time so anyone could make his mistake.

 

Btw Spooks about shader flexibility, depending on the shader it can have plenty of flexibility, you obviously can't modify the shader code itself through a material call, but by changing the input, you change the outcome of the shader, so with one shader you can have many materials with different looks and behaviors. For example the heatHaze shader, it's used to make glass, water, heat waves for explosions and fire, etc.

[Spooks]

That's the point, raise of hands, any currently active mappers who can fluently code in GLSL. My worry is that nobody will actually edit the shader and will use it stock out of the box. I know the point of this particular one is just to ship something experimental as a proof of concept for 2.07, but I'm warning you that no one will go the extra mile, or ought to for that matter if their time would be better spent on level layout and asset creation.

[HMart]

Spooks I wouldn't worry about that, like i said a single shader can have many different outcomes, depending on the inputs giving, so it doesn't matter if mission makers don't write new ones.

 

But i'm sure someone will, just having the ability to write or use custom shaders is very good, especially now in GLSL because is like coding in C and there's plenty of examples on the internet. This opens the door to many new possibilities just look to this site shader Toy.

[duzenko]

The important thing is to give mappers the choice and the tool. Now when someone needs this they can use it instantly, without waiting a year till the next version.

[Guest]

I don't code in GLSL, but I'd like to have this as an option, I can always find proper documentation and educate myself later.