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