 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
problems with float-point precission are quite common in POV (i.e. box
-9.999,+9.999 with checker pigment can show errors, as well as cone{-
x,1,+x,1} with color_map{[0 rgb 0][1 rgb 1]} - as noticed in .bugreports).
How about building version of Pov with long double type (for geometry and
textures calculations).
First step to do it could be IMHO using different types like
typedef long dobule DBLGeo; // geomtery
typedef dobule DBLPig; // pigment
typedef float DBLHf ; // HF values
etc...
simple replacing DBL probably will not work because i.e. of many "tricks"
in AFAIR Radiosity code depending on exacly binary format of DBL.
--
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <Xns### [at] 204 213191226>, "Rafal 'Raf256' Maj"
<raf### [at] raf256com> wrote:
> problems with float-point precission are quite common in POV (i.e. box
> -9.999,+9.999 with checker pigment can show errors, as well as cone{-
> x,1,+x,1} with color_map{[0 rgb 0][1 rgb 1]} - as noticed in .bugreports).
You misunderstand the basic problem: Your idea will just slow POV-Ray down
by a factor of ten or more. Increasing the precision is trivial,
maintaining speed is impossible*.
Thorsten
* I don't want to get into details nor should someone tell me it is possible
with special-purpose hardware for US$10 million. I know that, but it isn't
the point.
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in
news:3dcfbfd6@news.povray.org
> You misunderstand the basic problem: Your idea will just slow POV-Ray
> down by a factor of ten or more. Increasing the precision is trivial,
> maintaining speed is impossible*.
No, I know that long double operations will be slower then float :)
The idea is to have ANOTHER distribution, and if someone realy needs high
precision and if speed is not important for him - he will run another build
of engine.
Normal peoples will work on standart version, and for finakl versions, if
someone realy needs it - one could download and use long-double version
--
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <Xns### [at] 204213191226>,
"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> No, I know that long double operations will be slower then float :)
> The idea is to have ANOTHER distribution, and if someone realy needs high
> precision and if speed is not important for him - he will run another build
> of engine.
You still don't understand...no amount of precision will avoid
coincident surface problems like the ones in the examples you gave, the
only thing it might help would be a few special cases in some root
solvers. Finding those and using "long double" only where it is useful
and necessary would be the correct solution, not a massive change
affecting the whole program. It would preferably be an alternate solving
method so people could use the faster version if they don't need the
high precision. And then, it should only be used if there is no way to
reduce the sensitivity of the algorithms to this kind of error.
Going through the trouble of doing this for the POV 3.5 source would be
a waste of time, and it wouldn't help nearly as much as you seem to
think.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] maccom> wrote in news:chrishuff-
1BC### [at] netplexaussieorg
> You still don't understand...no amount of precision will avoid
> coincident surface problems like the ones in the examples you gave,
I'm afraid that maybe YOU don't understand, I know that coidencident
surfaces that are *ideal* in same spaces can not be improved (by any
floating point math).
But I found that i.e. box sized -9.998, +9.998 with checker (scale 1) has
ALSO this problem. If size was 10.000 etc - I would understand this, but I
especialy used 9.998 to *avoid* the problem.
Or maybe, this is something connected with topic on .programming :
<cit>
> POV_SRAND(Hash3d((int)floor(EPoint[X]+Small_Tolerance),
> (int)floor(EPoint[Y]+Small_Tolerance),
> (int)floor(EPoint[Z]+Small_Tolerance)));
> Why is Small_Tolerance being added to EPoint? That just offsets the
> pattern by a little bit. What's the point?
Probably so that when the cell border is coincident with the surface
being textured there will be no speckling. This would be the case if
it was applied to a plane facing along a coordiante axis at an
integral distance from the origin.
</cit>
maybe "small tollerance" for checker is 0.001 and therefore using
coordinates like W+0.001 (where 0.001 is to AVOID coincidence) is a bad
idea.
Maybe using small tollerance like 0.0013456 is a better idea - ther would
be much less chance that some user my use variable like this (0.0013456...)
in code.
--
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <Xns### [at] 204213191226>,
"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> I'm afraid that maybe YOU don't understand, I know that coidencident
> surfaces that are *ideal* in same spaces can not be improved (by any
> floating point math).
Well, why didn't you give an example of something that would actually be
fixed by your suggestion? You give two coincident surface errors as
examples, and then suggest increasing precision to avoid errors, what do
you expect people to think?
> But I found that i.e. box sized -9.998, +9.998 with checker (scale 1) has
> ALSO this problem. If size was 10.000 etc - I would understand this, but I
> especialy used 9.998 to *avoid* the problem.
Try 10. The checker pattern is offset internally to avoid this problem
without making the user translate things all the time. You just either
canceled this out, or are seeing an unrelated problem.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 11 Nov 2002 13:35:50 -0500, Christopher James Huff
<chr### [at] maccom> wrote:
>Try 10. The checker pattern is offset internally to avoid this problem
>without making the user translate things all the time. You just either
>canceled this out, or are seeing an unrelated problem.
Or scaled the box together with the texture :)
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> Your idea will just slow POV-Ray down by a factor of ten or more.
It will probably also take a lot more memory, which is another problem.
So to "fix" something which can be got around by changing some numbers in
the scene we should make POV-Ray a lot slower and make it consume a lot more
memory (mostly for things that don't need any extra precision).
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11 Nov 2002 09:04:28 -0500, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> typedef long dobule DBLGeo; // geomtery
> typedef dobule DBLPig; // pigment
> typedef float DBLHf ; // HF values
What about geometry based on pigments?
What about pigments based on geometry?
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
