[Bf-committers] tfaces, makesdna and custom blobs

[Toni Alatalo]

On Monday 20 February 2006 19:04, Mal wrote:
> Regarding forward compatibility, is there any way that additional UV
> layers could be defined as a new type, with the first layer being the
> exception ( using the current sdna format ).

old:
self.uv = UV()

new:
self.uvs = []
(..)
def get_uv(self):
    return self.uvs[0]
uv = property(get_uv, set_uv, None, "(bw compat: )the first/active UV")

?

> This would mean that older versions of Blender would only be able to
> read the first layer of UV's ( which is how it works now anywho ), and
> just ignore the additional UV info.

right, that is basically what i tried to 'implement' above.
probably possible with the makesdna / readfile majik.

> Mal

~Toni

>
> > Hi
> >
> > I'm working on support for multiple UV sets. At this point I have code
> > support for multiple TFace sets, that contain color, UV's, a texture
> > image
> > and game engine flags. The next step is to split the color off from
> > TFace,
> > to also allow multiple color sets, and get rid of the double storage
> > for color
> > in MCol and TFace.
> >
> > Makesdna, however, does not allow to read members that have been
> > removed from a struct, so in order to keep backwards compat, my idea
> > is to deprecate the TFace struct, and replace it by MCol and MTFace.
> >
> > typedef struct MCol {
> >     char a, r, g, b;
> > } MCol;
> >
> > typedef struct MTFace {
> >     struct Image *image;
> >     float uv[4][2];
> >     char flag, transp;
> >     short mode, tile, unwrap;
> > } MTFace;
> >
> > This means breaking forward compat, so Blender 2.41 and earlier will
> > not be able to read UV's, colors, or any game engine data from newer
> > Blender versions. This is not that great, but it is the only solution
> > I can
> > come up with that does not involve placing custom hacks makesdna
> > code. Is losing forward compat acceptable?
> >
> >
> > But I was thinking, if we break forward compat anyway, we might as well,
> > you know, break it properly. Like allowing a custom blobs of data to be
> > attached to verts, edges, and faces, without unified handling of uv's,
> > colors,
> > vertex groups, and user defined data, for meshes, nurbes, lattices, .. .
> >
> > That's maybe a bit ambitious, and will further delay multiple UV sets for
> > those who really want it (hi Campbell :). It doesn't seem impossible,
> > but clearly won't be for 2.42 then.
> >
> > Good idea? Bad idea?
> >
> > Cheers,
> > Brecht.
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at projects.blender.org
> > http://projects.blender.org/mailman/listinfo/bf-committers
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers