Hi Y'all

I'm a new pov user (physics grad student) and I want to do a project that seems
both simple and complex at the same time.

The simple thing is that I want to do a plane of fog with a single inplane light
source and to view it from above.  I have a background with c++ and autocad, and
am pretty sure I can figure this part out.

The hard thing is that I want the fog to have either variable density and/or a
medium with a variable index of refraction.  Either one.

I'm doing this so I can view some data from an experiment.  The data I want to
view is in the form of 480x480x1 arrays, stored either as a fit or bmp or tiff
file.

So, a plane of fog and light source is surely doable.  Linking fog density to a
grid of numbers and thus importing the numbers into the script seems much
harder.

Can someone point me in the right direction?  Is what I want to do possible?

I have looked at scripting language and documentation but it looks like I could
spend years figuring out all the options.

Thanks in advance,

Michael

Post a reply to this message

sirzerp wrote:

> So, a plane of fog and light source is surely doable.  Linking fog
> density to a grid of numbers and thus importing the numbers into the
> script seems much harder.

Povray supports so-called density files that are basically a
3d grid of numbers. Have a look at df3 in the docs (3.5.11.13
for POV-Ray 3.7 RC3). I don't think many tools exist for that
but the format is very simple.

Such an imported density can be used for scattering media,
which basically gives you fog based on variable density.

Post a reply to this message

> Hi Y'all
>
> I'm a new pov user (physics grad student) and I want to do a project that seems
> both simple and complex at the same time.
>
> The simple thing is that I want to do a plane of fog with a single inplane light
> source and to view it from above.  I have a background with c++ and autocad, and
> am pretty sure I can figure this part out.
>
> The hard thing is that I want the fog to have either variable density and/or a
> medium with a variable index of refraction.  Either one.
>
> I'm doing this so I can view some data from an experiment.  The data I want to
> view is in the form of 480x480x1 arrays, stored either as a fit or bmp or tiff
> file.
>
> So, a plane of fog and light source is surely doable.  Linking fog density to a
> grid of numbers and thus importing the numbers into the script seems much
> harder.
>
> Can someone point me in the right direction?  Is what I want to do possible?
>
> I have looked at scripting language and documentation but it looks like I could
> spend years figuring out all the options.
>
> Thanks in advance,
>
> Michael
>

The fog feature can't be illuminated by a light_source.
For that, you need to use scattering media.
Your media will then be contained in a whide box or between two planes.

As your data are only 1 layer deep, you can use your BMP or TIFF 
directly as an image_map that can directly determine the density of the 
media.


As for variable ior, sory, that's not possible, and may never be.
It may be simulated to a sertain degree by giving your object an ior and 
altering it's normal according to some pattern.



Alain

Post a reply to this message

Alain <aze### [at] qwertyorg> wrote:
> As for variable ior, sory, that's not possible, and may never be.
> It may be simulated to a sertain degree by giving your object an ior and
> altering it's normal according to some pattern.
>
Though it is painfully slow, a merge of a grid of boxes, each with its own ior,
does seem to work as expected.

Post a reply to this message

"waggy" <hon### [at] handbasketorg> wrote:
> Alain <aze### [at] qwertyorg> wrote:
> > As for variable ior, sory, that's not possible, and may never be.
> > It may be simulated to a sertain degree by giving your object an ior and
> > altering it's normal according to some pattern.
> >
> Though it is painfully slow, a merge of a grid of boxes, each with its own ior,
> does seem to work as expected.

Sounds good.  How would you tie the file data to the box grid? Can you post your
test code?  Variable ior would be really good, but I can live with variable
scatter. :)

I found a good link at http://paulbourke.net/miscellaneous/df3/

My orginal data is 3d, so the link looks very promising.

I assume DF3 is the only supported file format?  Would be nice if DF3 supported
floats, but gee, you can't have anything.  I probably could write a matlab
float2df3 util, but there's some 'c' code posted on the linked wavepage.

Life is good,

Thanks y'all for the posts.

Post a reply to this message

> > Though it is painfully slow, a merge of a grid of boxes, each with its own ior,
> > does seem to work as expected.
>
> Sounds good.  How would you tie the file data to the box grid? Can you post your
> test code?  Variable ior would be really good, but I can live with variable
> scatter. :)
>
I always try to have my code output a valid POV-Ray include file, and sometimes
an entire scene file.  I've also used stand shell tools (grep,sed,awk) to
transform data similarly.  That said, POV-Ray can read something like a .csv
without too much trouble, just be sure to end each row with a comma.

My quick test POV-Ray scene (below) just uses an image for the IOR data.  [Note
I inverted the role of the source PNG's transmit component in the merged boxes
so it makes a sort of weird-lens-in-a-frame kind of thing.]

