I've just started to learn about object making, and have a question I hope someone knows about-
So far I've made a coffee table and started on a sofa and when I first imported them into Milkshape(it happened on both) I had 6 or maybe 12 symetrically placed additional vertices with no faces (or maybe teeny faces I didn't see) floating around the perimeters of the mesh. Oddly, both times they seemed to somehow dissapear by themselves over the course of me making my mesh...
I tested the table in game and it works but the couch isn't done yet.
So my question is, do I need to add the floating vertices back? Or does anyone even know what I'm talking about,lol? I've been following JWoods beginners tutorial, and it doesn't mention this

Also, I cloned the maxis Medieval Sofa because I wanted mine to be 'hard' with no change for playing on the couch, since it's an unpadded wood sofa.
I understand that sofas change when being played on through morphs-if I clone one that has the morph, for making a base game compatible version, if I leave the morph out, will it still work in game and just never morph, like a body mesh with no morph? Or can you not do that with objects?
Thnx :lovestruc

I don't use Milkshape frequently, and I don't think to have understood exactly how these additional vertices look. If no one else replies quickly, I suggest to add a screenshot, maybe.
In any case, from what I read, I guess that they are not real vertices, but a representation of... something given by Milkshape.

As for the sofa and the morphs, yes, if you edit a morphing mesh but choose not to retain the morphs, the mesh will appear correctly in game, but it won't be animated when the sims sit/jump on the sofa.

You've lost me too. I think a screenshot would definitely help!

Here is how it looks on the tray and balls deco object (I have already finished and replaced my copies of the sofa and table)
The first pic has both groups shown, the second has both hidden. On the sofa and table it only had the symetrical ones on the perimeter of the object, and not the huge mess in the middle this one has.
Anyway, I tested my table and sofa extensively, and they seemingly work perfectly...

As said, I'm not very expert with Milkshape, but when you hide a group, it should disappear from all the viewports; therefore, in this mesh there aren't only 4 extra vertices, but a lot more, it seems like the mesh is duplicated...
What happens if you select all the vertices shown in your second screenshot (i.e. with the groups hidden), delete the selected vertices and then un-hide the groups?

Ya, there are tons of extras on this one-it was the table and sofa that only had the 4 or so extra. This one made me lol when I looked at it, with the hundreds of extras it seems to have. If I do what you say, when I un-hide the groups they are fine and the additional vertices are gone.

I'm not sure what the cloud in the food object is, but the symetrical vertices are undoubtedly the remains of the groundshadows. I don't know what happened to the faces that were attached to them.

<* Wes *>

This is not special at Milkshape. In Blender, when I import a Wavefront obj unchecking all the options, I obtain the same thing in Edit Mode (example with a groundshadow):

And when I keep checked "group":

Always in Edit Mode, the problem disappears:

For a part of an object, it's the same. When importing it I have to keep "Separate objects from Group" checked or the same problem appears:

This is odd, really...

I've extracted myself the mesh of the Tray-of-sphere in OBJ format, including all the groups and the groundshadow. SimPE claims the object to have 644 verts and 1030 faces.

Importing it in Milkshape gives the same visual result as Iamliz, and the object stats read: 1932 Verts (i.e. 644 x 3!), 1030 Faces. If I ask Milkshape to WELD the vertices, the count lowers to 644 and the extra vertices are not visible any more.

