[Bf-viewport] Updates for the week of May 30th - June 6th

Fri Jun 10 02:18:54 CEST 2016

On Fri, Jun 10, 2016 at 12:54 AM, Clément FOUCAULT
<foucault.clem at gmail.com> wrote:
> So what I propose :
> - Having some correct handling of cycles materials preview : That means to
> not support things like area lights (which is approximated). Only point
> lights. Using filtered inportance sampling and maybe local cubemaps (without
> parallax correction). SSR would be OK but AO should be the cycles "weird" AO
> in additive mode (also why is there not an option to set the blending mode
> for the AO in cycles??).

I'm not sure we should make it impossible to use those features, but
we can require users to edit the settings with the realtime renderer
selected? I imagine users will ask for all the features at some point.
But it makes sense if you can develop the realtime renderer as a
separate renderer option, with the freedom to add new options without
worrying about cluttering the Cycles UI. And then we can figure out
the specifics of how to make that work best for Cycles viewport
previews later, which features should be disabled or enabled.

The reason Cycles AO doesn't support multiply blending is because it's
not possible to compute that product in an unbiased way, particularly
with pure path tracing that uses a single AO sample it doesn't work
well. It might make sense to add a multiply blend mode even if it's
not totally unbiased. I don't like multiplying AO on direct light like
Blender Internal does though, mainly I see AO as an approximation for
indirect light shadows. Perhaps the most useful thing in Cycles would
be to have an option to replace or augment indirect light with AO
after N bounces.

> - Having a dedicated realtime renderer with all options here. I would focus
> on having great and optimized GGX approximation (as it's considered industry
> standard) and not support others as it would required too much effort (ie :
> LTC uses 2 LUTS (4+1 channels) by bsdf) and ressources. And maybe this one
> could have in the end an hybrid deferred / forward implementation.

GGX only seems fine to me, also for offline rendering I think it's the
right distribution to use. We'll have multiple scattering GGX in
Cycles in the future, but that should still look quite similar.
Ashikhmin-Shirley will be removed.

> the underlying code would be the same of course. Just restricting what is
> used by each viewport.
>
> this is what the current implementation gives you
> https://docs.google.com/spreadsheets/d/1RCp94HurgNFz82rZ4Y5tDgngHRbr4rcyLyEPfOvGcYA/pubhtml
> So concerning cycles preview, I'm ok to have area lights only where it's
> correct so for diffuse / translucent and sharp shaders. Other shaders would
> default to point lights with correct behaviour.

GGX + area light preview would be useful I think, even if it's an
approximation it still seems better than assuming it's a point light.

The reason to use simpler approximations would be for better
performance, or if the approximation is so bad that it makes things
worse, or if it the more advanced approximation requires some kind of
manual tweaking / setup to make it work right.

