Also, those distance field functions from the previous page, becomes very useful when it comes to volumetrics, but they require little changes to get them comfortably working with particles.
A normal baker...Slow one, but works haha. I'll try to improve it. If I can get all the aspects of this right, I should get back to the painter. https://youtu.be/KlNeGY87chc
It bakes a world normal map, which gets transformed to tangent space. I should automate this after the baking is done, instead of transforming it in the material.
The baking process itself captures the vertex normals, and the local position of the unified cage mesh into textures, and it traces from the positions, along the negative vertex normal of the cage. This is done on a per pixel base, and currently it uses a scanline method which is kinda slow as we can see. I'm thinking a bucket one with user set bucket size would work better.
A similar (but lighter and faster) technique can be used to achieve similar resuts to procedural foliage used together with "grass"node in the material editor, but this one would allow you to parameterize things better with textures. You could have like a scale map for example. In this example, I'm only showing a mask map working. It also works with static meshes, not only with landscape:
It looks like one solution to speed up the normal map baking could be to split up the rendering into workers (duplicate actors) rendering smaller sections, parallal. From what I see, reading the huge array of pixels is the bottleneck here. This is why it gets faster when its split up into smaller sections (shorter arrays). I think I should also give it a pre-processing pass, where it removes empty pixels first, but this doesn't help when you have a nicely filled up uv. In this pre processing pass, I could also put them into structs, containing coordinates, and only pixels with content, so coordinate wouldn't need to be calculated, but it would be just pulled from the struct. I would imagine this would only help a little bit.
Here are some measurements not including post composition - if its needed, I'm not sure yet...
The second thought is to make this to be a standalone application with tga/png output to the disk, so I could nativize the blueprint. Now this would give like 400% performance increase probably, maybe more.
I'm also looking at the Nvidia doc about normal map baking implementation, but they do it on the gpu, and I don't really understand how they are doing it. I don't get how does the pixel shader know about the position of the highpoly mesh, when it doesn't have a position map baked. They do some pre voxelization pass. Does this mean they render a position volume texture from both using slicing method? https://developer.nvidia.com/gpugems/GPUGems3/gpugems3_ch22.html
I'm also wondering, if changing the array to a map or some array of structs (like rows of pixels) would help.
I'm trying to figure out the gpu one. I got some of the required textures of the highpoly working. Reference on the picture is from the link above. I think I need to have the empty spaces in the triangle index list texture, like their one...
There is this node that can be used to actract information from meshes:
So yes, I need the spaces in the triangle texture, because that will show where is the end of the list for the given cell. And the uniform grid texture is indeed a volume texture, and its very much like a mask texture about if the cell contains anything. This texture can be generated on the cpu by simply box tracing the cell positions and writing the hit result into a texture. So a pre process pass on the cpu is needed anyways, grid density would determine how long it takes to render the uniform grid. Using a tile based approach or an octree again, could speed this up somewhat.
Some expectations: - higher grid density -> less tris per cell ->faster hit calculation, but longer ray travel->more loops - lower grid density -> more tris per cell->slower hit calculation, but shorter ray travel, as it needs to visit less cells.
My upcoming scene will have a bunch of specific type of trees, so I decided to make a spline based generator, so making the variations will be a matter of changing some parameters. Not complete, but trunk and level1 branches works fine. Level1 still needs some work, but I got the basics working. Level 2 branches are completely missing yet. Most of the things can be controlled with curves, similar to SpeedTree. Creation of LODs would be done by swapping the spline mesh to a lower poly version. I already tried it out, and merge actors option works fine with it, so I can even bake them into unified meshes, after generating them. This solves the movement animation issue with spline meshes as well, because I can make specific uv layouts and gradients afterwards.
The tree type I'm making is the "money puzzle tree" or "Araucaria Araucana"... I think it looks pretty cool with the scale looking leaves and bark.
Here is a screenshot showing the spline skeleton, and some different parameters:
This is the list of the currently implemented parameters:
A standalone texture packer tool I made over the last weekend, using umg and blueprints. It isn't fully finished, but mostly functional already. I will add windows dialogs for easier input. https://www.youtube.com/watch?v=TlC969RQmj4
I should compile my texture tools, like the baker and painter and some more including this one into an xNormal-like app.
I'm not a tech artist, but I love checking out this thread. The work you do directly inside the engine is fantastic. Baking and painting in UE4.......Wow!
Thats right, unfortunately it doesn't have tga output support. None of the 3 custom save functions (write pixels directly to the hard drive) that I tried has option to save as tga. Only png,jpg, and bmp are supported for some reason. I'll ask my coworker to take a look into this, he could probably make me a fourth one, with tga support, lol.
Looking into the tga export, but it will probably take some time. The idea is to use the same function as whats used when you export a tga out from Unreal...
Currently I'm not working on the painter, I think if I would get back to it now, I would probably rework it a lot, to simplify things. I had an idea of putting all these texture related tools into a single standalone application, so the painter would get place in this, but these are just thoughts yet.
About the edge wear shader - some simple description is already provided on one of the previous pages, plus there were a few guys on artstation/level90 using the technique, and they talk about it a little bit more. Currently I'm unable to find those articles, sorry.
About the edge wear shader - some simple description is already provided on one of the previous pages, plus there were a few guys on artstation/level90 using the technique, and they talk about it a little bit more. Currently I'm unable to find those articles, sorry.
Would you have the edge wear shader saved as a function(or Mat) that you could upload? I'm having trouble trying to get it going based on your post on page 2. I had no luck finding the 80Lv or Artstation articles you mentioned.
Or better yet put it up on Gumroad and I'll gladly pay you for it. To me this shader is pure gold as I do LOT of assets using FWVN.
Uncut, so please forward to 0:25 to get started!!! Minimal description in the youtube video description. Slightly longer, I used UE4 materials and blueprints, and render targets. https://www.youtube.com/watch?v=KnswbutXPa0
Playing with volume rendering again. This is the mannequin voxelized at 256*256*256 resolution. If the volume is used with the volume material domain, it even gets lighting. But no self shadowing unfortunately, because thats a limitation of the volumetric fog currently. So you can choose between getting light from scene lighting and have no self shadowing, or to use a custom ray marcher, have self shadowing from a single directional light but not affected by the actual scene lights.
Took a break from freelance today and added normal computation to my distance aided ray marcher which is a topic that I'm researching for a long time now. Its a nice technique if you are ray marching solid surfaces, because it heavily optimizes the step count and allows early quit from the loop (except near the edges of the primitives). You basically leap through the most of empty spaces. I just plugged the result world normal to the normal input of the material, and set the material to not use tangent space normal as normal input. So the default lights in UE can interact with them. As a next step, I'll try to figure out some data structure to allow free user input on primitive types and parameters. The plan is to include blend mode into the structure so you can boolean stuff. It will be probably an array of information stored in a lookup texture.
Texturing them is fairly straight forward since the position in space is already known from the hit. So tri planar projection can easily be performed. I could add a normal map using the same method, but actually, when you are using a distance aided ray marcher, displacement is so cheap that its just better to use that instead of a normal map. The normal from the displacement would be also computed automatically, unlike with regular real time displacement. Maybe next time I'll show some displacement too but I should rather do the scene description data structure now, so multiple different primitives could be used to compose a scene.
Man, there are so many possibilities using this technique. Adding cast soft shadows and reflections would be fairly easy. I'll definitely try them once I have the proper system to input data.
I would like to share something with you guys, that I discovered some time ago, but I didn't have nice use cases to show it off. Now in the ray marcher, it saves me a lot of time, and simplifies and shortens the hlsl code that I actually need to write. Hopefully it will be useful for someone else too. It is about adding custom hlsl functions to the engine, so they can be accessed and called in the custom material node.
First lets see how some of the distance field functions looks in hlsl. My main reference all the time when it comes to ray marching and distance field rendering, is the fantastic site of Inigo Quilez. His examples are written in glsl, but its very simple to translate them to hlsl, as there are very little differences between the 2 languages. http://www.iquilezles.org/www/articles/distfunctions/distfunctions.htm
So here are some of them translated to hlsl, formatted in a way that Unreal accepts:
To make Unreal seeing my functions, the file needs to be incuded into "common.ush". I just placed it in the same folder, but any absolute path works too!
Here are 2 comparison images to show the difference between not using custom functions from an own ush, and using one.
Sdf torus WITHOUT a function in a ush:
Sdf torus WITH a function in a ush:
As you can see, the code in the second example is significantly shorter, and you only need to call the function and input the parameters, rather than writing the full formula. This can shorten the longer and more complex codes a lot. I find it very user friendly when the same function would need to be called multiple times, or when things would be nice to be reusable.
Now one might ask why would you even write a code when all of those functions can be made out of nodes. They definitely can. And I even uploaded the material function version of some of them some time ago. But there are certain cases, where nodes just doesn't work, because the number of nodes would need to dynamically change based on conditions or user input. The most common example for this is loops. The simplest example for a looping shader is blur for example. The blur width or radius would determine how many times you would need to sample the texture. This cannot be done with nodes because the engine can't place you new nodes when you crank up the blur radius. You could only have a fixed radius with hand placed sample nodes. So its a good case for using code, and make a "for loop" where you can dynamically set the loop count. There are other good use cases too. Ray marching is one of them, and this is why I had the idea to write about all of this. I found the custom ush method really useful during my experimentation with this. I hope it will help some other people too.
As a bonus example, here is the same torus function used in a distance aided ray marcher. Only the opacity of the primitive was computed. Note that we quit marching once we are close enough to a surface. Also notice that because we are estimating the remaining distance at each step, we can quit after a few steps on a lot of pixels, and this number increases (the needed step count) as the fresnel angle increases. Another optimization could be added so we also quit if we went too far and went out from the bounds from the box. I didn't find this necessary, because in classic ray marching scenes, we can see a lot further than the bounds of the enclosing box like in the infinite spheres example a bit above. It also wasn't the point .
So I was thinking about the data structure to use with them and I think something like this could nicely work for primitive descriptions. The user inputs some data into an array, setting up the primitives with their parameters. Note that not all types of primitives utilize the roundness parameter, but I wanted to have a uniform set of parameters for simplicities sake.
Then based on this array, the blueprint makes the actual data structure that is stored in a texture like this:
Then this can be easily looked up in the ray marcher.
This is not the final thing, because using this method, I could only add some primitives, and couldn't blend them in interesting ways (which is how they are actually supposed to be used, so you can create more complex shapes). I think what I actually need is an array of arrays basically. Arrayception. Then multiple primitives could be blended and used to describe one object, and multiple objects could be added to the ray march scene.
The description texture of that would look something like this:
The idea of adaptively ray marching non-distance field translucent volumes: There is visually no difference between doing this and regular uniform steps, but I found that volumes with a lot of empty spaces benefits from doing this a lot. Depending on the amount of empty space in the volume, you can get up to double rendering speed using adaptive step size. On this demonstration image, the blue line represents a single camera ray (one pixel on the screen) , the red dots are the sparse steps that we use when we are in empty space, and once we enter content, we take a step back using the sparse step size, and switch to much smaller steps (green dots). Once we got out from the content, we switch back to sparse step size, until we hit something again. Its important to note that the sparse step size still can't bee too large, because then there would be a high possibility of jumping through and skipping smaller details. It also need to be noted that a volume full of content (homogenous fog volume for example) does not benefit from this at all because the intersector would be constantly using the small step size setting. But volumes with at least some empty spaces shows some performance improvement, and volumes with a lot of empty spaces shows nice speedup.
Do u think RTX tech is ready for games atm? I am guessing this will be implemented in next generation consoles although pc games will already have this.
Hi. On some level, and only on high end hardware, yes. But the 10th series definitely isn't. You can safely enable 1-2 features with 1 bounce and low spp but anything higher will kill the fps, so I would say in this current generation its more suitable for cinematics and 30fps. This last reflections test uses 16 bounces and 4 samples per pixel which results in 20 fps on 1080p. With that said, you could safely enable ray traced reflections with 1 bounce and 1 spp on any rtx card, and have more than 60 fps on 1080p in a game.
Different topic, but I'm not even sure if there will be a next generation of consoles because of the cloud solutions (stadia for example). Long story short, on low settings, yes its ok, but games still needs to wait for higher settings to be able to run smoothly.
Ok. Thanks. Stadia. I have heard of it and I am not sure this would hold up for third world countries though. Super high speed internet is not the norm in these countries so that is something they should think about.
Replies
And a simple noisy ball:
Also, those distance field functions from the previous page, becomes very useful when it comes to volumetrics, but they require little changes to get them comfortably working with particles.
Here is a volumetric torus:
It bakes a world normal map, which gets transformed to tangent space. I should automate this after the baking is done, instead of transforming it in the material.
The baking process itself captures the vertex normals, and the local position of the unified cage mesh into textures, and it traces from the positions, along the negative vertex normal of the cage. This is done on a per pixel base, and currently it uses a scanline method which is kinda slow as we can see. I'm thinking a bucket one with user set bucket size would work better.
Here are some measurements not including post composition - if its needed, I'm not sure yet...
Still very slow...
The second thought is to make this to be a standalone application with tga/png output to the disk, so I could nativize the blueprint. Now this would give like 400% performance increase probably, maybe more.
I'm also looking at the Nvidia doc about normal map baking implementation, but they do it on the gpu, and I don't really understand how they are doing it. I don't get how does the pixel shader know about the position of the highpoly mesh, when it doesn't have a position map baked. They do some pre voxelization pass. Does this mean they render a position volume texture from both using slicing method?
https://developer.nvidia.com/gpugems/GPUGems3/gpugems3_ch22.html
I'm also wondering, if changing the array to a map or some array of structs (like rows of pixels) would help.
I think I need to have the empty spaces in the triangle index list texture, like their one...
There is this node that can be used to actract information from meshes:
http://gpurt.sourceforge.net/DA07_0405_Ray_Tracing_on_GPU-1.0.5.pdf
So yes, I need the spaces in the triangle texture, because that will show where is the end of the list for the given cell. And the uniform grid texture is indeed a volume texture, and its very much like a mask texture about if the cell contains anything. This texture can be generated on the cpu by simply box tracing the cell positions and writing the hit result into a texture. So a pre process pass on the cpu is needed anyways, grid density would determine how long it takes to render the uniform grid. Using a tile based approach or an octree again, could speed this up somewhat.
Some expectations:
- higher grid density -> less tris per cell ->faster hit calculation, but longer ray travel->more loops
- lower grid density -> more tris per cell->slower hit calculation, but shorter ray travel, as it needs to visit less cells.
The tree type I'm making is the "money puzzle tree" or "Araucaria Araucana"... I think it looks pretty cool with the scale looking leaves and bark.
Here is a screenshot showing the spline skeleton, and some different parameters:
This is the list of the currently implemented parameters:
And here are some of my references:
Out of curiosity, is that blueprint image one of yours or just a meme from online?
I should compile my texture tools, like the baker and painter and some more including this one into an xNormal-like app.
Currently I'm not working on the painter, I think if I would get back to it now, I would probably rework it a lot, to simplify things. I had an idea of putting all these texture related tools into a single standalone application, so the painter would get place in this, but these are just thoughts yet.
About the edge wear shader - some simple description is already provided on one of the previous pages, plus there were a few guys on artstation/level90 using the technique, and they talk about it a little bit more. Currently I'm unable to find those articles, sorry.
https://en.wikipedia.org/wiki/Brownian_motion
Uncut, so please forward to 0:25 to get started!!!
Minimal description in the youtube video description.
Slightly longer, I used UE4 materials and blueprints, and render targets.
This is the mannequin voxelized at 256*256*256 resolution. If the volume is used with the volume material domain, it even gets lighting. But no self shadowing unfortunately, because thats a limitation of the volumetric fog currently. So you can choose between getting light from scene lighting and have no self shadowing, or to use a custom ray marcher, have self shadowing from a single directional light but not affected by the actual scene lights.
Example of pseudo volume texture:
Man, there are so many possibilities using this technique. Adding cast soft shadows and reflections would be fairly easy. I'll definitely try them once I have the proper system to input data.
First lets see how some of the distance field functions looks in hlsl. My main reference all the time when it comes to ray marching and distance field rendering, is the fantastic site of Inigo Quilez. His examples are written in glsl, but its very simple to translate them to hlsl, as there are very little differences between the 2 languages.
http://www.iquilezles.org/www/articles/distfunctions/distfunctions.htm
So here are some of them translated to hlsl, formatted in a way that Unreal accepts:
To make Unreal seeing my functions, the file needs to be incuded into "common.ush". I just placed it in the same folder, but any absolute path works too!
Here are 2 comparison images to show the difference between not using custom functions from an own ush, and using one.
Sdf torus WITHOUT a function in a ush:
Sdf torus WITH a function in a ush:
As you can see, the code in the second example is significantly shorter, and you only need to call the function and input the parameters, rather than writing the full formula. This can shorten the longer and more complex codes a lot. I find it very user friendly when the same function would need to be called multiple times, or when things would be nice to be reusable.
Now one might ask why would you even write a code when all of those functions can be made out of nodes. They definitely can. And I even uploaded the material function version of some of them some time ago. But there are certain cases, where nodes just doesn't work, because the number of nodes would need to dynamically change based on conditions or user input. The most common example for this is loops. The simplest example for a looping shader is blur for example. The blur width or radius would determine how many times you would need to sample the texture. This cannot be done with nodes because the engine can't place you new nodes when you crank up the blur radius. You could only have a fixed radius with hand placed sample nodes. So its a good case for using code, and make a "for loop" where you can dynamically set the loop count. There are other good use cases too. Ray marching is one of them, and this is why I had the idea to write about all of this. I found the custom ush method really useful during my experimentation with this. I hope it will help some other people too.
Note that not all types of primitives utilize the roundness parameter, but I wanted to have a uniform set of parameters for simplicities sake.
Then based on this array, the blueprint makes the actual data structure that is stored in a texture like this:
Then this can be easily looked up in the ray marcher.
This is not the final thing, because using this method, I could only add some primitives, and couldn't blend them in interesting ways (which is how they are actually supposed to be used, so you can create more complex shapes). I think what I actually need is an array of arrays basically. Arrayception. Then multiple primitives could be blended and used to describe one object, and multiple objects could be added to the ray march scene.
The description texture of that would look something like this:
There is visually no difference between doing this and regular uniform steps, but I found that volumes with a lot of empty spaces benefits from doing this a lot. Depending on the amount of empty space in the volume, you can get up to double rendering speed using adaptive step size. On this demonstration image, the blue line represents a single camera ray (one pixel on the screen) , the red dots are the sparse steps that we use when we are in empty space, and once we enter content, we take a step back using the sparse step size, and switch to much smaller steps (green dots). Once we got out from the content, we switch back to sparse step size, until we hit something again. Its important to note that the sparse step size still can't bee too large, because then there would be a high possibility of jumping through and skipping smaller details. It also need to be noted that a volume full of content (homogenous fog volume for example) does not benefit from this at all because the intersector would be constantly using the small step size setting. But volumes with at least some empty spaces shows some performance improvement, and volumes with a lot of empty spaces shows nice speedup.
I think I exaggerated the soft shadows a bit too much
Different topic, but I'm not even sure if there will be a next generation of consoles because of the cloud solutions (stadia for example). Long story short, on low settings, yes its ok, but games still needs to wait for higher settings to be able to run smoothly.
Stadia. I have heard of it and I am not sure this would hold up for third world countries though. Super high speed internet is not the norm in these countries so that is something they should think about.