This is the feedback thread for our research prototype implementing Procedural Stochastic Texturing. Use this space to ask questions, offer feedback and show your results if you try it out !
Our goal is to implement this technique as a new sampler node in ShaderGraph at some point, offering support for custom shaders and the new rendering pipelines.
What is Procedural Stochastic Texturing?
Did a google search and the only thing I saw was something that looks like a better version of triplanar.
[quote]
it solves the issue of tiling repetition when tileable textures are repeated across a surface
[/quote]quote from https://github.com/UnityLabs/procedural-stochastic-texturing
Is this method solve problems with parralax (height) map when rotating object on 45%? Triplanar blend textures from different angles and than some artefacts happen.
Yes, the thread went up a bit before the blog post, thanks for linking it. I’ll edit the top post
Does it work in Unity 5.6?
Woah??? any performance comparison with and without?
Currently it works with the last Unity 2018 releases in the built-in render pipeline. Since the plugin plugs into parts of the Standard Shader code, and some of that has evolved since the initial release in Unity 5, it’s not working with older versions as it is.
I will be backporting it in the coming days as separate packages for older popular versions of Unity, mainly Unity 5.6!
We have performance comparisons on page 20 of the Technical chapter:
https://drive.google.com/file/d/1QecekuuyWgw68HU9tg6ENfrCTCVIjm6l/view
As a quick overview, it uses three input texture fetches in the fragment shader and some additonal math, so the cost is basically similar to that of Triplanar Mapping.
Thank you for still continuing to support 5.6
Very nice, this could be usefull for terrains and natural materials
When I download from github and install into my project on Unity 2018.3.5f1 on Mac (running Mojave), I get two hard stop console errors that will not clear…
Assets/Shaders/Procedural Stochastic Texturing/Editor/StandardStochasticShaderGUI.cs(585,11): error CS1644: Feature `byref locals and returns’ cannot be used because it is not part of the C# 4.0 language specification
Assets/Shaders/Procedural Stochastic Texturing/Editor/StandardStochasticShaderGUI.cs(587,12): error CS1644: Feature `byref locals and returns’ cannot be used because it is not part of the C# 4.0 language specification
When a I create a new material and choose StandardStochastic from the drop-down (it’s in the root of the shader hierarchy by default), I don’t get something that looks like what’s pictured in the blog, but something like this…
Any ideas on how I can fix that?
While it’s obviously a good fit for terrain, it’s also not going to be feasible if using a tiled caching system… any way to make them tango, perhaps being applied to the combined baked texture?
I don’t actually think it’s a good fit for terrain; I tried this technique a while back in MicroSplat and abandoned it- it just doesn’t look good on most textures. In fact, the use cases where this does look good are few IMO.
If, for instance, you have a highly stochastic texture (like concrete) which will be viewed up close and far away, then it will work well- but if the texture is highly stochastic to begin with, it’s not that hard to get it to tile well, and not that hard to break up the tiling with other techniques. I have yet to see a real world example where this is a real win, but I am happy to be proven wrong. (IE: in todays market of multi-gig gfx cards, 2k textures being the norm, and multiple samples and heavy ALU usage being plausible even on low end platforms like mobile)
So what to do instead? I’d offer these options as all being cheaper and better looking:
Requires designing multiple textures
Classic macro/detail texturing. Essentially using one texture to vary the other. So you tile your stochastic texture as normal, but use a second map to vary it’s luminosity or normal.
This is just my opinion, of course- I’m happy to see the community come up with some real-world use cases where this technique might be worth the cost.
trilobyteme switch on NET4 in Player settings
I had a similar discussion half an hour ago, I felt that this isn’t really a problem for most surfaces - you just use a bigger texture with more variation from the outset. But terrain remains the only place where I find tiling to actually become a problem, and Unity’s doing cached terrain texturing soon, and I hope that’s not going to be a problem.
Really like your ideas Jason. Will probably pursue something along those lines… (HDRP else I’d be using microsplat already).
That sorted it, thanks @id0
I mean, generally cached terrain just renders out the inputs to the lighting equation and caches it in virtual texture, such that you don’t need to render the full shader every frame. Unless something is animated, it should work with any shader technique that supports outputting those channels. I’ll eventually port MicroSplat to HDRP, but I’m waiting for it to be more stable and demand to pick up; the LWRP module for MicroSplat sells a few copies, but nothing near the work required to port it or maintain it while Unity is changing it all the time.
Now that it’s working, I’m trying to do some tests. I have noticed that if I change Stochastic Inputs to Albedo (from nothing) and click Apply, the ‘Pre-processing textures for stochastic sampling’ progress bar appears and just hangs in limbo. It effectively kills Unity, I can’t save or open another scene or project, and can’t even quit Unity. I have to manually force quit the Editor and start over.
