POV-Ray : Newsgroups : povray.beta-test.binaries : Function / pattern issues. Adding f_granite23,... Server Time
24 Apr 2024 21:03:14 EDT (-0400)
  Function / pattern issues. Adding f_granite23,... (Message 1 to 1 of 1)  
From: William F Pokorny
Subject: Function / pattern issues. Adding f_granite23,...
Date: 19 Apr 2020 18:18:01
Message: <5e9cce19@news.povray.org>
<---------------------- References. See four additional previous posts

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

and

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


Adding four more inbuilt functions in f_granite23, f_mult1to8pairs, 
f_max1to8pairs and f_min1to8pairs.

The f_max1to8pairs and f_min1to8pairs are what they are, both with the 
ability to take the min or max of all the pair results before returning.

The central aim of f_mult1to8pairs is better intersection and difference 
capability for isosurfaces.

The inbuilt f_mult1to8pairs does regular multiplication as a mode too. 
It also takes the min or max of all pair results before exit. It has a 
second regular multiplication mode which takes the square root of the 
results prior to the min/max on return.

The default mode is a specialized multiplication where only negative 
times a negative value returns a negative result while all other 
combinations return positive values. A square root of all the multiplied 
values is done ahead of the min/max before return.

The square root helps with the gradients - which are often bad after 
multiplication. The main goal is to better normalize the resultant 
values to the shape's incoming values. If we work out a nice pattern 
displacement on shape A, we'd like it to track well in effect to the 
multiplied shape A * shape B (intersection) result, for example.


---
In the image Story1to8.png :

row A - min is essentially a merge of the original spheres.
row B - max is an collection of intersections
row C - simple multiplication is a, not very useful to isosurfaces, xor.

Multiplying two 'shapes' today isn't often useful as the shape value 
result is basically an xor - with bad gradients. If a bounding shape is 
used to cut away the surface so the xor -1,-1 regions are visible as in 
row02, you can create interesting structures.

row D - New neg * neg multiply and we get a worse than max looking result.

It's worse because the values at the surface are very small and the 
isosurface solver result is somewhat unstable.

row E - Burns off the tiny values with a tiny positive adder.

Currently, this addition is done outside of f_mult1to8pairs. It's not a 
universal, smooth sharp seams, solution. If the incoming shapes in the 
pair have sharp parts, the burn off does nothing but push the surface 
inward a little. If the 'intersection' of shapes expose, or create, a 
surface deep within the negative values of one or both, the small value 
burn off no longer works or works less well.

row F - A neg * -(neg) shape multiply gives us a difference mechanism.

A difference mechanism with the same tiny value surface burn off 
capability.  An example using this technique was posted to p.b.i 
recently where the two input functions were text hard_object pattern based.

In the row F image an output of the new f_granite23 function acts as the 
-(neg) shape / differencing shape on the left. On the right we do a 
difference(sphere,smaller_sphere).


--- f_granite23

This inbuilt function is a bit of an experiment. It's the combined noise 
2 and 3 variation except it provides 6 post granite modifiers and a 
trailing multiplier. Run with all modifiers and the multiplier at 0, the 
result is very like granite in the 0-1 range and without the apparent 
artefacts of pure noise 1, 2 or 3 - though probably there are some not 
recognized because the result is different.  Further some effort 
internally to better fill the 0-1 range - a stretch of values gets done.

The six on/off modifiers are in order: inverse, dents-treatment, 
inverse, cube root value stretch filter, inverse. Why all the inverses? 
Well the granite pattern in particular 'looks' quite different inverted.

The last argument is an internal multiplier. Perhaps obvious, but with 
functions / isosurfaces value multiplication ahead of displacement is 
different than a 1x value displacement and multiplicative scale. 
Questioning whether, perhaps, all f_<pattern> inbuilt functions should 
provide for internal multiplication / scaling rather than doing it via 
the vm.

---
In the image StoryGranite23.png :

row 0 - Eight pair multiply result with f_granite23 displacement.
row 1 - Dents pow(val,3) treatment to the granite pattern.

Looks useful to me. Should this be another general wave modifier instead...

row 2 - Applying the multiplier ahead of displacement.

Interesting to me, as shown in row 2, with isosurfaces - depending on 
the base function values you can get shapes forming perpendicular to 
simple value adder displacement. It can be hard to hit the window where 
this happens without getting too many floating pieces, but it's a cool 
result when you get it.

Bill P.


Post a reply to this message


Attachments:
Download 'story1to8.png' (281 KB) Download 'storygranite23.png' (583 KB)

Preview of image 'story1to8.png'
story1to8.png

Preview of image 'storygranite23.png'
storygranite23.png


 

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