Data Export Plugin (.obj-like format)
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 06/12/2004 at 20:59, xxxxxxxx wrote:
Hello
Maybe, I don't really underdstand your problem ,so my reply may be unuseful for you. Sorry for that.
I think you shoud record all the vertices and then what type the object is also (for each and every object,and their hierarchy). Then when reloading them again, you should craete the corresponding objects again. And then those objects should have the corresponding vertices of the old. Am I get?
I'm also interested in your case ( although I'm not an experienced in it), so I discussed. I have seen the "File Format Documentation for C4D V 5.2". Will they be useful for this problem. And I also want to know if the next versions of C4D publish the documentation like that.
If I waste your time, I beg your pardon.
ZawMinTun -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/12/2004 at 09:49, xxxxxxxx wrote:
No, please, I much appreciate it!
Actually for the format I only need to worry about rendering triangles, nothing else is excepted. (So when looking at the polygon structure I ignore the last bit)
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/12/2004 at 11:18, xxxxxxxx wrote:
Don't do that. The final vertex index of the polygon should point to the last index used (c = d) when using triangles. Otherwise, you may get strange results.
Since only one response, I will write what I had intended to write before. C4D stores vertices in an ordered array in memory. This is what you should save out - the array. The LONGs (a,b,c,d) in the polygon reference this array by index (which is a good reason why the vertex order should be maintained).
One thing to consider: Wavefront .obj format is 1-based (starting at 1) on the vertex lists (V, VT, VN). Arrays are 0-based (starting at 0). Also, if you are importing an already existing Wavefront .obj, you must react to negative indices in the facet list (e.g.: F -1/-1/-2) These are relative, backward offsets from the last encountered positive index.
Robert
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/12/2004 at 16:37, xxxxxxxx wrote:
Yea, I know. So if c = d, why should I export d? And to the rest of your post, yup, I'm fine with all that.
Currently it appears things are all good, at this point I need really need to emulate what the Wavefront plugin does as I'm happy things work in-game for me. Now I just need to figure out which vertices are effected by which bones. (then I can move on to the next thing :p)
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/12/2004 at 19:41, xxxxxxxx wrote:
Alright, I've gotten most everything figured out where hopefully in the next few days I can get basic animation working in game. Currently I can't figure out a way to find out what vertices are a part of a vertex map (weightmap). Rarely in the models I'm working with are the weightmaps created for the entire mesh in one weightmap. How do I figure this out?
Thanks again!
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/12/2004 at 20:06, xxxxxxxx wrote:
Easy enough. Each vertexmap has a Real array the same size as the vertex array for the object and its array members directly correspond to the vertex array (in index). This array is set from 0.0 (not influenced) to 1.0 (fully influenced). If you set the weights to only 0.0 and 1.0, then the vertices that are part of a vertexmap will be those that are 1.0.
Robert
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/12/2004 at 20:50, xxxxxxxx wrote:
Oh duh, cool
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 11/12/2004 at 21:06, xxxxxxxx wrote:
Now what about matching up the texCoords to the vertices? I export both the vertices and texture coordinates that I recieve directly from the structure manager. From there I export the indices in whatever order the structure manager gives me, thus rendering out the final geometry looks right...well, expect the texture coordinates are clearly screwed up. Is there something else I have to do to get the texCoords to match up?
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 11/12/2004 at 23:28, xxxxxxxx wrote:
This is trickier. Texture coordinates are not stored the same way that vertices are. They are stored in the UVWTag more like Polygon indices than an array. The UVWTag contains an array of UVWStructs that are exactly analogous to Polygons (they are literally UV polygons) with the same count as Polygons in the object. But (the big BUT), instead of storing indices into an array of texture vertices, the UVWStructs store the actual texture Vectors. There is no array of texture vertices. There is an array of UVWStruct "UV polygons" each containing 3 or 4 unique texture Vectors.
In other words, I wouldn't use the Structure Manager for retrieving Object and Tag information.
Robert
- Don't forget the Tylenol after reading this!
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 11/12/2004 at 23:31, xxxxxxxx wrote:
And to answer your question directly:
You can match up each Polygon by array index to the UVWStruct array index, then each vertex index in the Polygon will match with the texture vector in the UVWStruct (vertex[poly->a] corresponds to uvwstruct->a).
Does that make sense?
Robert
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 12/12/2004 at 22:04, xxxxxxxx wrote:
Unfortunately, no, it doesn't quite make sense. I believe some sample code would much better illustrate what you mean.
Sorry,
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 12/12/2004 at 23:42, xxxxxxxx wrote:
Unfortunately, I don't have any sample code to illustrate with. The only place where I deal with texture vertices is in my Wavefront Object import class and it would be difficult to boil out the rest of the code to get the essence of this. Plus, it's in C++ and not COFFEE.
So, let me try it this way.
* Every Object in C4D that has UV mapping has a UVWTag.
* Each UVWTag has a Texture Polygon array attached to it. This array matches the regular Polygon array on the Object (index for index). TexturePoly[0] is the texture polygon for Polygon[0] (and so on). Using COFFEE, you use UVWTag->GetData() to get the array of Texture Polygons and UVWTag->GetDataCount() to get the array size.
* Each array element (e.g.: TexturePoly[0]) has four Vectors (a,b,c,d) just like a regular Polygon. But...
* The difference is that regular Polygons' a,b,c,d are indices into the Object's Vertex array. Texture Polygons' a,b,d,c are actual Points (Vectors) - there is NO UV Vertex array!!!. This is done because UV mapping does not require that UV polygons are actually connected or touching. You can have a Geometry Vertex which has many UV Vertices (dependent upon how many polygons it is indexed by). There is not a one-to-one (Geometry vertex to UV vertex) correspondence; there is a one-to-many correspondence.
* You can create a list of Geometry Vertices in the file and the Polygon vertex references are directly from the Polygon a,b,c,d. On the other hand, when you create a list of UV Vertices, you will need to go UV Polygon by UV Polygon creating the list and tracking an index counter to apply to the Polygon reference in the file.
In Wavefront format this is sort of like:
f 1/1 2/2 3/3 4/4
f 5/5 2/6 3/7 4/8
f 6/9 5/10 3/11 2/12
...Note that as you fill in each Polygon index set, the UV Vertex counter keeps increasing. There are probably ways to eliminate identical UV Vertices, but you will need to preprocess an array of UV Vertices and keep an array of UV Polygons in which to store the indices (instead of the actual vectors).
Robert
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/12/2004 at 23:56, xxxxxxxx wrote:
Alright, so I rewrote my texture coordinate exporter part in my plugin so for each vertex I'd export the coorisponding texcoord. My code looks great, it seems to match up with the data I see in the structure manager, yet of course when I render it out in game it's all wrong. I'm fairly confident my in game rendering code is right, so I'm scratching my head why this isn't working. When I export to wavefront though they match up differently (IE my data isn't correct with theirs) although I don't know exactly where they got the match-ups from.
Here's all I got that might help:
// finish mesh texcoords if(ObjectTexCoordArray) { var referenceArray = new(array, ObjectVertexCount); var i; // sort the data for(i=0; i < ObjectFaceCount; i++) { referenceArray[ObjectFaceArray[i*4+0]] = ObjectTexCoordArray[ObjectFaceArray[i*4+0]]; referenceArray[ObjectFaceArray[i*4+1]] = ObjectTexCoordArray[ObjectFaceArray[i*4+1]]; referenceArray[ObjectFaceArray[i*4+2]] = ObjectTexCoordArray[ObjectFaceArray[i*4+2]]; } // write the data for(i=0; i < ObjectVertexCount; i++) { var values; //if(i/4 % 0) continue; //println(referenceArray _); values = stradd(tostring(referenceArray _.x, ".3g"), " "); values = stradd(values, tostring(referenceArray _.y, ".3g"), " "); obj->WriteLine(file, "vt", values); } }Hrm, thanks in advanced!