W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2016

Re: [css-transforms] CSS3D breaks with opacity flattening

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 19 Sep 2016 14:18:38 +0100
Message-ID: <CAGN7qDAB86Xaa5BxiMyBEMJrN8A2ZfcgsMLe+xb5XyOPgCP4Mg@mail.gmail.com>
To: Nexii Malthus <nexiim@gmail.com>
Cc: Matt Woodrow <mwoodrow@mozilla.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, "/#!/JoePea" <trusktr@gmail.com>, Chris Harrelson <chrishtr@google.com>, Simon Fraser <simon.fraser@apple.com>, "public-fx@w3.org" <public-fx@w3.org>
On Mon, Sep 19, 2016 at 1:35 PM, Nexii Malthus <nexiim@gmail.com> wrote:

> It doesn't seem like the perspective is being preserved well though.
> Shouldn't the perspective matrix be applied to the render-to-texture? At
> the moment it's rendered as if it is an entirely new perspective context
> instead of taking into account the parent viewport perspective. That is,
> the render-to-texture billboard  should be static in place around the
> on-screen 2D bounding box of the car.

I don't really understand what you're saying. It's correct that the content
inside a opacity group has it own perspective matrix.
Matt's proposal tries to solve this by rendering to a texture that is
outside the current perspective matrix and instead applying it to the
children (which seems difficult to implement)

> E.g. more like the classic 'impostor' technique: http://www.
> gamasutra.com/view/feature/130911/dynamic_2d_imposters_a_simple_.php
> On Mon, 19 Sep 2016 at 13:11 Rik Cabanier <cabanier@gmail.com> wrote:
>> On Mon, Sep 19, 2016 at 12:58 PM, Nexii Malthus <nexiim@gmail.com> wrote:
>>> It's been a while since I have done 3d graphics programming, but isn't
>>> this solvable as a 'render to texture' - a simple technique that dates back
>>> to very early 3d game graphics? This should preserve-3d on the car frame
>>> for the internal 3d perspective, no?
>> Yes, that is what the current spec says and what is implemented in
>> Chrome.
>>> You could even use a simple pixel shader of you fancied having depth
>>> still working.
>>> On Mon, 19 Sep 2016 9:41 am Rik Cabanier, <cabanier@gmail.com> wrote:
>>>> On Mon, Sep 19, 2016 at 8:22 AM, Matt Woodrow <mwoodrow@mozilla.com>
>>>> wrote:
>>>>> On 19/09/16 6:27 PM, Tab Atkins Jr. wrote:
>>>>>> No, as I explained in more detail in the GitHub thread I linked
>>>>>> <https://github.com/w3c/svgwg/issues/264#issuecomment-246750601>,
>>>>>> this
>>>>>> is a logical consequence of 'opacity' and other filter-type effects
>>>>>> being "group effects".  If you want the effect to only apply to the
>>>>>> leaves, you can do that yourself by specifying it on the leaves, but
>>>>>> it has a visibly different effect than doing it "as a group".
>>>>> Sorry, I'm not quite sure I follow. The idea I proposed explicitly
>>>>> *doesn't* break the group nature of opacity, which is why I think it's
>>>>> worth discussing.
>>>>> The example I gave had opacity applied to an intermediate element, and
>>>>> showed the internal representation needed to apply it as a group while
>>>>> maintaining preserve-3d.
>>>> What you're proposing will also change how content is rendered. :-\
>>>>> Are there more complex examples you can think of where this breaks
>>>>> down?
>>>>> Obviously this would prevent depth sorting occurring between elements
>>>>>>> inside
>>>>>>> and outside of 'b', and we need to figure out how to depth sort 'b'
>>>>>>> itself
>>>>>>> (given that it is an atomic entry for sorting, but isn't a 2d
>>>>>>> plane), but
>>>>>>> those seem solvable.
>>>>>> That's actually the core problem preventing this from working; it's
>>>>>> not a detail we can just paper over later.
>>>>> Which part of this? The first piece is the exact same situation we
>>>>> have when we flatten for opacity, so I don't see how that's a problem. The
>>>>> latter is somewhat difficult from an implementation standpoint, but it's
>>>>> not obvious that it's a showstopper.
>>>> Why is that not a showstopper? Your proposal seems very difficult to
>>>> implement since it pushes matrix manipulation all the way down to the
>>>> individual elements.
>>>> It also introduces more rendering surfaces.
>>>> You're also relying on how firefox is representing the render tree
>>>> which might be completely different from other UA's
>>>> Browsers already have a hard time giving a consistent experience with
>>>> the simple model and this will make it even more complicated.
Received on Monday, 19 September 2016 13:19:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:57 UTC