 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lots of people have heard about this problem... I'm not sure if it's been
heavily looked into, but there's definitely a problem with black artifacts
appearing at the edge of smooth meshes.
Anyway, I thought I'd make a formal bug report for it, in hopes that someone
might figure it out and fix it. The following scene, consisting of a mesh
with a single triangle, displays the problem:
camera {
location <0,3,-3>
look_at 0
}
light_source {
<-1,1,-1>*9999
rgb 1
}
mesh2 {
vertex_vectors {
3,
-x,x,3*z
}
normal_vectors {
3,
y,y,y+z // last normal points away from camera, but not *directly* away
}
face_indices {
1,
<0,1,2>
}
texture {
pigment {rgb 1}
}
}
Pictures will be posted momentarily in p.b-t.b.
RC5, WinXP, 900mhz P3 (i think), 256MB RAM
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3cf448cd@news.povray.org> , "Slime" <slm### [at] slimeland com> wrote:
> Lots of people have heard about this problem... I'm not sure if it's been
> heavily looked into, but there's definitely a problem with black artifacts
> appearing at the edge of smooth meshes.
Sorry, but RTFM for double_illuminate!
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Sorry, but RTFM for double_illuminate!
I was under the impression that double_illuminate was merely a workaround.
It looks to me like there's something physically unrealistic here that
deserves some attention. If it's not going to be fixed before the 3.5
release, then that's alright, but if it *is* a bug, then it should at least
be recognized as so.
In the meantime, thanks for the tip.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3cf47cbf@news.povray.org> , "Slime" <slm### [at] slimelandcom> wrote:
> I was under the impression that double_illuminate was merely a workaround.
> It looks to me like there's something physically unrealistic here that
> deserves some attention. If it's not going to be fixed before the 3.5
> release, then that's alright, but if it *is* a bug, then it should at least
> be recognized as so.
No, you simply create a normal vector that point in the wrong direction.
POV-Ray allows you to specify any garbage as normal vector while normal
modeling software usually protects you from creating such garbage.
Add this to your scene to see the normal vectors. To help you see the problem
with the normal vector there is a small yellow "vector" that is perpendicular
to the blue "vector":
cylinder
{
-x, -x + y, 0.1
texture {
pigment {red 1}
}
}
cylinder
{
x, x + y, 0.1
texture {
pigment {green 1}
}
}
cylinder
{
3*z, 3*z + y+z, 0.1
texture {
pigment {blue 1}
}
}
cylinder
{
3*z, 3*z + y+z, 0.025
texture {
pigment {red 1 green 1}
}
translate -3*z
rotate x*-90
translate 3*z
}
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This is the same problem I noticed some time ago. It also happens with
smooth heightfields for the exact same reason.
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).
Smooth meshes and heightfields don't do this. They return normal vectors
which are not perpendicular to the actual surface. This causes errors in the
rendering.
What happens is that when the rendering engine shoots a ray and it hits
the surface of an object, the engine asks the object "what's the normal vector
at this point in your surface?".
Now, if the angle between the returned normal vector and the ray vector
is less than 90 degrees (that is, the normal vector points away from the
point of view of the starting point of the ray), then the engine reverses
the returned normal vector. This is essential for the lighting to work
properly (if the normal is not reversed in this case, you would get all kind
of errors in lighting, ie. surfaces which are illuminated from behind when
they shouldn't, or surface which are not illuminated even though they are
facing a light source).
This assumes that the normal vector returned by the object is a *true*
normal vector, and it works perfectly when this is so.
However, if the object returns an erroneous normal vector, ie. a vector
which is not perpendicular to the surface, rendering errors can occur.
Smooth triangles and heightfields do this, and the price to pay are the
artifacts in the lighting in certain situations.
The artifact is produced when the *true* normal vector would have an angle
larger than 90 degrees with the ray, but the the actual vector returned by
the object has an angle smaller than 90 degrees with the ray.
In this case the rendering engine reverses the normal vector even though
it shouldn't. This is because it assumes that it's the true normal vector
when in fact it isn't.
You can get rid of the artifacts by making the mesh double_illuminated.
When a surface is double_illuminated, it doesn't matter which way its normal
points - it will always be illuminated regardless of which side the light
source is.
Of course it shouldn't matter that the mesh is now illuminated in both
sides. If this is a problem, then there's little we can do.
Another place where this problem can be seen is when using the slope pattern,
which also uses the normal vector to calculate the value of the pattern at
a certain point. If the normal is reversed when it shouldn't, the wrong
slope is calculated as well. double_illuminate will not fix this because it
is only related to lighting, not to patterns.
If you are having this problem in a smooth heightfield, the solution is
to mirror the color_map (or whatever map you are using) around 0.5. This way
it doesn't matter if the normal is reversed.
Perhaps I should add this text to the povQandA.
--
#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 <war### [at] tagpovrayorg> wrote:
> Perhaps I should add this text to the povQandA.
Done:
http://iki.fi/warp/povQandT/SmoothTriangleArtifact/
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
3cf4e89c@news.povray.org...
> http://iki.fi/warp/povQandT/SmoothTriangleArtifact/
You could add that the double_illuminate trick may cause bright artifacts on
the borders of the object left in shadow, even for closed meshes. They can
be quite visible too but they are also, fortunately, usually easier to fix
with a paint program than the black ones...
G.
--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
3cf47cbf@news.povray.org...
> In the meantime, thanks for the tip.
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 the wpovman072 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran <tra### [at] inapginrafr> wrote:
> You could add that the double_illuminate trick may cause bright artifacts on
> the borders of the object left in shadow, even for closed meshes.
Only if you are using no_shadow to get rid of the shadow line artifact... :P
--
#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 <war### [at] tagpovrayorg> wrote:
> Only if you are using no_shadow to get rid of the shadow line artifact... :P
I added a note about that and also added a note to the shadow line artifact
page about this artifact.
--
#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
|
|
| |
| |
|
|
|
|
| |
|
|
