 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This pov file:
================
#include "colors.inc"
#include "metals.inc"
light_source { <6, 9, -21> color White }
camera { location <0, 0, -3> look_at <0, 0, 0> }
sphere_sweep {
cubic_spline
6
<-2.0, 0, 0> 0.05
<0.000,0,0> 0.2
<0.025,0,0> 0.2
<0.050,0,0> 0.2
<0.075,0,0> 0.2
<3.0,0,0> 0.2
pigment { color White }
}
================
Produces two strange artifacts: A disk at the center of the sweep, and a faint
"halo" or veil which shows as 4 faint hyperbolas centered around the origin.
I have tried tweaking tolerance (for no other reason than I saw that someone
else was tweaking it to solve a problem) but this does not seem to change
things.
For a look at MY result when I run this, view this image:
http://riventree.com/archive/bugdata/povray/SphereSweepArtifacts.jpg
(I can't post attachments to this newsgroup)
-Jeff Evarts
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
My apologies for not including this in the first post:
I'm running POV-Ray for (64 bit) Windows v3.62 on (64 bit) Windows Vista
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Not sure if in this case it is a bug or just one of the limitations of
sphere_sweeps but anyway:
I always use a string of cones with spheres at the joints rather than a
sphere_sweep. It renders faster, you can easily change the resolution according
to your needs and you don't get such problems.
Actually this works so well, i'm wondering why they don't implement it that
way...
Regards Roman
"JeffEvarts" <riv### [at] earthlink net> wrote:
> Produces two strange artifacts: A disk at the center of the sweep, and a faint
> "halo" or veil which shows as 4 faint hyperbolas centered around the origin.
>
> I have tried tweaking tolerance (for no other reason than I saw that someone
> else was tweaking it to solve a problem) but this does not seem to change
> things.
>
> For a look at MY result when I run this, view this image:
>
> http://riventree.com/archive/bugdata/povray/SphereSweepArtifacts.jpg
>
> (I can't post attachments to this newsgroup)
>
> -Jeff Evarts
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> This pov file:
>
> ================
>
> #include "colors.inc"
> #include "metals.inc"
>
> light_source {<6, 9, -21> color White }
> camera { location<0, 0, -3> look_at<0, 0, 0> }
>
> sphere_sweep {
> cubic_spline
> 6
> <-2.0, 0, 0> 0.05
>
> <0.000,0,0> 0.2
> <0.025,0,0> 0.2
> <0.050,0,0> 0.2
> <0.075,0,0> 0.2
>
> <3.0,0,0> 0.2
> pigment { color White }
> }
>
> ================
>
> Produces two strange artifacts: A disk at the center of the sweep, and a faint
> "halo" or veil which shows as 4 faint hyperbolas centered around the origin.
>
> I have tried tweaking tolerance (for no other reason than I saw that someone
> else was tweaking it to solve a problem) but this does not seem to change
> things.
>
> For a look at MY result when I run this, view this image:
>
> http://riventree.com/archive/bugdata/povray/SphereSweepArtifacts.jpg
>
> (I can't post attachments to this newsgroup)
>
> -Jeff Evarts
>
>
You use very small dimentions that can cause calculations errors, but
scaling everything up by 1000 just change the location of the disk, it
make it move left.
Changing the scale don't change the stripes nor the artefacts on the
right end.
The hyperbola like things are still there, and the ones on the right
becomes more visible, and I get a parabola like thing on the left.
The "disk" receives and cast shadows. A rotation shows that it's not a
disk, but a long plane.
It's still there with the latest version: 3.7 beta 35a.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Your post and Alain's comments got me to thinking about this long-standing
problem, so I did some experiments (and a few animations). Here's what I've come
up with (in v3.6.1) using your code unchanged:
1) The cubic_spline type is *by far* the worst offender. It produces those
hyperbolas *outside* the object, plus the vertical 'plane' that Alain mentioned.
It also takes MUCH longer to render than either a b_spline or linear_spline
(about 10X longer!). The ENTIRE scene renders slower--every pixel. Moving the
camera way back--so that the sphere_sweep is barely visible in the
scene--doesn't change this; in fact, the scene renders even *slower*, which is
completely counter-intuitive. Changing the tolerance value doesn't affect it.
Putting all of this together, it *seems* as though there's a 'visible' part of
the object (the one we see) and an infinitely large INVISIBLE part as well, that
POV-Ray is also having to do render calculations on --the outside artifacts
showing up as vestiges of this part. BTW, my animation tests seem to show that
the 'plane' artifact is at the location of the asymptote of the hyperbolas (or
one of them, anyway.) Not sure about that, though. And I still can't tell why
this 'plane' is showing up where it does; it has nothing to do with the
sphere_sweep being made near POV's <0,0,0> origin location. (See 3) below.)
2) The b_spline and linear spline don't produce any artifacts *outside* the
object, except for that 'plane'--and it's actually more pronounced with a
linear_spline than either of the other two spline types.
3) Creating the sphere_sweep somewhere other than near the origin (via its
spline points OR by translating it afterward)--and moving the camera
likewise--doesn't alter the artifacts. Changing the tolerance helps somewhat,
but not with the cubic_spline's hyperbolas.
4) The artifacts don't seem to change their positions relative to the object,
when the camera moves around. (I thought at first it was some kind of
camera/sphere_sweep 'interaction'; but moving the camera via animation doesn't
really alter their behavior or location, it just shows them in 3-D space.)
My own conclusion is that the cubic_spline code (at least when used in a
sphere_sweep) needs to be re-worked. That may not fix ALL of the sphere_sweep
artifacts, but would surely help!
Question (a bit off-topic): Is POV's b_spline the same as a natural_spline?
Looking them up on Wikipeadia doesn't give me a clear answer.
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] earthlinknet> wrote:
> The ENTIRE scene renders slower--every pixel. Moving the
> camera way back--so that the sphere_sweep is barely visible in the
> scene--doesn't change this; in fact, the scene renders even *slower*, which is
> completely counter-intuitive. Changing the tolerance value doesn't affect it.
> Putting all of this together, it *seems* as though there's a 'visible' part of
> the object (the one we see) and an infinitely large INVISIBLE part as well, that
> POV-Ray is also having to do render calculations on --the outside artifacts
> showing up as vestiges of this part.
That makes me wonder what the effects of a clipping or bounding shape would be.
-Reactor
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kenneth <kdw### [at] earthlinknet> wrote:
> The ENTIRE scene renders slower--every pixel. Moving the
> camera way back--so that the sphere_sweep is barely visible in the
> scene--doesn't change this; in fact, the scene renders even *slower*, which is
> completely counter-intuitive.
Manually specifying a bounding box for the sphere sweep object should fix
that problem.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Kenneth <kdw### [at] earthlinknet> wrote:
> > [When using a cubic_spline] the ENTIRE scene renders slower--every pixel.
> > Moving the camera way back--so that the sphere_sweep is barely visible in the
> > scene--doesn't change this; in fact, the scene renders even *slower*, which
> > is completely counter-intuitive.
>
> Manually specifying a bounding box for the sphere sweep object should fix
> that problem.
Did a test, and that does indeed work; the OP's object renders MUCH faster, and
the artifacts are confined to the bounding shape. (Remove_Bounds=on needs to be
in the INI file, though; I don't know how that might affect 'bigger' scenes.
With it off--the default--POV issues a non-fatal warning, "Unnecessary bounding
object removed" and eliminates the bounding object.)
Something else: With Remove_Bounds=off, but by changing Bounding_Threshold to
zero (the default in v3.6.1 is 3), it also significantly speeds up the render.
Seems that there *is* a bounding object around the sphere_sweep in this
case...perhaps a 1-unit box, I can't tell. It doesn't eliminate *all* of the
hyperbolas and 'plane', but cuts off most of them.
My tests/results in v3.6.1 may not be the same as in 3.6.2 or the later betas;
the bounding algorithm was changed/improved, IIRC.
The nice thing about the OP's sphere_sweep is that it's a simple 'linear' one.
With a snaking, sinuous sphere_sweep, these bounding tricks would have a hard
time containing the artifacts.
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kenneth <kdw### [at] earthlinknet> wrote:
> (Remove_Bounds=on needs to be
> in the INI file, though; I don't know how that might affect 'bigger' scenes.
> With it off--the default--POV issues a non-fatal warning, "Unnecessary bounding
> object removed" and eliminates the bounding object.)
IMO that's a design mistake in POV-Ray worth of a bug report.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Kenneth <kdw### [at] earthlinknet> wrote:
> > (Remove_Bounds=on needs to be
> > in the INI file, though; I don't know how that might affect 'bigger' scenes.
> > With it off--the default--POV issues a non-fatal warning, "Unnecessary
> > bounding object removed" and eliminates the bounding object.)
>
> IMO that's a design mistake in POV-Ray worth of a bug report.
>
Very interesting. I've been living with that for years, scratching my head
about it, and just thought it was 'the way POV-Ray worked.' (I never *could*
make complete sense of the docs' section about bounding, due to this particular
behavior.) Good to know that I wasn't crazy after all!
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
