POV-Ray : Newsgroups : povray.general : question about bounding Server Time
29 Jul 2024 10:23:48 EDT (-0400)
  question about bounding (Message 1 to 4 of 4)  
From: povman
Subject: question about bounding
Date: 18 Apr 2012 22:50:00
Message: <web.4f8f7c22f5e5b2711a9616a60@news.povray.org>
I am working on some rendering of data using voxel datapoints. There is
something I don't really understand going on with bounding and translate limits
or possibly a bug or overflow.

I am on ubuntu 10.04 with povray version:
Persistence of Vision(tm) Ray Tracer Version 3.6.1 (Debian  (x86_64-linux-gnu-g+
+ 4.3.3 @ x86_64-pc-linux-gnu))

Take this POV file here: http://pastebin.com/Bp5H9swS [test.pov]

It loads two rows of cubic voxels, however in rendering it with:
povray -Q0 test.pov

It looks like: http://i.imgur.com/nBwb2.png

Notice the gabs between the blocks, they should not be there based on the data.

However if rendered with:

povray -Q0  -MB test.pov

The expected result is obtained here: http://i.imgur.com/odoR8.png

Notice the smooth row of blocks.

Fair enough seems like bounding is the issue, obviously rendering is MUCH slower
with -MB . I would really like a way to optimize to a more +MB speed. The really
odd part though is that if I simply change the translate positions to use
smaller numbers as in this .pov file:
http://pastebin.com/jkm9fX3U [test2.pov]

Changing a value like this:
object { MyMesh translate <7458344, 721, 13692132> }

to this:
object { MyMesh translate <8344, 721, 2132> }

and then run:

povray -Q0 test2.pov

I get the correct result with the +MB performance here:

http://i.imgur.com/yKJme.png

Is there something I can do settings wise or other options (even compile time)
to resolve this?

Thanks.


Post a reply to this message

From: Le Forgeron
Subject: Re: question about bounding
Date: 19 Apr 2012 03:30:48
Message: <4f8fbf28$1@news.povray.org>
Le 19/04/2012 04:44, povman a écrit :
> Is there something I can do settings wise or other options (even compile time)
> to resolve this?

Replace your mesh2 with a real box, upgrade to 3.7RC5 and use the cubic
pattern.

#declare tz=texture {pigment{rgb<0,0,1>}};
#declare tx=texture {pigment{rgb<1,0,0>}};
#declare ty=texture {pigment{rgb<0,1,0>}};
#declare MyMesh = box { -0.5,0.5 texture { cubic
    texture {tx}
    texture {ty} texture {tz}
    texture {tx}
    texture {ty} texture {tz}
    } };


Post a reply to this message

From: povman
Subject: Re: question about bounding
Date: 19 Apr 2012 06:45:01
Message: <web.4f8fec4190f437bd1a9616a60@news.povray.org>
Interestingly the same error occurs in the same way using that setup of a "real
box" instead of mesh 2 and -MB is still necessary. Is there a place where the
limits of the values for transform
are documented? -MB produces smooth rows of boxes, +MB has the same
gaps/clipping issue.

I will have to whether mesh2 or box performance is better when dealing with huge
numbers of datapoints.

Thanks.

Le_Forgeron <lef### [at] freefr> wrote:
> Le 19/04/2012 04:44, povman a écrit :
> > Is there something I can do settings wise or other options (even compile time)
> > to resolve this?
>
> Replace your mesh2 with a real box, upgrade to 3.7RC5 and use the cubic
> pattern.
>
> #declare tz=texture {pigment{rgb<0,0,1>}};
> #declare tx=texture {pigment{rgb<1,0,0>}};
> #declare ty=texture {pigment{rgb<0,1,0>}};
> #declare MyMesh = box { -0.5,0.5 texture { cubic
>     texture {tx}
>     texture {ty} texture {tz}
>     texture {tx}
>     texture {ty} texture {tz}
>     } };


Post a reply to this message

From: Alain
Subject: Re: question about bounding
Date: 19 Apr 2012 22:52:35
Message: <4f90cf73$1@news.povray.org>

> I am working on some rendering of data using voxel datapoints. There is
> something I don't really understand going on with bounding and translate limits
> or possibly a bug or overflow.
>
> I am on ubuntu 10.04 with povray version:
> Persistence of Vision(tm) Ray Tracer Version 3.6.1 (Debian  (x86_64-linux-gnu-g+
> + 4.3.3 @ x86_64-pc-linux-gnu))
>
> Take this POV file here: http://pastebin.com/Bp5H9swS [test.pov]
>
> It loads two rows of cubic voxels, however in rendering it with:
> povray -Q0 test.pov
>
> It looks like: http://i.imgur.com/nBwb2.png
>
> Notice the gabs between the blocks, they should not be there based on the data.
>
> However if rendered with:
>
> povray -Q0  -MB test.pov
>
> The expected result is obtained here: http://i.imgur.com/odoR8.png
>
> Notice the smooth row of blocks.
>
> Fair enough seems like bounding is the issue, obviously rendering is MUCH slower
> with -MB . I would really like a way to optimize to a more +MB speed. The really
> odd part though is that if I simply change the translate positions to use
> smaller numbers as in this .pov file:
> http://pastebin.com/jkm9fX3U [test2.pov]
>
> Changing a value like this:
> object { MyMesh translate<7458344, 721, 13692132>  }
>
> to this:
> object { MyMesh translate<8344, 721, 2132>  }
>
> and then run:
>
> povray -Q0 test2.pov
>
> I get the correct result with the +MB performance here:
>
> http://i.imgur.com/yKJme.png
>
> Is there something I can do settings wise or other options (even compile time)
> to resolve this?
>
> Thanks.
>
>
>
>
>
>
>
You probably encounter some floating point errors.
Your cubes are 1 unit whide, going from -0.5 to 0.5.
Your coordinates are in the MILLIONS and 10 MILLIONS range.
This result in coordinate proportions of 14916688:1 and 27384264:1 for 
the given cube.

The range is just to large, the bounding get screwed by FP errors and 
may cause distinct cubes to overlap, or to be totally missed.

The key is to restrict the range of dimentions and distances in a 
proportional range of less than 1e6.



Alain


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.