Відео

Unfortunately it is too time consuming to script these videos, especially since this channel isn't monetized. I just have some talking points I want to hit, so that stuff slips in. I think most people will find they do the same if they are talking off the top of their head of 20 minutes straight.

The PCG generation can consider both direction and radius and weight them against eachother, but I haven't experimented with that. It could potentially help reduce points being generated off screen, although you may get more pop in and possibly stutter when rotating the camera as a result. Worth a try for sure. It seems the static mesh spawner is the most expensive node by far. Generating the points can be fairly expensive (especially for the large grids) but I think the best fix for that is simply spawning fewer points on the larger grids. In my example, I'm using the same point density for all grids, so the larger grids are exponentially more expensive to complete, since each step squares the surface area. A huge endless field of grass with no occluders whatsoever is basically a worst case scenario/ torture test. It is possible to spawn a cluster of points around a sampled point, but I'm not sure if that extra logic would be faster than just having sampled more points to begin with. That kind of technique is really useful for things like spawning saplings near a parent tree, for example. Its worth looking into, but I think using a single point to spawn more than one blade might work better (either by using a mesh with multiple blades, or maybe spawning a level instance with multiple meshes) Based on your comment I tried to see if forcing a particular execution order would make any difference. I forced the smaller grids to wait until the larger ones had finished by creating a dependency using the gather node. I was hoping this would mean fewer static mesh spawners running at once. I didn't notice any difference is performance, but it is a bit tough to measure. Making the large grids dependent on the small ones didn't work at all for some reason, but if it did I expect the results would be the same. Maybe there are other ways to control the execution sequence though.

@@TechArtAlex I haven't had a chance to view all the videos yet but I assume you have checked out the PCG Profiler window and that's how you are determining the cost? I wonder how much an improvement you might see using the rdInst (Marketplace Plugin) StaticMeshSpawner Node instead as he maintains his system is faster then the normal ISM/HISM add instance method.

@@shannen1188 Correct. I'll have to look into that node.

Think of a Vector Displacement Map like a super stretchy square of rubber. You can make any shape you could stretch it over, but you can't add any holes to it. It would be impossible, as far as I am aware, to make a brush that could turn any subdivided surface into an archway. The problem isn't the overhang, it is the hole. A common mesh used to demonstrate VDMs capabilities is a mushroom. Quite complicated, with a large overhang. but our imaginary sheet can stretch over it just fine, with no holes needed. Topology is the relevant mathematical field.

​@@TechArtAlexYeah someone told me holes are impossible, and that's fine. But what if I had a hard modeled surface? Like a cube that has been booleaned by another cube? Is there a way to accomplish this through the shader editor? The only way I've found has been through multires and shrinkwrapping and manipulating the mesh of the grid in Sculpt mode. But I was hoping there might be a simpler work around. Blender secrets put out a video regarding vdm brushes, and said that it was possible to make vdms from existing objects. But does not disclose how. He only teases in his video that he uses shape keys. And that's what led me to your video [via keywords "Vector Displacement with shape keys"]

@@syaoranli7869 You just need to bake the world position of the plane/mesh before and after applying the shape key, and then the difference between the two world positions is a standard vector displacement map.

​@@TechArtAlexcan this be accomplished when joining a hard modeled object with a grid?

@@syaoranli7869 By grid you mean a subdivided plane? Any object/shape that can be flattened into a continuous plane with no overlap or holes should work. Think about our infinitely stretchy square of rubber. It may be possible to go beyond these constraints with clever mesh construction, but not in a generalized manner.

Thanks! On my machine it didn't make any difference what type of instance I selected, but yes in theory HISM or Foliage instances should perform better than standard instances. They also cull in grid clusters instead of individual instances which is faster, but in some cases you may notice a blockiness to the culling.

Hierarchical runtime generation with PCG. The next video will probably cover an example of that and some of the pros and cons.

@@TechArtAlex awesome! Thanks.

