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

|
 |