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

Fri Jun 10 14:23:47 CEST 2016

> 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.

I see what you mean. Having a similar workflow that the variance shadow map
uses. You have to switch renderer to have full options. I'm ok with this.
but that may be a bit annoying for some users.

> 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.

Well the sun light approximation is still far off when radius is getting
big due to the non uniform Light intensity over the radius.

By the way would you (Brecht) help me to derive a diffuse formula for the
sun light edge brightening? I've somehting in mind but I need someone
better than me in math to acheive it.

> 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.

I think you are talking about the environment cubemap parallax correction
or others things that needs manual setup.

Thinking out loud is to have scene wide settings (maybe inside render
settings?) for approximations methods.
(in order from cheap to accurate)
Lights : Point light > MRP > LTC (uses 2 textures slots)
Environment : Prefiltered Envmap > Filtered Importance sampled
AO : Fast AO > Accurate AO
and so on.

> I think that bad matching with Cycles is not bad. More important is do
not add any additional tweaks in UI. Following this requirement we could >
make update for Cycles Viewport even in 2.7*.
> I think that such strategy could be efficient:
> 1) Update Cycles Viewport where we are able to do it keeping UI in master.
> 2) Continue improvements in 2.8 branch with dedicated real-time Cycles
twin.

I think that could be viable. But there is some area in the code that seems
unoptimized. And a first code review would be helpful to see if i'm not
doing big mistakes (especialy on the opengl side).

> Clément, is it real to keep UI for some features from your branch?

If you could rephrase that because I'm not sure I understand. I'm assuming
that you want to know which features could be added without touching the UI.
Light preview is the only one I can think of but getting rid of the
shadows. (or using BGE shadow settings [impractical to the user])
Environment lighting is just 1 or 2 parameters to be added to the shading
tab inside the N panel, and also some quality parameters to the World tab.

We could agree on a default quality parameter and not display all these
options for cycles for now.
That's what substance designer do, theses quality settings are not shown to
the user.

potential default parameters :
- Envmap size : 512
- SH calculation : 64
- BRDFs Samples : 48
- lod bias : -0.5

then the only settings we have to display is the enable material preview
button.

About the other renderers, well the best we could do is to create a custom
shader API so that the viewport shading can be customized via python.

2016-06-10 12:01 GMT+02:00 Yury Baranov <cucumberer at gmail.com>:

> AFAIK translation from renderengine shaders to realtime viewport shaders
> is a task for renderengine maintainers, so your suggestion should be
> addressed to Pixar/ChaosGroup.
>
> 2016-06-10 12:24 GMT+03:00 Paul Geraskin <paulgeraskin at gmail.com>:
>
>> I would like to see the same cool viewport with Renderman and Vray.
>> Please, don't bind it to Cycles only.
>> 10 июня 2016 г. 9:07 пользователь "Alexander Romanov" <
>> a.romanov at blend4web.com> написал:
>>
>> I think that bad matching with Cycles is not bad. More important is do
>>> not add any additional tweaks in UI. Following this requirement we could
>>> make update for Cycles Viewport even in 2.7*.
>>> I think that such strategy could be efficient:
>>> 1) Update Cycles Viewport where we are able to do it keeping UI in
>>> master.
>>> 2) Continue improvements in 2.8 branch with dedicated real-time Cycles
>>> twin.
>>> Clément, is it real to keep UI for some features from your branch?
>>> 10 июня 2016 г. 0:22 пользователь Clément FOUCAULT <
>>> foucault.clem at gmail.com> написал:
>>>
>>> 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 listBf-viewport at blender.orghttps://lists.blender.org/mailman/listinfo/bf-viewport
>>>
>>>
>>> --
>>> Alexander Romanov
>>>
>>> Developera.romanov at blend4web.com
>>>
>>> Blend4Web: Unleashing the Power of 3D Internethttps://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20160610/b85d0fe2/attachment-0001.htm 