In the binary images forum there has recently been discussion related to 
triangles and meshes as sprite surfaces representing plants.

https://news.povray.org/povray.binaries.images/thread/%3Cweb.654efeced2ab8e2ef22cdb33dabc9342%40news.povray.org%3E/

I've had on my yuqk to do list a partly finished triangle / 
smooth_triangle sample scene / test case. Scene file and image attached. 
The scene file in this case runs back to v3.7 so long as the version 
gets set on the command line with +mv3.7 or +mv3.8.

In the image there are six columns. Left two are v3.7. Middle two 
v3.8b2. Right two yuqk.

The top two rows are just triangle{}s and the ccw or cw order relative 
to the incoming ray (the camera ray here) in which the corners are 
specified sets the surface normal direction. The ccw order points back 
toward the 'z' ortho camera.

For the triangles there is always both an texture and an 
interior_texture specified with an emission 1.0 finish.

The middle two rows are smooth-triangle{}s. In the left column of each 
column pair the specified normals all point back at the camera. In the 
right column of each column pair the specified normals all point away 
from the camera. If normals are specified, it looks like the corner 
order specification does not matter.

The bottom two rows are an open question for me. These rows are 
duplicates of the middle two rows except I invert one (or it can be two) 
of the normals. This does cause a degenerate triangle warning, but I 
suddenly get a black result - why the latter? My naive thought is if bad 
normals are the reason for the degenerate condition, the normals should 
all be ignored and the ccw or cw order used instead. I think we should 
get the interior or exterior texture no matter how mangled the normals.

Bill P.

---
Aside (1) not directly triangle related, but shown in the scene file:

The sample scene has some stuff in it related to open questions about 
finish{} texture updates - applying to pigment{}, normal{} updates too.

One of the cool things about the original Scene Description Language 
(SDL) approach was that more often we could update aspects of already 
defined things.

With an object's texture, if in some later placement / use, we want to 
tweak the finish we just write:

object { Widget12 finish { ... } translate ToMoon }

However, when the interior_texture{} capability was introduced, this 
sort of blind update capability of an aspect of the object's original 
interior_texture was not implemented.

The only way to make a 'partial' interior_texture{} update to a 
particular instance of something with an interior_texture{} is to 
re-specify the entire interior_texture. This method is, of course, ugly. 
Especially true if the object's texture is not accessible as a defined 
ID. There we basically have to unravel the inline interior_texture{} to 
be to replicate the whole of it, so we can update just the finish{} 
aspect.

Post a reply to this message

Attachments:
Download 'triangles.pov.txt' (2 KB) Download 'tristory.png' (2 KB)

Preview of image 'tristory.png'

William F Pokorny <ano### [at] anonymousorg> wrote:
> In the binary images forum there has recently been discussion related to
> triangles and meshes as sprite surfaces representing plants.
>
>
https://news.povray.org/povray.binaries.images/thread/%3Cweb.654efeced2ab8e2ef22cdb33dabc9342%40news.povray.org%3E/
>
> I've had on my yuqk to do list a partly finished triangle /
> smooth_triangle sample scene / test case. Scene file and image attached.
> The scene file in this case runs back to v3.7 so long as the version
> gets set on the command line with +mv3.7 or +mv3.8.
>
> In the image there are six columns. Left two are v3.7. Middle two
> v3.8b2. Right two yuqk.
>
> The top two rows are just triangle{}s and the ccw or cw order relative
> to the incoming ray (the camera ray here) in which the corners are
> specified sets the surface normal direction. The ccw order points back
> toward the 'z' ortho camera.
>
> For the triangles there is always both an texture and an
> interior_texture specified with an emission 1.0 finish.
>
> The middle two rows are smooth-triangle{}s. In the left column of each
> column pair the specified normals all point back at the camera. In the
> right column of each column pair the specified normals all point away
> from the camera. If normals are specified, it looks like the corner
> order specification does not matter.
>
> The bottom two rows are an open question for me. These rows are
> duplicates of the middle two rows except I invert one (or it can be two)
> of the normals. This does cause a degenerate triangle warning, but I
> suddenly get a black result - why the latter? My naive thought is if bad
> normals are the reason for the degenerate condition, the normals should
> all be ignored and the ccw or cw order used instead. I think we should
> get the interior or exterior texture no matter how mangled the normals.
>
> Bill P.
>
> ---
> Aside (1) not directly triangle related, but shown in the scene file:
>
> The sample scene has some stuff in it related to open questions about
> finish{} texture updates - applying to pigment{}, normal{} updates too.
>
> One of the cool things about the original Scene Description Language
> (SDL) approach was that more often we could update aspects of already
> defined things.
>
> With an object's texture, if in some later placement / use, we want to
> tweak the finish we just write:
>
> object { Widget12 finish { ... } translate ToMoon }
>
> However, when the interior_texture{} capability was introduced, this
> sort of blind update capability of an aspect of the object's original
> interior_texture was not implemented.
>
> The only way to make a 'partial' interior_texture{} update to a
> particular instance of something with an interior_texture{} is to
> re-specify the entire interior_texture. This method is, of course, ugly.
> Especially true if the object's texture is not accessible as a defined
> ID. There we basically have to unravel the inline interior_texture{} to
> be to replicate the whole of it, so we can update just the finish{}
> aspect.

