[Bf-committers] tfaces, makesdna and custom blobs

[Brecht Van Lommel]

Hey,

Mal wrote:
> Hi Brecht,
> 
> Multiple UVs would be an excellent new feature for Blender!!!
> 
> 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 ).
> 
> 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.

This is how the code I have now works. But if I split off colors from
the UV's and put the colors in separate layers, that doesn't work
anymore. Maybe with some evil custom hacks in sdna code.. but
it's probably not worth.

If I add support for custom blobs of data, maintaining forward compat
will not be possible at all.

trip somewhere wrote:
 > You mean will break backwards compat right ??
 > if so you could implement it like a new uv editing window till
 > everyone has had time to get aquanited with it.. As the image view ahs
 > been hyjacked with compositeing anyways..
 >
 > But the faster you can get it installed the faster users can re create
 > their uv maps and use the feature... Cause we sure need it..

Breaking backwards compat is out of the question.

Cheers,
Brecht.

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