Author
Topic: dandelO's Grass Shader Update (Read 20139 times)

This is probably as far as I will take these files, for public sharing purposes, at least. I think that pretty much covers the main needs of a procedural grass layer. With the colour variation, specular settings, mud layers, and general slope constraints all pre-set inside, you're still left with all the functions of the main parent node on the outside to further tune things.All your height constraints and any extra slope constraints can be set there, as can blending/breakup shaders, coverage, intersection, surface smoothing, luminosity etc.Patchiness colours and specular highlights are all still editable, as are the length of each blade(and the size of each clump), from inside the nodes. Experts will see easily how they are all put together and edit it themselves and inexperienced users will get a good use out of this too with the simple plug-and-go tactic, I'd imagine.

I hope to see it sprouting up in some of your lovely pic's in the future, it has been a long labour getting these shaders to this point. From way back in 2007, actually(link is from 2008 but it's the oldest one I can find at the PS forums)... http://forums.planetside.co.uk/index.php?topic=3842.0

No exploded stones indeed, I just checked them out. Thanks Martin, very useful and a clever way of doing this. I made the clumps to sit the stretched stones on from a PF, but the fake stone base is actually much smarter. The only thing I don't grasp is the Lambert shader, but that's one I never use at all, so I never bothered to test it. It works great, thanks again.

Hi, Ulco. The Lambert shader was there to give the individual blades translucency, you can see the effect best in the close-up screenshots at the top of page 1. I've now replaced that Lambert shader with a default shader so that I can have translucency, as well as specular functions. See the updated files at the bottom of page 1.

I just read your Plugsnpixels interview last night and I see that you have had much the same idea, I'd like to say I didn't steal Ulco's idea from there. These were older files that I've just edited and replaced recently.

I know you didn't, because I had your files earlier, and might have gotten the idea for the long stones from you, and subsequently put together something 'of my own'. Can't remember, you pick up so many bits and bites here and there.... by the way, I would have hoped the Plugsnpixels interview to be a little more in favor of TG2 and XFrog. I put down the naked truth, but forgot to give Planetside's amazing product a serious boost. Probably because I'm not a salesman. Hate them actually

Ingenious Martin. No more need of grass populations, although I wonder what would happen if the camera moved. I've become a little more wary of displacements turning themselves on and off between frames. I'd like to give this a test run to find out if you don't mind. Grass seems to me to be such a waste of memory, and this would be a brilliant solution.

Hmmm, I couldn't say there definitely wouldn't be any issues with that, Hetzen. If you look at the 'extreme close up 1' image on page 1, you'll see halfway across the width of the image(most noticeable at the right hand side) that there were some displacement discrepancies between render buckets, there's a sharp cut-off. That was the only time I've came across the problem, mind you. I think it was just a random render error, the next image below it doesn't suffer the same problem but I had also used a different AA on that one so, I've no way to say for sure.There are often slight differences in subtle displacement details between renders of fake stones and such. You could always try and, I suppose, motion blur would minimize any major discrepancies, were you to animate it.

And, of course, you also couldn't use the current public's RTE rendering for this shader either.

In the planet node there is a function called "displacement tolerance" changing it should help with the cut offs at the bucket edges. Start with very small increments to test as changing the numbers in a big way will result in huge render time increases.

More on topic, the "grass" looks great. Very useful for almost any scene.

Yes, indeed. Displacement tolerance is the way to go if the cut-off problem ever arises again. I have only seen it that one time with this shader and that was in a pretty close-up shot that you aren't likely to want to do with this grass but, it's good advice. Thanks, RArcher!

I used your procedural grass Martin that worked out very well except for what you see that has happened to the fake stones at the shore line. The next message will illustrate the difference between the 'Quick render' and the 'Full render'.

Great image!It does require a good render detail to look its best, Bob. I'd use it at about 0.7 to 1, any lower and it can quickly turn to mulch. I've never seen that speckling effect as a result of using it, weird. I kind of like it on the stones here, even though, it wasn't actually desired.

Great image!It does require a good render detail to look its best, Bob. I'd use it at about 0.7 to 1, any lower and it can quickly turn to mulch. I've never seen that speckling effect as a result of using it, weird. I kind of like it on the stones here, even though, it wasn't actually desired.

Thanks Martin, I initially did the final render at 0.9 quality; 0.6 AA with GI at 2/4. After about 12 hours, I got an unknown error - a couple of buffers did not render towards the bottom. I tried lowering the quality and AA but got the same results. I attached the .tgd if you want to look. Note: I couldn't get a pop on the Lily pads so I placed them individually. The terrain is a .ter of Bright Angel Canyon.