From Unify Community Wiki
Revision as of 04:12, 13 January 2013 by Drobe (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

I will test this later but I believe the problem is not that it only saves one game object but rather that it is saving the same file multiple times with the same name. The filename for the object is retrieved from the first selection outside of the loop, but then the loop iterates over all the items in the selection and saves them using the same filename.


The above comment is completely correct; the exporter will write each selected GameObject's mesh data, but it will constantly open the same file and overwrite the previous version of the file. In the end, that last written GameObject's mesh data will persist. There's are one of several possible fixes to this: first, you could try appending an extra character to the filename for each of the additional selected objects, but that will result in possibly a lot of individual .obj files. You could also do this:

ObjExporterScript.MeshToFile(mf, fileName, /*This is the change*/true);

Which should tell the stream writer to append to the file. This, however, will result in a file with a lot of submeshes. That might be what you want.

There's still a few more problems: The script doesn't dig through the GameObject hierarchy to write all of the child meshes to disk. You would need a recursive appending of mesh-strings to do that.

Also, this doesn't scale the mesh to its Transform's scale or offset. This could be a problem if a user is intending to use this script to export a GameObject as they see it.

And one more; The .OBJ exporter that this refers to identifies submeshes using their GameObject name. As we all know, GameObjects can easily share names without issue, but the .OBJ format sort of lumps together vertices and faces that share a submesh name. That causes some interesting stuff to happen to the exported mesh.


Personal tools