Le 18-02-09 à 07:19, Mike Horvath a écrit :
> On 2/6/2018 7:22 PM, Alain wrote:
>> Le 18-02-06 à 19:09, Mike Horvath a écrit :
>>> How do I get blurred reflections working in UberPOV? I had it working 
>>> a few years go, but have since forgotten how. Thanks.
>>>
>>>
>>> Mike
>>
>> You only need to add roughness into the reflection block such as :
>>
>> reflection{0.9 metallic roughness 0.001}
>> or
>> reflection{1 fresnel roughness 0.001}
>> or
>> reflection{0.8 roughness 0.001}
>> or
>> reflection{0.1, 1 roughness 0.001}
>>
>> Normally, you also want to add specular highlights with the same 
>> roughness amount.
> 
> What would the correct way to update the following be?
> 
> 
> #local ldrawChromeFin=finish {
>   brilliance 6
>   diffuse 0.7
>   metallic
>   specular 0.80
>   roughness 1/120
>   reflection 0.8
> };
> 
> 
> 
> Do reflection and specular each have their own blocks containing a 
> roughness parameter?
> 
> 
> #local ldrawChromeFin=finish {
>   brilliance 6
>   diffuse 0.7
>   metallic
>   specular {0.80 roughness 1/120}
>   reflection {0.8 roughness 1/120}
> };
This could cause an error message.
> 
> 
> 
> Mike

This way :
#local ldrawChromeFin=finish {
  brilliance 6
  diffuse 0.7
  metallic
  specular 0.80 roughness 1/120
  reflection {0.8 roughness 1/120 metallic}
}

The first metallic affect the specular or phong highlight. The metallic 
in the reflection block affect the reflection only.
There is NO specular block.
Reflection may be used without a block which is the legacy syntax. In 
that case, it will borrow the metallic of specular, but not the roughness.

Post a reply to this message

On 2/9/2018 8:23 PM, Alain wrote:
> This way :
> #local ldrawChromeFin=finish {
>   brilliance 6
>   diffuse 0.7
>   metallic
>   specular 0.80 roughness 1/120
>   reflection {0.8 roughness 1/120 metallic}
> }
> 
> The first metallic affect the specular or phong highlight. The metallic 
> in the reflection block affect the reflection only.
> There is NO specular block.
> Reflection may be used without a block which is the legacy syntax. In 
> that case, it will borrow the metallic of specular, but not the roughness.
> 

Awesome, thanks. That clears up the syntax for me.


Mike

Post a reply to this message

Alain <kua### [at] videotronca> wrote:


> Reflection may be used without a block which is the legacy syntax. In
> that case, it will borrow the metallic of specular, but not the roughness.

I didn't know that reflection would 'borrow' the specular's metallic in such a
case. Thanks.

Post a reply to this message

Le 18-02-10 à 02:59, Kenneth a écrit :
> Alain <kua### [at] videotronca> wrote:
> 
> 
>> Reflection may be used without a block which is the legacy syntax. In
>> that case, it will borrow the metallic of specular, but not the roughness.
> 
> I didn't know that reflection would 'borrow' the specular's metallic in such a
> case. Thanks.
> 
> 
> 
> 

It's a leftover/backware compatibility thing.
Before the reflection block was introduced, there was no way to know if 
any metallic modifier was intended for phong, specular or reflection. 
Also, the actual order was totally ignored.

Thus
metallic
phong 1
phong_size 150
reflection 0.8

phong 1
metallic
phong_size 150
reflection 0.8

phong 1
reflection 0.8
metallic
phong_size 150

phong_size 150
metallic
reflection 0.8
phong 1

and

phong 1
phong_size 150
reflection 0.8
metallic

would gives the same result.
This is what I mean by "borrow".

Post a reply to this message

Alain <kua### [at] videotronca> wrote:
> Le 18-02-10 à 02:59, Kenneth a écrit :

> >
> > I didn't know that reflection would 'borrow' the specular's metallic
> > in such a
> > case. Thanks.

>
> It's a leftover/backware compatibility thing.
> Before the reflection block was introduced, there was no way to know if
> any metallic modifier was intended for phong, specular or reflection.
>

Ah. That explains the 'mystery' I used to wonder about in the older 3.6.x days--
I could never figure out exactly what was going on with metallic. Thanks!
Mystery solved ;-)

Post a reply to this message

Will blurred reflection integrate into official version one day? (this function
is too important)

Post a reply to this message

Am 16.07.2018 um 16:10 schrieb And:
> Will blurred reflection integrate into official version one day? (this function
> is too important)

One could argue that "too important" also means "too important to screw up".

So the answer to your question may depend on whether a sufficiently good
and robust implementation (including a sufficiently good syntax and all)
can be... well, implemented.

My gut feeling is that the answer is "yes".

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 16.07.2018 um 16:10 schrieb And:
> > Will blurred reflection integrate into official version one day? (this function
> > is too important)
>
> One could argue that "too important" also means "too important to screw up".
>
> So the answer to your question may depend on whether a sufficiently good
> and robust implementation (including a sufficiently good syntax and all)
> can be... well, implemented.
>
> My gut feeling is that the answer is "yes".

Well
But what is the disadvantage with recently implement?

Post a reply to this message

Am 18.07.2018 um 08:03 schrieb And:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 16.07.2018 um 16:10 schrieb And:
>>> Will blurred reflection integrate into official version one day? (this function
>>> is too important)
>>
>> One could argue that "too important" also means "too important to screw up".
>>
>> So the answer to your question may depend on whether a sufficiently good
>> and robust implementation (including a sufficiently good syntax and all)
>> can be... well, implemented.
>>
>> My gut feeling is that the answer is "yes".
> 
> Well
> But what is the disadvantage with recently implement?

If you want my opinion: Speed.

Blurred reflections work best when the render engine includes a good
framework for unbiased stochastic rendering, so that all oversampling
stuff -- blurred reflections, area lights, media, focal blur and
what-have-you-not -- don't cause the render time to explode exponentially.

POV-Ray does not have any such framework. UberPOV does, but it is still
rudimentary and probably needs lots more work.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 18.07.2018 um 08:03 schrieb And:
> > clipka <ano### [at] anonymousorg> wrote:
> >> Am 16.07.2018 um 16:10 schrieb And:
> >>> Will blurred reflection integrate into official version one day? (this function
> >>> is too important)
> >>
> >> One could argue that "too important" also means "too important to screw up".
> >>
> >> So the answer to your question may depend on whether a sufficiently good
> >> and robust implementation (including a sufficiently good syntax and all)
> >> can be... well, implemented.
> >>
> >> My gut feeling is that the answer is "yes".
> >
> > Well
> > But what is the disadvantage with recently implement?
>
> If you want my opinion: Speed.
>
> Blurred reflections work best when the render engine includes a good
> framework for unbiased stochastic rendering, so that all oversampling
> stuff -- blurred reflections, area lights, media, focal blur and
> what-have-you-not -- don't cause the render time to explode exponentially.
>

Yeah... indeed. Unbiased stochastic rendering grew rapidly (and showed its
advantage) during this ten years.

> POV-Ray does not have any such framework. UberPOV does, but it is still
> rudimentary and probably needs lots more work.

Post a reply to this message