//----------------------------------
#version 3.7;

#include "stdinc.inc"

#declare pig_image =
pigment {
 image_map {
  png "povray_64.png"
  once
  }
}

box{<0,0,0>,<1,1,1>
pigment{pig_image}
}

#local image_width  = 64;
#local image_height = 64;

merge{
#local j=0.5;
#while(j<image_height)
   #local i=0.5;
   #while(i<image_width)
      #local image_color = eval_pigment(pig_image,
         <i/image_width,j/image_height,0.5>) ;
      box{<0,0,0>,<1,1,1>
         pigment{ Clear*(1-image_color.transmit)
                +Yellow*   image_color.transmit}
         interior{ ior 1+image_color.gray}
         scale 1.001 // Prevent coincident surfaces.
         translate <i,j,0>
      }
      #local i=i+1;
   #end
#local j=j+1;
#end

translate -0.5*<image_width,image_height,0>
scale <0.06,0.06,1>
translate -5*z
}//end union

plane{y,-2 pigment{checker Blue Gray50}}
sphere{0,100 pigment{color White} }
light_source{<-50,50,-50> color 1}
camera{location -10*z}
//----------------------------------

Post a reply to this message

Thank you for posting your code.  My advisor wants me to switch from varible
scatter to varible IOR, so it should come in very handy.  I wish I had a 2500K
I7, Hex AMD's only can do so much :)

On the other hand, look what I did with varible scatter.

http://www.scivee.tv/node/29097

That's the magnetic field in ways it has never been seen before.  I did it with
about 300 lines of GPU cuda C code that makes the density files and povray that
displays them.  I feed a small job file to the cuda code that defines the
locations of the magnets, not unlike objects in povray.


Question, if there Povray coders out there that would like to collaborate and
merge my code into povray?

Being able to display magnetic/electric fields would be big plus for the
scientific community.  The packages that I know of, cost thousands of dollars,
and take clusters of computers.

I'm doing it with free 3.7 povray, a $200 hex core cpu and a $90 GPU.

Cuda is C based and I believe povray is C++ based, I am sure a good programmer
could merge the two, add some new type EM objects and be off the races in a
weeks time.

-------------------------------------------------------------------

Quick question, is there anyway to generate density filenames based on the
clock?  I would like to have slightly different named density files for each
frame if it was possible.

Post a reply to this message

> That's the magnetic field in ways it has never been seen before. 



> Being able to display magnetic/electric fields would be big plus for the
> scientific community.

It's good to have tools like that, but I think it's a
bit too specialized for a general raytracer. Things like
this might be better packaged as your own cool science
app that has an export mode for povray density files
and a sample scene for rendering.

> Quick question, is there anyway to generate density filenames based on the
> clock?  I would like to have slightly different named density files for each
> frame if it was possible.

You should be able to use a combination of concat()
and str() for that (see 3.2.1.7.4 string functions)

Post a reply to this message

> Thank you for posting your code.  My advisor wants me to switch from varible
> scatter to varible IOR, so it should come in very handy.  I wish I had a 2500K
> I7, Hex AMD's only can do so much :)
>

Here, you will have a serious problem. The provided code only work if 
you have a thin object where you can assume the ior stays constant 
across it's thickness.

In your case, you need an ior that will change in a volume.
Now, you can no longer merge the constituent boxes at it makes the 
internal surfaces disapear. You also need to provide a tiny gap between 
the boxes to prevent coincident surfaces artefacts. Also, any ray 
parallel to an axis will always go straight through. You also can have 
problems with total internal reflection whenever you attempt to exit a 
box from any faces not parallel to that from whitch you entered it.

For a variable ior in a volume, you need to follow curved rays. Those 
ray's curvature depends on the 3D gradient along it's path. With the 
stacked boxes method, the gradient is always parallel to one reference 
axis and perpendicular to the other two.
Also, the direction and curvature of that curve can change in a very 
complexe way. That means, in a simple case, 100's of sample points along 
the ray's path, each one of those points will need additional samples to 
find the effective gradient.

A density file can no longer be used as you need a continuous 
transition, while the density file have discreete values.


Anyway, I find it dificult to aprehend the reason why, in this case, you 
may need to use variable ior.


Alain

Post a reply to this message

Alain <aze### [at] qwertyorg> wrote:
> Anyway, I find it dificult to aprehend the reason why, in this case, you
> may need to use variable ior.
>
I'll take a stab in the dark (matter) and guess gravitational lensing.

On a somewhat related note, I'm starting to wonder why scattering media seems to
be the go-to media for visualizing fields.  I've had good luck applying the much
less intensive emission media for this purpose to get a good look at some fairly
gnarly fractal-generating functions.

Post a reply to this message