In an earlier post to this newsgroup:

http://news.povray.org/povray.beta-test.binaries/thread/%3C5da5ba46%40news.povray.org%3E/

I started documenting longstanding bugs and issues with VM function and 
pattern interplay. I believe as many as possible should be fixed in the 
POV-Ray v3.8 release. Documenting these bugs/issues as I do my best to 
find and fix them in my personal version of POV-Ray.

---
The internal kWaveType_Raw waveType clipka introduced with the new 
potential(1) pattern should go the whole way and be available via a new 
'raw_wave' keyword.

It's frustrating to recognition the core developers implemented 
significant infrastructure which should make creating and manipulating 
functions and isosurfaces via the pattern mechanisms easy - except often 
it falls short.

Everything exists today to code and run:


//--- FnZZ used directly in an isosurface - attached image left column
#declare VarPlaneSheetThickness = 0.01;
#declare FnZ = function (x,y,z) { z-(VarPlaneSheetThickness/2.0) }
#declare FnZ_inv = function (x,y,z) {
     -(z)-(VarPlaneSheetThickness/2.0)
}
#declare FnZZ = function (x,y,z) { max(FnZ(x,y,z),FnZ_inv(x,y,z)) }

#declare VarPlaneSheetOffset = 0.8;
#declare FnZZOffset = function {
     pattern { function { FnZZ(x,y,z) }
   //raw_wave // Without middle column, with get intended result right.
     translate <0,0,VarPlaneSheetOffset>
     turbulence 0.1
     }
}
#declare IsoPlaneZOffset = isosurface {
     function { FnZZOffset(x,y,z) }
     contained_by {
         box { <-1,-1,-0.20+VarPlaneSheetOffset>,
         <1,1,0.20+VarPlaneSheetOffset> }
     }
     threshold 0
     accuracy 0.0005
     max_gradient 1.3
     max_trace 1
     pigment { color Indigo4 }
}

but the above code doesn't work though the developers enabled the 
overall mechanisms.

The raw_wave keyword bypasses the usual pattern 'wave' modification code 
- including the code below which makes manipulating functions with the 
remaining pattern modifiers difficult(2) and very confusing.

Today one has to understand in detail how ALL the pattern wave modifiers 
work and how to hack your functions to get past the issues to use the 
warp/turbulence capability. Oh, and to use any pattern modified function 
in with other functions. It's a huge pain. Anyway, the problem code for 
many functions(3) is:

     /* allow negative frequency */
     if(value < 0.0)
         value -= floor(value);


Bill P.

(1) - Aside. I have concerns with the potential pattern for blobs and 
isosurfaces as currently implemented for v3.8. Other than perhaps being 
complete in providing an isosurface potential pattern, it doesn't make 
much sense. Most anyone will just use the function into the isosurface 
directly. Further, the keywords added code added slows all isosurfaces.
Lastly, with both blobs and isosurfaces the internal 'raw_wave' is hard 
set on - preventing the use of the wave modifiers when they could be 
used.

(2) - In the scene file provided for the thread referenced at top, it's 
why this extra, but today, necessary code :

#declare Fn00f_Tiling11_3 = function {
     pattern { function { max(0,-Fn00e_Tiling11_3(x,y,z)) } }
}

Yes, the clamping hurts the gradient and to get something a little 
better I code:

#declare Fn00_Tiling11_3 = function (x,y,z) {
     0.001-Fn00f_Tiling11_3(x,y,z)
}

instead of:

#declare Fn00_Tiling11_3 = function (x,y,z) {
     -Fn00f_Tiling11_3(x,y,z)
}

for the final isosurface function.

(3) - I have in mind an additional wave modifier keyword - 
function_wave(?) - which bypasses only the problem code. Not yet worked 
on it in detail. Aiming to allow most (or all) the existing wave 
modifiers with it. Excepting of course the new raw_wave one which just 
bails on that code.

Post a reply to this message

Attachments:
Download 'raw_wavekeyword.png' (28 KB)

Preview of image 'raw_wavekeyword.png'