Chris Cason wrote:

>   Radiosity
>   ---------
> 
>   Radiosity has been re-enabled. Currently it is limited to a single thread
>   and has some issues. As stated for dispersion, we would appreciate assistance
>   in determining where individual issues lie and what influences them.
> 
>   Multi-thread support will be added later, once the radiosity code settles
>   down and is functioning as expected in single-thread mode.

No "radiosity mosaic", now?

This tripped me up a bit. (thinking POV-Ray had hung)

-- 
~Mike

Things! Billions of them!

Post a reply to this message

Mike Raiford wrote:
> No "radiosity mosaic", now?
> 
> This tripped me up a bit. (thinking POV-Ray had hung)

No, no progress reporting for that yet.

	Thorsten

Post a reply to this message

Raf256 wrote:
> Perhaps any chances for releasing linux binary as well?

This really has been answered more than once now in this group!!!  But as 
usual, Raf256 cannot be expected to read old messages and has to ask again :-(

	Thorsten

Post a reply to this message

Mike Raiford wrote:
> One question: b9 seems to complain about the assumed_gamma setting in 
> the scene files. I know to look write a lot of scenes requre their own 
> assumed_gamma setting, now it needs to be on the command line?

Yes, and if you really need to play with assumed_gamma, you are actually 
using it for something it isn't supposed to be used for (adjusting the 
brightness of a scene).  There will be other mechanisms for doing that 
eventually (also on the command-line though).

In case you are wondering why this (and a few other) changes are necessary, 
it has to do with the division of work between the various parts inside 
POV-Ray.  Now that we have a clear structure (in POV-Ray 3.7) various logic 
problems surface that simply did not matter before (where everybody was just 
getting their data where they wanted).  Essentially this setting and a few 
others should never have been in the scene file for this reason, but nobody 
noticed back when it was added.  Over time more patches added things to the 
global settings that they should have been command-line settings as well. 
So now we clean it us.  The upside is, this will make developing newer 
versions of POV-Ray a lot easier and faster because the chance to cause a 
bug by some minor change that some other end of the code depends on its a 
whole lot smaller.

> Since it does require a command line option, enlighten me on what it is?

The same one it used to be in the scene file ;-)

	Thorsten

Post a reply to this message

Thorsten Froehlich wrote:
> Mike Raiford wrote:
> 
>> One question: b9 seems to complain about the assumed_gamma setting in 
>> the scene files. I know to look write a lot of scenes requre their own 
>> assumed_gamma setting, now it needs to be on the command line?
> 
> 
> Yes, and if you really need to play with assumed_gamma, you are actually 
> using it for something it isn't supposed to be used for (adjusting the 
> brightness of a scene).  There will be other mechanisms for doing that 
> eventually (also on the command-line though).

Wow. Glad you made sense of what I wrote (I think I was short on 
caffiene at the time ;). Yes, this is what I was using it for, mainly in 
radiosity scenes it seems to bring out the shadows a bit more. A better 
alternative to this might be something like the tone-mapping patch in 
MegaPOV (I don't know if it is technically feasable, given your 
explanations of the assumed_gamma issue)

Anyway, I was wondering, becuase it seemed like the assumed_gamma 
commandline option wasn't having an effect.

> In case you are wondering why this (and a few other) changes are 
> necessary, it has to do with the division of work between the various 
> parts inside POV-Ray.  Now that we have a clear structure (in POV-Ray 
> 3.7) various logic problems surface that simply did not matter before 
> (where everybody was just getting their data where they wanted).  
> Essentially this setting and a few others should never have been in the 
> scene file for this reason, but nobody noticed back when it was added.  
> Over time more patches added things to the global settings that they 
> should have been command-line settings as well. So now we clean it us.  
> The upside is, this will make developing newer versions of POV-Ray a lot 
> easier and faster because the chance to cause a bug by some minor change 
> that some other end of the code depends on its a whole lot smaller.
> 

In the end, I think this will be very positive for the program, this 
seems to be what is making this such a long beta cycle and breaking so 
many things.

-- 
~Mike

Things! Billions of them!

Post a reply to this message

Mike Raiford wrote:
> Anyway, I was wondering, becuase it seemed like the assumed_gamma 
> commandline option wasn't having an effect.

