Dev:Source/Textures/UV/Rewrite

UV Editor Rewrite

Introduction

The introduction of HE mesh means that the UV editor will have to be rewritten to accomadate for both the quad/tri-based Mesh and the ngon-based HE mesh. This document is a proposal to do that.

And while this may seem like out of the scope of HE mesh, it is not; the demand for UV texturing seems fairly high, and most people when asked would rather not have to convert to normal Meshes for texturing. In other words: I don't particularily want to do this project, but it seems like it needs to be done anyway.

User Interface

The new window will use the same interface as the old one, but with ngons-uvs.

Data Structures

Currently the structure TFace is used for UV-editing. Since it is entirely quad-limited, it will be necassary to write a new structure that will be able to operate on both HE faces and TFaces.

This data structure will have to support support ngons, so it can either be a) Simple Ngon Structure like HyperMesh (e.g. the subsurf mesh), or b) it can be a b-rep like Radial-Edge (shiver). I vote for "a"!

typedef struct UVVert { 
   float co[3]; /*U,V,W coords, done in float for texture-baking purposes in the renderer.*/ 
   int maxco; /*the maximin numbre of UV coords, 2 for Mesh and 3 for HE Mesh*/ 
   int cotype; /*the coord data type, can be short=1, int=2, float=3, double=4, unsigned=bitflag 1024*/ 
   int flag;
} UVVert;

typedef struct UVFace { Image *image; /*image*/ UVVert **verts; /*verts*/ int totvert; int flag;
} UVFace;

typedef struct UVMesh { UVVert *verts; UVFace *faces; MemArena *arena; /*the memory arena*/ int flag;
} UVMesh;

Each UV mesh is allocated all at once, in a MemArena.

Comments

It should be possible to modify the UV editor to use an abstract interface to work on the mesh. This is not a trivial change, but it is also not a major project. Part of the work is just in making the editor work with ngon type objects (not I mean making the operations defined on ngon type objects, not changing the structure to an ngon one). Ideally these would be part of a general emphasis on moving to generic mesh accessor APIs (see MeshUsers). -- DanielDunbar - 22 Mar 2005

-- JosephEagar - 22 Mar 2005