Mike Williams wrote:

> Wasn't it Hartmut Wagener who wrote:
> 
>>Mike Williams wrote:
>>
>>>Wasn't it Hartmut Wagener who wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>i have written a converter to convert from the stl-format to povray. The 
>>>>first version of this converter is now some years old, the last one is 
>>>>ready now written in java.
>>>>
>>>>But i have some problems with rendering the scenes. In binary.images you 
>>>>can see two images, the one showing the result of the rendering, the 
>>>>other showing the calculated norm-vectors that really look as they 
>>>>should be for a smooth scene.
>>>>
>>>>When gouraud-shading a 3d-scene there might be a error called 
>>>>mach-banding, but with phon-shading by interpolating the norm-vectors in 
>>>>stead of the shading-values this mach-banding should dissapear.
>>>>
>>>>But you can see that some triangles are not calculated smooth. I can 
>>>>post the stl-file (shortened) and the java-prog for examination, perhaps 
>>>>it is my fault and i am not able to see it ...
>>>>
>>>>The problems appear in all of my stl2pov-versions, not only in the new 
>>>>java-version ...
>>>
>>>
>>>Although the displayed calculated normal vectors look as if they're
>>>pointing in roughly the correct directions, I suspect that they might
>>>not be exactly correct.
>>>
>>>In particular, I suspect that some of the vertices have slightly
>>>different normals in each of the smooth triangles they are used in. This
>>>sort of thing can happen if you're calculating the normals one triangle
>>>at a time. When I do this sort of thing, I now calculate the normals for
>>>each of the vertices first and store them in an array.
>>>
>>
>>The problem is the thing Slime mentioned in the p.b.images-section.
>>The CAD-software creates stl-files containing triangles. In the past the 
>>software creates almost triangles and some quads. Now these quads are 
>>splitted in to two triangles.
>>There are two possible solutions to split a "normal" quad in to two 
>>triangles. In most cases you don't have to care what solution is used to 
>>split. But in some cases, the one solution produces two triangles of 
>>almost the same size and the other solution creates two triangles, one 
>>of them very small and the other very big.
>>The last solution is not good for smooth shading.
>>To avoid this i have to find these triangles and transform them to the 
>>other splitting-solution. Hugh, that is much work to do ...
> 
> 
> It shouldn't be necessary to change the triangulation, but what you need
> to do is change the way you calculate the normals.
> 
> I guess that you currently calculate the normals by looking at the
> positions of some nearby vertices. In the case of the thin triangles,
> the closeness of one of those vertices is causing the problem. You end
> up with most of the curvature happening in the thin triangles and the
> normal triangles end up being too flat.
> 
> What you might be able to do is to add a check to see if any of the
> points you are using to calculate the normal is within a certain minimum
> distance from the vertex you are calculating the normal for. If it is
> too close, then use another point further away. This might lead to the
> thin triangles becoming a little too flat, but that's going to look a
> lot better than having the large triangles being too flat.
> 

I am not calcualating the normals for the triangles, they are given by 
the stl-output. I only normalize them (length 1) if neccessary. What i 
do is to interpolate the normals for the endpoints of the triangles.
Perhaps i can use a weighting depending on the distance of the 
endpoints. This weighting should only be used if the distances of points 
differ a lot. Hugh, thats hard ...
But i think that the small triangles and the given normals are bad 
calculated by the cad-software.
I will have some checks on that by calculating the normals by my own and 
comparing them with the given normals ...

Thanks

Hartmut

Post a reply to this message