> 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

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