On 6/4/25 07:19, Kenneth wrote:
> (Although, adding triangle_wave to the function pattern*greatly*
> reduces this-- from 2000 down to 2!-- which seems to produce a similar effect to
> your 'raw' wave type. A nice discovery!)

Hi,

For all your questions, you are running into the pattern{} / pigment{} 
wrap issues I was alluding to in (4) of my response to BE/BW. I don't 
have the energy for an exhaustive guess at causes for each result you 
see. I'm sorry.

Yes! The triangle_wave is another magic bit for gradients which works 
especially well where using yuqk's 'function_interval' (-1 to +1 
wrapping) setting used for lowering the gradients.

In official releases of POV-Ray with the isosurface-adverse, pattern 
mechanism value whacking, it will make the gradient better where all 
values would otherwise be of a 0-1 saw tooth wave aimed at 0-1 *_map 
usage. As you noticed though, the values still never cross 0 to the 
negative/inside of the shape. We have to move to a somewhat positive 
threshold - which generally perverts the specified, inbuilt function's 
shape without detailed value adjustments. Just moving to a slightly 
positive threshold usually gives some result though - which can work 
depending on stuff...

I believe there are no universal solutions for the isosurface issues 
introduced by pattern{} / pigment{} wrapping of otherwise solid 
functions for isosurfaces with the official releases of POV-Ray. It's a 
complicated mess(*). The only general solutions require core code 
changes like those implemented in the yuqk fork.

Bill P.

(*) - Though a work not complete, I should mention too that the yuqk 
fork did a great deal of work to standardize the values returned by the 
inbuilt functions for a threshold of zero while also removing things 
like internal clamping / wrapping.

In other words, the official POV-Ray inbuilt functions tend to be 
one-off mathematical forms difficult (or impossible) to use in general 
ways to build more complicated isosurface functions. Inconsistent 
thresholds, thresholds which are tangled in the definition of the shape 
itself, bugs... That said, one of two inbuilt f_torus* implementations 
survived, pretty much in the form which exists in official POV-Ray - IIRC.

Post a reply to this message