 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
jr -
I think it ought to be possible to use the object pattern to do what you want,
if you can apply that to the media.
It's too hot to think over here, and I don't have POV-Ray handy to try a sample
scene - but intuitively it seems like it should be possible.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 18-06-17 à 10:05, jr a écrit :
> hi,
>
> I tried using the 'no_image' object modifier to achieve an effect where one
> (emissive) media filled container, hidden, is intersected by another, visible
> one.
>
> the documentation (3.4.5.5.7) says "..the object will not be seen...will still
> cast shadows, and show up in reflections.."
>
> I read this as: the object is still there but you can't see it. apparently not,
> since the media filled container seems gone completely. :-(
>
> the question then is how can I have an media filled container "out of view" but
> still interact with another, intersecting media filled container?
>
>
> regards, jr.
>
>
With no_image, the object can't be seen directly. That also affect it's
interior including any media.
If you don't want to see the container, you need to give it a fully
transparent texture, with no reflection nor highlights :
pigment{rgbt 1} OR pigment{rgbf 1}
finish{specular 0 phong 0 reflection 0}
Do NOT use rgbft<1,1,1,1,1> as it WILL make the object visible by
screwing up it's transparency.
Don't forget to make the container hollow.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Alain <kua### [at] videotron ca> wrote:
> >
> > the question then is how can I have an media filled container "out of view" but
> > still interact with another, intersecting media filled container?
> With no_image, the object can't be seen directly. That also affect it's
> interior including any media.
> If you don't want to see the container, you need to give it a fully
> transparent texture, with no reflection nor highlights :
> pigment{rgbt 1} OR pigment{rgbf 1}
> finish{specular 0 phong 0 reflection 0}
> Do NOT use rgbft<1,1,1,1,1> as it WILL make the object visible by
> screwing up it's transparency.
ok.
> Don't forget to make the container hollow.
;-)
cheers.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
(nearly overlooked, I still struggle without Thunderbird and its threaded views)
"Bald Eagle" <cre### [at] netscapenet> wrote:
> > I think it ought to be possible to use the object pattern to do what you want,
> if you can apply that to the media.
you mean like WF Pokorny suggests in
http://news.povray.org/5b279884%241%40news.povray.org?
the whole concept is new to me.
> It's too hot to think over here, ...
lucky so and so..
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> you mean like WF Pokorny suggests in
> http://news.povray.org/5b279884%241%40news.povray.org?
Yeah - I just got around to reading through his code before to see that that's
what he was actually doing. I had a hard time implementing it from scratch, as
I'm still struggling with the context and syntax for using patterns in
functions.
POV-Ray didn't like this:
density {
function {pattern {
object {Intersector
color_map {
[0.0 rgb 0]
[0.5 rgb 0]
[0.5 rgb 1]
[1.0 rgb 1]
}
}}
}
}
> the whole concept is new to me.
Try these:
http://www.f-lohmueller.de/pov_tut/tex/tex_560e.htm
http://www.f-lohmueller.de/pov_tut/tex/tex_561e.htm
http://www.f-lohmueller.de/pov_tut/tex/tex_562e.htm
> > It's too hot to think over here, ...
>
> lucky so and so..
Surely you jest. But we got a storm front in last night that whisked away
everything in a sudden downpour. LOTS cooler at the moment. (crossing
fingers)
Hoping you work this out - the idea seems very cool, and I'm _really_ looking
forward to seeing the animation!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Bald Eagle" <cre### [at] netscapenet> wrote:
> > you mean like WF Pokorny suggests in
> > http://news.povray.org/5b279884%241%40news.povray.org?
> Yeah - I just got around to reading through his code before to see that that's
> what he was actually doing. I had a hard time implementing it from scratch, as
> I'm still struggling with the context and syntax for using patterns in
> functions.
>
> POV-Ray didn't like this:
> density {
> function {pattern {
> object {Intersector
> color_map {
> [0.0 rgb 0]
> [0.5 rgb 0]
> [0.5 rgb 1]
> [1.0 rgb 1]
> }
> }}
> }
> }
>
> > the whole concept is new to me.
>
> Try these:
> http://www.f-lohmueller.de/pov_tut/tex/tex_560e.htm
> http://www.f-lohmueller.de/pov_tut/tex/tex_561e.htm
> http://www.f-lohmueller.de/pov_tut/tex/tex_562e.htm
thanks. I will have to get v3.8 installed first though. next couple of days
or so, is the plan.
> Hoping you work this out - the idea seems very cool, and I'm _really_ looking
> forward to seeing the animation!
phew. no pressure then. ;-)
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 18-06-19 à 06:36, Bald Eagle a écrit :
> "jr" <cre### [at] gmailcom> wrote:
>
>> you mean like WF Pokorny suggests in
>> http://news.povray.org/5b279884%241%40news.povray.org?
>
> Yeah - I just got around to reading through his code before to see that that's
> what he was actually doing. I had a hard time implementing it from scratch, as
> I'm still struggling with the context and syntax for using patterns in
> functions.
>
> POV-Ray didn't like this:
> density {
> function {pattern {
> object {Intersector
> color_map {
> [0.0 rgb 0]
> [0.5 rgb 0]
> [0.5 rgb 1]
> [1.0 rgb 1]
> }
> }}
> }
> }
>
Obviously, it don't like that. The object pattern don't support
color_map, but demand 2 colours.
function{pattern{object{Object Colour1, Colour2}}}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> The latest 'Pre_release' has been good to me.
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9606898
thanks. after installing I tried your code, and yes, you were correct, the
scene demonstrates the exact effect I'm after.
so I printed out the code for closer examination. it must have taken me 20 mins
or so before I saw where the colours are coming from (the trailing commas in
user_defined{} did that :-)), and perhaps as long again to understand why the
enclosing sphere doesn't display in white.
I thought I now have a handle on this - until I changed the green component of
the user_defined from multiply to add. :-) and now I have more questions..
so, I do not understand why the multiplication and addition differ. I get the
changed colours, but not why the part of the hidden sphere which does not
intersect the reveal box only shows when added or why it doesn't when
multiplied.
another question regards the actual density of box and hidden sphere. their
densities decrease away from the centres because functions are used, I presume.
how would one get an uniformly dense box and/or sphere? is a DF3 needed?
and, last question, is there a particular reason that the media colour is rgb
while all other colours are sRGB?
thank you again for the code (and your time), I feel I'm learning.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/21/2018 04:48 AM, jr wrote:
> hi,
>
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> The latest 'Pre_release' has been good to me.
>> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9606898
>
> thanks. after installing I tried your code, and yes, you were correct, the
> scene demonstrates the exact effect I'm after.
>
> so I printed out the code for closer examination. it must have taken me 20 mins
> or so before I saw where the colours are coming from (the trailing commas in
> user_defined{} did that :-)), and perhaps as long again to understand why the
> enclosing sphere doesn't display in white.
>
> I thought I now have a handle on this - until I changed the green component of
> the user_defined from multiply to add. :-) and now I have more questions..
>
> so, I do not understand why the multiplication and addition differ. I get the
> changed colours, but not why the part of the hidden sphere which does not
> intersect the reveal box only shows when added or why it doesn't when
> multiplied.
The object pattern returns 0 or 1. Where we have the reveal box for the
red channel, the density value is always 1.0 and we always see that box.
To reveal the hidden sphere only where the reveal box exists we're using
the green channel and multiplication. Only where we have 1(reveal
box)*1(hidden sphere) in the green channel does it turn on (=1) and red
and green now mix to get yellow for box samples within the hidden
sphere. Outside the reveal box where have 0(reveal box)*1(hidden sphere)
or 0 for density.
When you use addition instead for the green channel of the reveal box is
also on inside the box (as already was red) and you get yellow for the
box alone. The sphere is 1 where points are inside so you get green for
the parts which are outside the reveal box. Inside the reveal box you
get 1+1 green channel density and a more intense yellow green where they
mix.
>
> another question regards the actual density of box and hidden sphere. their
> densities decrease away from the centres because functions are used, I presume.
> how would one get an uniformly dense box and/or sphere? is a DF3 needed?
>
The densities in the original implementation are 1 or 0 inside the
reveal box. The apparent density decrease you see is due the differences
in path length through the constant the density. In other words each
ray's travel time through the density is different. When using emissive
media this means the longer travel distances end up brighter. You can
normalize to degrees in various ways, but up front I'd suggest adding
absorbing media also at 1/white to start. As rays travel further the
more absorption you get.
> and, last question, is there a particular reason that the media colour is rgb
> while all other colours are sRGB?
>
The media spec could be srgb so long as you understand the resulting
internal linear rgb values, but with densities and media it's much
easier to work and think in linear, 'assumed_gamma 1.0' space.
> thank you again for the code (and your time), I feel I'm learning.
Happy to help - it's an interesting challenge.
>
> regards, jr.
>
Aside: In the code the overall media container encloses the reveal and
hidden shapes. In an actual implementation you likely want your reveal
object to also be your media container for performance reasons.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 18-06-21 à 04:48, jr a écrit :
> hi,
>
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> The latest 'Pre_release' has been good to me.
>> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9606898
>
> thanks. after installing I tried your code, and yes, you were correct, the
> scene demonstrates the exact effect I'm after.
>
> so I printed out the code for closer examination. it must have taken me 20 mins
> or so before I saw where the colours are coming from (the trailing commas in
> user_defined{} did that :-)), and perhaps as long again to understand why the
> enclosing sphere doesn't display in white.
>
> I thought I now have a handle on this - until I changed the green component of
> the user_defined from multiply to add. :-) and now I have more questions..
>
> so, I do not understand why the multiplication and addition differ. I get the
> changed colours, but not why the part of the hidden sphere which does not
> intersect the reveal box only shows when added or why it doesn't when
> multiplied.
>
> another question regards the actual density of box and hidden sphere. their
> densities decrease away from the centres because functions are used, I presume.
> how would one get an uniformly dense box and/or sphere? is a DF3 needed?
>
> and, last question, is there a particular reason that the media colour is rgb
> while all other colours are sRGB?
>
> thank you again for the code (and your time), I feel I'm learning.
>
>
> regards, jr.
>
>
>
>
The actual effect of all media depend on how long is the path through
them as well as it's density. Double the path's length and you double
it's contribution.
Next, that density can get affected with some pattern, like spotted,
granite, spherical, planar, ... You don't need to use any DF3.
If you don't use any pattern, then the media's density is uniform and
only the length of the paths through it will affect the end result.
Using an orthographic camera parallel to an axis and a container/pattern
aligned to the axis can ensure that all paths are of the same length. In
all other cases, you can't be sure that all paths have the same length
unless you are extremely careful.
Take those colours : rgb<1,0,0.5> and rgb<0,1,0.5>
When you multiply them, you get :
Mult = <1,0,0.5>*<0,1,0.5> = <1*0, 0*1, 0.5*0.5> = <0,0,0.25> (dark blue)
When you add then, you get :
Add = <1,0,0.5>+<0,1,0.5> = <1+0, 0+1, 0.5+0.5> = <1,1,1> (white)
That's when working in rgb or linear colour space.
If you use srgb instead, the actual values you give are gamma adjusted
before the rendering start. If all of the colour components are 0 or 1,
then, it makes no difference to use rgb or srgb. In all other cases,
there is a difference.
rgb<0.1, 0.5, 0.8> is not the same as srgb<0.1, 0.5, 0.8>
Whenever you have additive effects to take into account, you need to
work in linear colour space to get accurate results. That's why it's
highly recommended to always use "assumed_gamma 1" in the
global_settings block.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
