 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
I've read http://radsite.lbl.gov/radiance/papers/erw92/paper.pdf which
explains how to use irradiance gradient (rotational (rotation of the normal)
and translational (sample point translated)) to improve extrapolation of
radiosity between sampling locations. Then I looked at pov source and I
didn't recognize anything in the gradient it calculate, in fact I don't
understand what exactly is this gradient... I tried to desactivate it then
render some radiosity scenes but see no differences ! I may have done
something wrong, so if anyone can confirm this .. ?
The rotational gradient seems easy to add to pov radiosity, but the
translational gradient is more difficult to implement (because it uses
radiance differences between neightboring samples)
M
Post a reply to this message
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: Irradiance gradient & radiosity
Date: 15 Mar 2003 06:25:18
Message: <3E730D9E.D907251A@gmx.de>
|
|
|
| |
| |
|
|
Mael wrote:
>
> Hello,
>
> I've read http://radsite.lbl.gov/radiance/papers/erw92/paper.pdf which
> explains how to use irradiance gradient (rotational (rotation of the normal)
> and translational (sample point translated)) to improve extrapolation of
> radiosity between sampling locations. Then I looked at pov source and I
> didn't recognize anything in the gradient it calculate, in fact I don't
> understand what exactly is this gradient... I tried to desactivate it then
> render some radiosity scenes but see no differences ! I may have done
> something wrong, so if anyone can confirm this .. ?
> The rotational gradient seems easy to add to pov radiosity, but the
> translational gradient is more difficult to implement (because it uses
> radiance differences between neightboring samples)
I am not sure if i understand you correctly but POV-Ray already calculates
and uses the translational gradients of the illumination values to improve
the results. I have not tried to deactivate this with the RAD_GRADIENT
switch but i guess this would make a difference.
Concerning what irradiance gradients are - they are the rate at which the
illumination changes when changing certain variables, in case of the
translational gradients when changing the position. How this is estimated
is described in the paper you cited.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ok sorry, I manage to build a simple scene that clearly shows the effect of
the gradient
http://195.221.122.126/gradients/plan_radgrad.png
http://195.221.122.126/gradients/plan_radnograd.png
As a test I tried to replace pov translational gradient by a rotational
gradient. Here are some results :
Radiosity parameters :
pretrace_start 0.04
pretrace_end 0.02
count 450
recursion_limit 1
nearest_count 5
error_bound .5
official pov
http://195.221.122.126/gradients/cornell_rad_eb.5c450_pov35.png
halton sampling, pov translational gradient
http://195.221.122.126/gradients/cornell_rad_eb.5c450_halton_povgrad.png
halton sampling, no gradients
http://195.221.122.126/gradients/cornell_rad_eb.5c450_halton_nograd.png
halton sampling, rotational gradient
http://195.221.122.126/gradients/cornell_rad_eb.5c450_halton_rotgrad.png
all scenes = 500 ko
(as always it's easier to see the differences with an image viewer to
quickly switch between images)
M
Post a reply to this message
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: Irradiance gradient & radiosity
Date: 16 Mar 2003 07:53:26
Message: <3E7473C7.6490ADD2@gmx.de>
|
|
|
| |
| |
|
|
Mael wrote:
>
> Ok sorry, I manage to build a simple scene that clearly shows the effect of
> the gradient
> http://195.221.122.126/gradients/plan_radgrad.png
> http://195.221.122.126/gradients/plan_radnograd.png
>
> As a test I tried to replace pov translational gradient by a rotational
> gradient. Here are some results :
>
> [...]
The results look quite how you would expect them i think - rotational
gradients improving results on curved surfaces. But the lighting on the
spheres looks somewhat wrong, at least quite different from the other
images. A test with higher quality (i.e. less disturbing artefacts) would
be good.
In practical situations artefacts on flat surfaces are often more relevant
though. Therefore i would not remove the translational version. Note the
difference in the ceiling appearance in front of the light. It would also
be important to test with real light sources in the scene since this is
the more common situation.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The results look quite how you would expect them i think - rotational
> gradients improving results on curved surfaces.
yes it's logical
> But the lighting on the
> spheres looks somewhat wrong, at least quite different from the other
> images.
How wrong ? I see a smoother lightning
Side note : all those images have the 0 1 clipping done by pov on prediction
value (IMHO this clipping should be removed..)
> In practical situations artefacts on flat surfaces are often more relevant
> though. Therefore i would not remove the translational version.
Right, But a final aim would not be to replace or remove translational
gradient, but to have translational+rotational gradients
> Note the
> difference in the ceiling appearance in front of the light.
concerning ceiling (and the top of back wall) I think it's more a problem of
low sampling at angles = 90° / normal than anything else
> It would also
> be important to test with real light sources in the scene since this is
> the more common situation.
For test scenes I prefer to use radiosity only as it's easier to see what
happens.
None the less for real scenes I'm not sure the gradient is really useful.
For example when you render a scene using a 2 pass method (with a second
pass with sample off) you don't use irradiance gradient at all (it is not
saved in the file)
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Side note : all those images have the 0 1 clipping done by pov on
prediction
> value (IMHO this clipping should be removed..)
Same parameters, with rotational gradient, (so compare to
cornell_rad_eb.5c450_halton_rotgrad.png) but with no clipping (the 'light'
is rgb 1 ambient 7.8)
http://195.221.122.126/gradients/cornell_rad_eb.5c450_rotgrad_noclipping.png
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 17 Mar 2003 17:59:14 +0100, Mael wrote:
>> Side note : all those images have the 0 1 clipping done by pov on
> prediction
>> value (IMHO this clipping should be removed..)
>
> Same parameters, with rotational gradient, (so compare to
> cornell_rad_eb.5c450_halton_rotgrad.png) but with no clipping (the 'light'
> is rgb 1 ambient 7.8)
> http://195.221.122.126/gradients/cornell_rad_eb.5c450_rotgrad_noclipping.png
>
> M
Ah, this clipping may explain why whenever I try to use ambient
objects/emission media as light sources it NEVER works! (All I see are a
few dull splotches)
--
light_source#macro G(E)sphere{z+E*y*5e-3.04rotate-z*E*6pigment{rgbt#end{
20*y-10#local n=162;1}#while(n)#local n=n-.3;G(n)x}}G(-n).7}}#end//GregE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Ah, this clipping may explain why whenever I try to use ambient
> objects/emission media as light sources it NEVER works! (All I see are a
> few dull splotches)
I was talking about it.... 2 weeks ago...
But Christoph said that I am the "bad man" because I am attacking POV community :)
OK till next sunday will provide patch for clipping removement and
full implementation of gradients... because there is no translational gradient in
current POV implementation... only rotational... because its cheap to calculate.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 18 Mar 2003 09:10:14 +0100, "T.J.Viking" <vik### [at] bp-domar pl> wrote:
> I was talking about it.... 2 weeks ago...
> But Christoph said that I am the "bad man" because I am attacking POV community :)
False claims. You were "bad man" because the wrong way helping in fixing it. You
demanded better quality but at that time refused to be responsible for making it
better and share you knowledge. The discussion was inspired by HDRI/radiosity
but was concerned about behaviour in opensourced-like community.
> OK till next sunday will provide patch
You said you have knowledge. You said mistakes are obvious. But you need three
weeks to fix it. Other patchers and Team members works on much more complicated
tasks spending months on some additions. I hope you understand now why
complaining without exact arguments and source code quotation is so annoying.
I really wait for your patch.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> False claims. You were "bad man" because the wrong way helping in fixing it. You
> demanded better quality but at that time refused to be responsible for making it
> better and share you knowledge. The discussion was inspired by HDRI/radiosity
> but was concerned about behaviour in opensourced-like community.
ok,ok :) EOT in this subject for me...
> > OK till next sunday will provide patch
>
> You said you have knowledge. You said mistakes are obvious. But you need three
> weeks to fix it. Other patchers and Team members works on much more complicated
> tasks spending months on some additions. I hope you understand now why
> complaining without exact arguments and source code quotation is so annoying.
I never said I will need three weeks to fix it....
You can fix it in 30-60 minutes...
But testing and providing stable patch is another matter, and having a lot of time
in the nowadays world.... is another hard try.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> OK till next sunday will provide patch for clipping removement and
Or a keyword "clipping" on/off in the radiosity block so the user have the
choice
> full implementation of gradients... because there is no translational
gradient in
> current POV implementation... only rotational... because its cheap to
calculate.
AFAICS it's the opposite, translational gradient (I admit I don't understand
how it is calculated in pov) but no rotational gradient. A problem in adding
another gradient is that it will cost a lot of memory (the existing gradient
already uses 3*3*sizeof(float) for each gather location !). Plus, for low
error_bound the gather locations get closer and the gradients become less
usefull (maybe a keywork to deactivate the gradient could be interesting for
people who want to save some RAM in those cases with many gather locations,
or for people who use only gather locations from a saved radiosity file)
Yet, I'll be happy to test your patch :)
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 18 Mar 2003 09:40:05 +0100, "T.J.Viking" <vik### [at] bp-domarpl> wrote:
> I never said I will need three weeks to fix it....
"2 weeks ago... [...] till next sunday "
2 weeks + 1 week = 3 weeks
> You can fix it in 30-60 minutes...
Perhaps, but this requires some assumptions about patcher:
1. I'm not concerned on other tasks.
2. Understand radiosity source
3. Have knowledge about radiosity theory.
It looked like from your words you fits those assumptions.
> But testing and providing stable patch is another matter, and having a lot of time
> in the nowadays world.... is another hard try.
Exactly!!! You starting to understand complexity of povray development :-)
I tried to make light version of complaining you directed to Community and you
quickly proved that you are affected with the same problems every coder has:
real life, testing, documenting and making patching stable - they are all part
of fixing.
I hope your changes will be worth of inclusion in http://megapov.inetart.net/
(finally up again).
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> AFAICS it's the opposite, translational gradient (I admit I don't understand
> how it is calculated in pov) but no rotational gradient. A problem in adding
> another gradient is that it will cost a lot of memory (the existing gradient
> already uses 3*3*sizeof(float) for each gather location !). Plus, for low
> error_bound the gather locations get closer and the gradients become less
> usefull (maybe a keywork to deactivate the gradient could be interesting for
> people who want to save some RAM in those cases with many gather locations,
> or for people who use only gather locations from a saved radiosity file)
> Yet, I'll be happy to test your patch :)
IMHO gradients can be removed totally from this implementation.
The reason is we can use better interpolation techniques and
give more oversampling of irradiance gathers in those areas where
variance is bigger. Another speeding up technique is to not use so
much samples during gather in areas partially occluded by nearby
objects... we can obtain this info from average distance to
objects calculated during hemisphere gather.
And one more which would conserve memory.... resign from
floats in normals stored in irradiance cache.. it can be stored in polar
coordinates (only 2 bytes) instead of 3 floats... when
irradiance map count reaches a few milions... it would be nice
idea to free some memory.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Exactly!!! You starting to understand complexity of povray development :-)
I am not starting to understand.. I understanded it for 13 years of programming...
gosh I am so old :) sic!
> I tried to make light version of complaining you directed to Community and you
> quickly proved that you are affected with the same problems every coder has:
> real life, testing, documenting and making patching stable - they are all part
> of fixing.
OK, stop this flame war :)
I wasn't complaining, my intention was to know if people need any changes...
If their are happy with current "radiosity"... OK let them live, if they are
sad because their renders render 72 hours or 54 days... let's help them...
And what can I say... I haven't seen any enthusiasm there... maybe this is
not so needed... maybe we should concern some other features and leave
GI alone..
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 18 Mar 2003 10:10:30 +0100, "T.J.Viking" <vik### [at] bp-domarpl> wrote:
> > Exactly!!! You starting to understand complexity of povray development :-)
>
> I am not starting to understand.. I understanded it for 13 years of programming...
gosh I am so old :) sic!
Can you refer released patches to povray source code? Other contributions to its
development?
> > I tried to make light version of complaining you directed to Community and you
> > quickly proved that you are affected with the same problems every coder has:
> > real life, testing, documenting and making patching stable - they are all part
> > of fixing.
>
> OK, stop this flame war :)
That's not a war. That's about guidelines of contributing, thought I do not
represent anybody in my opinions but I feel part of community.
> I wasn't complaining, my intention was to know if people need any changes...
Can you refer in what post you asked if somebody need your fixes ? I remember:
"Your problems are not my problems, I can live with it how POV is working."
> If their are happy with current "radiosity"... OK let them live, if they are
> sad because their renders render 72 hours or 54 days... let's help them...
Did you decided to release patch before hearing our arguments?
> And what can I say... I haven't seen any enthusiasm there...
Do you work only when enthusiasm is showed??? Do you have internal opinion that
you think correct way? Then patch it and release. Simple.
Moreover hard to expect much enthusiasm if I can count no more 5 person who
understand radiosity source code. Artists will appreciate your work _after_
releasing working, well documented patch.
ABX
Post a reply to this message
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: Irradiance gradient & radiosity
Date: 18 Mar 2003 04:43:09
Message: <3E76EA2D.A7977880@gmx.de>
|
|
|
| |
| |
|
|
Mael wrote:
>
> > Side note : all those images have the 0 1 clipping done by pov on
> prediction
> > value (IMHO this clipping should be removed..)
>
> Same parameters, with rotational gradient, (so compare to
> cornell_rad_eb.5c450_halton_rotgrad.png) but with no clipping (the 'light'
> is rgb 1 ambient 7.8)
> http://195.221.122.126/gradients/cornell_rad_eb.5c450_rotgrad_noclipping.png
This complies with the observations i made, the difference is not much
visible in most cases but it can lead to problems in special situations
like bright ambient objects or light sources. See for example:
http://www.schunter.etc.tu-bs.de/~chris/files/rad_clip.png
http://www.schunter.etc.tu-bs.de/~chris/files/rad_no_clip.png
I think a switch for turning clipping on or off will be a good idea, i
planned something like that too.
Concerning rotational vs. translational gradients - as i already said i
think both have their uses. I'd probably also introduce a switch for that
and make some more testing in practice. Note that the gradients are not
stored in the rad cache file right now anyway.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > I am not starting to understand.. I understanded it for 13 years of programming...
gosh I am so old :) sic!
>
> Can you refer released patches to povray source code? Other contributions to its
> development?
Nope :)
But I studied POV sources for years, side by side with my own developement and
side by side with other sources... its beutifull source of knowledge to see someones
code.
> > I wasn't complaining, my intention was to know if people need any changes...
> Can you refer in what post you asked if somebody need your fixes ? I remember:
> "Your problems are not my problems, I can live with it how POV is working."
>
> > If their are happy with current "radiosity"... OK let them live, if they are
> > sad because their renders render 72 hours or 54 days... let's help them...
>
> Did you decided to release patch before hearing our arguments?
Yes. I was using POV GI for very long period and wasn't satisfied with results.
I am planning to use it in the future... so one and only way is to patch it...
> > And what can I say... I haven't seen any enthusiasm there...
>
> Do you work only when enthusiasm is showed??? Do you have internal opinion that
> you think correct way? Then patch it and release. Simple.
Enthusiasm speeds up developement.. specially in free/open source projects.
When there is no enthusiasm... there is no need for further developement.. project
dies...
> Moreover hard to expect much enthusiasm if I can count no more 5 person who
> understand radiosity source code. Artists will appreciate your work _after_
> releasing working, well documented patch.
Count me as that 6-th :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
the bigges horror was to render those ones.. with POV GI...
http://www.cgarchitect.com/gallery/galleryList.asp?searchName=2600&searchChecked=1
that was the time.. when I switched to other renderers
rendering times for print quality (3500x2500) was something like 30-60 hours on
TB1.2Ghz ... geometry counts was from 1M polys to 10M polys.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I do not understand this part of the source code, but I certainly welcome any
improvements to it! :-)
>
> Enthusiasm speeds up developement.. specially in free/open source projects.
> When there is no enthusiasm... there is no need for further developement.. project
dies...
>
Drifting a little off topic I think life moves through stages when it comes to
our contributions to others.
Early in life we have the time, but not the ability or determination.
Later we have the ability and determination, but not enough time.
We end life without the ability, the determination or the time.
Perhaps we are all stuck doing the best we can at any given moment.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I think a switch for turning clipping on or off will be a good idea, i
> planned something like that too.
Isn't that what the max_sample keyword is for? It seems like its
implementation is incomplete in the current version. In the documentation,
it says, "Specifying a non-positive value for max_sample will allow any
brightness of samples (which is the default)." Guess, 'any brightness'
really means, 'no brighter than 100%'. ;-)
PS. Does prodding with the code to get a no_radiosity hack to work count as
understanding it? I'm guessing it doesn't...
--
light_source#macro G(E)sphere{z+E*y*5e-3.04rotate-z*E*6pigment{rgbt#end{
20*y-10#local n=162;1}#while(n)#local n=n-.3;G(n)x}}G(-n).7}}#end//GregE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
