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

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

From: Nexii Malthus <nexiim@gmail.com>
Date: Mon, 19 Sep 2016 12:35:03 +0000
Message-ID: <CALbUtNZrN32Zu3Dx7rMDg95WdBuDvPbZVUmGiEP6veSQFN1mZw@mail.gmail.com>
To: Rik Cabanier <cabanier@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>
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.

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 Tuesday, 20 September 2016 07:18:06 UTC

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