POV-Ray : Newsgroups : povray.pov4.discussion.general : On triangle and smooth_triangle shapes. : On triangle and smooth_triangle shapes. Server Time
20 May 2024 06:57:01 EDT (-0400)
  On triangle and smooth_triangle shapes.  
From: William F Pokorny
Date: 12 Nov 2023 21:43:57
Message: <65518d6d$1@news.povray.org>
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'
tristory.png


 

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