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