Correct, the vectors need to be in tangent space, which needs to be converted into world space for the WPO. I never got a version of the script to bake them correctly though with this particular encoding method due to a difference in how blender handles vertex normals vs tangents. I'll probably revisit it eventually, I've wanted to redo these videos for some time to correct some things.

@@TechArtAlex Hey, so I finally made some headway in this matter. I'm currently using a traditional UV mapped tangent map to get the effect in unreal on a skeletal mesh. The key was to make a distance offset map that then controls how far each vertex should move in the direction of the new tangent map. I made the offset map by subtracting position maps of the mesh and the modified mesh. I made the vertex normals on my deformed mesh face outward in a unifor way as I just need the displacement to deform inward and this way I don't need to calculate the displacement direction and just have it baked into the tangent map. Btw you also don't need to use a 32 bit format if you just add a 1 to all your values and then divide by 2. That will store all the negative values in the 0 - 0.5 range and the positive in the 0.5 - 1 range, You can then do the math in reverse in unreal to get the proper coordinates.(Not too sure which approach is cheaper on the system, but it makes working with the img formats easier :D )

@@AbyssFX. Awesome, glad you got it working. The reason for 32 bit accuracy get more accurate displacement. If this isn't necessary then remapping to 0-1 is fine.

@@TechArtAlex That is something I still need to tweak and test. The last issue I have is the accuracy of the displacement. It's a bit messy still. I need to figure out how to bake in tangent space with the pixel per vertex UV thing you're doing and then I can test to see how much of a difference the 32 bit makes(it could be a huge difference and I was just foolish 😅). The main thing I noticed is that unreal sets a rly bad compression on non 32 bit images by default, changing those settings appears to "fix" the issue..

@@AbyssFX. Yeah, regardless of bit depth, you need to use uncompressed formats for the pixel per vertex technique.

Is the artifact only in the material viewer, or does it also appear on the grass in level?

@@TechArtAlex both. It tanks my fps and if I turn off world position offset, or switch it to transparent it goes away and viewing it anywhere, it has it. I suspect it is detecting it is underground. When I spawn it, I have to elevate it with pcg because it spawns clipped into the ground. Maybe it's contact shadows?

@@NorwinLabs of it is clipped below the ground then your mesh pivot or UVs must be different than how I've set them up in the example. This could be adjusted but I set it up the way I did to minimize shader math. It could also be the setting "affects distance field lighting" in the mesh spawner. This setting often causes black artifacts.

@@TechArtAlex It was affects distance field lighting. I was using the wrong pcg graph. Thanks!

Thanks! There's a possibility.

Those are "Named Reroute Nodes", a very useful tool for making the material tidier.

@@TechArtAlex Thanks!

@@TechArtAlex Yes, its good tutorial. But i have mistake- there triplanar only on Y coorditanates, On X i have stretchings. Please help me..

This isn't really a substitute for triplanar mapping, but rather how to achieve a sort of tri-planar mapping effect with landscape RVTs. The dithering technique used will be far more efficient than sampling a landscape RVT multiple times as normal triplanar mapping would, however.

@@TechArtAlex we want to use rvt method, but tri-planar has performance problem, so we want to find a good method to solve the strectching problem..

@@YodaMaster-p3k Sampling virtual textures actually requires two samples. So when you use a triplanar mapped RVT you get 6 samples per texture instead of 3. This could be part of the poor performance. The dithering technique (which I go into more detail about in my single sample triplanar mapping video) allows you to get a good projection with one one texture sampler (two in the case of RVTs instead of 6). So it can dramatically reduce the number of samples needed for RVT.

Thanks!

Yes, that kind environmental animation is one of the primary use cases of this technique. You would just input time * speed into the rotation angle, and something will spin nonstop.

@@TechArtAlex Oh thank you for your answer man !

Because we are pre-computing and storing the landscape normal vector as instance data, this blending technique is very cheap at runtime. Nearly all of the cost is at build time instead of runtime. This could be an issue for those wanting to do hierarchical runtime generation, as the more complex the PCG volume is, the slower the grass can be spawned. This is something I'm considering making a video on.

Haha thanks, yeah this one is definitely too much spaghetti right now.