Importing the same OBJ file into Wings3D gives a visually perfect result (no extra vertices visible) and the stats are: 644 Verts, 1046 Faces (it's normal: Wings counts also the 16 invisible faces existing in the mesh, i.e. the "holes").

Importing the very same OBJ into UVmapper (that is NOT capable of showing single vertices) gives a visually correct result, and the stats read:
Vertices: 1932 (1288)
Facets: 1030.
I really DON'T know what means that number in brackets, but I see that 1932-1288=644, so it must mean something...


EDIT
I've examined the OBJ file produced by SimPE with the Notepad and I've found interesting things.
Each and every vertex is listed in all the groups (three groups = vertices tripled); but then, in each group only the right faces are defined, leaving all the remaining vertices in the group unassigned.
The OBJ ends with the comment:
# totalVertices: 1932
# vertGroupStart: 1288
Here is the "1288" again! What should mean "VertGroupStart"?

In any case, it seems something related to the OBJ exproter built-in in SimPE; I don't know if Quaxi or Peter Jones or anyone else has ever modified it since its first implementation into SimPE; maybe the meshes has always be exported this way? I never noticed that, because I always use Wings3D, that automatically discards the unassigned vertices...

Ahh! The vertex pool.

There are two ways to build a multiple-group mesh withing the game GMDC format. In one method, shared vertices, all of the vertices are in a single pool, and the sets of faces for each group all have index values that refer to this one big pile of vertices.

In the non-shared method, each group has it's own set of vertices, and the faces for that group use index values for just the vertex pool they are associated with.

To help clarify this, in the shared vertex pool, vertex index 222 might appear in any of the group face lists, and if it did so would refer to the same vertex, while in the non-shared pool (assumng the groups were all large enough) index 222 for group one would be a different vertex, from a different pool, than 222 in the next group.

The .obj export method you are describing would work properly on the non-shared pool meshes, but the entire pool is being repeated for each group in teh shared version. It would require some redesign to make it work right (the pool would need split into smaller sets for shared vertices).

<* Wes *>

So, should we report the problem to someone? If we leave things this way, Milkshape and Blender users will automatically have their meshes with a tripled number of vertices...

I know that SimPE always (and automatically) unwelds the vertices, when importing an OBJ; probably it's because the games requires it, I don't know; but in any case it seems that the non-shared method is more compatible with the game; while Milkshape exports the OBJ using the shared pool method, but is perfectly capable of interpreting an OBJ file containing a non-shared vertices pool.

Of course, the problem could be easily solved it the user welds the vertices (in Milkshape or UVmapper), but I think that many creators just don't do that.

As far as I know, the majority of objects use non-shared vertices. You could research this by looking at the GMDC in the tab that shows the sections. If there is only one Vertex (plus normal plus UV) chunk (with a count) then it has a shared vertex pool. Unless it has only one group, that would be normal.

If there are as many vertex chunks as groups, it is unshared. (If the total is somewhere between, it is part of each).

I know internally, MilkShape stores all the vertices in a single pool, I never examined the .obj format it writes as closely as you apparently have done. I know that the UniMesh exporter always creates seperate vertex pools, only the oldest of my MilkShape plugins (way back when) used a shared pool. The game can use them either way, and there is little criteria that would guide deciding one way or the other. I suspect that the differences in the way the game files were made are related to which ones are the oldest.

The UniMesh importer reads the files either way, and should not duplicate (or triplicate) the vertices. However, all the groups will be 'unwelded' if the original file had unshared vertices, because the importer does not weld duplicates, and in many meshes that would be a problem, especially where unwelded vertices were designed into the mesh, like on body meshes.

As far as reporting it, I would guess the obj exporter could be fixed, by whome is the likely question. However, this issue has been there a long time, I bet it's been more than a single year since it was last updated. Exporting the obj files as seperate vertex pools is fine, but those pools should be only the used vertices for that group (which would require the face indexes to be renumbered). That is not that hard to do, it just has to be thought of.

<* Wes *>

I just found this thread and just wanted to add a little something that maybe useful for meshers. The how's, the why's and the wherefore's I'll leave to Wes and Numenor.

Some although not all cloned objects seem to have these extra vertices. The best thing to do is hide all subsets which will leave these in plain view, edit-select all and then delete. You'll still have the mesh but without the vertex residue which is not needed for your new object. Also be sure to import the shadows at the same time even if you won't be altering them, because they too can contain extra vertices that will need to be zapped (interestingly the same pattern as the mesh).

Could it be useful to compile a list of objects which contain these?

I don't know where the extra vertices com from http://i236.photobucket.com/albums/...ilkshape3da.png
But you can get rid of them using the vertex/manual edit tool at the top left of the screen
http://i236.photobucket.com/albums/...ilkshape3db.png once you select manual edit a box list of verticels will open, just click ok and all the unused vertices will vanish.