Thanks' so much for all the info. I'll study the scene file for a closer look.
Mike

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> The bottom two rows are an open question for me. These rows are
> duplicates of the middle two rows except I invert one (or it can be two)
> of the normals. This does cause a degenerate triangle warning, but I
> suddenly get a black result - why the latter? My naive thought is if bad
> normals are the reason for the degenerate condition, the normals should
> all be ignored and the ccw or cw order used instead. I think we should
> get the interior or exterior texture no matter how mangled the normals.

It looks like you might be running into what I discovered here: ?

http://news.povray.org/povray.advanced-users/thread/%3Cweb.5f763c8daf8e23f91f9dae300%40news.povray.org%3E/

I'm guessing that you'll likely have to implement some debugging capability to
output or make visible the normal vectors.

If the normal vector is <0, 0, 0> does that result in a degenerate triangle?
If the normal is zero, very small, or perpendicular to the triangle surface,
wouldn't that result in a black/non-visible triangle?

You might try rendering arrows for the vertex and face normals, and show
warnings/symbols for <0, 0, 0> or <(<threshhold), (<threshhold), (<threshhold)>
normal vectors, and see what that gives you.

Rendering problematic triangles individually, and mapping the surface normals by
interpolating the vertex normals across the face might reveal something wonky
that's hard to do in any other way.

See the excellent link that TOK posted:
https://codeplea.com/triangular-interpolation


- BW

Post a reply to this message

On 11/12/23 22:09, Bald Eagle wrote:
> I'm guessing that you'll likely have to implement some debugging capability to
> output or make visible the normal vectors.

As always. Thanks for the references! Yes, related.

Yes, your debugging capability for normals. It's been on my todo list 
for a while. I plan to implement it as a special pattern so I can return 
the perturbed normals in addition to the raw normals.

I've already modified the yuqk aoi pattern to work with the full range 
-1 to +1 possible perturbed normals. I should try that now actually on 
the black ones... Ah, it didn't offer clue why things go black in the 
degenerate case - things are still black.

I'll need to do some debugging I guess.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 11/12/23 22:09, Bald Eagle wrote:
> > I'm guessing that you'll likely have to implement some debugging capability to
> > output or make visible the normal vectors.
>
> As always. Thanks for the references! Yes, related.

You're welcome.   And thanks for confirming.

> Yes, your debugging capability for normals. It's been on my todo list
> for a while. I plan to implement it as a special pattern so I can return
> the perturbed normals in addition to the raw normals.
>
> I've already modified the yuqk aoi pattern to work with the full range
> -1 to +1 possible perturbed normals. I should try that now actually on
> the black ones... Ah, it didn't offer clue why things go black in the
> degenerate case - things are still black.
>
> I'll need to do some debugging I guess.

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

https://news.povray.org/5c45e632%241%40news.povray.org

I also had a link to an external site/article, but can't find it atm.

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

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/


Speaking of functions, I just threw up my hands and gave up on converting a
"simple" shader, because trying to convert that into SDL with functions blows up
into over 1000 lines of bloated code.  As you know, there's a long list of
things that make the function parser unusable in such circumstances, so I won't
get into it .... here.   ;)

- BW

Post a reply to this message

On 11/12/23 22:36, William F Pokorny wrote:
> I've already modified the yuqk aoi pattern to work with the full range 
> -1 to +1 possible perturbed normals. I should try that now actually on 
> the black ones... Ah, it didn't offer clue why things go black in the 
> degenerate case - things are still black.
> 
> I'll need to do some debugging I guess.

Alright. What is happening is the code marks degenerate triangles with 
an internal flag setting that they are degenerate.

This flag setting gets tested during most operations including the 
ray->triangle intersection code, where it immediately returns with no 
intersections. (The bounding box intersections still happen, if those 
are active with the active bounding)

Doing this where the specified normals are the only reason it is being 
considered degenerate would be wrong for mesh inside testing - and I 
think too conservative generally. Those mesh inside tests care not a 
whit about normals, but dropping intersections will certainly create 
problems.

The complication is the mesh / mesh2 parsing is different and I'm not 
yet sure if things all work the same way there. I'll have to dig some more.

With respect to the smooth_triangle, what I've done in the yuqk fork is 
modify the code so that, where the specified normals are the reason a 
triangle is considered degenerate, we still get the warning messages 
from the parser, but the triangle degenerate flag is no longer set.

Updated image of the new behavior is attached.

Bill P.

Post a reply to this message

Attachments:
Download 'tristory.png' (2 KB)

Preview of image 'tristory.png'

On 11/13/23 08:45, William F Pokorny wrote:
> The complication is the mesh / mesh2 parsing is different and I'm not 
> yet sure if things all work the same way there. I'll have to dig some more.

It appears the mesh / mesh2 code was already working as yuqk's 
smooth_triangle was just updated to work - except there are no 
degenerate warnings for the normal cases considered degenerate by 
smooth_triangle.

Think I'll leave it as is for now. If there are many triangles people 
are going to use mesh / mesh2 anyhow.

Bill P.

Post a reply to this message

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

William F Pokorny <ano### [at] anonymousorg> wrote:

> I need to better understand the gradient calculation method(a)

> (a) There is a similar method used to calculate isosurface normals.

No ...  if you're talking about the

* FUNCTION
*
*   IsoSurface_Normal

in isosurface.cpp, in source/core/shapes,

that looks like just regular old forward-difference to calculate a function
gradient.

> > https://news.povray.org/5c45e632%241%40news.povray.org
>
> I don't remember reading that particular post - thanks.

Certainly.  I stumbled across it while trying to find one of my other posts.

- BW

Post a reply to this message