![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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'
![painful.jpg](/povray.binaries.images/attachment/%3C47c09b47%40news.povray.org%3E/painful.jpg?ttop=443866&toff=3350&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"John VanSickle" <evi### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Chris B" <nom### [at] nomail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"John VanSickle" <evi### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris B wrote:
> "John VanSickle" <evi### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |