"Warp" <war### [at] tagpovrayorg> wrote in message news:401a3203@news.povray.org...

>   By the way, you could also say "in computer languages there's usually
> a shortcut for writing '*10^' by writing 'e' instead. That is, for
> example 1234*(10^12) can be written as 1234e12". Then from that point
> forward you can use the e-syntax instead of the *10^ one for clarity.

Good idea - although I might not use that notation in the examples as, for the
novices, it might just be another layer of abstraction getting in the way of
understanding the issue.

BTW the graphics on the page (and site) are all rendered in POV. (although if
you wander outside of cgi-bin you'll hit a username/password request).

Post a reply to this message

Thank you vary much Christopher, you've solved it!!  I had to set the
accuray to 0.000001 to be rid of all the artifacts, but its fixed.  Huzzar!

I especially appreciate the explanation.  As I understand it, the accuracy
setting is like increasing the "Zoom" on the ray tracings engine.

I'll post the finished image when its rendered ( probably take most of the
weekend ) so you can see what you've helped along.

Thanks again.

Post a reply to this message

In article <401a832c$1@news.povray.org>,
 "Felbrigg" <som### [at] microsoftcom> wrote:

> Thank you vary much Christopher, you've solved it!!  I had to set the
> accuray to 0.000001 to be rid of all the artifacts, but its fixed.  Huzzar!

That's probably pushing the boundaries of what will work, especially if 
you're using functions that are already stretching machine precision 
limits.


> I especially appreciate the explanation.  As I understand it, the accuracy
> setting is like increasing the "Zoom" on the ray tracings engine.

I'm not sure what you're thinking of, but it just controls the allowable 
error in the isosurface calculations. The isosurface solver just takes a 
series of progressively refined estimates, the accuracy parameter tells 
it when it can stop refining its result and decide it found the 
intersection point. The actual intersection will be somewhere within 
"accuracy" distance of that point. (note that this doesn't necessarily 
mean distance within the scene...scaling can change the relationship 
between what's one unit to the object and what's one unit in the scene)

Anyway, since the value found is not the true value, you can end up with 
a situation where the transparent isosurface is the first one hit, but 
when POV traces a ray from the computed intersection point, it misses 
the green isosurface. Or hits it, decides it's so close to the ray 
origin that it's likely to be an erroneous hit on the transparent 
object, and ignores it.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

I've posted the finished image in the povray.binaries.images section, look
for "Cactus Halo".

Thanks for your help.


"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cjameshuff-6DF932.14392730012004@news.povray.org...
> In article <401a832c$1@news.povray.org>,
>  "Felbrigg" <som### [at] microsoftcom> wrote:
>
> > Thank you vary much Christopher, you've solved it!!  I had to set the
> > accuray to 0.000001 to be rid of all the artifacts, but its fixed.
Huzzar!
>
> That's probably pushing the boundaries of what will work, especially if
> you're using functions that are already stretching machine precision
> limits.
>
>
> > I especially appreciate the explanation.  As I understand it, the
accuracy
> > setting is like increasing the "Zoom" on the ray tracings engine.
>
> I'm not sure what you're thinking of, but it just controls the allowable
> error in the isosurface calculations. The isosurface solver just takes a
> series of progressively refined estimates, the accuracy parameter tells
> it when it can stop refining its result and decide it found the
> intersection point. The actual intersection will be somewhere within
> "accuracy" distance of that point. (note that this doesn't necessarily
> mean distance within the scene...scaling can change the relationship
> between what's one unit to the object and what's one unit in the scene)
>
> Anyway, since the value found is not the true value, you can end up with
> a situation where the transparent isosurface is the first one hit, but
> when POV traces a ray from the computed intersection point, it misses
> the green isosurface. Or hits it, decides it's so close to the ray
> origin that it's likely to be an erroneous hit on the transparent
> object, and ignores it.
>
> -- 
> Christopher James Huff <cja### [at] earthlinknet>
> http://home.earthlink.net/~cjameshuff/
> POV-Ray TAG: <chr### [at] tagpovrayorg>
> http://tag.povray.org/

Post a reply to this message