[Imstk-developers] Deferred decals

[Sreekanth Arikatla]

Hi Nick,
            Read the blog, option 2 seems fine to me. Can deferred decals
be used for the case of cuts with blood that evolves between frames?

On Mon, Oct 2, 2017 at 2:44 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> What tradeoffs do you all want for deferred decals? The main issue is
> which objects get affected by which decals (since a projection volume
> encompasses the target area). Deferred decals would be used for various
> markings such as burn marks, blood, or possibly just environmental details.
> You can think of them as a sticker.
>
> Here is a decent overview of the technique and the problem with volume
> (please read if you're unfamiliar with this topic):
> https://mtnphil.wordpress.com/2014/05/24/decals-deferred-rendering/
>
> Option 1:
> Add a material option to toggle decals on or off for a given mesh. This is
> the easiest implementation but also the most limited (meshes are either
> affected by all decals or none).
>
> Option 2:
> Add a mask for up to 8 types (layers) of decals. Each layer would be a
> property in the material class. You could can put the same type of decal
> (such as burn marks) on different layers to apply them to different meshes,
> but you are only limited to 8 layers total. This takes up 1 byte in the
> GBuffer. If we use two bytes, we can use up to 16 layers.
>
> Option 3:
> Add a material ID for each mesh in the simulator. Each decal would be
> assigned to one mesh. This would allow up to 256 unique meshes but
> unlimited types of decals. This takes up 1 byte in the GBuffer. If we use 2
> bytes, then we can use up to 65k unique meshes. The drawback is that there
> can be a large amount of drawing/overdraw here (since decals must be drawn
> multiple times for each compatible material in the scene), which is
> expensive on both the CPU and GPU side.
>
> Personally, I'm leaning towards Option 2, but I was wondering what you all
> thought.
>
> _______________________________________________
> Imstk-developers mailing list
> Imstk-developers at imstk.org
> http://public.kitware.com/mailman/listinfo/imstk-developers
>
>


-- 
Sreekanth Arikatla, Ph.D.,
Senior R&D Engineer,
Kitware, Inc. <http://www.kitware.com>, Carrboro, NC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20171003/6b505818/attachment.html>