POV-Ray : Newsgroups : povray.binaries.images : Looks painful (23kbbu) : Re: Looks painful (23kbbu) Server Time
1 Aug 2024 22:18:39 EDT (-0400)
  Re: Looks painful (23kbbu)  
From: John VanSickle
Date: 24 Feb 2008 14:01:11
Message: <47c1bef7$1@news.povray.org>
Chris B wrote:
> "John VanSickle" <evi### [at] hotmailcom> wrote in message 
> news:47c0e4c4@news.povray.org...
>> Chris B wrote:
>>
>>> Oh and, just in case your problem is similar, I really should have 
>>> mentioned the way I fixed it ...
>>>
>>> In my macro I added a check to detect where any more than two triangles 
>>> shared an edge, then added a cylinder object to highlight that edge, so 
>>> that, when I rendered in POV-Ray I could see where the problem in the 
>>> mesh was and I could go back into the modeler to fix it.
>> My modeler won't allow more than two faces to share an edge, so that's not 
>> the issue.
> 
> The modeller may not consider them shared, but I'd be suprised if it 
> prevented the edge of one pair of faces from becoming coincident with the 
> edge of another pair of faces.

The object which tracks edges has only two fields that reference the 
border faces.  The function that creates faces will not create them if 
one of the required edges already has two faces bordering on it.  This 
same function will not create an edge between two vertices if an edge 
already exists.  There is yet another function which identifies 
redundant edges and eliminates them.

> It may record internally that these are not 
> adjoining faces, but I think such information would be lost when 
> exporting/converting to POV-Ray format. If the macro you use runs after 
> you've converted to POV-Ray format then it may still be a possibile 
> explanation.

Another macro in the set builds the entire set of edges from the 
face-vertex array; only sharp edges are exported from the modeler, and 
this model had no sharp edges.  The arrays that specify the edge data 
store data for only two bordering faces.

> Of course, if the macro is not building it's own map of which faces join 
> together, for example if it's inside the modeller and has access to the 
> information about which faces join, then it would rule this potential 
> explanation out.

I also added a diagnostic loop to count the number of faces bordering on 
each edge.  The check showed that no edge has more than two faces.

>> If there was a problem like this with the mesh there would be very 
>> significant subdivision artifacts.
> 
> I'm not sure that it would generate anything that would look particularly 
> significant either in the modeller or in POV-Ray. When I got this problem 
> there was nothing visible or distinctive in either. Subdivision just gives 
> you more triangles within the existing triangles. If the original triangles 
> look fine, then the subdivided ones look equally fine.

The mesh is subdividing consistently, independently of the pattern of 
error in the normals, so that can't be it.

The error appears to be in the algorithm by which the normals are 
corrected.  I have an algorithm that works fine, but its efficiency 
isn't so hot.  I'm putting that one back in.

Regards,
John


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.