Mesh objects don't like to be scaled too small: They'll tend to "leak" 
at the edges under certain lighting conditions.

Apparently, even mesh models about 1 POV unit in total size may be too 
small in this respect.

Post a reply to this message

clipka wrote:
> Mesh objects don't like to be scaled too small: They'll tend to "leak" 
> at the edges under certain lighting conditions.
> 
> Apparently, even mesh models about 1 POV unit in total size may be too 
> small in this respect.

Doesn't POV consider positions within 0.001 units of each other to be 
equivalent?  This would certainly account for that.

...Chambers

Post a reply to this message

Chambers schrieb:
>> Apparently, even mesh models about 1 POV unit in total size may be too 
>> small in this respect.
> 
> Doesn't POV consider positions within 0.001 units of each other to be 
> equivalent?  This would certainly account for that.

That would only account for part of the effect I observed.

It appears that in some semi-rare cases, not only does POV-Ray ignore 
intersections closer to 0.001(?) units from the current point, but /all/ 
intersections from the same object.

After having had a closer look at the code, I have a vague idea what's 
going on there, and if I'm right, I really think it needs fixing.


Basically, it seems that what happens is as follows:

- The mesh is tested for intersections by computing all ray-triangle 
intersections; this is done in mesh coordinate space, i.e. the triangle 
vertices are never actually transformed (which allows copies of the very 
same mesh to share the mesh data regardless of transformations, 
rotations or even scaling or shearing), but the ray origin and direction 
are subject to the inverse transformations instead before performing the 
tests. Intersections "too close" are discarded right away, with "too 
close" being 1e-6 units (in /mesh/ space!).

- This list of intersections is then traversed to identify the closest 
intersection with the whole mesh.

- To determine which of all objects is closest, this process is 
performed for all objects; if an object's closest intersection is 
farther away than an intersection with some other object already found, 
it is ignored; likewise, if an object is "too close" (being 1e-4 units 
in /global/ space), it is ignored as well.

Note the fallacy here: This process causes /all/ intersections with a 
particular object to be ignored if the /closest/ of them is "too close".

This wouldn't be a problem if intersections "too close" were already 
filtered out in the ray-mesh-intersection test, but that is not the 
case: Although a "too close" filtering is done, it (a) uses a more 
"forgiving" numeric constant, and (b) is done in a completely different 
coordinate space.


If this is really what is happening, then it means that meshes are 
generally prone to exhibit edge artifacts whenever they are not scaled 
to at least 100 times their "raw" dimensions.

Post a reply to this message

"clipka" <ano### [at] anonymousorg> schreef in bericht 
news:4aa5649c@news.povray.org...
> If this is really what is happening, then it means that meshes are 
> generally prone to exhibit edge artifacts whenever they are not scaled to 
> at least 100 times their "raw" dimensions.

That problem is probably why Poseray scales Poser figures up by (default) 
100.

Thomas

Post a reply to this message

Thomas de Groot schrieb:
> That problem is probably why Poseray scales Poser figures up by (default) 
> 100.

Well, actually I don't care anymore: /My/ version of POV-Ray now no 
longer exhibits this type of artifacts at /any/ scale :-D

(At too small scale, meshes may still fail to self-shadow, but then that 
happens to the whole mesh, not just portions near edges.)

So far I have not seen any negative effects of my patch (tested on 
roundabout 150 scenes). Individual scenes do show differences at very 
close inspection, but those scenes happen to exhibit differences between 
3.6 and 3.7 anyway, and the patch actually seems to get the results back 
closer to the 3.6 results.

Post a reply to this message

Chambers <Ben### [at] gmailcom> wrote:

> Doesn't POV consider positions within 0.001 units of each other to be
> equivalent?  This would certainly account for that.
>

If so, that's big news (to me, anyway.)  From what does such a relatively large
value arise? I had always assumed--not having read anything to the contrary in
the docs or elsehere--that positional accuracy, as well as most everything else
in POV-Ray, would be down around the limit of its floating-point accuracy.
..00000000001 or something similar. I'm honestly surprised by this new info; it
may explain some oddities that I've seen in scenes over the years.

But in making meshes (hi-rez heightfields) from functions, using shapes.inc (or
rather, my own modified version, to get even higher rez) I haven't *seen* any
mesh anomalies, even looking close-up at a 1-unit-scaled HF. The function
pattern reproduces with great detail--down 'below' this .001 limitation, as far
as I can tell.

However, I *have* seen a scaling problem when making an ISOSURFACE from a
function pattern; scaled to about .01 units, the isosurface starts losing some
of its detail (and lowering the isosurface accuracy only helps that to a
certain degree.) Though this is probably off-topic from what clipka is talking
about.

But in general, I do agree about the scaling problem. (I generally scale objects
to at least 10 units, to try and eliminate any odd artifacts.)  From experience,
I've always wondered if POV's default '1-unit' is actually at the *correct
place* within the range of its in-built numerical values. I.e., moving it to 10
or 100 instead (but still calling it '1-unit', of course!)

Ken

Post a reply to this message