![](/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) |
Why does this scene have artefacts on the superellipsoid?
>>>> snip >>>>
#version 3.6;
global_settings {
assumed_gamma 1
max_trace_level 25
}
light_source { <20, 100, -10>, rgb 1 }
camera {
right x*image_width/image_height
location <0, 9, -12> look_at <0, 0, 0>
}
plane {
y, 0
pigment { rgb <0.4,0.6,0.6> }
}
#declare o_Rod =
superellipsoid {
<1, 0.05>
scale <1, 1, 7>
}
object {
o_Rod
pigment { rgb 0.8 }
translate <-1, 1, 0>
rotate y*29
}
>>>> snip >>>>
Post a reply to this message
Attachments:
Download 'Test.jpg' (12 KB)
Preview of image 'Test.jpg'
![Test.jpg](/povray.binaries.images/attachment/%3C6p8nj3tckhrd1pihpofmvltqrfrs4lish8%404ax.com%3E/Test.jpg?ttop=443866&toff=3550&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) |
Forgot to add, POV-Ray for Windows version 3.6.1a
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) |
Here's the problem:
> #declare o_Rod =
> superellipsoid {
> <1, **0.05**>
> scale <1, 1, 7>
> }
Unfortunately, if you go too small on one of the dimensions, it makes artifacts.
You'll have to bump up that second parameter a little bit. Someone wiser than
I may have a better solution, but I know of none.
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 Wed, 14 Nov 2007 21:19:06 EST, "Kirk Andrews" <kir### [at] tektonart com> wrote:
>Here's the problem:
>
>> #declare o_Rod =
>> superellipsoid {
>> <1, **0.05**>
>> scale <1, 1, 7>
>> }
>
>Unfortunately, if you go too small on one of the dimensions, it makes artifacts.
> You'll have to bump up that second parameter a little bit. Someone wiser than
>I may have a better solution, but I know of none.
>
Hmm, I still get small artefacts in the same spot as high as 0.25 on the second
parameter, and the
object is then not shaped as I'd like.
I guess I can always just merge a couple of cylinders and tori as a means to an end.
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) |
Kyle <hob### [at] gate net> wrote:
> Why does this scene have artefacts on the superellipsoid?
IMO because the pigment is strechted on z-axis by
the scaling factor "7"
Better use: Rounded_cylinder
This figure is more flexible and you can use all
kind of pigments/textures/normals/materials etc.
without scaling.
Example:
//------------------
#include "shapes.inc"
global_settings {
assumed_gamma 1
max_trace_level 25
}
light_source { <20, 100, -10>, rgb 1 }
camera {
right x*image_width/image_height
location <0, 9, -12> look_at <0, 0, 0>
}
plane {
y, 0
pigment { rgb <0.4,0.6,0.6> }
}
object {
Round_Cylinder(<0,0,-3.5>, <0,0,3.5>, 1, 0.15, 1)
pigment { rgb 0.8 }
translate <-1, 1, 0>
rotate y*29
}
//-----
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 Thu, 15 Nov 2007 00:44:59 EST, "Meothuru" <nomail@nomail> wrote:
>IMO because the pigment is strechted on z-axis by
>the scaling factor "7"
Actually, that's not the case. The superellipsoid is scaled first, then the pigment
is applied.
>Better use: Rounded_cylinder
Yep, that's another means to an end.
I'm still curious as to why the artefacts appear, though, even with a higher "n"
parameter of 0.25.
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) |
Kyle wrote:
> I'm still curious as to why the artefacts appear, though, even with a higher "n"
parameter of 0.25.
It's hard to say the exact reason offhand, but it's most probably
related to floating point inaccuracy. Maybe 64-bit IEEE floating point
numbers simply aren't accurate enough in this case.
(Of course there's a slight possibility that there's some other
reason, eg. a bug or an ill-written implementation.)
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 15.11.2007 17:24, Kyle nous fit lire :
> On Thu, 15 Nov 2007 00:44:59 EST, "Meothuru" <nomail@nomail> wrote:
>
>> IMO because the pigment is strechted on z-axis by
>> the scaling factor "7"
>
> Actually, that's not the case. The superellipsoid is scaled first, then the pigment
is applied.
>
>> Better use: Rounded_cylinder
>
> Yep, that's another means to an end.
>
>
> I'm still curious as to why the artefacts appear, though, even with a higher "n"
parameter of 0.25.
>
>
Confirmed.
Correction with the source very easy.
Details (in french) here:
http://jgrimbert.free.fr/pov/correct/superellipsoid.html
Short version: the box used for the computation of the
superellipsoid must be a bit bigger than the perfect {-1,1} box, due
to numerical precision. 1% is enough.
If not, some point computed during the evaluation of the ray
intersecting with the superellipsoid will be found to be outside of
the bounding 'perfect' box... and removed from the intersection list.
Coding version:
in source/super.cpp,
const DBL MIN_VALUE = -1.01;
const DBL MAX_VALUE = 1.01;
--
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius
Post a reply to this message
Attachments:
Download 'bogus1.png' (33 KB)
Preview of image 'bogus1.png'
![bogus1.png](/povray.binaries.images/attachment/%3C473c978f%40news.povray.org%3E/bogus1.png?ttop=443866&toff=3550&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) |
Le Forgeron wrote:
> const DBL MIN_VALUE = -1.01;
> const DBL MAX_VALUE = 1.01;
I made this change for the next beta.
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 Thu, 15 Nov 2007 20:01:31 +0100, Le Forgeron <jgr### [at] free fr> wrote:
>Short version: the box used for the computation of the
>superellipsoid must be a bit bigger than the perfect {-1,1} box, due
>to numerical precision. 1% is enough.
>If not, some point computed during the evaluation of the ray
>intersecting with the superellipsoid will be found to be outside of
>the bounding 'perfect' box... and removed from the intersection list.
Makes sense. Good catch!
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) |