4d procedural textures for cycles (without OSL)
It's often useful to animate a texture through time as well as the usual space dimensions in order to create a morphing 3D volume (e.g. clouds).
It's currently
possible to create such a 4D texture with OSL
, however this means that it cannot be used in GPU render.
A 4th dimension "time" is needed, as animating 3D coordinates results in an obvious sliding effect when viewed in 3D:
With an extra dimension to be animated, the whole texture will appear to morph seamlessly in 3D without any appearance of sliding or moving (in much the same way as the 3D texture morphs on the 2D face in the gif above):
This would of course be even more visible with volumetric shaders.
As far as I know, 4D versions of the existing textures would be able to do exactly what the current 3D versions do now. If that's true, then it makes sense to me to replace all the current 3D textures with 4D equivalents, adding a "time" variable which is exposed in the node, similar to the OSL node in this screenshot:
6 Comments
Actually the BI textures also need 4D - that is something I've been waiting for a long time now. With 4D you could for example create a force field that actually evolves. And 4D is really handy whenever you do volumetric effects.
Perhaps its a stupid question, but can't you just keyframe (or uses a driver on) a mapping offset? This is a pretty common practice in BI; I'm pretty sure it's also possible in Cycles.
No, as it's quite apparent the texture is moving in a direction (or just rotating). See the SE question linked above for some gifs
In which case, where would the controls be best placed in the material node editor? Would they be built into applicable texture nodes? Or would you have a way to map time variables some other way?
I kind of imagined having an extra "time" variable on all procedural texture nodes. In other words, replace the existing 3D procedural textures with 4D textures.
AFAIK 3D textures don't have any advantages over 4D textures; anything you can do with 3D should be possible with 4D.
I'd be curious to know how much overhead, if any, that 4D textures introduce... be it in code maintenance, system complexity, or kernel size. I don't think it'd be a blocker in any case, but it would be nice to quantify that.