havenphillip

That's a pretty sick shader but it has like 5 buffers. It's insane. The problem would still be how to do trails. I can draw a point at the player. But how to make it remember every point the player has been and draw that line? Sounds like Josh is saying use a render to texture - which makes me think of the minimap. Seems like maybe in script all I need is to bind a texture? I just need to start doing experiments.

Yep that thing. I can't isolate the principle. I'm racking my brain.

Ok. I'll have to take some time to pull this apart. I can write something that puts a dot on the ground under the player but what part of this leaves the trail? Am I right about needing to create a frame buffer or some such buffer?

I need a shader or shader/script combo that allows me to leave long trails like a painting shader like this: https://www.shadertoy.com/view/WdVyDR I need that buffer and I don't know how to go about that. Hoping someone who knows that stuff better will throw me a bone.

Any idea or anyone have success making something like this in Leadwerks? I'm thinking if I can get my hands on something like this I can create a shader for footprints or tire tracks in snow: https://medium.com/@strattonbrazil/writing-a-texture-painter-part-1-f0d732d287d1

I don't really know. But if so I think you'd run into a problem where if you stood your guy in the shadowed area he wouldn't be shadowed. Only the terrain would be.

What do you mean? Are these hard to use? What's your idea like put them on Github or something?

Thanks, man. Yeah Leadwerks is super fun. Looking forward to seeing that content.

Yeah it looks awesome the only thing I might do different is put weapons and armor together.

Hello, fellow noobs. Hope you're doing well. I have a few extra shaders I had wanted to get out to you earlier but couldn't because they weren't complete or they were a bit off-track. I have some more extras I want to add but here's a few for now. I had wanted to do a multiple lights + alpha shader but it turned out to be a little trickier than I anticipated. I finally got it, though. Haven't tried this out in various situations but I doubt there will be any problem using this for whatever you might intend it for. 48a_multiple lights blinn-phong + alpha.zip A kernels shader from LearnOpenGL. There's a sharpen, blur, and edge detect kernel included in the shader. You just have to comment or uncomment the sections depending on which you want to use. I also included a kernels post effects shader so you can use these as post effects as well. Actually all the post effect shaders I posted can be changed to model shaders. I'm just not sure whether that's something people might want. Maybe I'll do that next so we have them. 01c_kernels.zip This shader shows how you can add lighted areas to your shaders. I used the blur kernel here on a glow map to get a bit of a softglow effect. Nice thing about this is you can design your glow map to anything you want (provided you have a basic understanding of some texture editing program). 01b_softglow.zip You know how sometimes you might find a cool rock in a creek that seems all colorful but then when you take it home and it dries out it's just a boring dry rock? I found a little trick for giving things that damp look. The whole of it is: float dampen = 0.3; outcolor += (-0.5 * dampen); ...that's it. It's a good trick for decreasing the brightness without sacrificing the colors. Increase the specular so it's nice and shiny and you get a pretty convincing noob "wet" look. 01a_dampen.zip Use this shader to get ambient occlusion out of your heightmap. 37a_ao from height.zip I had wanted to add a 3D version of the bepuddled shader but it took awhile to get it to a place I was happy with. When the rain hit here I decided to finish it. There are a lot of variables you can tweak in both the evaluation and fragment stages to get it to your liking. I set them all to what I considered close to universal but tweak them all to your liking. Should be fairly easy to figure out how to use this one. There's a lot to it, though. It's kind of a long shader. I included the ambient occlusion shader from above in here, for instance. It's got six textures in play. I tried to use reference puddles from the internet but couldn't find too many good examples of how the mud color and the fresnel work together. But I think the skybox brightness is biased by the color of the mud in the puddle somewhat. You can increase the "hillness" of the shader but keep in mind it won't affect collisions so probably best to keep them low. Also I wouldn't recommend this on a sloped surface because the puddles don't take the slope of the model into consideration (puddles on the side of a hill? The solution for this would be somewhere in the slope blend shader [25_slope blend] but I had to call it here. Hours already into this). You can see the heightmap is used for a lot of things here, including how the opacity of the puddle mud changes. And of course you can affect the mud brightness and hue. I've found that vec3(1.0, 1.0, 0.95) looks like a good mud color regardless of the brightness. I tried this with a lot of different textures and with a few adjustments each time it looks good. Included a 4x4 plane. Looks like the picture if you scale it to 30x1x30. Notice also the dampen effect from above is used around the edges of the puddle areas: 41a_bupuddled + tessellation.zip

