 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello
I use this code to produce the body of a rocket :
#declare forme = sor { 16,
<0.0005,-6>,
<1.0,-4>,
<1.01,-2>,
<1.15,0>,
<1.35,2>,
<1.55,4>,
<1.69,6>,
<1.8,8>,
<1.89,10>,
<1.925,12>,
<1.79,14>,
<1.5,16>,
<0.99,18>,
<0.175,20>,
<0.07,20.1>
<0.0005,23>
hollow
}
later restricted to the sections of interest by various "difference" with
co-axial cylinders in CSG operations, but this makes no ... difference.
When textured with :
#declare txtr = texture { pigment { color Red }
finish { ambient 0.05 diffuse 0.8 }
}
I get strange results, with the object beeing usually OK, but, for some
orientations and distances to the observer, full of "semi-random" holes
(perpendicular to the axis of the SOR), shape errors, and granite-like black
imperfections.
Which parameter is wrong ?
I set :
global_settings { max_trace_level 256 assumed_gamma 1.0 }
Thanks !
Gilles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 22/07/2011 10:27, 43oasis nous fit lire :
> Hello
>
> I use this code to produce the body of a rocket :
>
> #declare forme = sor { 16,
> <0.0005,-6>,
> <1.0,-4>,
> <1.01,-2>,
> <1.15,0>,
> <1.35,2>,
> <1.55,4>,
> <1.69,6>,
> <1.8,8>,
> <1.89,10>,
> <1.925,12>,
> <1.79,14>,
> <1.5,16>,
> <0.99,18>,
> <0.175,20>,
> <0.07,20.1>
> <0.0005,23>
> hollow
> }
> later restricted to the sections of interest by various "difference" with
> co-axial cylinders in CSG operations, but this makes no ... difference.
>
> When textured with :
>
> #declare txtr = texture { pigment { color Red }
> finish { ambient 0.05 diffuse 0.8 }
> }
>
> I get strange results, with the object beeing usually OK, but, for some
> orientations and distances to the observer, full of "semi-random" holes
> (perpendicular to the axis of the SOR), shape errors, and granite-like black
> imperfections.
>
> Which parameter is wrong ?
> I set :
> global_settings { max_trace_level 256 assumed_gamma 1.0 }
Sor documentation:
>
http://wiki.povray.org/content/Documentation:Reference_Section_4.1#Surface_of_Revolution
have you tried to add "sturm" before "hollow" ?
what and where is your camera ? your light sources ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <jgr### [at] free fr> wrote:
> Le 22/07/2011 10:27, 43oasis nous fit lire :
> > Hello
> >
> > I use this code to produce the body of a rocket :
> >
> > #declare forme = sor { 16,
> > <0.0005,-6>,
> > <1.0,-4>,
> > <1.01,-2>,
> > <1.15,0>,
> > <1.35,2>,
> > <1.55,4>,
> > <1.69,6>,
> > <1.8,8>,
> > <1.89,10>,
> > <1.925,12>,
> > <1.79,14>,
> > <1.5,16>,
> > <0.99,18>,
> > <0.175,20>,
> > <0.07,20.1>
> > <0.0005,23>
> > hollow
> > }
> > later restricted to the sections of interest by various "difference" with
> > co-axial cylinders in CSG operations, but this makes no ... difference.
> >
> > When textured with :
> >
> > #declare txtr = texture { pigment { color Red }
> > finish { ambient 0.05 diffuse 0.8 }
> > }
> >
> > I get strange results, with the object beeing usually OK, but, for some
> > orientations and distances to the observer, full of "semi-random" holes
> > (perpendicular to the axis of the SOR), shape errors, and granite-like black
> > imperfections.
> >
> > Which parameter is wrong ?
> > I set :
> > global_settings { max_trace_level 256 assumed_gamma 1.0 }
>
> Sor documentation:
> >
http://wiki.povray.org/content/Documentation:Reference_Section_4.1#Surface_of_Revolution
>
> have you tried to add "sturm" before "hollow" ?
>
> what and where is your camera ? your light sources ?
Ah, interesting : by adding the "sturm" specification (more precise maths), I
remove almost all the black defects, leaving mainly the shape errors.
I removed the "hollow", which I do not use in fact ; no difference.
Here is the camera and lightsource specs :
.....
#declare Position = (1-klok)*100*<100,15,80> - 10*<120,7,50>;
// Part of an animation, 0<=klok<=2 ; the effect occur around klok = 1.06.
// That is Position = <-1776.4413,-156.4662,-961.1530>
// This is where the SOR is translated in my scene
.....
camera {
#declare xS = 0;
#declare yS = 1;
#declare zS = 0;
up <xS,yS,zS>
right x*image_width/image_height
angle 1
location <0,0,-2000>
look_at (Position - 9*x)
}
.....
light_source { // far enough to avoid problems ...
0
color White
translate <20000, 30000, -10000>
}
For zCam <= -1958.5 or zCam >= 2003.5, all the defects in my scene (where there
are other SORs, affected by the same problem) are gone.
Gilles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
43oasis <43o### [at] orangefr> wrote:
> I use this code to produce the body of a rocket :
> #declare forme = sor { 16,
If you are having rendering artifacts with the sor object (which you can't
get rid of even with 'sturm'), one possibility is to use a mesh instead.
As an additional bonus, the mesh might even render faster.
Incidentally, there's a macro at lib.povray.org for that exact purpose
(ie. to create a mesh in the shape of a surface of revolution from a spline).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> 43oasis <43o### [at] orangefr> wrote:
> > I use this code to produce the body of a rocket :
>
> > #declare forme = sor { 16,
>
> If you are having rendering artifacts with the sor object (which you can't
> get rid of even with 'sturm'), one possibility is to use a mesh instead.
> As an additional bonus, the mesh might even render faster.
>
> Incidentally, there's a macro at lib.povray.org for that exact purpose
> (ie. to create a mesh in the shape of a surface of revolution from a spline).
>
> --
> - Warp
Thanks for this tip ; I'll try that.
I wonder how the rendering of the SOR can vary with the distance of the
observer,
and, more specifically, be wrong only within a certain interval of
distances/orientations ...
At first sight, it seems that this happen when the axis of the SOR is ~
perpendicular to the view ray, and, then, within a certain interval of observing
distances.
At first sight ...
Gilles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
43oasis <43o### [at] orangefr> wrote:
> I wonder how the rendering of the SOR can vary with the distance of the
> observer,
> and, more specifically, be wrong only within a certain interval of
> distances/orientations ...
It probably has to do with the algorithm by which it's calculated and
the limited accuracy of floating point numbers (although I can't say this
with certainty without knowing the specifics).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> camera {
>
> #declare xS = 0;
> #declare yS = 1;
> #declare zS = 0;
> up<xS,yS,zS>
> right x*image_width/image_height
>
> angle 1
> location<0,0,-2000>
> look_at (Position - 9*x)
> }
> .....
> light_source { // far enough to avoid problems ...
> 0
> color White
> translate<20000, 30000, -10000>
> }
>
> For zCam<= -1958.5 or zCam>= 2003.5, all the defects in my scene (where there
> are other SORs, affected by the same problem) are gone.
>
> Gilles
>
>
>
>
>
>
You place your camera at a large distance and use a very small angle
that effectivelt removes perspective. That, in turn, can cause
calculation errors. Those errors will cause the apearance of various
artefacts.
Try placing your camera closer and use the orthographic projection. It
effectively simulate a camera set at infinity.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <aze### [at] qwertyorg> wrote:
>
> > camera {
> >
> > #declare xS = 0;
> > #declare yS = 1;
> > #declare zS = 0;
> > up<xS,yS,zS>
> > right x*image_width/image_height
> >
> > angle 1
> > location<0,0,-2000>
> > look_at (Position - 9*x)
> > }
> > .....
> > light_source { // far enough to avoid problems ...
> > 0
> > color White
> > translate<20000, 30000, -10000>
> > }
> >
> > For zCam<= -1958.5 or zCam>= 2003.5, all the defects in my scene (where there
> > are other SORs, affected by the same problem) are gone.
> >
> > Gilles
> >
> >
> >
> >
> >
> >
>
> You place your camera at a large distance and use a very small angle
> that effectivelt removes perspective. That, in turn, can cause
> calculation errors. Those errors will cause the apearance of various
> artefacts.
>
> Try placing your camera closer and use the orthographic projection. It
> effectively simulate a camera set at infinity.
>
>
> Alain
I can imagine that (this is also a reply to Warp) floating point has a limiting
accuracy, which may be critical when you deal with infinitely thin (right ?)
surfaces like SOR.
Of course, without looking at the algorithm, one cannot say more ...
I am nevertheless slightly amazed by the fact that the defect vanish when you
move the camera closer or FARTHER from the object ...
Gilles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>
> I can imagine that (this is also a reply to Warp) floating point has a limiting
> accuracy, which may be critical when you deal with infinitely thin (right ?)
> surfaces like SOR.
> Of course, without looking at the algorithm, one cannot say more ...
> I am nevertheless slightly amazed by the fact that the defect vanish when you
> move the camera closer or FARTHER from the object ...
Such is the floating point precision... and its issues.
For instance, considers (you can translate in C if you like):
#declare AA=1/10;
#declare BB=1/2;
#declare SA=0;
#declare SB=0;
#local I=0;
#while(I<10)
#declare SA=SA+AA;
#declare SB=SB+BB;
#end
Bye now, what is the value of SB and SA ?
For instance, SB is 5.0;
But SA is not 1.0 (due to the fact that 1/10 cannot be represented
accurately in binary floating points)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Alain<aze### [at] qwertyorg> wrote:
>>
>>> camera {
>>>
>>> #declare xS = 0;
>>> #declare yS = 1;
>>> #declare zS = 0;
>>> up<xS,yS,zS>
>>> right x*image_width/image_height
>>>
>>> angle 1
>>> location<0,0,-2000>
>>> look_at (Position - 9*x)
>>> }
>>> .....
>>> light_source { // far enough to avoid problems ...
>>> 0
>>> color White
>>> translate<20000, 30000, -10000>
>>> }
>>>
>>> For zCam<= -1958.5 or zCam>= 2003.5, all the defects in my scene (where there
>>> are other SORs, affected by the same problem) are gone.
>>>
>>> Gilles
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> You place your camera at a large distance and use a very small angle
>> that effectivelt removes perspective. That, in turn, can cause
>> calculation errors. Those errors will cause the apearance of various
>> artefacts.
>>
>> Try placing your camera closer and use the orthographic projection. It
>> effectively simulate a camera set at infinity.
>>
>>
>> Alain
>
>
> I can imagine that (this is also a reply to Warp) floating point has a limiting
> accuracy, which may be critical when you deal with infinitely thin (right ?)
> surfaces like SOR.
> Of course, without looking at the algorithm, one cannot say more ...
> I am nevertheless slightly amazed by the fact that the defect vanish when you
> move the camera closer or FARTHER from the object ...
>
> Gilles
>
>
>
That's the problem with floating numbers. There are situations where
they introduce some random noise in the results, while, at other times,
you get exact results.
If you appen to work with values that can be represented exactly within
the precision available, all is well. If, at least some values can't be
represented exactly in binary, then you get rounding errors.
If you use very small values with large ones, or very large with small,
you get precision and underflow errors in addition to the rounding ones.
You can also notice that the defects will move, change or vanish totaly
if you rotate your object, or rotate the camera around it, while keeping
the same distance.
Also, in your case, if you scale the object, the result WILL change.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
