LuxCoreRender Forums

Agree, with normalmap it should not work, I mean, is like if you get a normal map for an object and you change it's orientation rotating the texture, it will be wrong, this is kind of the same

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

lacilaci 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?

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 texel

Dade wrote: Tue Jan 07, 2020 3:52 pm

lacilaci 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?

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 texel

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.

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 this: https://eheitzresearch.wordpress.com/738-2/

I posted the link to the "High-Performance By-Example Noise using a Histogram-Preserving Blending Operator" paper a while ago. It is beautiful but I really don't like to have to store additional information (i.e. the histogram map), I'm checking if there is a way to avoid the problem.

Dade wrote: Tue Jan 07, 2020 3:07 pm P.S. however the wrong input warning sounds strange.

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.

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

So this is done already?

Here...

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.

https://benedikt-bitterli.me/histogram-tiling/

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).

For imagemaps, I am also considering the suggestion of lacilaci to have a simple "triplanar mapping" checkbox on the imagemap. If the "normalmap" checkbox on the imagemap is also ticked, it would do the same stuff as above behind the scenes. This would be convenient for imagemaps, but the other variant would also be needed or other kinds of textures.

lacilaci wrote: Tue Jan 07, 2020 4:56 pm

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

So this is done already?

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.

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).

Yes, having custom blending mode for normal maps could solve the problem.