Oktokolo Posted September 23, 2018 Report Posted September 23, 2018 So GLSL allows mappers to include water that looks like https://www.shadertoy.com/view/Ms2SD1 into their maps? 1 Quote
HMart Posted September 23, 2018 Report Posted September 23, 2018 (edited) So GLSL allows mappers to include water that looks like https://www.shadertoy.com/view/Ms2SD1 into their maps? Yes if TDM GLSL version supports those features but i'm sure is not a matter of copy pasting the shader code from shader toy, it needs to be reworked to support TDM engine particularities like lighting, geometry, etc. About shaders one that i would love TDM to have some day is volumetric lighting. https://www.shadertoy.com/view/4dsGRn Edited September 23, 2018 by HMart 3 Quote
duzenko Posted September 24, 2018 Author Report Posted September 24, 2018 So GLSL allows mappers to include water that looks like https://www.shadertoy.com/view/Ms2SD1 into their maps?If it's using static vertex data then I think yes. In fact, I would like to work on that demo for TDM as a proof of concept and an engine capability check. About shaders one that i would love TDM to have some day is volumetric lighting. https://www.shadertoy.com/view/4dsGRn Can you insert a translucent cone in the skybox area? It might look like that. 2 Quote
Spooks Posted September 24, 2018 Report Posted September 24, 2018 You can put a cone model/brush with translucent textures but it won't look that good. Of note is that the shadertoy link presents volumetric lighting but the screenshot is god rays, which are a post-processing effect (still a shader, but different; they're always based on your view). I (and I know Judith, too) am waiting for the day to come where TDM might have the emissive materials from UE3 so that we may throw the current, ugly particle hacks for faking volumetric lighting away. 1 Quote My FMs: The King of Diamonds (2016) | Visit my Mapbook thread sometimes! | Read my tutorial on Image-Based Lighting Workflows for TDM!
peter_spy Posted September 24, 2018 Report Posted September 24, 2018 (edited) I (and I know Judith, too) am waiting for the day to come where TDM might have the emissive materials from UE3 so that we may throw the current, ugly particle hacks for faking volumetric lighting away. Definitely, although I'm not sure why TDM can't have it already. AFAIK, this is just a posprocess effect. Edit: the main problem with TDM Bloom is that it can't go beyond the bounds of a model, at least not with current postprocess settings. Other engines allow that easily. Maybe it's because other engines have dedicated emissive slot, while TDM just uses blend add mode? No idea. Edited September 24, 2018 by Judith Quote Artstation stuff
duzenko Posted September 24, 2018 Author Report Posted September 24, 2018 I would suggest creating a separate forum thread with a feature request for emissive materials/volumetric lights. 1 Quote
peter_spy Posted September 24, 2018 Report Posted September 24, 2018 Awesome, will do that after work. Quote Artstation stuff
VanishedOne Posted September 24, 2018 Report Posted September 24, 2018 You can put a cone model/brush with translucent textures but it won't look that good.Although it needn't look that bad either: see http://forums.thedarkmod.com/topic/9082-newbie-darkradiant-questions/page-245?do=findComment&comment=375979 for a basic example (easy to set up with func_beam entities). It won't react to the player's view angle or the visibility of the 'light source', though, which I think is the kind of thing Epifire was asking about in http://forums.thedarkmod.com/topic/17301-directional-based-visibility/ -- so it could certainly be improved upon, and I'll be interested in the volumetric lighting thread. Quote Some things I'm repeatedly thinking about... - louder scream when you're dying
VanishedOne Posted August 19, 2019 Report Posted August 19, 2019 How did this (the material stage GLSL support) turn out? I see it made it into 2.07 but I don't remember any fanfare for the new feature. (Hence also no documentation I know of, though glsl.h seems to provide clues about available uniforms.) Is it considered available for mapper use, or is it unstable? Quote Some things I'm repeatedly thinking about... - louder scream when you're dying
HMart Posted August 19, 2019 Report Posted August 19, 2019 (edited) 1 hour ago, VanishedOne said: How did this (the material stage GLSL support) turn out? I see it made it into 2.07 but I don't remember any fanfare for the new feature. (Hence also no documentation I know of, though glsl.h seems to provide clues about available uniforms.) Is it considered available for mapper use, or is it unstable? The problem is not supporting GLSL shaders, afaik TDM already does, the problem is making the glsl shaders themselves. Someone from the team (coders mostly) needs to take some GLSL shaders from shader toy and make them work in TDM engine or make ones from scratch but afaik that requires good trigonometry/math skills. I converted some post-process GLSL shaders to work in the FHDoom engine but it was, hit and miss because I don't know much about writing shaders from scratch. Here is a post-process noise shader that I converted and know it works, in the FHDoom engine, don't know how shaders are written for TDM... vertex shader #include "global.inc" layout(location = 0) in vec3 vertex_position; layout(location = 1) in vec2 vertex_texcoord; out vs_output { vec2 texcoord; } result; void main() { gl_Position = rpProjectionMatrix * rpModelViewMatrix * vec4(vertex_position, 1.0); result.texcoord = vertex_texcoord; } fragment shader (pixel shader) #include "global.inc" layout(binding = 0) uniform sampler2D InputTexture; // vec4 shaderParm0 timer; // vec4 shaderParm1 amount; in vs_output { vec2 texcoord; } frag; out vec4 FragColor; void main() { vec2 texSize = textureSize(InputTexture, 0); vec2 uv = frag.texcoord; uv *= 1.0 - uv.yx; vec4 src = texture(InputTexture, frag.texcoord); vec4 c = vec4(src.rgb, 1.0); float mDot = dot( frag.texcoord.xy , vec2(12.9898,78.233) + shaderParm0.x ); float mFract = fract(sin(mDot) * 43758.5453); c += (mFract - 0.5)*shaderParm1.x; FragColor = vec4(c); } shader material textures/glsltest/debugNoiseShader { noshadows translucent sort postProcess { blend add vertexShader noise.vp fragmentShader noise.fp shaderParm 0 time * 0.05 // timer shaderParm 1 0.1 // amount shaderMap 0 _currentRender } } c++ code called in the playerView.cpp file inside the SingleView() function... if ( !pm_thirdPerson.GetBool() && !g_skipViewEffects.GetBool() ) { ... const idMaterial *mtr = declManager->FindMaterial("textures/glsltest/debugNoiseShader", false); if (pp_noise.GetBool()) { renderSystem->SetColor4(1.0f, 1.0f, 1.0f, 1.0f); renderSystem->DrawStretchPic(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT, 0, 0, 1, 1, mtr); } player->DrawHUD( hud ); ... Right now I have a problem rendering more than one post-process effect at the same time, this indicates to me that this is not the best way to render them but my knowledge on this is limited. Any idea would be welcomed. Edited August 19, 2019 by HMart Quote
duzenko Posted August 20, 2019 Author Report Posted August 20, 2019 12 hours ago, VanishedOne said: How did this (the material stage GLSL support) turn out? I see it made it into 2.07 but I don't remember any fanfare for the new feature. (Hence also no documentation I know of, though glsl.h seems to provide clues about available uniforms.) Is it considered available for mapper use, or is it unstable? Mappers are welcome to try it 1 Quote
stgatilov Posted September 30, 2019 Report Posted September 30, 2019 On 8/20/2019 at 12:12 AM, VanishedOne said: How did this (the material stage GLSL support) turn out? I see it made it into 2.07 but I don't remember any fanfare for the new feature. (Hence also no documentation I know of, though glsl.h seems to provide clues about available uniforms.) Is it considered available for mapper use, or is it unstable? The thing I am really worried about is supporting custom GLSL shaders. We have discussed it a bit without any conclusion. Imagine some mapper creates a custom GLSL shader for his material and it works. Then developers have to change something, e.g. move to newer GL version. Suddenly these custom shaders stop working because something also changes on GLSL side and the syntax must be changed. It is not clear how this could be resolved, aside from developers converting all such custom shaders and repacking missions. In case of ARB shaders, it turned out that there is only one custom shader in all the FMs ever created, and it is used only on one TV box. No player would notice it if it stops working. But GLSL is much easier to use than ARB, so it is much more likely that mappers would use it. This is probably the only reason for weak public exposure. 1 Quote
duzenko Posted September 30, 2019 Author Report Posted September 30, 2019 For now, there is zero interest from mappers for custom shaders. Quote
VanishedOne Posted October 9, 2019 Report Posted October 9, 2019 I see you found metaball.vfp. Apparently neither of these ARB shaders has ever been used in a released FM, then: (Though some FMs do pack versions of shaders in the HeatHaze family that presumably weren't yet in core when they were released.) 1 Quote Some things I'm repeatedly thinking about... - louder scream when you're dying
jonri Posted March 5, 2020 Report Posted March 5, 2020 I decided to play around with using a custom GLSL shader just for fun. I put together a splatmap shader that uses a simulated texture height for better blending, it worked surprisingly well: Unfortunately, there is one problem. I can only get it to show up using an additional blend stage in my material: textures/splatmap { qer_editorimage textures/splatmap { blend blend program splat fragmentMap 0 textures/splatmap fragmentMap 1 textures/darkmod/nature/grass/short_dry_grass fragmentMap 2 textures/darkmod/nature/dirt/dry_earth_stones fragmentMap 3 textures/darkmod/nature/dirt/sand_purplish } } I want to use this as the diffuse map so it can get lit properly, but when I change to "blend diffusemap" the material goes black. I know the custom GLSL feature was basically experimental, but should this scenario work? 1 Quote
duzenko Posted March 5, 2020 Author Report Posted March 5, 2020 28 minutes ago, HeresJonny said: I decided to play around with using a custom GLSL shader just for fun. I put together a splatmap shader that uses a simulated texture height for better blending, it worked surprisingly well: Unfortunately, there is one problem. I can only get it to show up using an additional blend stage in my material: textures/splatmap { qer_editorimage textures/splatmap { blend blend program splat fragmentMap 0 textures/splatmap fragmentMap 1 textures/darkmod/nature/grass/short_dry_grass fragmentMap 2 textures/darkmod/nature/dirt/dry_earth_stones fragmentMap 3 textures/darkmod/nature/dirt/sand_purplish } } I want to use this as the diffuse map so it can get lit properly, but when I change to "blend diffusemap" the material goes black. I know the custom GLSL feature was basically experimental, but should this scenario work? Can you upload a test map? Also, I can only see one stage in your material Quote
VanishedOne Posted March 5, 2020 Report Posted March 5, 2020 (edited) Could it be related to this? On 2/17/2017 at 4:48 AM, rich_is_bored said: My concern is the custom shaders we call from our materials are executed after interaction.vfp. I noticed while playing with duzenko's experimental skybox material that it has 'translucent' set even though there's nothing behind a skybox to be shown through it; when I removed that I encountered problems that looked like z-fighting, even in blend modes that have no obvious relation to depth. My hunch at the time was that 'translucent' was making the material draw after opaque surfaces; but nobody seems to know exactly what translucency does. Edited March 5, 2020 by VanishedOne Quote Some things I'm repeatedly thinking about... - louder scream when you're dying
jonri Posted March 5, 2020 Report Posted March 5, 2020 1 hour ago, duzenko said: Can you upload a test map? Also, I can only see one stage in your material Here's the test map I've been using. I meant to say it works using a later blend stage, not an additional blend stage. In splat.mtr, you can swap out the commented blend line to see what is happening. https://drive.google.com/file/d/1iHUUXFzGO9oAy5oRpjPKwlGs1YVLGuFG/view?usp=sharing I tried adding the "translucent" keyword, and this makes the material disappear entirely. Quote
duzenko Posted March 5, 2020 Author Report Posted March 5, 2020 18 minutes ago, HeresJonny said: Here's the test map I've been using. I meant to say it works using a later blend stage, not an additional blend stage. In splat.mtr, you can swap out the commented blend line to see what is happening. https://drive.google.com/file/d/1iHUUXFzGO9oAy5oRpjPKwlGs1YVLGuFG/view?usp=sharing I tried adding the "translucent" keyword, and this makes the material disappear entirely. Are you using the build attached to one of this thread messages? It could be too old to use. Nothing even draws for me because uniform names have changed since then. Try again with this one https://drive.google.com/file/d/0B9OoHSmkeSeNZWdyZFliQkNsVTA/view?usp=sharing Quote
jonri Posted March 5, 2020 Report Posted March 5, 2020 On 8/19/2019 at 1:12 PM, VanishedOne said: How did this (the material stage GLSL support) turn out? I see it made it into 2.07 but I don't remember any fanfare for the new feature. (Hence also no documentation I know of, though glsl.h seems to provide clues about available uniforms.) Is it considered available for mapper use, or is it unstable? It sounded like this made it into the 2.07 release, which I am using. I tried your latest build and indeed nothing shows up at all. I'll grab the svn version so I can look into the new uniform names... Quote
duzenko Posted March 5, 2020 Author Report Posted March 5, 2020 Look at the unform names in the standard shaders inside the glprogs folder for referense Post here for more info Quote
jonri Posted March 5, 2020 Report Posted March 5, 2020 I updated the shader to match the others and also stripped this down to the bare minimum, still getting the same result using your build. Using the following shaders/material, "blend blend" will display a solid color, but switching to "blend diffusemap" yields black instead. splat.vs: #version 140 #pragma tdm_include "tdm_transform.glsl" INATTR_POSITION in vec4 attr_TexCoord; void main() { gl_Position = tdm_transform(attr_Position); } splat.fs: #version 140 void main() { gl_FragColor = vec4(0.8, 0.4, 0.2, 1.0); } splat.mtr: textures/splatmap { qer_editorimage textures/splatmap { //blend blend blend diffusemap program splat } } Quote
duzenko Posted March 5, 2020 Author Report Posted March 5, 2020 56 minutes ago, HeresJonny said: I updated the shader to match the others and also stripped this down to the bare minimum, still getting the same result using your build. Using the following shaders/material, "blend blend" will display a solid color, but switching to "blend diffusemap" yields black instead. splat.vs: #version 140 #pragma tdm_include "tdm_transform.glsl" INATTR_POSITION in vec4 attr_TexCoord; void main() { gl_Position = tdm_transform(attr_Position); } splat.fs: #version 140 void main() { gl_FragColor = vec4(0.8, 0.4, 0.2, 1.0); } splat.mtr: textures/splatmap { qer_editorimage textures/splatmap { //blend blend blend diffusemap program splat } } Try this .mtr textures/splatmap { qer_editorimage textures/splatmap { program splat fragmentMap 0 textures/splatmap fragmentMap 1 textures/darkmod/nature/grass/short_dry_grass fragmentMap 2 textures/darkmod/nature/dirt/dry_earth_stones fragmentMap 3 textures/darkmod/nature/dirt/sand_purplish } } .vs #version 140 #pragma tdm_include "tdm_transform.glsl" INATTR_POSITION in vec2 attr_TexCoord; out vec4 var_TexCoord0; void main() { var_TexCoord0 = vec4(attr_TexCoord, 0, 1); gl_Position = tdm_transform(attr_Position); } .fs #version 140 uniform sampler2D u_texture0; uniform sampler2D u_texture1; uniform sampler2D u_texture2; uniform sampler2D u_texture3; in vec4 var_TexCoord0; in vec4 var_TexCoord1; in vec4 var_TexCoord2; in vec4 var_TexCoord3; out vec4 FragColor; void main() { vec4 w = texture(u_texture0, var_TexCoord0.st); vec4 tex1 = texture(u_texture1, var_TexCoord0.st); vec4 tex2 = texture(u_texture2, var_TexCoord0.st); vec4 tex3 = texture(u_texture3, var_TexCoord0.st); FragColor = w[0]*tex1+w[1]*tex2+w[2]*tex3; } How it looks to me At this point I have to say that I am confused by your `blend` confusion What are you trying to achieve with this? Note that my version does not use it at all (leaves it default) Quote
duzenko Posted March 5, 2020 Author Report Posted March 5, 2020 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 textures/splatmap { qer_editorimage textures/splatmap diffusemap _white { blend modulate program splat fragmentMap 0 textures/splatmap fragmentMap 1 textures/darkmod/nature/grass/short_dry_grass fragmentMap 2 textures/darkmod/nature/dirt/dry_earth_stones fragmentMap 3 textures/darkmod/nature/dirt/sand_purplish } } Quote
VanishedOne Posted March 5, 2020 Report Posted March 5, 2020 That's pretty much how Obsttorte had 'fragment blending' work: https://forums.thedarkmod.com/index.php?/topic/17308-epis-many-questions-thread/&do=findComment&comment=375331 At one point SteveL even suggested a tweaked interaction shader to allow three-way RGB vertex colour blending: https://forums.thedarkmod.com/index.php?/topic/17308-epis-many-questions-thread/&do=findComment&comment=375331 Light interaction is usually where these things run into complications: the old 'soft alpha transparency without light interaction or hard alphatested edges with it' limitation is another one. And since real-time lighting plays such a central part in TDM... Quote Some things I'm repeatedly thinking about... - louder scream when you're dying
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.