 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
>
> Unless you make use of POV-Ray's mechanisms for storing and re-loading
> of radiosity samples, some deal of flicker is virtually inevitable with
> radiosity - the lower-quality the settings, the worse.
You mean more than other renderers?
>
> (Of course it doesn't help that if your scene contains any moving
> objects, you'd theoretically need to recompute radiosity for every frame
> anyway.)
Of course I want to be able to animate the character in the long run, so I have
planned to do it with no baking, that's why my radiosity settings are so low.
I have to increase them. But I really would have liked to stay under 6 minutes
per frame. Is Povray radiosity never used for animation? It's the main reason
why I first came to Pov instead of Blender Internal
You seem to imply that you recognize this flicker as Pov radiosity's fault, if
so and if you're right, I can try to lower fast proxsampling and increase
Radiosity's to keep reasonable times and reduce flicker.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mr"
> You seem to imply that you recognize this flicker as Pov radiosity's fault, if
> so and if you're right, I can try to lower fast proxsampling and increase
> Radiosity's to keep reasonable times and reduce flicker.
Great! I switched to BSP for a try and the scene went down from 6 min 26 sec, to
4 min 18 sec! Now I have the room to improve radiosity: 2 spare minutes per
frame should allow for quite some polishing. don't you think that the flicker
could totally disappear? I mean not from a theoretical point of view, but as a
user, comparing to other renderers: they can get invisible when settings are
high enough
Or maybe POV can't be used for animation as much as these renderers because of
some real limitation it has that they don't?
I'll ask some more about BSP in another thread, it seems to be worth it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mr schrieb:
> don't you think that the flicker
> could totally disappear? I mean not from a theoretical point of view, but as a
> user, comparing to other renderers: they can get invisible when settings are
> high enough
Honestly, a theoretical point of view is the only one I can offer here;
I'm not doing animations myself, so I have no experience how well
POV-Ray radiosity behaves in animations in practice, let alone in
comparison with other renderers.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
What I meant, I see much less of a flicker now:
maurice.raybaud.eu/images/stories/FASTSSS.avi
though it doesn't mean there is none...
Here are my new settings for radiosity:
pretrace_start 0.08
pretrace_end 0.08
count 70
nearest_count 7
error_bound 1.75
recursion_limit 1
low_error_factor 0.2
gray_threshold 0
minimum_reuse 0.025
brightness 1.0
adc_bailout 0.01/2
always_sample off
For now I should focus on something else.
The color for instance is not satifying at all, mainly because of the use of
Ambient values > 0, I suppose. I also need to work on the mesh
Again, BSP is great!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mr schrieb:
> For now I should focus on something else.
> The color for instance is not satifying at all, mainly because of the use of
> Ambient values > 0, I suppose.
You should change that indeed. Radiosity and ambient don't mix very well.
If you're not using ambient to model glowing objects, you can just set
"ambient_light" to zero.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Mr schrieb:
> > For now I should focus on something else.
> > The color for instance is not satifying at all, mainly because of the use of
> > Ambient values > 0, I suppose.
>
> You should change that indeed. Radiosity and ambient don't mix very well.
>
> If you're not using ambient to model glowing objects, you can just set
> "ambient_light" to zero.
thanks, in the global settings? but If I do decide to use some mesh light or
the ambient of an hdri will it make an "exception for it"? or there is another
way to change the default ambient to 0 instead and just specify a value for
glowing objects? I want to make things as flexible as I can since this is only
the character and the set should be able to change.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
web.4a9fd5eb6629da5e6ce87ead0@news.povray.org...
> clipka <ano### [at] anonymousorg> wrote:
>> Mr schrieb:
>> > For now I should focus on something else.
>> > The color for instance is not satifying at all, mainly because of the
>> > use of
>> > Ambient values > 0, I suppose.
>>
>> You should change that indeed. Radiosity and ambient don't mix very well.
>>
>> If you're not using ambient to model glowing objects, you can just set
>> "ambient_light" to zero.
> thanks, in the global settings? but If I do decide to use some mesh light
> or
> the ambient of an hdri will it make an "exception for it"? or there is
> another
> way to change the default ambient to 0 instead and just specify a value
> for
> glowing objects? I want to make things as flexible as I can since this is
> only
> the character and the set should be able to change.
>
Put at the beginning of the script :
#default {
finish { ambient 0 }
}
Every texture with no ambient statement will take 0 as ambient value
Marc
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"m_a_r_c" <jac### [at] wanadoofr> wrote:
> web.4a9fd5eb6629da5e6ce87ead0@news.povray.org...
> > clipka <ano### [at] anonymousorg> wrote:
> >> Mr schrieb:
> >> > For now I should focus on something else.
> >> > The color for instance is not satifying at all, mainly because of the
> >> > use of
> >> > Ambient values > 0, I suppose.
> >>
> >> You should change that indeed. Radiosity and ambient don't mix very well.
> >>
> >> If you're not using ambient to model glowing objects, you can just set
> >> "ambient_light" to zero.
> > thanks, in the global settings? but If I do decide to use some mesh light
> > or
> > the ambient of an hdri will it make an "exception for it"? or there is
> > another
> > way to change the default ambient to 0 instead and just specify a value
> > for
> > glowing objects? I want to make things as flexible as I can since this is
> > only
> > the character and the set should be able to change.
> >
>
> Put at the beginning of the script :
>
> #default {
> finish { ambient 0 }
> }
>
> Every texture with no ambient statement will take 0 as ambient value
>
> Marc
Wow! great, thank you Marc.
A question about the beta related to Fastprox:
Does the min extent and max extent thing still require some margin? Comments in
the macro say this is because Pov has difficulties adjusting tight bounding
boxes, so I wondered if that hadn't been solved already in the current beta
with all the work that has been done...?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mr schrieb:
> Does the min extent and max extent thing still require some margin? Comments in
> the macro say this is because Pov has difficulties adjusting tight bounding
> boxes, so I wondered if that hadn't been solved already in the current beta
> with all the work that has been done...?
Not sure what you mean, but if your question is "do min_extent and
max_extent still return a box larger than absolutely necessary in
certain circumstances (e.g. cylinders not aligned with either of the
three axes)", then yes: This is still the case, has been the case with
3.6 already, and I assume it will remain so.
POV-Ray will /never/ be able to guarantee that for all object types the
min_extent / max_extent values are as "tight" as theoretically possible.
With this being an unsurmountable fact, I don't expect anyone to invest
any significant effort into addressing this for /some/ object types.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Mr schrieb:
> > Does the min extent and max extent thing still require some margin? Comments in
> > the macro say this is because Pov has difficulties adjusting tight bounding
> > boxes, so I wondered if that hadn't been solved already in the current beta
> > with all the work that has been done...?
>
> Not sure what you mean, but if your question is "do min_extent and
> max_extent still return a box larger than absolutely necessary in
> certain circumstances (e.g. cylinders not aligned with either of the
> three axes)", then yes: This is still the case, has been the case with
> 3.6 already, and I assume it will remain so.
>
> POV-Ray will /never/ be able to guarantee that for all object types the
> min_extent / max_extent values are as "tight" as theoretically possible.
> With this being an unsurmountable fact, I don't expect anyone to invest
> any significant effort into addressing this for /some/ object types.
No problem, I just wanted to make sure I optimized my sample count.
I'm starting to get decent results with fastprox:
http://maurice.raybaud.eu/images/stories/FASTSSSskin.avi
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
