Here is some code that will change the behaviour of smooth-triangles:
- It will trim the triangles so the spots with inverted normals get
transparent.
- This also trims the triangles towards the light source so there will be
less shadow on triangles behind a smoothed triangle.

There is a mayor side effect:
The inside of the triangles of a mesh get transparent also...
This is no problem for 3d objects (like body-parts or a chair) but the mesh
will be more restricted in use. It could be handy to make a flag on the
mesh so that this 'feature' can be turned off for people that don't approve
on this restriction.

The calculations on a smoothed mesh will be somewhat slower but not much.
But at least by me there are not many 'side-effects' to a smoothed mesh
anymore (pun intended).

I used the Linux-standard patch tool to deliver this patch...

diff -U 3 -N -r povray-3.50a/src/mesh.cpp povray-3.50b/src/mesh.cpp
--- povray-3.50a/src/mesh.cpp   Thu Aug  1 04:30:14 2002
+++ povray-3.50b/src/mesh.cpp   Sat Aug 10 17:38:05 2002
@@ -1344,6 +1344,7 @@
 * CHANGES
 *
 *   Feb 1995 : Creation.
+*   Aug 2002 : Smooth outlines for smooth triangles
 *
 ******************************************************************************/

@@ -1367,8 +1368,41 @@

     push_entry_pointer_uv(world_dist, IPoint, uv, Object, Triangle,
Depth_Stack);
     */
-
-               push_entry_pointer(world_dist, IPoint, Object, Triangle,
Depth_Stack);
+/*
+
+   When the normal of a smooth triangle is pointing away from the current
ray
+   that point on the triangle gets invisible.
+
+*/
+
+    if (Triangle->Smooth)
+    {
+      VECTOR Normal;
+      VECTOR IMesh;
+      DBL NDot;
+
+      Assign_Vector(IMesh, IPoint);
+      if (Mesh->Trans != NULL)
+      {
+        MInvTransPoint(IMesh, IMesh, Mesh->Trans);
+      }
+
+      smooth_mesh_normal(Mesh, Normal, Triangle, IMesh);
+
+      if (Mesh->Trans != NULL)
+      {
+        MTransNormal(Normal, Normal, Mesh->Trans);
+      }
+
+      VDot(NDot, Normal, OrigRay->Direction);
+      if (NDot>0) {
+        return(false);
+      }
+    }
+/*
+*/
+
+    push_entry_pointer(world_dist, IPoint, Object, Triangle, Depth_Stack);
     return(true);
   }

Post a reply to this message

How about applying the same idea to smooth heightfields?

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:
>  How about applying the same idea to smooth heightfields?
>
It should not be very difficult... but I like some response before doing the
work... ;)

Post a reply to this message

In article <web.3d556659fa75637ea3c6bc9f0@news.povray.org>,
 "Jurjen" <jjs### [at] hotmailcom> wrote:

> Here is some code that will change the behaviour of smooth-triangles:
> - It will trim the triangles so the spots with inverted normals get
> transparent.
> - This also trims the triangles towards the light source so there will be
> less shadow on triangles behind a smoothed triangle.

I have been wondering about this as a possible solution to the inverted 
normal problem, I've just been too lazy to try it out...nice work!

Actually, the variation I was thinking was this: if the smoothed normal 
is pointing in the direction of the ray, skip that intersection *and the 
next one*, but then go on as usual. In most well-behaved meshes, this 
should have the effect of "chopping off" the areas with the bad normals 
like your patch, but still let the inside of the mesh render, leaving 
the mesh still useful for things like media.

I think your change might have another side effect: it will always let 
rays go through the entire mesh, even if the area that has the reversed 
normal is in front of an area with a correct normal. I'm not sure 
though, I haven't applied this patch to see where it goes.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
> Actually, the variation I was thinking was this: if the smoothed normal 
> is pointing in the direction of the ray, skip that intersection *and the 
> next one*, but then go on as usual. In most well-behaved meshes, this 
> should have the effect of "chopping off" the areas with the bad normals 
> like your patch, but still let the inside of the mesh render, leaving 
> the mesh still useful for things like media.

  Be aware that there's a case where both solutions give the *WRONG* result,