It's not expensive. It's parallax. I haven't had any problem at all.

Since I started doing shaders I've begun to stare a lot at things. I stare at the ground. I stare at walls. I stare at rocks...and when autumn hit I started staring at fog...puddles....mud... This week I've been working on puddles and fog in keeping with that spooky October/November vibe. I worked out a pretty good mud puddle shader which I'll post next but I figured this one is done and I've tweaked the **** out of it so I need to stop at some point and know when it's done. This shader is made up of the fog shader (39_ground fog) and the POM shader (27_parallax occlusion) with a texture scroll element (02_texture scroll and/or 20_creek), which is nice because if you have these you can study each aspect of the shader independently if you so desire. Since this is made from a few previous shaders, and because I feel I missed some points before, and because I'm only posting this one and I've heard a blog works well when it's somewhere between 200-500 words, AND because the shader code feels a little cluttered to me I figured I'd go a little in depth. You may be able to tell I don't entirely know what I'm doing but that seems to be all one needs for noob shading. I put this shader on a Leadwerks box brush and flattened the box to a plane. The blend mode is set to alpha, it's z-sorted and I unchecked "cast shadows" in the material editor. I want to make a couple points so you can see some of the thinking behind this shader and adapt it to suit you, so I guess I'll just break this up in sections: I have some grasp on this first section (in the vertex stage) and I can't remember how I wound up with it but it's just a variation on the TBN matrix in the Leadwerks parallax shader. The one point I want to make about this section is this line: TBN_Matrix[2][2] -= 0.25; //lateral reduction Somehow in my experimenting I figured out if you subtract some number from TBN_Matrix[2][2] you reduce the parallax effect at grazing angles. If you crank this up to "1.0" while looking at the box in the material editor you can see that along the sides there is no parallax at all. And this grazing angle is where the trouble comes from in dealing with curved surfaces. That makes this useful if you want to put POM on rolling hills or a curved wall, etc. //Parallax tangent/binormal/normal matrix mat3 TBN_Matrix; TBN_Matrix[0] = ex_tangent*mat3(cameramatrix); TBN_Matrix[1] = ex_binormal*mat3(cameramatrix); TBN_Matrix[2] = ex_normal*mat3(cameramatrix); TBN_Matrix[2][2] -= 0.25; //lateral reduction vec3 inversecampos = vec3(camerainversematrix * ex_vertexposition); eyevec = vec3(inversecampos) * TBN_Matrix; The camerainversepos (in the vertex stage) is pretty simple but I have no idea why this works. But the z coordinate establishes the foreground depth in the fog (from camera to fog plane) (*shrug*). camerainversepos = camerainversematrix * ex_vertexposition; Fragment stage: This next section is the same as it is in the parallax POM shader. The texture coordinates are set up as a vec3. The "for" loop creates several "slices" of the texture which increases in alpha according to the heightmap (z-coord). The slices are "pushed" along according to the eye vector (established in the TBN_matrix) and this is what gives the impression of the overlapping "3D" effect. The bright areas in the height map are pushed more than the dark areas. If the height is greater than the parallaxed_texcoords then break. The second "for" loop smooths out the spaces between these slices and that allows you to get away with a ridiculously small number of parallax_steps (slices) and this is why the parallax shaders look so good without being detrimental to the FPS. One thing I want to point out here are these "height" lines. I found that if I start with a vec4(1) and subtract the height, which inverts the texture, and then do a 1-the texture inside the smoothstep - reverting it, it flips something in the parallax. When I then increase the smaller parameter of the smoothstep, it greatly reduces the slippage you get with parallax. If you change "anti_slip" to 0 and then run the game you can see what I mean - particularly if you strafe while looking at the fog. It will slip like crazy. So that's why these lines look so ridiculous. But an anti_slip setting of "0.3" appears to be enough to eradicate the slippage. Further, you can see I wrote the texture out twice in each "for" loop. This is because I'm scrolling the texture in two opposing directions. By multiplying them you get only the intersections of the two, giving a rippling effect very similar to how the normals create motion in the creek shader (20_creek). The "0.8" in the second height line only offsets the size of that texture slightly so that the two textures never line up exactly, which - in game - looks like a momentary freezing of motion. I also clamped the parallax_depth to between 0.0 and 0.1. 0.1 seemed to be more than I needed but if you end up in a situation where you need more than that you can delete this line (line 57) without any problem. //Parallax //---------------------------------------------------------------------------- float height; vec2 tex = ex_texcoords0 * fog_tex_size; vec3 parallaxed_texcoords0 = vec3(tex, 1.0); parallaxed_texcoords0.xy += (time * fog_speed); vec3 dir = (-eyevec / eyevec.z)/parallax_steps; parallax_depth = clamp(parallax_depth,0.0,0.1); dir.xy *= parallax_depth; for (int i = 0; i < parallax_steps; i++) { parallaxed_texcoords0 += dir; height = vec4(1).r - smoothstep(anti_slip,1,1-texture(texture0, parallaxed_texcoords0.xy + (time * fog_speed)).r); height *= vec4(1).r - smoothstep(anti_slip,1,1-texture(texture0, 0.8 * parallaxed_texcoords0.xy - (time * fog_speed*0.5)).r); if (parallaxed_texcoords0.z < height) break; } for (int i = 0; i < parallax_steps; i++) { dir *= 0.5; if (parallaxed_texcoords0.z < height) parallaxed_texcoords0 -= dir; else parallaxed_texcoords0 += dir; height = vec4(1).r - smoothstep(anti_slip,1,1-texture(texture0, parallaxed_texcoords0.xy + (time * fog_speed)).r); height *= vec4(1).r - smoothstep(anti_slip,1,1-texture(texture0, 0.8 * parallaxed_texcoords0.xy - (time * fog_speed*0.5)).r); } //----------------------------------------------------------------------------- I uncommented this next section because I wasn't sure I wanted it. But the idea here is to affect the opacity of the fog from a distance so that when you're far away it is faded, and when you're close it's normal. You can comment these lines in and then on line 97 multiply this dist by the fog_opacity (inside the parentheses) and see the effect by walking backwards while looking at the fog. //Distance //float fade_dist = 30.0; //float max_fade = 0.8; //0 - 1 //float dist = 1-clamp(smoothstep(0,1,distance(cameraposition, ex_vertexposition.xyz) / fade_dist),0.0,max_fade); This next section establishes the outcolor. The parallaxed_texcoords0 already has a texture size variable applied to it, and I needed to do that prior to the "for" loops. But this outcolor really just works to add a little extra detail to the look of the fog and so I added an extra texture size modifier so I could change the size of this texture and get a few more "spots" on the surface of the fog. I established the texture with a time element and a reverse timed texture and added them together. I then clamped down the dark areas of the texture so that the fog is mostly light colors (you don't want dark clouds, really. It's fog). Lastly, I put a fog_hue adjustment and a fog_brightness adjustment like I do almost every time (note the spooky green hue). If you go to the fragData0 line and delete the outcolor.xyz you can see what it looks like without this section and it's cool. But I added this because I wanted a little more. It's preferential. //Diffuse float col_tex_size = col_tex_size_modifier; vec2 col_tex = parallaxed_texcoords0.xy * col_tex_size; vec4 outcolor = texture(texture0,col_tex + (time * fog_speed * 0.2)); outcolor += texture(texture0,0.8 * col_tex - (time * fog_speed * 2.0)); outcolor.xyz = clamp(outcolor.xyz,0.7,1.0); outcolor.xyz *= fog_hue * fog_brightness; The fog part of this shader is Josh's code from the soft particle shader so I'm not entirely sure how this section works but the shader first grabs the gl_FragCoord.xy/buffersize. The gist of this is that the shader is grabbing the entire screen size? Sort of the idea of a depth buffer is that the shader gets the distance from the camera to the fog plane (foreground depth) and the distance from the camera to the ground behind the plane (background depth) then gets the difference between the foreground and the background. And the effect shows weak or strong depending on this difference. At the end there I added a fog fade - which allows you to adjust this difference. You can see if you place your fog plane in a kind of bowl shape that the alpha border around it fades a lot. If you change this number to a 2, for instance, this alpha border will become much smaller (you don't want that). Lastly I added fog opacity which is pretty self-explanatory. But here you can multiply that fog opacity by the dist from the distance section above if you want the fog to fade out from far away. //Screen depth vec2 fogcoords = gl_FragCoord.xy / buffersize; if (isbackbuffer) fogcoords.y = 1.0 - fogcoords.y; float fog_backgrounddepth = depthToPosition(texelFetch(texture11,ivec2(fogcoords*buffersize),0).r,camerarange); float fog_foregrounddepth = camerainversepos.z; float diff = min((fog_backgrounddepth-fog_foregrounddepth)*fog_fade,fog_opacity); //fog_opacity * dist); Finally I set the fog color and alpha. Again I establish the texture and set some time and speed to the texture coordinates to scroll them and here I just mix them together by 0.5. I then clamp the minimum like before. And for the alpha channel I clamp the fog difference by the parallaxed fog color.r - making the fog difference (diff) the minimum color so that the fog will not only fade by the difference but also by the height. I then add the difference times the height to strengthen the effect (though this could be considered preferential as well). //Fog vec4 fog_col = texture(texture0,parallaxed_texcoords0.xy + (time * fog_speed)); vec4 fog_reverse = texture(texture0, 0.8 * parallaxed_texcoords0.xy - (time * fog_speed * 0.5)); fog_col = mix(fog_col,fog_reverse,0.5); fog_col.xyz = clamp(fog_col.xyz,0.3,1.0); fog_col.a = clamp(diff * fog_col.r,diff,1.0) + (diff*height); Ok so that's about it. If you have questions or comments feel free to drop them below. 39a_ground fog + parallax.zip

