POV-Ray : Newsgroups : povray.pov4.discussion.general : On triangle and smooth_triangle shapes. : Re: On triangle and smooth_triangle shapes. Server Time
27 Feb 2024 16:18:28 EST (-0500)
  Re: On triangle and smooth_triangle shapes.  
From: William F Pokorny
Date: 14 Nov 2023 06:45:14
Message: <65535dca$1@news.povray.org>
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 

> Also reminds me of the problem I still have to solve/work-around here:

I should get back to some of these ideas once in a while :-).

Bill P.

Post a reply to this message

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