ie. they cause a hole in the mesh when there shouldn't be any.
  This scene demonstrates such case:

camera { location -z*4 look_at 0 }
light_source { y*10, 1 }

mesh
{ smooth_triangle
  { <0,-.5,-1><0,1,-1>, <-1,0,0><-1,1,.1>, <1,0,0><1,1,.1> }
  smooth_triangle
  { <1,0,0><1,1,.1>, <-1,0,0><-1,1,.1>, <0,.5,1><0,1,-1> }

  //double_illuminate // use this to fix the artifact
  pigment { rgb 1 }
}


-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <3d55bec5@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Be aware that there's a case where both solutions give the *WRONG* result,
> ie. they cause a hole in the mesh when there shouldn't be any.

That's why I specified "well behaved" meshes. You can't make a well 
behaved mesh with fewer than 4 triangles.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
> That's why I specified "well behaved" meshes. You can't make a well 
> behaved mesh with fewer than 4 triangles.

  Uh? I don't understand how the number of triangles affects my example.
The two triangles in my example could perfectly be part of a mesh with
a million of triangles. There would still be a hole.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

>I think your change might have another side effect: it will always let
>rays go through the entire mesh, even if the area that has the reversed
>normal is in front of an area with a correct normal. I'm not sure
>though, I haven't applied this patch to see where it goes.

My patch lets the ray through only the triangle that has the inverted
normals. The inside triangle that is behind the current one will normally
have outside pointing normals and this patch will skip that triangle also.

If there is a normal triangle behind the second one (with at least 1 normal
pointing towards the current view point) then that triangle will still be
intersected and drawn.

When all the normals of a convex part of a mesh are pointing outwards then
there should not be any holes where they shouldn't be. But when the viewer
is inside the mesh the part of it that encloses the viewer will be totally
transparent (all the normals will be pointing away from the viewer).

I think this is the best solution but I have an alternative... and wrote it
also:
When a triangle has any normals pointing away from the viewer rotate these
normals towards the viewpoint till they are at an 90 degrees angle (can be
done with 2 VCross functions). This can only be done in the Mesh_Normal
function so it should be made aware of the ray->Direction.

But this alternative doens't provide a solution to the knive sharp shadows
around some of the triangles... these shadows are just as much of a pain to
my eyes as are the back bending normals towards the sides of the mesh.

So I choose my current patch as the best solution. I can provide the other
code if you want...

Post a reply to this message

In article <3d55d070@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Uh? I don't understand how the number of triangles affects my example.
> The two triangles in my example could perfectly be part of a mesh with
> a million of triangles. There would still be a hole.

Ok, I see what you are saying. I'm not sure that would be part of a 
"well behaved" mesh though, the normals don't match the surface 
geometry. Even double_illuminate won't always work. My solution would 
work for many cases, at least.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <web.3d563c38956bba3e2d1684350@news.povray.org>,
 "Jurjen" <jjs### [at] hotmailcom> wrote:

> When all the normals of a convex part of a mesh are pointing outwards then
> there should not be any holes where they shouldn't be. But when the viewer
> is inside the mesh the part of it that encloses the viewer will be totally
> transparent (all the normals will be pointing away from the viewer).

In the case of a transparent mesh the inside needs to be visible, that's 
the reason for my idea. It would be especially bad when media is 
involved, the ray would never leave the mesh because all intersections 
from inside are ignored.

Pseudocode:

if true-normal faces toward ray
    (ray origin is on outside)
    
    if interpolated-normal faces away from ray
        skip intersection
        (it shouldn't be visible anyway)
        
        set flag to skip next
        (it is part of the interior visible through
            the skipped intersection)
    end
else
    (ray origin is on inside, flip the normal
        directions and do the same thing as above)
end

There are a few cases where this wouldn't work, and it would require a 
"well behaved" mesh with good normals and a completely closed surface, 
but I think it would work in most cases.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message