No biggie but the letters aren't showing up when I type in the search bar. Search works fine but seems like the letters got switched to white or something? Been that way for maybe a month or so.

Ok so I didn't quite do one shader a week but I got to 52. I wasn't sure I could pull it off but hopefully the shaders are diverse enough to give something to work with for most occasions. I tried to keep the language consistent throughout and organize them sort of from easy to hard. I threw in all kinds of links because I don't know a lot of the technical terminology. I don't know how Ultra is going to be but I get the impression it's not going to be too much different. From what I understand, Ultra uses the PBR model for lighting rather than the Blinn-Phong and it uses Vulkan as its shader language. From what I've seen of Vulkan it doesn't look too much different. I want to continue here for at least a little while. There are still a few things I want to make. An ocean shader and a snowtracks shader, for instance. I've found that LE4 can do just about anything I can think of, though not perhaps on a large scale, and from what I've heard Ultra is going to be extremely fast so hopefully it will be user-friendly enough (for noobs such as myself) that its users can make some of those open world environments we see in PS4 games and such. "Fastest game engine on the market" [paraphrase] is a bold claim but LE4 turned out to be exactly what it was advertised to be and I'm starting to get those little tingles of excitement the closer it gets to the release date. Leadwerks is legit. A couple tips: One of the things that helped me a lot in working with shaders was to learn what the errors mean in compile. I ran into a few common ones. Sometimes I would try to multiply a vector3 by a vector4 or some other kind of thing and this doesn't work. Also, you can't put uniforms on the left-hand side of the equation (to the left of the "equal" sign). Sometimes I would forget a semicolon at the end of a line and you'll get an error for the line under that line (that's a tricky one because it's telling you the error is on the NEXT line). Also make sure you declare any variable you introduce, such as "float" or "vec3" etc. Most commonly I would simply get an error because I tried to use something that I didn't declare. Like I'd try something like: float mask = texture(texture0,ex_texcoords0).r; ...and the compiler would tell me that texture0 doesn't exist because I forgot to include it in the shader like: uniform sampler2D texture0; Another trick I found useful was to use "discard" in the fragment stage. Sometimes I was able to tell where something was or what something did because I used discard. For instance, try this in any of your shaders: If (gl_FragCoord.w < 0.1) discard; ...this is a good way of finding out what stuff does. I'm not entirely sure which direction I should go from here. There are certainly some shaders I still want to do and I'll post them here when I'm done. Ideally I'd be able to do ALL the shaders. But that's a process. But I'm open to ideas and shader ideas. One thing I thought might be cool is to start making little scenes. That would mean I'd need to learn how to do some modeling. I just don't know which program I should get for that. Anyway happy shading. See you soon.

