[Cogl] Creating sliced textures from data and framebuffer

[Robert Bragg]

On Wed, Jan 25, 2012 at 1:27 PM, Tobias Hansen
<tobias.hansen at physik.uni-hamburg.de> wrote:
> Robert Bragg wrote:
>>>>>
>>>>> Otherwise... Do you see another reasonable way to use multiple sliced
>>>>> textures for multitexturing than a cogl_meta_texture_foreach_in_region
>>>>> variant that accepts multiple CoglMetaTextures and sets of texture
>>>>> coordinates and iterates over regions that don't cross borders of any
>>>>> of
>>>>> the native GL textures involved?
>>>>>
>>>>
>>>> Cogl doesn't currently support multi-texturing on textures that are
>>>> composed of multiple GL textures. So if you are trying to use sliced
>>>> textures to circumvent the maximum texture size limits (ie, it actually
>>>> needs slicing) then you won't be able to use Cogl's multi-texturing
>>>> support. I think this is a fairly tricky problem to solve. However if
>>>> you are just trying to create non-power-of-two textures then they can be
>>>> represented as either a single texture with padding or can be put in an
>>>> atlas so either way it will be a single GL texture so multi-texturing
>>>> should work fine.
>>>>
>>>
>>> What do you think about my suggestion about a new "foreach" function?
>>> Should it not be possible to use that to allow multitexturing with
>>> sliced textures?
>>>
>>
>>
>> Yeah, potentially it could be useful for Cogl to also provide a
>> utility mechanism to help support multitexturing with multiple sliced
>> textures. We have a comment in cogl-primitives.c as I recall saying
>> that we should support this one day. It's something we've considered a
>> few times, but I think we'd only want to try handling cases where all
>> the textures are aligned and perhaps allowing an offset for each
>> layer. Often when multitexturing it can be desirable to use all kinds
>> of texture coordinate transforms for each of the textures (such as
>> rotations and scales) but I think it could very quickly get
>> out-of-hand if we tried to provide a general solution that tried to
>> handle multiple sliced layers with rotations too. I get the impression
>> you wouldn't need support for transformed layers when multitexturing
>> so hopefully that would be ok for you?
>>
>>
>>
>
> We don't need rotations, but we do need scales. Would it get out of hand
> implementation or API wise?
> API wise you could allow scales by just replacing most parameters of the
> current meta texture API with array pointers.

I was more thinking about the implementation. Taking all the lines of
slicing for each layer; applying the layer transforms to those lines
and then intersecting them all to build up a collection of polygons
representing regions that can be multitextured without crossing any
slice boundaries sounds quite fiddly to me. It would be doable but it
also seems like it could also lead to bad performance if the slicing
and layer transforms are overly complex.

It could be worth taking a step back to see if there are some ways
that your game engine could be adapted to avoid needing complex
multi-texturing with multiple sliced textures.

That said, supporting scales is probably a lot simpler than having to
deal with rotations, so maybe if we think it though it wouldn't be too
tricky to handle.

>
>> P.S
>> I'm really jealous you have a Pandora device; I'm *still* waiting for
>> mine to be shipped (over a year now) :-)
>>
>
>
> I don't have a Pandora. I just figured the Pandora forums would be a good
> place to look for testers for SLUDGE with gles2. After one day someone had
> it working, only the background textures are not shown, because they are too
> large.

Ah ok, I don't feel so bad now :-)

regards,
- Robert

>
>
> Best regards,
> Tobias
> _______________________________________________
> Cogl mailing list
> Cogl at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/cogl