It won't yet, that part isn't implemented yet.  With gamma the only thing 
that changed was the warning message between beta 8 and beta 9, the frontend 
doesn't make any use of gamma yet.

> In the end, I think this will be very positive for the program, this 
> seems to be what is making this such a long beta cycle and breaking so 
> many things.

Well, the beta cycle for POV-Ray 3.5 was well over half a year with iirc 18 
public releases.  So we are within the usual timeframe I suppose :-)

	Thorsten

Post a reply to this message

One thing I neglected to mention is that radiosity save/load isn't
implemented at the moment, so please don't be surprised if it doesn't
work ...

-- Chris

Post a reply to this message

Moving assumed_gamma out of the scene file is going to be a very good thing. 
I was glad to read that in changes.txt.

I thought, right away, that the idea is to make it less of an image tweak 
and more of a display adjustment like it was intended for. In other words, 
it probably got overused or abused where it was. Prior to version 3.6 I was 
often unconcerned with what affect I was doing to the scene file and its 
render as to any global sense. Global meaning other computers not just 
global to a rendered scene.

I must be thinking of MegaPOV about some sort of contrast adjustments on the 
scene renders. Seemed like someone here mentioned replacing assumed_gamma 
with a way to do that instead, but I don't find anything said of it.

Of course, I realize now, this official change is likely to be only a gamma 
code remake and not a feature addition at the same time.

Post a reply to this message

> Essentially this setting and a few
> others should never have been in the scene file for this reason

I don't understand this (for assumed_gamma only).

I do understand that assumed_gamma was never meant to be used for adjusting
the brightness of a scene.

However, I thought its purpose was to let the artist say, "when I made this
image, I assumed the viewer had a gamma of x." That's an important
assumption that affects the appearance of the colors the artist chose. In
that way, it is strongly linked to the scene (and so should be stored in the
scene file).

The only thing that should be able to change when the image is rendered on a
different computer is the display gamma, so that when POV-Ray does its gamma
correction, the render displayed on the screen appears the same as it did to
the artist on his own screen. Allowing the renderer to change the
assumed_gamma - that is, to change an assumption the artist based his colors
off of - will cause the final image to look different.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Slime wrote:
>>Essentially this setting and a few
>>others should never have been in the scene file for this reason
> 
> I don't understand this (for assumed_gamma only).
> 
> I do understand that assumed_gamma was never meant to be used for adjusting
> the brightness of a scene.
> 
> However, I thought its purpose was to let the artist say, "when I made this
> image, I assumed the viewer had a gamma of x." That's an important
> assumption that affects the appearance of the colors the artist chose. In
> that way, it is strongly linked to the scene (and so should be stored in the
> scene file).

Well, yes and no.  You might know, the gamma factor POV-Ray uses internally 
is simply assumed-gamma divided by display-gamma.  So what assumed-gamma is 
really good for is tweaking display-gamma.  Of course, as you argue, that is 
specifically what it is designed for.  The main problem is that it is not 
what it gets used for.  To make proper use of it, you first need a proper 
display-gamma.  The chance that you have to tools (an external measurement 
device or a pre-calibrated screen) is extremely unlikely.  So you cannot get 
a truly accurate display-gamma.  Consequently, what do you do?  You tweak 
assumed-gamma because that is what you can easily change on a scene by scene 
basis.

So assumed-gamma makes sense, right? Wrong! ;-)  What you did with this use 
of assumed-gamma is exactly what it is not for because all you do is alter 
the brightness on a scene by scene basis, while still using the exact same 
display and display-gamma.  So, what you get is indeed some kind of 
brightness adjustment, but that isn't what assumed-gamma is for.  Yet, that 
is what you effectively used it for, without really doing so consciously.

So, if you think about it, what good is assumed-gamma for once you adjusted 
display-gamma to your screen?  Basically, nothing that has to do with gamma! 
:-)

Thus, while we still provide it mainly for backward compatibility as far as 
possible (you can render old scenes without changing your display-gamma), to 
adjust brightness we will provide a more flexible and more suitable mechanism.

I realise this is a huge change.  Still, it is one we had to make for a 
"better future".

	Thorsten

Post a reply to this message