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


Hartmut Wagener

Post a reply to this message

The problem is simple. Even though the triangles' normals have their part in
the lighting calculations, the entire triangle has a distinct angle in which
it is positioned in regard to the lightsource. And triangles still throw
straight shadows, so even if they are "smooth-curved" you'll get shadows
unterneath the triangles. See here:
http://tag.povray.org/povQandT/TheShadowLineArtifact/index.html

What you'd need to do is raise the resolution of the mesh, and maybe use a
true area-light (with "true" meaning several point lightsources, not the
area_light feature of POV-Ray: it only calculates smooth shadows, not smooth
lighting).

Regards,
Tim
-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>

Post a reply to this message

Tim Nikias <JUSTTHELOWERCASE:timISNOTnikias(at)gmx.netWARE> wrote:
> What you'd need to do is raise the resolution of the mesh, and maybe use a
> true area-light (with "true" meaning several point lightsources

  In which way that's a "true" area light?-)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

>   In which way that's a "true" area light?-)

Oh, you nitpicking backstabbing... :-P

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>

Post a reply to this message

Tim Nikias wrote:

> The problem is simple. Even though the triangles' normals have their part in
> the lighting calculations, the entire triangle has a distinct angle in which
> it is positioned in regard to the lightsource. And triangles still throw
> straight shadows, so even if they are "smooth-curved" you'll get shadows
> unterneath the triangles. See here:
> http://tag.povray.org/povQandT/TheShadowLineArtifact/index.html
> 
> What you'd need to do is raise the resolution of the mesh, and maybe use a
> true area-light (with "true" meaning several point lightsources, not the
> area_light feature of POV-Ray: it only calculates smooth shadows, not smooth
> lighting).
> 
> Regards,
> Tim

A fine idea, but thats not the solution. You can put the lightsources 
where you like and still get these results.

But i think i have found the reason for this. It seems to be a bad 
stl-output out of the cad-program. I can post a zoomed picture tommorow 
and show the triangles the cad-program produces in these parts. Awful ... :)
I will try an other stl-output with a newer version and perhaps other 
options, but this can take time, i don't have the dongle available today ...

Hartmut

Post a reply to this message

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.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

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

Hartmut

Post a reply to this message

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.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

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

Hartmut Wagener wrote:

> 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

See if PoseRay may be of help to you. It can calculate normals by direct 
averaging and area weighted. If the software you are using exports in 
3DS, OBJ, DXF, RAW or LWO PoseRay may be able to read it. You will also 
have control on the threshold angle and what regions to smooth.

PoseRay home:
http://user.txcyber.com/~sgalls/

later,

FlyerX

Post a reply to this message