# New Import script: creating UV coordinates

I'm writing a new import script from DSON (DAZ Studio json-based format) to Blender. I've got the vertexes and faces in, but I'm having difficulty generating sensible UVs.

My Problem

I can't seem to get the UV faces (correctly) into my object in Blender. I've been trying to follow the example of the Wavefront OBJ importer code but I don't understand what I'm reading and my results reflect that. I keep loosing some of my UV points, and whats left are being connected by a nonsensical zigzagging mess.

Complicating things is that I have a severe case of perl brain so I'm sure my data structures make real Python programmers cry.

What I have:

• A datastructure called uvs that wrangles all the UV information from the file. A given object in DSON can have one-or-many UV sets; usually only one is used at a time although obviously Blender can do fancier things.
• uvs is a dictionary of named UV sets (the name of the set is the key to uvs) Each UV set is a dictionary with two keys
• one is 'textureCoord' and is an ordered list of tuples-pairs of the UV co-ordinates in the 0..1 format Blender uses.
• the other is 'uvFace' and is an ordered list of tuples-tris or -quads, each representing one face of the UV map. Each tuple is a list of indexes referring to the co-ordinates from 'textureCoord' used to build that face.
• Order for both 'textureCoord' and 'uvFace' comes from the original DSON file and matches the order in [the OBJ][1] file. Same with the vertexes and faces in my data structure and the OBJ file, therefore I'm feeling pretty safe in assuming the geometry face order corresponds 1:1 with the UV face order.
• Since I think I'm messing up terminology, I'll explain what I have with an example.
• A 1m cube exported from Studio has 8 vertexes, and six faces (all quads).
• It is unwrapped with what looks like a Lightwave style unwrap algorithm, giving me 6 UV faces packed into the UV map into a rectangular space - three per row, two rows, with no border padding between islands.
• I get a list of 8 geometry vertexes, and 6 geometry faces (referring to 4 indexes into the list of geometry vertexes).
• I get 18 UV vertexes, and 6 UV faces (referring to 4 indexes into the list of UV vertexes).

Given information organized in this way, what seems to be the best way to go about importing my UVs and getting them associated with the geometry correctly?

What I have found so far and what I've tried so far

Found: No real tutorials on how the UV API works. :( I would LOVE it if there's a tutorial out there that walks you through the Python API and UV creation, like I've found for geometry creation, but I can't seem to find something like that.

I read Importing UV coordinates and the linked article on BA and didn't find it particularly illuminating. I certainly thought I was building my mesh via polygon, when I tried implementing the BA article code I get KeyValue exceptions that seem related to the index of the loop??

[1]I've validated that I'm untangling the DSON data correctly by dumping my face lists to the console while I try to import, and comparing with an OBJ export from DAZ Studio. I've confirmed the OBJ imports fine into Blender, so I know Studio is producing consistent output. The UV co-ordinates and UV-face lists/orders match up, so that seems good...

I can create a new tessfaces_uv_textures and name it (and also a new uv_textures); I'm confused as to what the difference between the two is. I've tried assigning values to the tessface_uv_textures[mapindex].data.uvN properties and get nonsense; I periodically even loose geometry faces by doing this, which seems very odd.

If I comment out my sub that's building the UVs, my geometry faces come back, so I have isolated whatever THAT problem is to the way I was (failing) to handle UVs.

I've also checked out https://blender.stackexchange.com/questions/6053/simple-uv-mapping-example-in-blender-2-63-python and from there looked at the io_import_images_as_planes.py script but it is... utterly unhelpful. It creates an UV texture and otherwise seems to rely on the image plane being exactly one quad and the default UV map being exactly a square the shape of the image space to do its work automatically. I need to import an existing UV map, not set up the bare bones of one.

• Is there one UV coordinate for every vertex, or for every vertex in a face in your source data? Vertices are shared in Blender, but to allow "hard edges" for textures/UVs, there is per-face data stored in so called loops. UVs are per loop, so the indices are not equal to vertex indices! – CoDEmanX Jan 29 '14 at 16:00
• Since I think I'm messing up terminology, I'll explain what I have with an example. A 1m cube exported from Studio has 8 vertexes, and six faces (all quads). It is unwrapped with what looks like a Lightwave style unwrap algorithm, giving me 6 UV faces packed into the UV map with no borders. I get a list of 8 geometry vertexes, 6 geometry faces (Referring to 4 indexes into the list of geometry vertexes), 6 UV faces (referring to 4 indexes into the list of UV vertexes), and 18 UV vertexes. – Emily Jan 29 '14 at 19:30
• 18 UVs seems pretty odd, you would have 24 loops / UVs in Blender. Looks like some are reused (= more than one face that references such a UV vertex). You'll need to duplicate the shared UV coordinates and map them properly to Blender loop indices. – CoDEmanX Jan 29 '14 at 19:42
• Ah-ha! OK, that's definitely part of the problem then. I end up with 18 UV co-ordinates in the OBJ that I export from Studio as well, so I suppose it'll the same contortions as the OBJ importer. Unfortunately I still haven't deciphered what's going on in there. – Emily Jan 29 '14 at 20:45
• I'm back at home with my files and I'm not seeing duplication. I'm now several times confused? My geometry faces: (0, 1, 3, 2), (4, 5, 7, 6), (5, 0, 2, 7), (1, 4, 6, 3), (2, 3, 6, 7), (1, 0, 5, 4) My texture faces: (0, 1, 3, 2), (4, 5, 7, 6), (8, 9, 10, 11), (1, 4, 6, 3), (2, 3, 12, 13), (14, 15, 16, 17) and my texture coordinates: (0, 0), (0.33, 0), (0, 0.5), (0.33, 0.5), (0.66, 0), (0.99, 0), (0.66, 0.5), (0.99, 0.5), (0.66, 0.5), (0.99, 0.5), (0.99, 1), (0.66, 1), (0.33, 1), (0, 1), (0.33, 0.5), (0.66, 0.5), (0.66, 1), (0.33, 1) – Emily Jan 29 '14 at 22:43