|
 |
On 11/13/23 07:12, Bald Eagle wrote:
> While you're in there digging around in the normal code, perhaps you can make
> some notes about exactly HOW that all works. Normals seem to me like they'd
> need a 2D modification (theta, r) rather than just a single scalar value.
> That whole weird tetrahedron thing....
Digging again into that code is something on my list, but it's not at
the top at the moment.
I need to better understand the gradient calculation method(a) - or
replace it - to understand, for example, what is happening with that
experimental facets pattern when I set the accuracy setting really large
compared to the value region dimensions. I don't get at all why results
become smoother. I have some wild guesses(b), but they are wild. I have
longer standing questions / issues with it too with the sampling pattern.
(a) There is a similar method used to calculate isosurface normals.
(b) My up front one is that the accuracy value is getting used,
intentionally or not, to inverse scale the effect of the perturbation -
before it can be scaled with the bump_size value. In other words, there
'might be' a missing normalization of the resultant gradient value.
>
> https://news.povray.org/5c45e632%241%40news.povray.org
I don't remember reading that particular post - thanks.
I had the thought while reading it, we often are too brief when
discussing how scalar values can get to the normal{} mechanism. I have
the follow parser test case which might help as sort of a guide:
// Patterns, pigments with normals
#declare Pig = pigment { bumps }
#declare Nrm = normal { bumps }
#declare Fn0 = function { pattern { bumps } }
#declare Nr0 = normal { function { Fn0(x,y,z) } }
#declare Fn1 = function { pigment { bumps } }
#declare Nr1 = normal { function { Fn1(x,y,z).red } }
#declare Nr1 = normal { function { Fn1(x,y,z).grey } }
#declare Nr2 = normal { pigment_pattern { bumps } }
#declare Nr3 = normal { pigment_pattern { Pig } }
// The following fail today with parsing errors though perhaps
// they should not?
// #declare Nr4 = normal {
// pigment_pattern { pigment { bumps } }
// }
// #declare Nn5 = normal {
// pigment_pattern { pigment { Pig } }
// }
// #declare Nn6 = normal { pattern { bumps } }
#error "Parse test. Stopping early"
As a guide for POV-Ray proper would need an example overriding the
default pattern color_maps. The yuqk for doesn't have default color_maps
except for the block patterns).
>
> I also had a link to an external site/article, but can't find it atm.
If it's the one you gave me, I have it somewhere in your folder.
>
> A useful pattern would be something that would allow a function to return the
> normal as a vector (and doesn't require the prior existence of an object surface
> to work).
The special pattern(s) I have in mind to implement will certainly be
returning vectors. Specifically three 21 bit floats in the double scalar
value return space - something which will work with today's pattern
mechanism.
>
> Also reminds me of the problem I still have to solve/work-around here:
>
https://news.povray.org/povray.unofficial.patches/thread/%3C60a268da%241%40news.povray.org%3E/
I should get back to some of these ideas once in a while :-).
Bill P.
Post a reply to this message
|
|
