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

Christopher James Huff <chr### [at] maccom> wrote:
> 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.

  I know that *usually* you don't get normal vectors oriented like that
from any mesh creation program. However, it's not impossible, nor even
improbable that such program could produce such meshes. For example
a program which tesselates an isosurface could produce such meshes
(if it calculates the normal vectors from the function itself, as it should,
instead of just averaging triangle normals; in this case the normal vectors
are oriented according to the original isosurface, even though the triangles
are less precise due to low tesselation resolution).

> Even double_illuminate won't always work.

  double_illuminate works most of the time, but it produces serious
problems in some cases, eg. when the mesh is shadowless (in which case
*all* light sources illuminate all triangles, producing unwanted lighting).
  However, the original solution I have proposed (ie. invert the normal
vector only if the true normal vector of the surface and the returned
normal vector agree in their direction relative to the ray) works better
than double_illuminate.

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

On Sat, 10 Aug 2002 15:15:38 EDT, "Jurjen" <jjs### [at] hotmailcom>
wrote:
> Here is some code that will change the behaviour of smooth-triangles

Added to http://abx.art.pl/pov/patches/patches.php.

ABX
-- 
disc{z,-z#macro O()asc(substr("-+((1*(,1,/.-,*/(,&.323/'1"e 1))/10-4#declare
e=e-1;#end#local e=26;5pigment{#local g=function(_){ceil(_)-_}function#local
k=function{pattern{object{sphere_sweep{linear_spline 13#while(e)<O()O()>.01#
end}}}}{k(g(atan2(x,y)),g(ln(pow(x+y,2)+1e-5)),0)}}finish{ambient 1}}//ABX35

Post a reply to this message

Christopher James Huff wrote:
>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

I am willing to try and modify my patch to support this concept.
There is a some small technical problem that needs to be solved though:

There is no ordering in the set of triangles of the mesh till all the
intersections are calculated.

So my implementation will be something like:
In test_hit:

if smooth
  {calc}
  if true normal faces towards ray
    flip directions of extra normals
  end
  {calc}
  if inverted
    register call but with invalid mark
  else
    current registering call
  end
else
  current registering call
end

In the function that determines the frontmost intersections:

extra loop:

Invalid=false
do
  if Invalid
    {calculate the front intersection}
    remove intersection from list
    {calculate the front intersection}
    Invalid=false
  else
    {calculate the front intersection}
  endif
  if marked
    remove intersection from list
    Invalid=true
  end
while not Invalid


This way there is not much overhead when there are no triangles skipped.
But this routine can handle the situation where 4 triangles (2 times 2) need
to be skipped.

Post a reply to this message

On Sat, 10 Aug 2002 15:15:38 EDT, "Jurjen" <jjs### [at] hotmailcom>
wrote:
> 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.

I have incorporated this patch to PoPOV with keyword inverted_normals [on|off]
in mesh modificators. When inverted_normals is not specified then default
value for this switch is ON which means old behaviour. For inverted_normals
off new behaviour is activated.

ABX

Post a reply to this message