The only reason I could see that happening is if you were using raytraced shadows without enabling the feature "use WPO with raytracing". I strongly suggest you don't use raytraced shadows for the grass, as it will be extremely expensive. I talk about shadows more on a later video.

@@TechArtAlex Thank you! Just wrong shadows misled me

Thanks! While I'm optimistic about the fancy new tech, I definitely think the old fashion techniques like LODs and even cube-mapped reflections will still have their place for a long time.

There are other ways, but a render target is probably the best.

There's a basic example in some ot the unreal sample projects. It does not use render targets. But the effect looks somewhat decent. It just distort the grass outward from pawns.

@@FishMan1nsk yea I've followed the kodeco tutorial before from tommy tran but I'm not trying to do the particle method, there's a way to sort of recreate the same effect but with render targets but I'm still trying to figure that part out. Effectively it's taking the same RT mask data and sort of adding to it with an offset to determine direction of the bend

Yes, that would work just fine.

@@TechArtAlex Do I have to do something additional to connecting alpha channel to SDF and funcion result to opacity? (the material is translucent UI)

Not that I can think of. It should work the same with any distance field.

Make it yourself from part 1 to achieve knowledge and understand how it works!

Still planning on it! Just needed a bit of a break haha. Maybe sometime this week.

Glad it helped, thanks!

Thanks!

In theory as long as it is the last thing you do, after applying all other modifications, you should be able to use regular deformation. But I would strongly recommend using and shifting the control points with your interaction system instead. This will make sure you have correct normals, and we have built in the length preservation system already it can take advantage of.

​@@TechArtAlex I can't work out how to directly affect the points. Do u have any idea on how I can apply normal WPO (regular deformation) such as simplegrasswind to the grass blades. Using an add node does not work as it creates the same stretching affect. Any rough idea would be appreciated.

@@avilxy8305 Directly applying to the points would be done in exactly the same was as the wind video. In that case we added and subtract from the control points coordinate based on the wind sine wave. But we can also push it based on things like our interaction system render target. The Simple grass wind always stretches meshes, which is part of why I recommended against using it in the wind video in favor of my method, which is capable of estimating and preserving approximate length.

its mostly a matter of deciding what direction you want to shift the vertex positions. In Ghost of Tsushima, they simply shifted them down in view space. I am shifting them in the downward facing vertex normal direction, but you could shift them in any direction you want and have a means to define. The downward local z normal would be another decent choice. The reason I went with the approach I did is that neither the view space or local z shift thickens the blade evenly regardless of the triangles orientation. You could also nullify part of your normal, and multiply by that. For example, say we only want to shift the verts in the Z and X direction. We can just eliminate the Y axis and then the roundness of the blade in that direction wont interfere.

@@TechArtAlex Interesting, I will mess with this myself more. I have kind of got it working by multiplying XZ vector and skipping the normal. Funny thing is the X pushes the verts towards -X instead of +X lol. But yeah, love your work. Thanks!

@@TechArtAlex Okay, final update. I got it working, I made changes to my mesh, and now it is working almost perfectly. Thanks!

A disappearing mesh may have something to do with the mesh bounds, or just displacing the mesh far away accidentally. Make sure you're only applying the wind to p1 and p2 and not p0.

@@TechArtAlex Ah, Thank you so much for the quick reply. It turns out because of my messy code I was applying wind to P0 not p1. Once again thank you for this brilliant series.

I don't have a start to finish tutorial version. If you haven't already, you'll probably want to watch my single sample triplanar mapping video, which has more details on that part. This video is just a slight modification of the world coordinates used for the triplanar mapping. If you are comfortable with creating a triplanar mapping material from scratch, this will be a lot more approachable.

@@TechArtAlex link? also im wondering since I am doing a TD game if it would be overkill anwyway. so kind of mulling over its use currently. lol. like should i, shouldn't i, what will it add to the scene blah blah. either way great video regardless, and definitely something I want to investigate and learn.

@@jamesbrady1930 Thanks! Yeah, might be kind of hard to notice this effect on a TD game. But it's always good to have another tool in the belt I guess.

