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

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