 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Radiosity still bears its mysteries, even to me - must be some magic in
there...
*This* is what I'd call a lighting challenge... quite pathological case,
I must confess: The door is almost closed, leaving no direct path of
light to the adjacent room whatsoever. Unfortunately, the high radiosity
recursion depth makes the light not only "seep" through the gap, but
also through the walls.
Well, I thought I'd share it anyway. It's a lot better already than
earlier experiments with the setting.
Render time: Days. Something around 48 hours I guess.
Post a reply to this message
Attachments:
Download 'the_secret.png' (860 KB)
Preview of image 'the_secret.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> Radiosity still bears its mysteries, even to me - must be some magic in
> there...
>
> *This* is what I'd call a lighting challenge... quite pathological case,
> I must confess: The door is almost closed, leaving no direct path of
> light to the adjacent room whatsoever. Unfortunately, the high radiosity
> recursion depth makes the light not only "seep" through the gap, but
> also through the walls.
>
> Well, I thought I'd share it anyway. It's a lot better already than
> earlier experiments with the setting.
>
> Render time: Days. Something around 48 hours I guess.
I remember that scene when someone was trying to figure out how to make it work
(i.e. complete before their great-great-grandchildren are born) in MCPov. I did
get it working, but it wasn't the whole scene, just the doors and walls. The
answer had to do portals and making sure that the container sphere wasn't too
large. After that, it started to converge reasonably quickly (instead of the
wait 20 minutes, see single bright pixel appear, wait 20 more, see it
disappear). Anyway, isn't that bleed through more of an error bound and reuse
of samples issue as opposed to depth?
-Reactor
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Reactor schrieb:
> I remember that scene when someone was trying to figure out how to make it work
> (i.e. complete before their great-great-grandchildren are born) in MCPov.
That was me I guess :-)
> I did
> get it working, but it wasn't the whole scene, just the doors and walls. The
> answer had to do portals and making sure that the container sphere wasn't too
> large. After that, it started to converge reasonably quickly (instead of the
> wait 20 minutes, see single bright pixel appear, wait 20 more, see it
> disappear).
Yes, I recall someone giving it a try also (the scene didn't feature the
child back then) - but IIRC that person "cheated" by having the door
open much wider...
I'm also using a POV-Ray 3.7 beta feature for the child's clothing
(diffuse backside illumination), so MCPov is no longer an option anyway.
> Anyway, isn't that bleed through more of an error bound and reuse
> of samples issue as opposed to depth?
If I had the slightest idea what kind of error it is, I'd be a good deal
happier :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Reactor schrieb:
>
> > I remember that scene when someone was trying to figure out how to make it work
> > (i.e. complete before their great-great-grandchildren are born) in MCPov.
>
> That was me I guess :-)
>
> > I did
> > get it working, but it wasn't the whole scene, just the doors and walls. The
> > answer had to do portals and making sure that the container sphere wasn't too
> > large. After that, it started to converge reasonably quickly (instead of the
> > wait 20 minutes, see single bright pixel appear, wait 20 more, see it
> > disappear).
>
> Yes, I recall someone giving it a try also (the scene didn't feature the
> child back then) - but IIRC that person "cheated" by having the door
> open much wider...
>
I never posted the results for that - the scene was really my first introduction
to MCPov and I got it working much later without changing the scene as posted,
albeit before my rebuild. I do not have the scene anymore, but I have trouble
running MCPov on this machine anyway.
> I'm also using a POV-Ray 3.7 beta feature for the child's clothing
> (diffuse backside illumination), so MCPov is no longer an option anyway.
>
If you don't mind posting it, I am curious as to how your radiosity block looks.
> > Anyway, isn't that bleed through more of an error bound and reuse
> > of samples issue as opposed to depth?
>
> If I had the slightest idea what kind of error it is, I'd be a good deal
> happier :-)
I hope the walls are of realistic thickness, and not a single flat polygon!
-Reactor
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Reactor schrieb:
>> Yes, I recall someone giving it a try also (the scene didn't feature the
>> child back then) - but IIRC that person "cheated" by having the door
>> open much wider...
>
> I never posted the results for that - the scene was really my first introduction
> to MCPov and I got it working much later without changing the scene as posted,
> albeit before my rebuild. I do not have the scene anymore, but I have trouble
> running MCPov on this machine anyway.
That must have been someone else then. But as I said, MCPov is no longer
an option for me anyway (not for this case at any rate).
>> I'm also using a POV-Ray 3.7 beta feature for the child's clothing
>> (diffuse backside illumination), so MCPov is no longer an option anyway.
>
> If you don't mind posting it, I am curious as to how your radiosity block looks.
As it is undergoing frequent experimental changes I'd need to
reconstruct it first from the current settings.
>> > Anyway, isn't that bleed through more of an error bound and reuse
>>> of samples issue as opposed to depth?
>> If I had the slightest idea what kind of error it is, I'd be a good deal
>> happier :-)
>
> I hope the walls are of realistic thickness, and not a single flat polygon!
Not only do they possess true volume of course - they also have their
interior texture set to pitch black, and another pitch black core
occupying 80% of the walls' inside... still no luck.
I guess the main problem is that I need very bright light in the
adjacent room, so that even a radiosity sample deemed to have a "quality
rating" as low as 0.1% on this side of the door will still have a
noticeable effect.
I'm thinking of changing the interpretation of the nearest_count
parameter: While it is currently interpreted simply as the desired
number of valid samples in the vicinity of any given point - however
low-quality they might be - I think it would be better to interpret it
as the desired "quality rating sum", i.e. a setting of 10 could be
satisfied by e.g. 10 samples of 100% quality or 100 samples of 10%
quality. This would (hopefully) lead to more high-quality samples to be
gathered, which would result in a stronger suppression of the
low-quality ones.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Radiosity still bears its mysteries, even to me - must be some magic in
> there...
>
> *This* is what I'd call a lighting challenge... quite pathological case,
> I must confess: The door is almost closed, leaving no direct path of
> light to the adjacent room whatsoever. Unfortunately, the high radiosity
> recursion depth makes the light not only "seep" through the gap, but
> also through the walls.
>
> Well, I thought I'd share it anyway. It's a lot better already than
> earlier experiments with the setting.
>
> Render time: Days. Something around 48 hours I guess.
>
Nice one. Brings back some prety old memories...
Some suggestions for the light going through the wall:
Add interior_texture{rgb 0 ambient 0 diffuse0} to the walls.
Make the walls thicker and have them penetrate the floor.
Place a box, or two, inside the wall, make them ambient -1 to absorb
leaking light.
Stop the floor under the wall, and make the inner box extend well below
the floor.
Add a plynth along the base of the wall. This will also add some
realism, as all houses walls have those.
Around the door, increase the overlap between the wall and the door frame.
Depending on the scale of the scene, scale it up by a factor of 2, 3 or 4.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Reactor schrieb:
>
>>> Yes, I recall someone giving it a try also (the scene didn't feature the
>>> child back then) - but IIRC that person "cheated" by having the door
>>> open much wider...
>>
>> I never posted the results for that - the scene was really my first
>> introduction
>> to MCPov and I got it working much later without changing the scene as
>> posted,
>> albeit before my rebuild. I do not have the scene anymore, but I have
>> trouble
>> running MCPov on this machine anyway.
>
> That must have been someone else then. But as I said, MCPov is no longer
> an option for me anyway (not for this case at any rate).
>
>>> I'm also using a POV-Ray 3.7 beta feature for the child's clothing
>>> (diffuse backside illumination), so MCPov is no longer an option anyway.
>>
>> If you don't mind posting it, I am curious as to how your radiosity
>> block looks.
>
> As it is undergoing frequent experimental changes I'd need to
> reconstruct it first from the current settings.
>
>
>>> > Anyway, isn't that bleed through more of an error bound and reuse
>>>> of samples issue as opposed to depth?
>>> If I had the slightest idea what kind of error it is, I'd be a good deal
>>> happier :-)
>>
>> I hope the walls are of realistic thickness, and not a single flat
>> polygon!
>
> Not only do they possess true volume of course - they also have their
> interior texture set to pitch black, and another pitch black core
> occupying 80% of the walls' inside... still no luck.
>
> I guess the main problem is that I need very bright light in the
> adjacent room, so that even a radiosity sample deemed to have a "quality
> rating" as low as 0.1% on this side of the door will still have a
> noticeable effect.
>
> I'm thinking of changing the interpretation of the nearest_count
> parameter: While it is currently interpreted simply as the desired
> number of valid samples in the vicinity of any given point - however
> low-quality they might be - I think it would be better to interpret it
> as the desired "quality rating sum", i.e. a setting of 10 could be
> satisfied by e.g. 10 samples of 100% quality or 100 samples of 10%
> quality. This would (hopefully) lead to more high-quality samples to be
> gathered, which would result in a stronger suppression of the
> low-quality ones.
I see that you alweady implemented at least 2 of my suggestions.
Maybe you'll have more luck using 2 cores, each roughly 1/3 or 1/4 the
thickness of the wall.
Try a pigment rgb -1 for the core.
Maybe adding some high density absorbing media inside the wall could help.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> That must have been someone else then. But as I said, MCPov is no longer
> an option for me anyway (not for this case at any rate).
AIUI the modifications made to POV 3.6 to get MCPov were not huge, I wonder
if there are any blocking points to prevent the same being applied to the
official POV 3.7 release?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Reactor schrieb:
>
>>> Yes, I recall someone giving it a try also (the scene didn't feature the
>>> child back then) - but IIRC that person "cheated" by having the door
>>> open much wider...
>>
>> I never posted the results for that - the scene was really my first
>> introduction
>> to MCPov and I got it working much later without changing the scene as
>> posted,
>> albeit before my rebuild. I do not have the scene anymore, but I have
>> trouble
>> running MCPov on this machine anyway.
>
> That must have been someone else then.
IIRC, I was the cheater... ;)
--
Jaime Vives Piqueres
http://www.ignorancia.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott schrieb:
>> That must have been someone else then. But as I said, MCPov is no
>> longer an option for me anyway (not for this case at any rate).
>
> AIUI the modifications made to POV 3.6 to get MCPov were not huge, I
> wonder if there are any blocking points to prevent the same being
> applied to the official POV 3.7 release?
There's one potential stumbling block: The "main loop", as I'd call it.
In order to implement SMP this has changed quite a lot. Re-starting the
render phase over and over again might not be as easy as it was in 3.6.
Aside from that, I guess applying the MCPov magic to POV 3.7 should be
as easy as eating pancakes, at least for someone familiar with the inner
workings of both MCPov and POV 3.7 - given a bit of time.
I hope, however, that whoever picks up that glove will not copy MCPov
behaviour 1:1, as I recently found out that MCPov gets diffuse
illumination wrong by what appears to be a factor of 2 in brightness.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
