|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
|
|