POV-Ray : Newsgroups : povray.beta-test.binaries : Function / pattern issues. Adding f_granite23,... Server Time 8 Aug 2024 16:58:09 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>
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#5e9cce19%40news.povray.org",
"headline": "Function \/ pattern issues. Adding f_granite23,...",
"dateCreated": "2020-04-19T22:18:01+00:00",
"datePublished": "2020-04-19T22:18:01+00:00",
"author": {
"@type": "Person",
"name": "William F Pokorny"
}
}
<---------------------- References. See four additional previous posts

and

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.
```

Attachments: