|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
How come radiosity pretrace replaces mosaic preview?
They work differently, they have different purposes, and the former has side
effects which may be undesired (especially when using load_file).
When I use mosaic preview, my intention is to get a fast view of the scene
so that I can see what it looks like in general without worrying about
detail. When I use radiosity pretrace, my intention is to add additional,
high quality radiosity samples to my scene. The former is a convenient
change in the order that pixels are rendered, the latter is a way of
changing the scene itself.
When I am using radiosity, I often generate a radiosity file with save_file.
Then I can use load_file to view my image as I tweak things. I would like to
use mosaic preview as I tweak, but doing so sends extra radiosity samples
(which changes my radiosity data) and takes forever because it's doing so.
Mosaic preview is essentially useless in this situation.
Wouldn't it make more sense to first run the radiosity pretrace (based on
the pretrace_start and pretrace_end values in the radiosity{} block), and
then run the mosaic preview on top of that (based on the command line or ini
settings), followed by the final pixel-by-pixel render? Then, by setting
pretrace_start 1 pretrace_end 1, one can nearly eliminate the pretrace step,
and then watch their image render from high to low levels of detail - as
they would do without radiosity in the first place.
Does this bother anyone else, or am I one of the few who really uses mosaic
preview a lot?
(By the way, while I'm talking about separating the two, it would really be
nice if there were a way to turn the radiosity pretrace step off *entirely*,
to avoid sending any extra samples at all and only use loaded data.)
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
> How come radiosity pretrace replaces mosaic preview?
>
> They work differently, they have different purposes, and the former has side
> effects which may be undesired (especially when using load_file).
>
> When I use mosaic preview, my intention is to get a fast view of the scene
> so that I can see what it looks like in general without worrying about
> detail. When I use radiosity pretrace, my intention is to add additional,
> high quality radiosity samples to my scene. The former is a convenient
> change in the order that pixels are rendered, the latter is a way of
> changing the scene itself.
>
> When I am using radiosity, I often generate a radiosity file with save_file.
> Then I can use load_file to view my image as I tweak things. I would like to
> use mosaic preview as I tweak, but doing so sends extra radiosity samples
> (which changes my radiosity data) and takes forever because it's doing so.
> Mosaic preview is essentially useless in this situation.
>
> Wouldn't it make more sense to first run the radiosity pretrace (based on
> the pretrace_start and pretrace_end values in the radiosity{} block), and
> then run the mosaic preview on top of that (based on the command line or ini
> settings), followed by the final pixel-by-pixel render? Then, by setting
> pretrace_start 1 pretrace_end 1, one can nearly eliminate the pretrace step,
> and then watch their image render from high to low levels of detail - as
> they would do without radiosity in the first place.
>
> Does this bother anyone else, or am I one of the few who really uses mosaic
> preview a lot?
>
> (By the way, while I'm talking about separating the two, it would really be
> nice if there were a way to turn the radiosity pretrace step off *entirely*,
> to avoid sending any extra samples at all and only use loaded data.)
>
> - Slime
> [ http://www.slimeland.com/ ]
>
>
I agree. It bothers me too that while I'm loading radiosity data from a
file, the pretrace steps still take place. If POV-Ray thinks it needs
extra samples despite loading the data, it should make a not of that in
the message window and leave the user to consider taking action or not.
I don't use mosaic view a lot. But, if radiosity and mosaic interfere
something should be done about it and your proposal sounds goods to me.
--
Maurice
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
> How come radiosity pretrace replaces mosaic preview?
>
> They work differently, they have different purposes, and the former has side
> effects which may be undesired (especially when using load_file).
>
First of all the mosaic preview is always an addition - the colors
calculated during it will not be used in the image (why should be fairly
easy to understand).
Now the radiosity pretrace actually abuses the mosaic preview code for
its own purpose. This is not so bad since it fits this purpose quite
well. It would not be difficult to run both a radiosity pretrace and a
mosaic preview but what for? It would just take additional time. Also
note turning off the radiosity pretrace while having the mosaic preview
will not really have the effect of no pretrace - radiosity samples would
still be taken, just not with the special settings usually used during
pretrace.
>
> (By the way, while I'm talking about separating the two, it would really be
> nice if there were a way to turn the radiosity pretrace step off *entirely*,
> to avoid sending any extra samples at all and only use loaded data.)
Just set pretrace_start and pretrace_end to 1.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> First of all the mosaic preview is always an addition - the colors
> calculated during it will not be used in the image (why should be fairly
> easy to understand).
I know. (As a side note, it seems like kind of a waste, since the preview
samples can easily be taken at pixel centers and stored to avoid work later.
But that's a topic for another thread.)
> It would not be difficult to run both a radiosity pretrace and a
> mosaic preview but what for? It would just take additional time.
The point would be to run the mosaic preview without the radiosity pretrace.
> Also
> note turning off the radiosity pretrace while having the mosaic preview
> will not really have the effect of no pretrace - radiosity samples would
> still be taken, just not with the special settings usually used during
> pretrace.
The idea is that "always_sample off" would apply to the mosaic preview as
well as the final render, so that the mosaic preview could be used without
affecting radiosity - for preview purposes.
I understand that mosaic preview and radiosity pretrace share the same code,
and I'm saying, they shouldn't! (Well, it's not so much a matter of "don't
share code" as it is "separate the two procedures"; I recognize the
importance of avoiding duplicating code.) The fact that POV-Ray considers
these two things as one and the same is - although not technically
"incorrect" - annoying at times.
I do see your point that there's no reason having them separate if no one in
their right mind would run both a radiosity pretrace *and* a mosaic preview.
So then my complaint could be restated as "I'd like an option to avoid
taking radiosity samples during the preview/pretrace pass when radiosity is
enabled." (Or, to be more precise, to treat the pretrace pass the same as
the final pass so that always_sample affects it and so that low_error_factor
doesn't.)
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oops, forgot one thing =)
> Just set pretrace_start and pretrace_end to 1.
Yeah, this is a practical solution (that I tend to use), but a single sample
is taken and that can't be avoided... it feels messy.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
>
> The idea is that "always_sample off" would apply to the mosaic preview as
> well as the final render, so that the mosaic preview could be used without
> affecting radiosity - for preview purposes.
always_sample off just sets nearest_count to 1 for the final pass so by
using explicitly nearest_count 1 you set always_sample off for the
pretrace as well.
> I understand that mosaic preview and radiosity pretrace share the same code,
> and I'm saying, they shouldn't! (Well, it's not so much a matter of "don't
> share code" as it is "separate the two procedures"; I recognize the
> importance of avoiding duplicating code.) The fact that POV-Ray considers
> these two things as one and the same is - although not technically
> "incorrect" - annoying at times.
As a matter of fact both do not share the same code. The radiosity
pretrace differs in some aspects. But still they essentially do quite
similar things.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|