According to learnopengl.com PBR - or physically based rendering - is "...a collection of render techniques that are more or less based on the same underlying theory that more closely matches that of the physical world...[it] aims to mimic light in a physically plausible way...[and] generally looks more realistic compared to our original lighting algorithms like Phong an Blinn-Phong...PBR is still nonetheless an approximation of reality...which is why it's not called physical shading, but physically based shading. For a PBR lighting model to be considered physically based, it has to satisfy the following 3 conditions: 1. Be based on the microfacet surface model. 2. Be energy conserving. 3. Use a physically based BRDF." 1. Microfacets: The microfacet model is an approach to lighting that treats the surface of all things as if they were covered in microscopic mirrors. When these mirrors (or microfacets) all reflect in the same direction you get a highly reflective effect on the eye. When these mirrors reflect in many different directions you get a scuffed "rough" reflection. Thus every surface is treated as having a roughness/smoothness value or some variation thereof. From learnopengl.com: 2. Energy Conservation: From learnopengl.com: "The microfacet approximation employs a form of energy conservation: outgoing light energy should never exceed the incoming light energy (excluding emissive surfaces). Looking at the above image we see the specular reflection area increase, but also its brightness decrease at increasing roughness levels. If the specular intensity were to be the same at each pixel (regardless of the size of the specular shape) the rougher surfaces would emit much more energy, violating the energy conservation principle...An additional subtlety when it comes to reflection and refraction are surfaces that are metallic. Metallic surfaces react different to light compared to non-metallic surfaces (also known as dielectrics). Metallic surfaces follow the same principles of reflection and refraction, but all refracted light gets directly absorbed without scattering. This means metallic surfaces only leave reflected or specular light; metallic surfaces show no diffuse colors." 3. BRDF: "The BRDF, or bidirectional reflective distribution function, is a function that takes as input the incoming (light) direction ωi, the outgoing (view) direction ωo, the surface normal n, and a surface parameter a that represents the microsurface’s roughness. The BRDF approximates how much each individual light ray ωi contributes to the final reflected light of an opaque surface given its material properties. For instance, if the surface has a perfectly smooth surface ( like a mirror) the BRDF function would return 0.0 for all incoming light rays ωi except the one ray that has the same (reflected) angle as the outgoing ray ωo at which the function returns 1.0. A BRDF approximates the material’s reflective and refractive properties based on the previously discussed microfacet theory. For a BRDF to be physically plausible it has to respect the law of energy conservation i.e. the sum of reflected light should never exceed the amount of incoming light. Technically, Blinn-Phong is considered a BRDF taking the same ωi and ωo as inputs. However, Blinn-Phong is not considered physically based as it doesn’t adhere to the energy conservation principle. There are several physically based BRDFs out there to approximate the surface’s reaction to light. However, almost all real-time PBR render pipelines use a BRDF known as the Cook-Torrance BRDF." The learnopengl.com PBR shader uses a lookup texture to get the BRDF (brdflut). This is sometimes referred to as "fake BRDF." The brdf texture included with the two PBR shaders is considered to be "universal" and need not ever change from material to material. You can just leave it in the specular slot every time. From polycount.com: As I've tried to do throughout, I've broken down some of these principles into simpler shaders so you can how they can be used on their own. The learnopengl.com PBR shader uses multiple lights. So here I broke that down into a Blinn-Phong. You can adjust the number of lights you need and add the color and position of each in the shader: 48_blinn-phong + multiple lights.zip Here is the "fake BRDF" technique. It's actually really simple but I find this very cool. All you do is create a fresnel (09_fresnel) and exchange the vector 2 texture coordinates of the given texture with it. Something like this: vec4 iridescence = texture(texture4,vec2(ndotv,0)); You can readily see how it works and change these textures with anything you want, really: 49_iridescent.zip The PBR shader splits the lighting in two ways: diffuse lighting, and specular. It further reduces the specular lighting into two parts: the BRDF, and the IBL specular map. The BRDF is shown above. Here is the second part of it. Note this and the PBR shaders are using something called "equirectangular" textures. There is no need to convert them to cubemaps. If you search for "HDRI's" you can find a lot of these for free on the webz: 50_windows.zip The PBR shader uses heightmaps and I wasn't sure if there was one "official" method of getting height information so I made one with parallax and one with tessellation. That ought to cover everything. Parallax: 51_PBR + parallax occlusion.zip I included with the above and below shader only the bare essential textures. But you can search for PBR textures and there are a lot of them for free with "do whatever you want with this" kinds of licenses. I included a list of them near the bottom of this post. Here this is shown with a texture from the following collection: https://lebedev.gumroad.com/l/ekRhc 52_PBR + tessellation.zip I tried to follow the learnopengl.com PBR shader as closely as possible. Some of the ambient light was too dark. I wasn't getting good specular IBL. My roughness at 0 looked funky so I clamped it just slightly. Little tweaks like that. And you can adjust all of it. I'm not sure but I'm almost certain these PBR materials are meant to be Z-sorted. The article said nothing about it but the reason I believe this to be the case is because if they are not then any lights added to the shadowed side of the object look very dulled and the surface doesn't look right. You can see that for yourself. There is a bit of an art to using the PBR shader. It's not always a magical production. For instance whether the ao texture is more white or more black will affect the outcome. Not all the PBR materials I downloaded came with ao maps or heightmaps. So you may have to improvise depending on this. The basics, however, are that white areas of the metallic texture will be metallic. Dark areas of the roughness texture will be highly reflective (that's a bit counter-intuitive). You can mess with the black and white textures I added, rearranging them to get different effects. I added this small number at the end of this line to counter the strong black ambience (as seen in the above picture, which looks just a bit washed-out to me) but you can adjust it (line 201 in the tessellation PBR and line 211 in the parallax PBR): Lo += (kD * albedo / PI + spec) * radiance * ndotl + 0.0075; I also added a flashlight option. Just put the script on the object and drag the player into the slot. But it's rudimentary. I figured someone better at coding may be able to develop it if they want and my goal was to get a flashlight working with the z-sorted materials (what a bizarre little obsession with the flashlight I have). Here is a list of free PBR sources: https://ambientcg.com/ https://3dtextures.me/ https://www.cgbookcase.com/ https://freepbr.com/ https://www.poliigon.com/search?is_free=true https://lebedev.gumroad.com/l/ekRhc https://www.artstation.com/deepmind/albums/89651 PBR + equirectangular photos: https://polyhaven.com/ Happy shading! Next: Outroduction...

I don't know buffers that well. From my understanding you have to use a script. I'm sure Leadwerks can do it somehow. Here's an example of using a buffer. This is about as far as I've gotten with those. The buffers aren't documented so there's not a lot of help figuring them out: basic minimap.zip

Ok. Maybe I don't need that. I want to make a tracks shader but the video I'm watching is calling for "blit"? There's not a lot of glsl examples out there but the closest thing looks like some of those mouse paint things on Shadertoy . The only thing I've found that leaves trails are the decals.

You can do it in Shadertoy with iMouse so it's possible but is there any Leadwerks equivalent?

Ok. What if you just change that fog range from 100 to 10 or something like that?

Thanks I appreciate it. I will keep it up. If Josh keeps making quality stuff that I can use then I'll annoy him forever. Brand loyalty.

Do you happen to know which channels Substance Painter uses for roughness, metalness, and ao?

You're probably right. That would be my assumption as well. You can always look in the shader and see which textures are being used for what. If it's the mighty Shadmar he usually wrote in some good notes on which texture was which.