>   The problem is that the rendering engine assumes that objects return
> the *true* normal vector for the given point in their surface. For an
object
> to render correctly, it *must* give the exact normal vector (ie. a vector
> which is exactly perpendicular to the surface at that point).

Yeah, I was thinking last night and realized what was happening internally.

So, would it be too difficult if, when doing the test to see if the normal
vector should be flipped around, instead of using the perturbed normal, it
used the actual normal? At least with smoothed triangles?

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

Slime <slm### [at] slimelandcom> wrote:
> So, would it be too difficult if, when doing the test to see if the normal
> vector should be flipped around, instead of using the perturbed normal, it
> used the actual normal? At least with smoothed triangles?

  Yes, it would be difficult with the current implementation. I have looked
at the code myself.

  Hopefully it will be fixed in pov4, as rewriting the whole engine will
allow to take into account this kind of things.

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

>   Yes, it would be difficult with the current implementation. I have
looked
> at the code myself.


Oh, alright. =)

I can't wait until the source comes out for 3.5...

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

Slime <slm### [at] slimelandcom> wrote:
>>   Yes, it would be difficult with the current implementation. I have
> looked
>> at the code myself.

> Oh, alright. =)

> I can't wait until the source comes out for 3.5...

  Of course "difficult" is not the same as "impossible".
  It should be possible to achieve the desired effect by making some ugly
hack. When I looked at the code I tried to find a clean and nice way of
doing it, but due to the structure of the code I didn't find any.

  One ugly hack would be making the triangle, mesh and heightfield objects
to write a flag to a global variable (forgive me for swearing in public)
stating that the normal they returned was not the true normal. The
normal-inverting code would first look at this flag, and if the flag states
that the normal was perturbed by the object itself and probably isn't the
true normal, then the code would request the true normal from the object.
Then it would make the decision whether to invert the first normal or not
according to the true normal.
  This of course causes a slight overhead in the rendering of these objects
as they will now have to return two normal vectors instead of one, but this
overhead might be irrelevant.
  Fortunately the "return the true normal" function would have to be
implemented only for these three objects, saving a lot of writing work,
I think.

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

>   Of course "difficult" is not the same as "impossible".
>   It should be possible to achieve the desired effect by making some ugly
> hack. When I looked at the code I tried to find a clean and nice way of
> doing it, but due to the structure of the code I didn't find any.


Yeah. I imagine the code that does the normal checking is just really far
separated from the code specific to height fields and meshes. It's cool,
I'll deal. =)

Actually, I'm waiting for the source code for other reasons too... for
instance, i'm *dying* to be able to create a camera through six functions of
u and v: three functions would determine the camera's position as a functoin
of u and v, and three of them determine the direction the camera is looking
in. (three functions for each in order to create an <x,y,z> vector.)

I dunno. Lots of stuff I'm excited to look into.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

3cf5654d@news.povray.org...
> Slime <slm### [at] slimelandcom> wrote:
>   Of course "difficult" is not the same as "impossible".
>   It should be possible to achieve the desired effect by making some ugly
> hack. When I looked at the code I tried to find a clean and nice way of
> doing it, but due to the structure of the code I didn't find any.

Looks like I have to post this again :

FYI, Christophe Bouffartigue has developed a patch that seems to fix the
problem for Megapov. I haven't tested it but it seems to work quite well.
You can have a look there (see the testmesh anims) and at the wpovman072 and
srcupd72 file.
http://tofbouf.free.fr/temp/


G.
--

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message