Q:  Why are some of them sticking out and others are sticking in?
A:  That's what I'd like to know.

This is a head mesh, not terribly well-modeled I admit, subdivided three 
times, with the normals of the original faces represented by cones 
pointing in the normal direction.  The normals for the final mesh are 
not smoothed.

As you can see, the normals are not consistent, in spite of a macro that 
is supposed to be making them consistent, and which I thought was fixed 
when I announced a bug fix early this AM.

The lighting, by the way, is a bunch of jittered area lights.  I've been 
testing out ideas.

Debugging in progress...

Regards,
John

Post a reply to this message

Attachments:
Download 'painful.jpg' (23 KB)

Preview of image 'painful.jpg'

John VanSickle napsal(a):
> Q:  Why are some of them sticking out and others are sticking in?
> A:  That's what I'd like to know.
> 
> This is a head mesh, not terribly well-modeled I admit, subdivided three 
> times, with the normals of the original faces represented by cones 
> pointing in the normal direction.  The normals for the final mesh are 
> not smoothed.
> 
> As you can see, the normals are not consistent, in spite of a macro that 
> is supposed to be making them consistent, and which I thought was fixed 
> when I announced a bug fix early this AM.
> 
> The lighting, by the way, is a bunch of jittered area lights.  I've been 
> testing out ideas.
> 
> Debugging in progress...
> 
> Regards,
> John
> 
> 
> ------------------------------------------------------------------------
> 
is the original mesh consistent?

-- 
the ultimate time-killer:
+a0.0 +am2 +r9

Johnny D

Post a reply to this message

Jan Dvorak wrote:
> John VanSickle napsal:
>> Q:  Why are some of them sticking out and others are sticking in?
>> A:  That's what I'd like to know.
>>
>> This is a head mesh, not terribly well-modeled I admit, subdivided 
>> three times, with the normals of the original faces represented by 
>> cones pointing in the normal direction.  The normals for the final 
>> mesh are not smoothed.
>>
>> As you can see, the normals are not consistent, in spite of a macro 
>> that is supposed to be making them consistent, and which I thought was 
>> fixed when I announced a bug fix early this AM.
>>
>> The lighting, by the way, is a bunch of jittered area lights.  I've 
>> been testing out ideas.
>>
>> Debugging in progress...
 >
> is the original mesh consistent?

There is a macro that is supposed to force it to be consistent, whether 
it starts out that way or not.  This macro is not working.

Regards,
John

Post a reply to this message

"John VanSickle" <evi### [at] hotmailcom> wrote in message 
news:47c0a15b@news.povray.org...
> Jan Dvorak wrote:
>> John VanSickle napsal:
>>> Q:  Why are some of them sticking out and others are sticking in?
>>> A:  That's what I'd like to know.
>>>
>>> As you can see, the normals are not consistent, in spite of a macro that 
>>> is supposed to be making them consistent, and which I thought was fixed 
>>> when I announced a bug fix early this AM.
>>>
>
> There is a macro that is supposed to force it to be consistent, whether it 
> starts out that way or not.  This macro is not working.
>

Hi John,
I had a similar problem some years ago with a macro that effectively tracked 
through from one triangle to the next, making sure the normals for one lined 
up with the normals from one it had already 'corrected'.  The macro had 
problems when it encountered spurious 'invisible' triangles that had gotten 
twisted and attached to the backs of other triangles. In my case this had 
occurred around the corners of the mouth and the corners of the eyelids 
where I'd been adding in triangles and merging corners together to make it 
bend round into the inside of the mouth and eye sockets.

You're right it does look painful. :-)

It looks a bit like some sort of ancient face mask and reminds me of a piece 
of dialogue from a UK series called Blackadder:  The series is set in World 
War I where the new recruit 'Bob' explains her reason for joining the army 
and explains to Blackadder  "I wanted to see how a war was fought, so 
badly".  He responded "Well you've certainly come to the right place. A war 
hasn't been fought this badly since Olaf the hairy, king of all the vikings, 
ordered 20,000 battle helmets with the horns on the inside."

Regards,
Chris B.

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote in message 
news:47c0a83b@news.povray.org...
>
> Hi John,
> I had a similar problem some years ago with a macro that effectively 
> tracked through from one triangle to the next, making sure the normals for 
> one lined up with the normals from one it had already 'corrected'.  The 
> macro had problems when it encountered spurious 'invisible' triangles that 
> had gotten twisted and attached to the backs of other triangles.

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 modeller to fix it.

Chris B.

Post a reply to this message

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.  If there was a problem like this with the mesh there 
would be very significant subdivision artifacts.

Regards,
John

Post a reply to this message

Have you mirrored part of the mesh? For instance from left side to right 
side? My experience with Silo is that sometimes the mirrored part of the 
mesh has the normals turned inside.

Thomas

Post a reply to this message

"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. 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.

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.

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

Regards,
Chris B.

Post a reply to this message

Thomas de Groot wrote:
> Have you mirrored part of the mesh? For instance from left side to right 
> side? My experience with Silo is that sometimes the mirrored part of the 
> mesh has the normals turned inside.

I don't recall if I mirrored the mesh in the modeler, but whether the 
normals are right or not, the mesh gets passed through a POV-Ray macro 
which is supposed to correct them.  That macro is not working.

Regards,
John

Post a reply to this message

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