
BTW this is a quick test of sheen and triplanar, bump included, it awesome

This is somewhat the last missing piece of the complete "picture". I could implement it but is there any additional information on how it works ? I assume it randomizes the tiles to avoid the visible regular pattern but, looking at the image, is a bit unclear if it works on a per tile base or may be per texellacilaci wrote: Fri Jan 03, 2020 7:47 am Good, hope this get's solved and we can start using uv-less objects easily.
By the way, is this a good base for stochastic/random texturing like here in fstorm:
tiles:
67801476_859576087762793_4763192252514172928_o.jpg
randomized(with locked rotation so pattern is straight):
68961877_859576027762799_4664134930685493248_o.jpg
or is this unrelated feature?
well there is this other implementation by unity: https://blogs.unity3d.com/2019/02/14/pr ... -in-unity/Dade wrote: Tue Jan 07, 2020 3:52 pmThis is somewhat the last missing piece of the complete "picture". I could implement it but is there any additional information on how it works ? I assume it randomizes the tiles to avoid the visible regular pattern but, looking at the image, is a bit unclear if it works on a per tile base or may be per texellacilaci wrote: Fri Jan 03, 2020 7:47 am Good, hope this get's solved and we can start using uv-less objects easily.
By the way, is this a good base for stochastic/random texturing like here in fstorm:
tiles:
67801476_859576087762793_4763192252514172928_o.jpg
randomized(with locked rotation so pattern is straight):
68961877_859576027762799_4664134930685493248_o.jpg
or is this unrelated feature?![]()
It is this: https://eheitzresearch.wordpress.com/738-2/lacilaci wrote: Tue Jan 07, 2020 3:57 pm well there is this other implementation by unity: https://blogs.unity3d.com/2019/02/14/pr ... -in-unity/
but this one doesn't handle patterns like fstorm is able to... no idea how the guy did it though.
It is just a UI indication in Blendluxcore, making sure users are warned early if they mix incompatible sockets (e.g. material output in color input), it doesn't affect the exported result.
So this is done already?Dade wrote: Tue Jan 07, 2020 9:27 am I could try, instead to fall back to constant UV values, to use triplanar mapping to automatically generate meaningful UV coordinates when they are not available![]()
https://benedikt-bitterli.me/histogram-tiling/This is a WebGL implementation of Histogram-preserving Blending for Randomized Texture Tiling. This method allows you to take any input texture and produce an infinite, non-repeating texture from it. The method is fast, simple, requires minimal preprocessing and storage, and the input texture doesn't even have to tile! The method works best on input textures that are stochastic in nature and don't have periodic features (e.g. brick). Natural textures (e.g. marble, bark, etc.) tend to work best.
Try the interactive demo below. Select any of the preloaded input textures or upload your own.
No, it wasn't working well but it than noticed the problem in OpenCL code, the fix seems to have fixed both problems: the ellipsoid I posted above is without UV coordinates.
Yes, having custom blending mode for normal maps could solve the problem.B.Y.O.B. wrote: Tue Jan 07, 2020 5:44 pm About normal map blending, we could make a variant of the triplanar texture that uses one of the methods described here, instead of lerping: https://blog.selfshadow.com/publication ... in-detail/
In Blender, this could be exposed as an extra node that also takes three color textures and a mapping, and has a bump output (internally adding a normalmap texture after the modified triplanar).