Drive Vector Coordinates with Textures

[AlexeyAdamitsky]

I really like LuxCore for a number a reasons and it's getting better and better. There is one feature I miss at the moment that if implemented can make LuxCore way more flexible with how it allows users to work with textures.

What is the issue?

Currently LuxCore doesn't allow you to drive texture mapping parameters with other procedural/non-procedural textures.

Only one of the texture node parameter is exposed and if we try to drive it with texture nodes it won't work.

Why is it important?

It gives an artist a great freedom how to work with textures and a lot of flexibility and creativity when doing shading work.

There are too many cases where it can be helpful but I'll focus on one that is particularly helpful for me.

Let's say we want to use grunge/scratches map to add variety to our material.

It's fine when it's the scale is big enough. But what if we want to scale it down. We immediately see repetition even with seamless maps.

And there is pretty much nothing you can do to get rid of the repetition in LuxCore because you can't affect texture vector coordinates in a creative way.

What can be done?

Expose more parameters in mapping node and make it possible to drive it with other textures.

Cycles does it really well offering great flexibility to the artist and if one applies knowledge and creativility such issues as above can be solved.

The author of this video shows a great example of such creativity to solve issues of repeating pattern.

Cycles suffer from the same issue with default toolset.

But it offers option to drive texture mapping nodes and allows to create this nodes network so we can create custom solutions/tools.

There are other approaches how to solve this or other issues with nodes but the point is that render engine gives such opportunity to the artist to solve his own creative issues.

Please consider making LuxCore more flexible and expose more parameters the artist can use to do his creative work.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Dade916]

The "right" solution to this problem is "Procedural stochastic texturing" #228. I was planning to do it in v2.4 but it will probably end in v2.5.

[AlexeyAdamitsky]

Thank you for the link. It really looks like a solid solution to what I usually need to solve as explained above and it is definitely will be great to see implemented in LuxCore.

Still I believe exposing more node's parameters and support the requested functionality I described above could be helpful for non-trivial tasks. But I understand there are most likely priorities in the development and time constraints.

It would be nice if you could consider it though. Thanks.

[Theverat]

The "right" solution to this problem is "Procedural stochastic texturing" #228.

This would only solve the one particular example problem here (covering up tiling issues).
However, texturable transformation properties would allow much more. The ability to distort the transformation of one texture with any(!) other texture tree is extremely powerful.

However, I can understand if you don't want to rework the existing textures to support this.
I was planning to support it for the Cycles procedural textures when they are ported (#244), and probably also for image textures at that point.

[Dade916]

It is always the same problem: it would automatically transform any texture using mapping in a recursive texture. It would be horrible performance wise on GPUs (instead, trivial to do on CPUs).

In general, using procedural textures on GPUs is an extremely bad idea.

[Theverat]

Can we, in general, make textures recursive only "on demand"?
For example, if a checker texture uses only constfloat3 textures as input colors, make it non-recursive to avoid the interpreter cost, and only make it recursive if other textures are used as inputs?

[Dade916]

It is possible but, under hood, we would have to duplicate all texture implementations: a normal and a recursive implementation.

[FarbigeWelt]

•If recursive textures are not any issue for CPU then why not process the whole textured surface first on CPU and use this resulting texture for the rendering on GPU like today as a bitmap texture?
•Resolution of this texture could also be processed depending on z-distance to save processing time and GPU memory.

•Sure one has to consider any zooming effects by convex lenses or mirrors to process an adequate resolution.
•Considering mirrors is also important if they make hidden textured surfaces visible, like a cube’s back side in front viewing at a mirror behind the cube.