> 2016-06-10 0:09 GMT+02:00 Mike Erwin <significant.bit at gmail.com>:
>>
>> I see value in both a "Cycles preview" and a dedicated real-time renderer.
>> Depends on what you (the artist) are targeting. Making assets for external
>> game engines (like UE4) is also important, which makes the viewport a
>> "preview" for that too.
>>
>> The tools/interface should work as close to the same as possible so people
>> can learn one material system and apply it to real-time or pre-rendered or
>> game projects. Avoid the situation we have now with multiple ways to create
>> materials.
>>
>> It doesn't have to be a perfect approximation to whatever "other" renderer
>> you're targeting. As long as it's good -- which it already is! -- and able
>> to be improved over time.
>>
>> Mike Erwin
>> musician, naturalist, pixel pusher, hacker extraordinaire
>>
>> On Thu, Jun 9, 2016 at 5:22 PM, Clément FOUCAULT <foucault.clem at gmail.com>
>> wrote:
>>>
>>> I think we first need to agree on how to integrate this.
>>>
>>> As of now it's trying to mimic cycles with viewport methods and I find
>>> this alienating for the UI to have all these options even for.
>>>
>>> Also under some circumstances approximations are very far from cycles
>>> render. So I don't realy like it being presented as cycles preview and would
>>> like to separate it to another renderer dedicated to that.
>>>
>>> What are your thoughts on this?
>>>
>>> 2016-06-09 22:37 GMT+02:00 Mike Erwin <significant.bit at gmail.com>:
>>>>
>>>> Excellent work as always Clément! How can we get this into an "official"
>>>> Blender release one day?
>>>>
>>>> Mike Erwin
>>>> musician, naturalist, pixel pusher, hacker extraordinaire
>>>>
>>>> On Thu, Jun 9, 2016 at 3:41 PM, Clément FOUCAULT
>>>> <foucault.clem at gmail.com> wrote:
>>>>>
>>>>> On my side I've release another iteration of my PBR experiment branch.
>>>>>
>>>>> https://vimeo.com/169475925
>>>>>
>>>>> I'm going to create a wikipage with some rambling about the PBR /
>>>>> shading side of things.
>>>>>
>>>>> I also think like Alexander that we should have another dedicated
>>>>> renderer. But I don't think we should focus it to replace BI because we
>>>>> can't do everything with rasterisation techniques efficiently. So in my
>>>>> opinion it should be focus to have realtime rendering feature only.
>>>>>
>>>>> Clément Foucault
>>>>>
>>>>> 2016-06-09 18:33 GMT+02:00 Alexander Romanov <a.romanov at blend4web.com>:
>>>>>>
>>>>>> Hi!
>>>>>> I've made some docs here
>>>>>> https://wiki.blender.org/index.php/BI_temporary_removal
>>>>>> and here
>>>>>> https://docs.google.com/spreadsheets/d/1sxIz_Uk-foCHMq3vRQxgrlX9c-r3kMVPMqfuh-N1ZRs/edit#gid=1586247834
>>>>>> . The table shows what we should implement in Viewport to cover BI
>>>>>> functionality, any comments are welcome!
>>>>>>
>>>>>>
>>>>>> On 09.06.2016 19:17, Mitchell Stokes wrote:
>>>>>>
>>>>>> Hello devs,
>>>>>>
>>>>>> Any interesting viewport updates for the week of May 30th to June 6th?
>>>>>> Any plans for the upcoming week? I will be aggregating information on the
>>>>>> Viewport Reports wiki page[1].
>>>>>>
>>>>>> Thanks,
>>>>>> Mitchell Stokes
>>>>>>
>>>>>> [1] https://wiki.blender.org/index.php/Dev:2.8/Viewport/Reports
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Bf-viewport mailing list
>>>>>> Bf-viewport at blender.org
>>>>>> https://lists.blender.org/mailman/listinfo/bf-viewport
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Alexander Romanov
>>>>>>
>>>>>> Developer
>>>>>> a.romanov at blend4web.com
>>>>>>
>>>>>> Blend4Web: Unleashing the Power of 3D Internet
>>>>>> https://www.blend4web.com
>>>>>>
>>>>>>
>>>>>> This email and any files transmitted with it are confidential and
>>>>>> intended
>>>>>> solely for the use of the individual or entity to whom they are
>>>>>> addressed.
>>>>>> If you have received this email in error please notify the sender
>>>>>> immediately.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Bf-viewport mailing list
>>>>>> Bf-viewport at blender.org
>>>>>> https://lists.blender.org/mailman/listinfo/bf-viewport
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Bf-viewport mailing list
>>>>> Bf-viewport at blender.org
>>>>> https://lists.blender.org/mailman/listinfo/bf-viewport
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Bf-viewport mailing list
>>>> Bf-viewport at blender.org
>>>> https://lists.blender.org/mailman/listinfo/bf-viewport
>>>>
>>>
>>>
>>> _______________________________________________
>>> Bf-viewport mailing list
>>> Bf-viewport at blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-viewport
>>>
>>
>>
>> _______________________________________________
>> Bf-viewport mailing list
>> Bf-viewport at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-viewport
>>
>
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> https://lists.blender.org/mailman/listinfo/bf-viewport
>