![](/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) |
Le 2023-11-25 à 12:40, GioSeregni a écrit :
> "GioSeregni" <gms### [at] hotmail com> wrote:
>> "Kenneth" <kdw### [at] gmail com> wrote:
>>> "GioSeregni" <gms### [at] hotmail com> wrote:
>>>> "Bald Eagle" <cre### [at] netscape net> wrote:
>>>>>
>>>>> And if you DO see red there, then try moving the camera around, and viewing it
>>>>> from different angles - because it may just disappear and pop up in different
>>>>> areas.
>>>>
>>>> It seems that they always arise on the
>>>> perimeter of the volumes (in positions tangential to the cone of vision)...
>>>
>>> Yes, that is where those artifacts sometimes appear on a smooth-triangle object.
>>> I think it also depends on the lighting angle, and maybe even the size of the
>>> triangles.
>>>
>>> What you are seeing is a known effect of raytracing the smooth normals when they
>>> are viewed at that raking angle. (I thought that there was a short technical
>>> explanation of this in the documentation, but I cannot find it.) The camera is
>>> picking up the unlighted (black) interior of the object.
>>>
>>> If I make a low-rez height_field and add the 'smooth' keyword, the same thing
>>> happens. The interior_texture trick is one way to try and make these artifacts
>>> less noticable. Or try adding the 'double_illuminate' keyword to the object. If
>>> I recall, this was a recommended 'fix' for the problem. It seems to work most of
>>> the time, but not in every situation.
>>
>> Ok, thank! I am working on .. it does not seems by light position, but by the
>> angle between WP and smooth_triangle (s) ...
>> Many thanks again!
>> G.
> Bug hacked?
> old sprites concept? I'm under no illusions, I'll do more tests, but in this way
> I don't see the bug anymore
Even better :
interior_texture{pigment{rgbt 1}}
or
interior_texture{pigment{rgbf 1}}
That way, no need to use any image file.
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) |
Alain Martel <kua### [at] videotron ca> wrote:
> > "GioSeregni" <gms### [at] hotmail com> wrote:
> >> "Kenneth" <kdw### [at] gmail com> wrote:
> >>> "GioSeregni" <gms### [at] hotmail com> wrote:
> >>>> "Bald Eagle" <cre### [at] netscape net> wrote:
> >>>>>
> >>>>> And if you DO see red there, then try moving the camera around, and viewing it
> >>>>> from different angles - because it may just disappear and pop up in different
> >>>>> areas.
> >>>>
> >>>> It seems that they always arise on the
> >>>> perimeter of the volumes (in positions tangential to the cone of vision)...
> >>>
> >>> Yes, that is where those artifacts sometimes appear on a smooth-triangle object.
> >>> I think it also depends on the lighting angle, and maybe even the size of the
> >>> triangles.
> >>>
> >>> What you are seeing is a known effect of raytracing the smooth normals when they
> >>> are viewed at that raking angle. (I thought that there was a short technical
> >>> explanation of this in the documentation, but I cannot find it.) The camera is
> >>> picking up the unlighted (black) interior of the object.
> >>>
> >>> If I make a low-rez height_field and add the 'smooth' keyword, the same thing
> >>> happens. The interior_texture trick is one way to try and make these artifacts
> >>> less noticable. Or try adding the 'double_illuminate' keyword to the object. If
> >>> I recall, this was a recommended 'fix' for the problem. It seems to work most of
> >>> the time, but not in every situation.
> >>
> >> Ok, thank! I am working on .. it does not seems by light position, but by the
> >> angle between WP and smooth_triangle (s) ...
> >> Many thanks again!
> >> G.
> > Bug hacked?
> > old sprites concept? I'm under no illusions, I'll do more tests, but in this way
> > I don't see the bug anymore
>
> Even better :
> interior_texture{pigment{rgbt 1}}
> or
> interior_texture{pigment{rgbf 1}}
>
> That way, no need to use any image file.
Well , I will check... anyway the gif image is only a transparence...
but I call the object twice, swapping inside/outside
Do you mean the same thing? To understand I would have to see your code on
pigments
TX!
G.
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) |
"GioSeregni" <gms### [at] hotmail com> wrote:
> Bug hacked?
> old sprites concept? I'm under no illusions, I'll do more tests, but in
> this way I don't see the bug anymore
Using a transparent texture like that is very clever! However, it actually
*removes* the offending triangles... that is, it makes them invisible (if that
matters.) I had to test it to see. You might want to examine your renders to see
if that happened.
The attached image is my height_field again; close-ups are on the right side:
A-- the artifacts
B-- with interior_texture{pigment{rgbt 1}}. The artifact triangles are
missing (invisible).
C-- with interior_texture{-- same as exterior--}
but with finish{--ambient or emission value--} to try to match it.
The triangles are visible.
The scheme of using the same interior_texture as the outer one still looks
better, to my eyes.
[code taken from your image]
object{GO
interior_texture{pigment{rgb...}...
texture{pigment{image_map{gif "transp_GIF".gif... [or pigment{rgbt 1} ]
Although this scheme might appear to work for your model, it has a problem: The
interior_texture is the 'real' one, but it does not respond to the usual
'exterior' lighting in a scene because it is actually on the INSIDE surface of
the mesh. Only ambient or emission in its finish{...} is of any use, which does
not look very good-- at least for my own height_field.
Post a reply to this message
Attachments:
Download 'artifact_comparison_kw.jpg' (129 KB)
Preview of image 'artifact_comparison_kw.jpg'
![artifact_comparison_kw.jpg](/povray.general/attachment/%3Cweb.65626f7d84c692a39b4924336e066e29%40news.povray.org%3E/artifact_comparison_kw.jpg?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) |
"Kenneth" <kdw### [at] gmail com> wrote:
> "GioSeregni" <gms### [at] hotmail com> wrote:
>
> > Bug hacked?
> > old sprites concept? I'm under no illusions, I'll do more tests, but in
> > this way I don't see the bug anymore
>
> Using a transparent texture like that is very clever! However, it actually
> *removes* the offending triangles... that is, it makes them invisible (if that
> matters.) I had to test it to see. You might want to examine your renders to see
> if that happened.
>
> The attached image is my height_field again; close-ups are on the right side:
> A-- the artifacts
> B-- with interior_texture{pigment{rgbt 1}}. The artifact triangles are
> missing (invisible).
> C-- with interior_texture{-- same as exterior--}
> but with finish{--ambient or emission value--} to try to match it.
> The triangles are visible.
>
> The scheme of using the same interior_texture as the outer one still looks
> better, to my eyes.
>
> [code taken from your image]
> object{GO
> interior_texture{pigment{rgb...}...
> texture{pigment{image_map{gif "transp_GIF".gif... [or pigment{rgbt 1} ]
>
> Although this scheme might appear to work for your model, it has a problem: The
> interior_texture is the 'real' one, but it does not respond to the usual
> 'exterior' lighting in a scene because it is actually on the INSIDE surface of
> the mesh. Only ambient or emission in its finish{...} is of any use, which does
> not look very good-- at least for my own height_field.
Unfortunately I noticed that my system still has artifacts that I didn't see.
However, I noticed that in my test models they are less evident because those on
the edges of the shape generally disappear (which I believe are faces tangential
to the vector starting from the point of view). I haven't tried playing with f
and t yet... I'll try tomorrow. Now I'm importing colors from STL to bring them
grouped onto distinct meshes
Thx!
G.
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) |
Le 2023-11-25 à 13:43, GioSeregni a écrit :
> Alain Martel <kua### [at] videotron ca> wrote:
>> Le 2023-11-25 à 12:40, GioSeregni a écrit :
>>> "GioSeregni" <gms### [at] hotmail com> wrote:
>>>> "Kenneth" <kdw### [at] gmail com> wrote:
>>>>> "GioSeregni" <gms### [at] hotmail com> wrote:
>>>>>> "Bald Eagle" <cre### [at] netscape net> wrote:
>>>>>>>
>>>>>>> And if you DO see red there, then try moving the camera around, and viewing it
>>>>>>> from different angles - because it may just disappear and pop up in different
>>>>>>> areas.
>>>>>>
>>>>>> It seems that they always arise on the
>>>>>> perimeter of the volumes (in positions tangential to the cone of vision)...
>>>>>
>>>>> Yes, that is where those artifacts sometimes appear on a smooth-triangle object.
>>>>> I think it also depends on the lighting angle, and maybe even the size of the
>>>>> triangles.
>>>>>
>>>>> What you are seeing is a known effect of raytracing the smooth normals when they
>>>>> are viewed at that raking angle. (I thought that there was a short technical
>>>>> explanation of this in the documentation, but I cannot find it.) The camera is
>>>>> picking up the unlighted (black) interior of the object.
>>>>>
>>>>> If I make a low-rez height_field and add the 'smooth' keyword, the same thing
>>>>> happens. The interior_texture trick is one way to try and make these artifacts
>>>>> less noticable. Or try adding the 'double_illuminate' keyword to the object. If
>>>>> I recall, this was a recommended 'fix' for the problem. It seems to work most of
>>>>> the time, but not in every situation.
>>>>
>>>> Ok, thank! I am working on .. it does not seems by light position, but by the
>>>> angle between WP and smooth_triangle (s) ...
>>>> Many thanks again!
>>>> G.
>>> Bug hacked?
>>> old sprites concept? I'm under no illusions, I'll do more tests, but in this way
>>> I don't see the bug anymore
>>
>> Even better :
>> interior_texture{pigment{rgbt 1}}
>> or
>> interior_texture{pigment{rgbf 1}}
>>
>> That way, no need to use any image file.
> Well , I will check... anyway the gif image is only a transparence...
> but I call the object twice, swapping inside/outside
> Do you mean the same thing? To understand I would have to see your code on
> pigments
> TX!
> G.
>
>
>
>
Just something like this :
First instance become
texture{pigment{rgbt 1}}
interior_texture{pigment{ Something }}
The other become
texture{pigment{ Something }}
interior_texture{pigment{rgbt 1}}
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) |
On 11/25/23 04:56, Kenneth wrote:
> Yes, that is where those artifacts sometimes appear on a smooth-triangle object.
> I think it also depends on the lighting angle, and maybe even the size of the
> triangles.
>
> What you are seeing is a known effect of raytracing the smooth normals when they
> are viewed at that raking angle. (I thought that there was a short technical
> explanation of this in the documentation, but I cannot find it.)
Not sure of any standard short explanation in our documentation, but you
are right there are a whole set of mesh artifacts which come down to
trying to represent smooth surfaces with patches. It's something which
happens in all tooling. Search for shadow, termination, shading, etc,
mesh artifacts with google.
Only general, 'minimization' solution I know is higher resolution
meshes, especially where there is curvature. There are lots of patching
/ artifact minimization approaches - always with trad-offs of one kind
or another.
Aside: These termination artifacts exist with other mathematical
representations of shapes too, they just tend to show up less frequently
and forcefully than with lower resolution meshes. Though, suppose, a low
resolution (accuracy) isosurface will have plenty of immediately
apparent artifacts too!
Bill P.
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) |