[Bf-viewport] Rendering to a cubemap

[Hadrien Brissaud]

Just my two cents : from a user pov having a monolithic ubershader for
viewport seems fine, probably covers most uses and you make it sound like
it's way easier to make. Now my use case is more like having a nice preview
of actual cycles shaders (ie not necessarily super-accurate) rather than a
full fledged cryengine, maybe not everyone is in the same boat.

By the way thanks a lot Clément for contributing.

Hadrien

On 28 January 2016 at 23:37, Clément FOUCAULT <foucault.clem at gmail.com>
wrote:

> Hi Ton,
>
> I don't have a design doc but I can share some thoughts about what I read
> on this mailing list.
>
> Please note I am not feeling very familiar with all concepts below and I
> can really be misleaded. I am a 3D artist before being a coder.
> Also please note that I'm primarily focusing on the viewport and not the
> game engine.
> Some of my notes have already been expressed by other participants.
>
> About deferred shading :
> I think it's a bad idea overall.
> Why? Because of the multitude and flexibility of blender's node setups we
> can have all sorts of bsdf inside one shader and thus having a lot of
> parameters.
> In fact the number of parameters is not fixed and we cannot pass this to
> the shading step unless using a gigantic G-buffer.
> So deferred shading would be nice ONLY if we have a static "ubershader"
> like unreal with consistent inputs. But that would mean subtracting
> features.
> Even Epic is reluctant to add anisotropic shaders because of the cost of
> another parameter inside the G-buffer.
> I know we could support both and switch between the one that fits better
> to the task. But in the short run I think we should try to focus only on
> one of these.
>
> About light probes :
> Needs to be HDR (kinda obvious). Needs to be dynamic (rendered from
> opengl) if not it wont be worth it to user to spend time to hit a render
> button and wait at least 30secs for a preview.
> Pre-convolving (baking) the bsdf to the cubemap can be slow even for the
> gpu (500ms for a 64px cubemap with diffuse brdf with average gpu). So I
> would prefer to have this as an option.
> Also we can't convolve for each Bsdf that would mean a lot of cubemaps.
> As I said previously, I'm in favor a global cubemap which would be the
> result of the world node tree. This one is applied by default to all
> materials / objects.
> Then similarly to the blender internal envmap texture, we could specify a
> viewpoint for the object cubemap.
> To get accurate reflection Epic Unreal Engine correct the ray casting (who
> sample the cubemap) to fit a volume sphere or box. This would be useful for
> indoor scenes.
> As of now, in my branch I use Importance sampling (
> http://http.developer.nvidia.com/GPUGems3/gpugems3_ch20.html ) because it
> does not need to precompute anything.
> The number of samples could be exposed to the user to get the most
> accurate reflections for render, or to lower the samples for performance
> reason.
> For diffusion i'm using spherical harmonics.
> https://seblagarde.wordpress.com/2012/01/08/pi-or-not-to-pi-in-game-lighting-equation/
> Computing them depends on the size of the map as it read each texel and
> the type of mapping. But it's fairly quick and require only 1sec for a
> 2000x1000px equirectangular envmap.
> Any kind of (lengthy) pre-computation should not freeze blender's UI.
> Pretty much like the renderers do.
>
> About lamps :
> I'm already using epic's approach of area lights.
> Using tube lights for area (rectangular) lights as I was not able to find
> a correct algorithm for them.
> But energy conservation is not perfect for this solution and does not
> quite match cycles at grazing angles.
> We could use this paper https://www.youtube.com/watch?v=O3TG1VXx1tg but I
> highly doubt the computational cost is worth it.
> Another technique is by Michael Drobot inside GPU Pro 5. But I did not
> have much success with it.
>
> About aligning on UE4 :
> Their implementation of PBR is already doable inside cycles.
> They just use baking to do less calculation at runtime.
> My branch is already using a lot of their maners.
> Supporting cycles shaders implies supporting UE4 shaders.
> If you want to talk about rendering pipeline that's another topic.
>
> About viewport framebuffer:
> We need a float framebuffer for a lots of effects. Like bloom,
> tone/colormapping, Quality dof.
> You could also render quick passes with float informations (like Z depth
> or world normal for instance) instead of doing a slow cycle pass.
> I suggested a R10_G11_B11 format but that means having a separate alpha
> buffer.
> To have a "correct shading", with only the indirect light being multiplied
> by ambiant occlusion, we need to separate the direct light from the
> indirect lighting.
> That would mean another float buffer unfortunately.
> Maybe there is a way to encode everything inside a big 64bit buffer with
> alpha but it can get a bit complicated.
> I've seen people doing these kind of things but I'm not completely sure if
> it's worth it.
>
> RGBA16    R16   G16   B16   A16
> Direct    8bits 8bits 8bits 4bits -> R9G10B9
> Indirect  8bits 8bits 8bits 4bits -> R9G10B9
> Alpha     -     -     -     8bits
>
> I don't know if these extra bits could be enough.
> Also not to forget the depth buffer.
>
> I'd really like to also see ScreenSpaceLocalReflection inside the viewport
> but this means to have a mean to tag relevant area of the frame-buffer to
> blend with a reflection buffer.
> And it should overwrite only the indirect specular (envmap), that means
> basically splitting up the color buffer again and it can get pretty far.
> So i'm not positive on this. But if someone has an idea about this that
> would be cool.
>
> I can populate some design docs (at least try I've) but as I mention
> earlier i'm not familiar with all the opengl drawing methods and how
> blender handles it.
>
> I'll be around IRC when I will have more time. I'm starting a job Monday
> so it won't be easy for me.
>
> I hope we can decide where to go and help each others.
>
> Thank you for your interest.
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> http://lists.blender.org/mailman/listinfo/bf-viewport
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20160128/1f3d6885/attachment-0001.htm