 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trf de> wrote:
> I realise this is a huge change. Still, it is one we had to make for a
> "better future".
Will POV-Ray include a way to modify the rendered pixels in the scene file
with eg. a user-defined function?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> You tweak
> assumed-gamma because that is what you can easily change on a scene by
scene
> basis.
I'm sure a lot of people do this, but I wouldn't be surprised to hear of
someone who had used assumed_gamma properly. For instance, if I had
discovered assumed_gamma one day and decided I should use it, I would have
set assumed_gamma 1.8 (for instance) in all my old scenes (since I had
developed them assuming the viewer had the same gamma my screen did), and
then used assumed_gamma 1 in all my new scenes. If I also set
display_gamma=1.8 in povray.ini, my old scenes wouldn't change, and my new
scenes would be rendered properly for anyone else who had their
display_gamma set.
So what if there are people out there who have done just this? I'm worried
you're removing an important feature because some people use it wrong.
Given the purpose of the feature, and how its meaning is linked to the
scene, I think it would make more sense to remove it entirely than make it a
command-line option. If it's still available, people might still abuse it,
so the only people who suffer are the ones who used it properly in the first
place.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rendering scenes\advanced\abyss.pov gives, once again, an image with
a black background, not light cyan as should be.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bob Hughes wrote:
>
> 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.
Since the MegaPOV tone mapping has been brought up in this context i
like to point out a few things.
The tone mapping patch primarily allows to apply color adjustments prior
to antialiasing (although it allows to specify them for post-aa as well)
which can be useful for high quality results with more-than-subtle
nonlinear adjustments. This has been discussed in depth and no need to
bring this up again. The patch can be used to do exactly what
assumed_gamma does (both before and after aa at your decision) and there
is a macro in tone_mapping.inc (Gamma_Correct()) that does exactly this.
The display_gamma/assumed_gamma distinction does only make sense if
assumed_gamma can be set in the scene file (and in this case there is no
real point to restrict it to a gamma factor). Without this two distinct
gamma factors are confusing and should be replaced by a single one (for
which both display_gamma and assumed_gamma would be misleading names).
Christoph
--
POV-Ray tutorials, include files, Landscape of the week:
http://www.tu-bs.de/~y0013390/ (Last updated 24 Jul. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
> I'm sure a lot of people do this, but I wouldn't be surprised to hear of
> someone who had used assumed_gamma properly. For instance, if I had
> discovered assumed_gamma one day and decided I should use it, I would have
> set assumed_gamma 1.8 (for instance) in all my old scenes (since I had
> developed them assuming the viewer had the same gamma my screen did), and
> then used assumed_gamma 1 in all my new scenes. If I also set
> display_gamma=1.8 in povray.ini, my old scenes wouldn't change, and my new
> scenes would be rendered properly for anyone else who had their
> display_gamma set.
This logic won't fly, I am afraid. In this case all you do is fix the
incorrect use of assumed-gamma in the old scenes (because you had an
incorrectly set display-gamma). And it would be easier to do in an INI file
then because you would only have to supply one "old scenes" INI file.
As pointed out, there really should be only one gamma setting, not two.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <43296e79$1@news.povray.org> Thursday 15 of September
2005 14:52
> 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
> :-(
No, I didnt noticed the follow-up-to until now...
--
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <nos### [at] deletethispovrayorg> wrote:
> o Radiosity support is still very alpha and there are numerous issues.
Hi all! I've started fooling around with radiosity and... not that i want to
sound rude to our beloved developing team, but i can't seem to get anything
sensible when radiosity is on, even in the simplest situations.
For instance, a red box over a plain plane (which can be thought of as a
beta version of the rsocp) leads to the results posted in pbtb. I don't
know the insides of Povray, but i'd say that currently the radiosity
samples are not distributed randomly in all directions of space, but rather
chosen following a wicked kind of reflection.
The sphere case is yet weirder, a cap of the sphere looks like it's been
bumped in.
I tried to play with:
- count: Seems to do nothing at all.
- error_bound: does have an effect, the lower, the sharper the image.
- recursion_limit: does **strongly** slow down the rendering, much more than
in 3.6.1a.
- pretrace_end: the lower, the smoother the results, as expected.
Well, i'm willing to keep testing and identifying... but maybe i'd need
pointers from experienced beta testers. Thanks!
JYR
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
JYR wrote:
>> o Radiosity support is still very alpha and there are numerous issues.
>
> Hi all! I've started fooling around with radiosity and... not that i want to
> sound rude to our beloved developing team, but i can't seem to get anything
> sensible when radiosity is on, even in the simplest situations.
<snip>
> Well, i'm willing to keep testing and identifying... but maybe i'd need
> pointers from experienced beta testers. Thanks!
As we said, it is in an alpha state, and does not really work in many, many
cases. We had to release a new beta but radiosity just needed a tiny bit
more work than we had time for to get those things worked out. A new beta
will appear in a few days or so and add the corrctions we were working on.
This is a beta test and we marked radiosity as in an alpha state, so what
you report is expected and the simplest thing is to not waste your time on
it when you notice it doesn't work for you until we say we think we have
worked out the major known problems.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> As we said, it is in an alpha state,
Point well taken Thorsten, thanks for your detailed and explanatory answer.
As a non-developper myself, i didn't exactly know what to expect from a
"very alpha" feature.
> the simplest thing is to not waste your time on it
.... and i'll quit wasting yours, by the way!!! :)
JYR
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've just run the source you posted through the current code, which has had a
number of fixes put into it since beta.9 was released, and it now renders
identically to version 3.6 ... the radiosity really needed fixing before we
released beta 9 but I didn't want to let the old one expire without a new
beta being released.
I'll post a beta 9a shortly with the fixed radiosity.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
