> > So why not include it to POV ??? If the user thinks his computer is
> > cray-equal than he will use it... If he has no cray he should know
whom's
> > fault it is ...
> > Of course, for developers it will be hard, to confirm the correctness of
> > this feature but why not ???
>
> It is not only processor intensive, it also would be difficult to code.
> A large amount of code would need to be rewritten, and it could be hard
> to get things right for overlapping objects.
I thought the media-code could be used for that, just instead of calculating
the color of the "current particle" change the direction-vector of the
traced ray ???
Quite the idea of adding a new type in the media-part, equal to emission,
absorption and scattering there could be something called
optical_density....
But I think the samplecount in media has to be increased dramatically...

Now, You are the coders ... that was just, what came into my mind ...

--

 ,',    Jan Walzer      \V/  http://wa.lzer.net     ,',
',','   student of      >|<  mailto:jan### [at] lzernet ',','
  '   ComputerScience   /A\  +49-177-7403863         '

Post a reply to this message

Jan Walzer wrote:
> 
> I thought the media-code could be used for that, just instead of calculating
> the color of the "current particle" change the direction-vector of the
> traced ray ???

Well, I am no coder. But if I understand correctly how media works, the problem
is as follows:
To calculate the color of media along a particular ray, first the points are
found where the ray enters and exits the object. Between these points the ray is
divided into a specified number of intervals, and a (variable) number of samples
is taken within each interval.
This method relies upon the ray traversing the volume in a straight line, from
enter to exit. You can probably see why this wouldn't work if the ray were to
curve in an (unpredictable) manner.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

"Margus Ramst" <mar### [at] peakeduee> wrote in message
news:39357143.E4A3D7E7@peak.edu.ee...
| Jan Walzer wrote:
| >
| > I thought the media-code could be used for that, just instead of calculating
| > the color of the "current particle" change the direction-vector of the
| > traced ray ???
|
| Well, I am no coder. But if I understand correctly how media works, the problem
| is as follows:
| To calculate the color of media along a particular ray, first the points are
| found where the ray enters and exits the object. Between these points the ray is
| divided into a specified number of intervals, and a (variable) number of samples
| is taken within each interval.
| This method relies upon the ray traversing the volume in a straight line, from
| enter to exit. You can probably see why this wouldn't work if the ray were to
| curve in an (unpredictable) manner.

I was thinking the refractions were most probably done simply by angling the rays
according to surface geometry, so basically no curvatures of the rays themselves only
straight lines, albeit turned from original directions.  Where curvature comes in,
seems
to me, would be the implementation of this whole idea about variable ior where these
lines of rays would be continously rerouted through the interiors of objects.

Bob

Post a reply to this message

> > I thought the media-code could be used for that, just instead of
calculating
> > the color of the "current particle" change the direction-vector of the
> > traced ray ???
> Well, I am no coder. But if I understand correctly how media works, the
problem
> is as follows:
> To calculate the color of media along a particular ray, first the points
are
> found where the ray enters and exits the object. Between these points the
ray is
> divided into a specified number of intervals, and a (variable) number of
samples
> is taken within each interval.
> This method relies upon the ray traversing the volume in a straight line,
from
> enter to exit. You can probably see why this wouldn't work if the ray were
to
> curve in an (unpredictable) manner.
Yes ... I think this is the way it's working, but
<experiment>
Lets have N intervals
If we say the ray is in the 1st interval on his way. Then we find a new
opt_density value in the media. Now lets bend the ray to the new direction.
By using the new directionvector we could determine two other points, where
(our new) ray intersects. The line between these both could be split again
in N intervals and we only look on the 2nd Point there on. Now we find a new
value and so on ...
Yes, I think this could be way it could be working, but the result will
hardly depend on N. For low N and a very small scaled or high turbulenced
Media it may create rather very obscure things... Sure, the best way would
be, to integrate about the ray, but I think the idea is there, (maybe in
POV4 *g*)
</experiment>

I'll try to find the old discussion about this in my newsreader and think
about it ...
Currently I've not a real Idea of Coding in C so I can't try it on myself,
but maybe someday ...

--

 ,',    Jan Walzer      \V/  http://wa.lzer.net     ,',
',','   student of      >|<  mailto:jan### [at] lzernet ',','
  '   ComputerScience   /A\  +49-177-7403863         '

Post a reply to this message

Jan Walzer wrote:
> 
> <experiment>
[snip]
> </experiment>
> 

Yes, something like this has been suggested and it might work.
My point was that it would require a rewrite of the volume sampling method.
Probably a large one. If you (or anyone else) is willing to try implementing it,
I wish you nothing but the best of luck.
But personally, I think it's not worth the trouble, at least until the average
computer gets considerably faster. Currently, even scattering media has to be
used sparingly. Variable IOR _will_ be worse.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message