@@TechArtAlex im doing a ruins project, going to revisit that kind of Skyrim feel, made my own rock and cliff faces. 1.5-2km wide terrain I made, road, along with a ruin cathedral. if you can link me that video and see if I can incorporate it into that one maybe.

@@jamesbrady1930 Nice! Here's that link ua-cam.com/video/dFApswlwsRc/v-deo.htmlsi=Wa1t0esNwNq74F_-

Thank you!

I have seen append go either way when it comes to instruction counts. Vector packing can also go either way in frame times, but I'd still consider it good form. That said, in a complete implementation wind params probably should be coming in from a collection parameter node anyway as it will probably be part of a larger global wind system so those were all just placeholders since I don't plan on building all of that out. Pow is in theory more expensive, but in practice most compilers are doing lots of automatic optimizations that may make that mostly irrelevant. For example if you put in a power of 2, it'll generally just multiply by itself anyway - although there are more sophisticated tricks being used as well. But it doesn't hurt to avoid potentially costly operations. I'm always quite skeptical of instruction counts, but if we can observe a frame time reduction then I'm all in. Like you said - doesn't hurt to try and see what happens. I'll have to test these changes out. Grass takes up a lot of screen space, and in this case has lots of verts, so every little bit counts. As for scaling the grass at a distance, I think this is generally a good approach. It is basically what nanite volume preservation does - and it is what outerra proposed in their blogpost that inspired Sucker Punch. Every time they cut the polygons in half, they double the surface area of the remaining grass. This can help reduce quad overdraw, reduce aliasing and lots of other goodies. Ideally I'd cull much more aggressively than I did in this demo, but I kind of wanted to show off a ridiculous number just because I figured people would want to see it haha. I've also been experimenting with importance based culling, but I'll probably make a separate video on that rather than bundling it in this series. Basically, rather than using distance alone, we can assign an importance value to grass based on things like proximity to a mesh. For example, if the grass is near a certain mesh, it should be culled later - since that grass is visually more important to the scene as its silhouette is contributing much more detail than a random blade in a field. The result is quite good I think. Another example would be that grass on a hilltop is more important than grass in a rut, although that's a bit harder to procedurally define. As for culling, I prefer to shrink and/or sink the grass blades while blending their normal towards the underlying terrain. This avoids the need for a masked material while still making the transition basically invisible. When I get around to the next video, it will probably be about blending out in more detail, and how to get the underlying terrain normal vector without needing to sample a virtual texture (thanks once again to PCG data packing). Thanks for the feedback and sticking around!

@@TechArtAlex >as for culling, I prefer to shrink and/or sink the grass blades while blending their normal towards the underlying terrain. How does this work? I have been informed/learned that using WPO to move a grass mesh, for example 10,000 down the Z-axis so it's culled and never drawn. Is flattening the mesh the same kind of thing? Does it prevent the mesh from being drawn in the first place? Genuinely eager to learn. From what I recall Final Fantasy had a similar/same thing with moving particles around the camera to be culled. Is flattening the grass the same thing?

@@Stygmire Pretty much, yeah. Using the vertex shader this way doesn't completely remove the mesh, because its verts technically still exist. However, because they occupy zero screen space, there is no fragment/pixel shading happening. And because they're instances, the verts were cheap anyway. This is the same reason why the extra/wasted triangle is basically free. Yes that vertex exists, but ideally no fragments are being shaded. If the grass sinks below the ground, then the z- pass can make sure the fragments are skipped too. Eventually the instance is entirely culled, but by that time it is already invisible. Using several cascades like I have cleans up the nullified meshes regularly to keep the instance count down, even if many are not really drawn. I tried assigning random cull values on a per instance basis, but it was not scalable to this many instances. But that might work for other things.

I'm not sure there's a whole lot more that can be done besides controlling these elements more tightly or cutting features. For example, one can cull the grass much more aggressively than I did. Ghost of Tsushima culled 75% of blades at each cascade, whereas I'm only culling 25%. But if I think of any easy performance wins I'll make sure to mention them.