Here's some information about the tspline format (we typically use the extension .tsp). Most of this conversation is from an email I wrote earlier, which assumes that the user is familiar with the OBJ file format. Our file format has several similarities with OBJ, although it also has significant changes, in order to maintain indices through load/save and handle T-Junctions and knot intervals.
You can load and save .tsp files via the command tsData. I think it's got help built into it, and I believe that it only works on the registered version of the plugin (although there is academic pricing if you're interested). You can also see the format if you save to a maya ascii file (which is also limited to the registered version).
We version our file format, so the first thing is a header. The current version of the format is 1.2. Earlier versions were more like obj, although changes have been made, as noted above.
I guess first, I should explain the format of our mesh. All of the components are single-indexed.
A vertex contains a face index (an index to one of the faces around the vertex) and a valence.
An edge contains two vertex indices, two face indices, and an interval index.
An interval contains a single double, the knot interval.
Faces are our heavy component. A face contains a list of edges, vertex flags, and UVs. The UVs are optional.
The ordering of the edges and flags is fairly straightforward. We use a CCW winding, and the vertex leads the edge. For example, if you have a square, edge 0 is on the left, vertex 0 is bottom-left corner. Edge 1 is on the bottom, vertex1 is bottom-right corner, etc.
The face also has a set of flags, indicating whether it holds geometry, beziers, or just knot information. If your shapes are all completely periodic, you don't need to worry about the face flags. (This was written to someone doing completely periodic shapes. I'll go back and edit the information about the face flags later).
Additionally, to maintain constant indices, we allow gaps in our indices. That is, if you've deleted vertex 30, vertex 31 is still vertex 31 after saving and reloading.
Here's information about the formatting.
The tag is v. A v without any other arguments on the line is a deleted vertex.
The other arguments are the parent face index (-1 for invalid) and the valence.
v [ <face index> <valence> ]
The tag is e. As with all of the components, just an 'e' on a line means it's a deleted edge, just in there to preserve the indices. The other arguments are vertex 0 and vertex 1, face 0, face 1. If the vertices or faces are invalid (as in the case near the edge of a mesh) then they will be -1. The edge is fairly unconstrained, in that there's no necessary relationship between the positions of the indices of the vertices and faces.
e [ <vertex0 index> <vertex1 index> <face0 index> <face1 index> ]
The tag is vt. The indices used are just for the file, so we don't have blank vt lines. The format is simply
vt <u value> <v value>
The tag is f. They can be deleted, and UVs are optional. The flag is whether the vertex is a T-Junction on that face. For example, a simple T-Junction is a corner for two faces, and a T-Junction for the third face.
Here's some amazing ascii art:
- Code: Select all
Say you have a mesh with the following local topology:
| | |
Here it is, labelled:
| f1 |
Vertex V is a T-Junction on f1, but it is not a T-Junction on f2 or f3.
f [<edge index0>/<is vertex0 T-Junction on face>[/<UV index0>]
<edge index1>/<is vertex1 T-Junction on face>[/<UV index1>] ... until vertex n.
That should be the basics of the file format. Of course, we reserve the right to change the format, although we'll try to maintain backwards compatibility (for reading files, at least).