POV-Ray : Newsgroups : povray.bugreports : bump maps inverted in spherical warp : Re: bump maps inverted in spherical warp Server Time
25 Sep 2022 10:23:52 EDT (-0400)
  Re: bump maps inverted in spherical warp  
From: clipka
Date: 6 Aug 2021 07:35:59
Message: <610d1e9f$1@news.povray.org>
Am 06.08.2021 um 02:20 schrieb William F Pokorny:

> If I comment that last warp{}, and un-comment two warp{}s above - or use 
> instead the plain pigment inside the texture with the warp{}, I get no 
> complaint about any 'pointless' warps(a) - though some of them certainly 
> are.

The primary reason is that textures - in general - are nothing but mere 
containers to bundle pigments, finishes and normal perturbations into a 
coherent unit. As such, they provide no functionality of their own.

Specifically, they have no "hook" built into them to plug a warp into.

Exceptions to the rule are patterned and layered textures, which both 
add extra functionality of their own. And patterned textures do provide 
a "hook" for a warp to plug into.

Yes, in theory we could have non-patterned textures propagate any warps 
to their pigments, finishes and normals. We mustn't do that for 
patterned textures though. Also, what should happen if the pigment, 
finish or normal already has a warp? Should the texture warp be ignored, 
appended, prepended, or override the pigment/finish/normal warp? What 
should happen in this context to things that may or may not be converted 
into warps under the hood, such as turbulence?

It would also mean that we'd have to add room for extra data to the 
generic texture data structure, at least during parsing, because we 
can't propagate the warp before the scene has been fully assembled: The 
texture could be re-used someplace else and the pigment replaced with a 
different one, for instance, in which case that new one would also have 
to have the warp propagated to it.
And currently we're using the same data structures for both parsing and 
rendering, so any extra memory we reserve for the parsing step is also 
memory that will be unavailable during the render proper for other 
stuff, such as storing image data, radiosity samples, photon maps and 
the like. It would also be unused memory sitting right in the middle of 
other data we might need frequently, potentially displacing useful data 
from the CPU caches and thus maybe even dragging down performance.

TL;DR: I think there are too many worms in that can to open it up 
without need.

Post a reply to this message

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.