Triplanar mapping / stochastic texturing

[lacilaci]

so just to confirm

transform stretching is gone.

Seam is still present

just as defects related to poor uv's as shown in previous post.

These defects will be a big issue as blender assigns some basic uv's to objects. However if you modify the objects (i.e. model from cube) then uv's get crappy and since you want to rely on triplanar, you run into this problem where poor uv's will ruin triplanar map. Not sure how cycles handles this, or if it's even close to what luxcore is doing. But in cycles (or other renderers) if you use triplanar you don't care about having no, or bad uv's cause the triplanar mapping takes care of it.

Both of these issues only go completely away with proper UV's (at which point you might as well use that instead of triplanar!)

[juangea]

Why should UV's have something to do with Triplanar?

I mean, Triplanar is there to avoid UV's so in any case Triplanar should ignore current UV's, right?

[Dade]

Both of these issues only go completely away with proper UV's (at which point you might as well use that instead of triplanar!)

This problem is present only for bump mapping and I'm not aware of a solution. To explain the problem: you need a XYZ reference system to apply bump mapping. The shading normal is used as Z axis but the problem is how to pick XY axes. There is an infinite amount of possible XY axes perpendicular to Z/shading normal.
If UV coordinates are available, they are used to orient the XY axes so their placement is coherent across all triangles. Without UV, I have not information on how to place XY axes.

Box mapping in Cycles should be the same of our Trinplanar mapping, does it exhibit problems with bump mapping too ?

[Dade]

Why should UV's have something to do with Triplanar?

I mean, Triplanar is there to avoid UV's so in any case Triplanar should ignore current UV's, right?

See above, it is (supposed to be) a problem specific bump mapping (and some other specific stuff like anisotropic highlights orientation of glossy surfaces).

Do you have the same problem outside bump mapping ?

[lacilaci]

Both of these issues only go completely away with proper UV's (at which point you might as well use that instead of triplanar!)

Box mapping in Cycles should be the same of our Trinplanar mapping, does it exhibit problems with bump mapping too ?

No, I have never seen these issues in cycles. Maybe blender exports some extra data for cycles to avoid these problems..? Bump mapping is in cycles horrible looking though, so maybe there is some tradeoff or whatever.

I have not seen these problems outside bump mapping in luxcore but you need bump mapping most of the time so it's pretty big problem

[B.Y.O.B.]

This problem is present only for bump mapping and I'm not aware of a solution. To explain the problem: you need a XYZ reference system to apply bump mapping. The shading normal is used as Z axis but the problem is how to pick XY axes. There is an infinite amount of possible XY axes perpendicular to Z/shading normal.
If UV coordinates are available, they are used to orient the XY axes so their placement is coherent across all triangles. Without UV, I have not information on how to place XY axes.

Box mapping in Cycles should be the same of our Trinplanar mapping, does it exhibit problems with bump mapping too ?

Cycles seems to use this method: Bump Mapping Unparameterized Surfaces on the GPU
https://github.com/sobotka/blender/blob ... e_bump.osl

[juangea]

Can't you get get the local axis orientation of the object?

For the box mapping we usually get the "Object" uv's form the coordinates node.

[lacilaci]

Well, whatever is the possible solution, let's just not end up with the dead cat's vomit quality of bump cycles has.

I'll do UV's all day to avoid such a shitty bump mapping like in cycles. Every dent on bump in luxcore is able to properly catch highlights from environment, while in cycles every bump map looks like a f**ing sticker on a flat surface imitating bump.

[Dade]

Cycles seems to use this method: Bump Mapping Unparameterized Surfaces on the GPU
https://github.com/sobotka/blender/blob ... e_bump.osl

As far as I understand, this looks like bump mapping done in "screen space". It uses the partial derivative of screen X and Y to align the axes I was talking before. It sounds like something more suited for real-time/game-like rendering in OpenGL/Vulkan/DirectX/etc. than for off-line rendering. I'm not suprise if the result is not exactly good.

Mmmm, I wonder if, instead of working in "screen space", I can compute the partial derivative DpDu and DpDv in "triplanar space" ... it was somewhat my initial idea, may be, I will give it a shot.

[B.Y.O.B.]

That is their OSL code, I tried to read the kernel code as well (C++/CUDA/OpenCL) but it is very arcane and convoluted which makes it hard to follow. So I'm not sure if they use the same method in the non-OSL parts.