Someone (thanks Warp) pointed out in a posting a few days 
that the df3 file format in PovPray had been expanded to
handle other than 1 byte voxels, I have no idea how I missed
that improvement!

I have a project which I had decided not to use PovRay for
because I figured there wasn't going to be enough voxel 
dynamic range, that has all changed. So I converted the
data and it turns out that the data cube is periodic so
it can be tiled in 3D space. Unfortunately when I tiled
my volume (cube containing df3 media) it got the following.
   http://astronomy.swin.edu.au/~pbourke/tmp/tiled.jpg

So, is it me or some limitation (implementation fact of
life) with media. In case you can't tell, I am expecting
to see a continuous volume without the dark regions around
the central instance of the volume.

All the source that matters should be below.

#declare NVOL = 200;  // Number of cells
#declare WW = 25;     // Final size
#declare cosmologymedia = interior {
   media {
      intervals 100
      ratio 0.5
      samples 2,2
      method 2
      emission 60 * <1,1,1> / NVOL
      absorption <0,0,0>
      scattering { 1, <0,0,0> }
      confidence 0.999
      variance 1/1000
      density {
         density_file df3 "p0100.df3"
         interpolate 1
         color_map {
            [0.00 rgb <0,0,0>]
            [0.01 rgb <1,0,0>]
            [0.02 rgb <1,1,0>]
            [1.00 rgb <1,1,1>]
         }
      }
   }
}

#declare onecell = object {
   box {
      <0,0,0>, <1,1,1>
      pigment { rgbf 1 }
      interior { cosmologymedia }
      hollow
      translate <-0.5,-0.5,-0.5>
      scale 2*WW // Final dataset is +- WW
   }
}

union {
   object { onecell translate <0,-2*WW,0> }
   object { onecell translate <0,2*WW,0> }
   object { onecell translate <0,0,-2*WW> }
   object { onecell translate <0,0,2*WW> }
   object { onecell translate <0,0,0> }
}

-- 
Paul Bourke
pdb_NOSPAMswin.edu.au

Post a reply to this message

Paul Bourke wrote:
> Someone (thanks Warp) pointed out in a posting a few days 
> that the df3 file format in PovPray had been expanded to
> handle other than 1 byte voxels, I have no idea how I missed
> that improvement!
> 
> I have a project which I had decided not to use PovRay for
> because I figured there wasn't going to be enough voxel 
> dynamic range, that has all changed. So I converted the
> data and it turns out that the data cube is periodic so
> it can be tiled in 3D space. Unfortunately when I tiled
> my volume (cube containing df3 media) it got the following.
>    http://astronomy.swin.edu.au/~pbourke/tmp/tiled.jpg

I am not completely sure but it is probably related to the use of 
multiple boxes.  Why don't you use one media container with a repetitive 
media pattern?  You can use the repeat warp or functions for that.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Paul Bourke wrote:

> So, is it me or some limitation (implementation fact of
> life) with media. In case you can't tell, I am expecting
> to see a continuous volume without the dark regions around
> the central instance of the volume.

In my experience there has to be some space between media containers, you'll get this
kind of effect if the surfaces are coincident or the containers are overlapping.

Try something like:

object { onecell translate <0,-2*WW + 0.001,0> }

Artur.

Post a reply to this message

A. Brinkmann wrote:

> Try something like:
> 
> object { onecell translate <0,-2*WW + 0.001,0> }

Oops, I think that should be -0.001 in this case!

Artur.

Post a reply to this message

On Mon, 04 Oct 2004 11:51:45 +0200, Christoph Hormann wrote:

> I am not completely sure but it is probably related to the use of
> multiple boxes.  Why don't you use one media container with a repetitive
> media pattern?  You can use the repeat warp or functions for that.
> 
> Christoph

From what I can tell, the reason is because it is outrageously slow. 
POV-Ray does not try to optimize containers with multiple media or density
into a bounding hierarchy, so it will be linearly slower as you increase
the number of contained media.  I've looked at this recently (because I
wanted to try to create a media waterfall), and the code could be improved
but it would require a lot of changes to the (terribly inflexible) media
code.  One more thing for the 4.0 redesign, I guess.

For the record, as far as I know you can't achieve this with multiple
objects because the media sampling needs to interact across the
repetitions for it to work, and this interaction is only supported when
you use multiple media inside a single container.

Andrew

Post a reply to this message

On Mon, 04 Oct 2004 22:24:45 -0500, Andrew Clinton wrote:

> On Mon, 04 Oct 2004 11:51:45 +0200, Christoph Hormann wrote:
> 
>> I am not completely sure but it is probably related to the use of
>> multiple boxes.  Why don't you use one media container with a repetitive
>> media pattern?  You can use the repeat warp or functions for that.
>> 
>> Christoph

Sorry I've reread my response, which may have seem offensive - I did not
mean that at all!  You may be right that warp or functions would solve his
particular case.  My problem was a more general one, I think,

Andrew

Post a reply to this message

> Why don't you use one media container with a repetitive
> media pattern?  You can use the repeat warp or functions for that.
> Christoph

> You may be right that warp or functions would solve his particular case.
> Andrew

Andrew, Christoph.....care to enlighten me on how to do this, it wasn't
immediately obvious how to use warp with an interior media. Otherwise I
guess it's time to hit the manual.

--
Paul Bourke
pdb_NOSPAMswin.edu.au

Post a reply to this message

On Mon, 04 Oct 2004 23:44:31 -0400, Paul Bourke wrote:

>> Why don't you use one media container with a repetitive
>> media pattern?  You can use the repeat warp or functions for that.
>> Christoph
> 
>> You may be right that warp or functions would solve his particular case.
>> Andrew
> 
> Andrew, Christoph.....care to enlighten me on how to do this, it wasn't
> immediately obvious how to use warp with an interior media. Otherwise I
> guess it's time to hit the manual.

In the density {} block try putting warp { repeat x } or something like
that.  As long as your container is large enough, it should repeat the
pattern along the x axis.  It won't repeat along all axes though.  In
fact, it seems you can use any pattern modifier on the density.  It's
seems to be treated just like a pigment internally.

Andrew

Post a reply to this message

Paul Bourke wrote:
> 
> Andrew, Christoph.....care to enlighten me on how to do this, it wasn't
> immediately obvious how to use warp with an interior media. Otherwise I
> guess it's time to hit the manual.

Like Andrew said you can use the repeat warp for any pattern so it does 
not matter if it is a media density or pigment.  You can find an 
introduction to repeat warps on:

http://www.tu-bs.de/%7Ey0013390/pov/warp.html

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Andrew Clinton wrote:
> 
> From what I can tell, the reason is because it is outrageously slow. 
> POV-Ray does not try to optimize containers with multiple media or density
> into a bounding hierarchy, so it will be linearly slower as you increase
> the number of contained media.

I am not talking about multiple media and density, i just suggested to 
use a repetitive pattern.  It will not be significantly slower (apart 
from the fact that a larger media container will of course slow down the 
calculations depending on the media settings.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message