Try 3Ds Studio Max help....

You actually don't need to add an MATD file just to texture something new you added to an object - in your case, the box. You just need to remap your texture coordinates. This is how I colored the shapes in the file I posted for you to look at.

I know how to do it in Milkshape if thats what you're using I can tell you how to do it. I don't know how to do it with other programs.

For a more complicated type of object with a lot of detail you would probably need to make extra MATD files.

I looked at your package file and I don't see anything obvious wrong with it, I compared it to mine and it looked to be okay. I haven't tried it in my game, but I am going to assume it is doing the same thing your other one was based on what you said. I have never encountered this particular problem so I don't really know how to fix it. You may need to wait for Miche to help you with it.

No, because each texture file is applied to a MATD which is applied to other files and it goes through the chain, but basically each texture file is applied to a "group" (I am going to call them subsets for this) in your mesh.

Yes, I know you can make more than one subset use the same texture file, but since they are different subsets then they will map the texture seperatly, not together, therefore you get odd results. (If that made any sense...)

The only way to aviode this is to put all of your subsets into how many subsets there were in the original mesh. This results in grouping some (or all) of your subsets into one subset in your 3D editor. If the original has more subsets than your new mesh, then you will need to delete the extra texture files and MATD files and entries in the SHPE file.

Once you do this you should be able to follow The Official Mesh Tool Tutorial and get your object made without any problems.

EDIT: Unless I misunderstood, and you were talking about what you need to do if/after your subsets are grouped into one subset...

I have been coloring my objects using the same texture file with a new map. I haven't had any problems as of yet doing it this way.

I do realize for some objects separate texture files may be needed but for a simple object or just for learning purposes, it may be a good idea to stick to the original number of files when possible.

I saw what you were saying about each map applying to a group, etc... and the way I have gotten around that in a case where I had a ton of separate groups (as in my keyboard in Beta Testers which started with about 15 groups and was condensed to 1) is I mapped each group separately in Milkshape, so that they all would fit together in one texture file, then I regrouped them to make just one group. It seems to work without any "odd results" as you said.

I updated my post... I think I misunderstood...

Yes, if they were all in one subset, there shouldn't be any odd results. (I don't think... :p)

Hi Miche, I know how it is.

I can answer my own question in #65 above. It all makes perfect sense now, AND there is an easy way to correct an XSI .obj for TS2 compatibility. Now that I understand this issue, I think I might be able to also apply it to .SMD import/export issues in XSI ModTool, especially since .SMD import/export is an XSI addon that uses scripts, which I believe I can study and edit.

First of all, this is all regarding the exportation, editing, and importation of a body mesh from TS2 in the .obj format, but it should also have a bearing on new mesh imports, and explains why you must turn off Auto Smoothing in Milkshape and XSI prior to exporting an .obj file. Second of all, I have XSI Foundation, the $500 version of XSI, upon which ModTool is based. I am not sure whether ModTool has native .obj import/export capability like XSI Foundation, but if it can run a .vbs script, then .obj import/export can be added to ModTool, and a vbs script to do this is available on the Softimage site. Finally, I am laying out all of this information to help advance everyone's understanding of the issues involved with 'Modding The Sims'. Even if I loose interest in this, someone should be able to use this to make progress with the modding tools.

The problem with all .obj import/export from the first and second-tier 3D applications is that they either strip out included vertex normals (VN) upon import or at the time of export, or they re-create an animation-industry-standard implementation of vertex normals at the time of export. There is no explicit specification of how normals should be implemented in the .obj file specification document (they are actually optional elements), and the examples in the document only show one VN per vertice (V), but different apps use them in .obj files in slightly different ways (or not at all). More on this below.

(Side Note: Face normals are NOT specified in the .obj file specification. They are implied by the face itself, but there seems to be some confusion on whether a face normal should point in one direction or another. The specification is present but apparently ignored by some programmers. Some applications import/export .obj files with some or all faces inverted from the direction in which other applications expect them to be. The .obj file spec does say that the order of vertices used by a face indicates that the face and face normal should be rendered as pointing in a certain direction. It states that "if vertices are ordered counterclockwise around the face, both the face and face normal will point toward the viewer." XSI does work exactly this way, but Cinema 4D generates a 'funky' .obj file, and apparently creates 'clockwise-oriented' normals.)

Vertex normals (not face normals) ARE specified in the .obj file specification, BUT they are optional. Many applications simply ignore them if they are present in an .obj import and they do not export an .obj file that includes vertex normals, even if the model was imported from an .obj file that had them. So the effect of importing an .obj into and immediately out of one of these applications is to strip out any vertex normals. If the application has the ability to display any normals at all, it is usually only the face normal, and that is just so the user can figure out if a face needs to be 'flipped'. Many apps now default to displaying the face as 'two-sided', rendering both sides of the face or poly, just in case the .obj file came from an app that created a mixed-up mesh.

The applications that don't strip them out often simply ignore the vertex normal data in the imported .obj file, and then create their own vertex normals when exporting a model as an .obj. For most of us who don't know what's going on in the .obj file, this is just as bad as stripping them out entirely, because this will create a file that is incompatible to one degree or another with TS2. It may or may not be acceptable to Mesh Tool, and render fine in the SimPE preview, but it might be 'exploded' in TS2 or Bodyshop, OR best-case, the body mesh will have normals that are not quite correct, resulting in rendering artifacts in TS2 or Bodyshop. For example, here is what XSI does: it reads in the actual vertex normals that exists and uses them to render the mesh correctly. However, the XSI .obj exporter is not perfect for TS2 in the sense that it exports vertex normals in the way XSI would like to see them implemented, which is different from how they are implemented within TS2. The XSI-generated .obj file has vertex normals that result in a correct rendering of the mesh in SimPE, but there is a problem.

Why are vertex normals an issue? TS2 uses meshes that are often not contiguous. Let's define a mesh section as a single mesh in which all polys share the vertices of adjacent polys. Open up a dress mesh, and you will see that many of the faces share vertices, but some do not. The mesh is broken up into sections so that there is a front and back half to a torso, and a upper and lower half to each arm, and so on. In XSI, the edges of the mesh sections are rendered light blue, indicating a boundary. In a TS2 dress mesh, the boundaries of mesh sections are arranged perfectly so that the vertices on the boundary of one section exactly coincide or reside at the same point in space as the vertices on the boundary of the adjacent mesh section. This make the mesh look like it is all one contiguous mesh, EXCEPT for one thing. A rendering engine is generally programmed to blend the colors of one face into the colors of an adjacent face so that a low-poly mesh looks like it is smooth, but this effect only occurs across polygons in the same mesh. Therefore, with default normals, the boundary lines will be visible because the shading of the poly on one side of the boundary will not be blended with the shading on the other side of the boundary. Furthermore, in XSI and other major apps, there is always one unique vertex normal for each vertex on a face, meaning that a face with three vertices will have three unique vertex normals, and this also means that a vertice that is shared by four faces will have four vertex normals associated with it. So it follows that the number of vertex normals generated by XSI (and apparently Milkshape in a certain situation) when exporting an .obj is always equal to the total number of faces multiplied by the number of vertices used by each face. For TS2 compatible meshes, each face has exactly three vertices, so this means that XSI exports 300 vertex normals for a model that has 100 faces. This is standard for most 3D apps. This allows a mesh that has faces that need to be rendered with sharp edges, such as a cube, to be rendered with sharp edges (no blending between faces), and meshes with faces that need to be blended, such as a sphere, to be rendered smoothly. Of course, it allows meshes that have a combination of smooth surfaces and sharp edges to be rendered correctly by selecting a 'smoothing angle', where faces that are at or below this angle relative to an adjacent face will be smoothed or blended with the adjacent face at render time.

Here is the heart of the problem. TS2, to save computer resources, is only able to use ONE vertex normal per vertex (which is smart, but bothersome). So if you look at an .obj exported from SimPE, it will always have one vertex normal for every one vertex, regardless of the number of faces. In the case of a vertex shared by three faces, the vertex normal associated with that vertex will be pointing out at an orientation that is the average of the normals of the three faces, resulting in the rendering engine creating a smooth blend between all three faces. In the case of the afbodydresslongtwo mesh, I believe it has 1341 vertices and VN's, and about 2084 faces, but when imported into and exported from XSI and many other major 3D apps, it will have 1341 vertices (good) and 2084 faces (good), BUT it will have 6252 vertex normals (bad). And because the new order of the vertex normals is very different from the expected order, even if TS2 or the Mesh Tool just throws away all VN's after 1341, the result will be 'wierd'.

TS2 creates the illusion that the two vertices that are co-incident on a boundary are actually one vertex, and that the two faces on opposite sides of a boundary are blended together by making the vertex normals of the two co-incident vertices also equal or co-incident. (I'll be adding pictures.) In other words, the two normals associated with the two points are bent or averaged together until they meet or become co-incident at a mid-point. This is also what happens when XSI or Milkshape smooths three adjacent faces together. In XSI, you can create a cube with 6 faces, and by default, the rendering will be hard-edged. If you display the vertex normals, you will see that each of the six faces of the cube have four vertex normals, resulting in 24 normals total. Each of the four normals associated with each face will be exactly perpendicular to the face. Then if the smoothing angle is increased so that the renderer tries to smooth the faces of the cube together, the normals will be bent so that all three normals associated with each of the 8 vertices of the cube will become co-incident. All three vertices at each corner of the cube will be pointing straight out from the center of the cube such that it will appear that 24 normals became only 8 normals.

(Side Note: The reason that this dress mesh can look right in SimPE after exporting from XSI and importing it back into a GMDC is that XSI will export the extra normals but they are all created using the vertex normal data extracted from the original dress .obj, and all vertex normals associated with a given vertex are co-incident and pointing in the same directions as the original TS2 mesh normals, resulting in the same smooth render of the mesh that it had originally in TS2. But the data is not exactly the same, and therefore it has rendering issues in TS2.)

There is good news however, which is the point of all this. There is a relatively simple algorithm for returning an XSI .obj to a TS2 compatible state. (Presumably, this will also work with Maya and Max, but since some apps actually throw away or trash the TS2 custom vertex normal data, this is not a given. Both ZBrush and Silo simply throw the custom vertex normal data away, making them unsuited to editing TS2 meshes (even with the pass through Milkshape! [EDIT: oops, this is apparently not true. Milkshape is tricky enough to smooth the normals of across mesh boundaries!]), though a custom .obj importer 'might' be able to rectify this.) The face data in a .obj file is in the form "f <vertex number>/<vertex texture number>/<vertex normal number>, where the number is determined simply by the order of the vertex data, starting at one. So the first face would be defined by a line similar to "f 1/1/1 2/2/2 3/3/3", indicating a face made up of the first three vertices listed in the .obj file. But in most 3D apps, a dress mesh .obj export will have the last face defined as something like "f 1339/6250/6250 1340/6251/6251 1341/6252/6252", where TS2 is expecting "f 1339/1339/1339 1340/1340/1340 1341/1341/1341". (Remember that each series of numbers above represents the vertex, then the texture vertex, and finally the vertex normal, each separated by a slash.)The cool thing is that since XSI has kept the custom vertex normal data and in so far that it altered it, it altered it correctly based on how the vertices were moved during editing, AND all the vertex normals associated with a vertice are exactly equal to each other, the list of faces in the XSI .obj provides a map that can lead the average plug-in programmer back to the ideal TS2-compatible .obj.

For example, if a vertex is shared by three faces, in the TS2 mesh it will have one vertex normal, but in the XSI .obj it will have three separate, differently numbered, BUT IDENTICAL vertex normals. This means that the list of faces can be parsed, and for each face that uses the same vertex, such as 1339 in the example above, all of the texture vertices and vertex normal numbers can be collected. In the second step, the list of vertex normals and texture vertex definitions must be parsed all duplicate definitions must be deleted. Then, the vertex normals and texture vertex definitions that remain must be properly reordered such that the vertex normal associated with vertex 1339 is also number 1339 in the list of vertex normal definitions. Finally, the list of face definitions is parsed and each vertex normal and texture vertex number is changed to match the associated vertex number. (i.e., the line "f 1339/6250/6250 1340/6251/6251 1341/6252/6252" must be changed to "f 1339/1339/1339 1340/1340/1340 1341/1341/1341")

If a plug-in structure is added to the Mesh Tool, I will be glad to write an XSI .obj import plug-in, and plug-ins for any other compatible 3D app. It should be pretty easy.



Final note regarding the "Cleaning of .obj files by importing/exporting through Milkshape: with what I now know about the .obj format and TS2 compatibility, I have a doubt about the correctness of a file that is passed through Milkshape. [EDIT: It appears to create good files by recreating normals even if they were stripped out by some other application, and by averaging the normals accross boundaries, and by deleting excess normals to create a file fully compatible with TS2. Sweet.] Because Milkshape is dedicated to editing game meshes, I can probably correctly state, even without yet seeing an MS .obj file, that Milkshape is exporting an .obj with the correct number of vertex normal and texture vertex definitions, IF Auto smoothing is off. Since its authors know that many games may only use one vertex normal per vertex, it may actually clean up .obj files with extra, BUT IDENTICAL normals automatically when Auto Smoothing is off. What probably happens when Auto Smoothing is on is that the extra vertex normals are generated so that faces that are at an angle to each other greater than the smoothing angle will be rendered without smooth blending. XSI has the exact same implementation and terminology, if I understand how it works in Milkshape. But a Big Question comes to mind. If a file from ZBrush or Max is imported into Milkshape, and it doesn't have the correctly blended normals along boundary edges, (or any normals at all in the case of ZBrush), then what does Milkshape do? I have no doubt that it can correctly recreate the averaged normal at each shared vertex, because this is commonly done by many apps, including XSI. But I am wondering what it would do at the boundaries of the separate meshes. It doesn't know anything about the mesh, such as whether it is a dress or a cube. So I am currently assuming that it would generate unequal normals for each pair of vertices along the boundaries within a dress mesh. This would result in a dress mesh that would have render artifacts in TS2 and probably be visibly blocky in the arms, fingers, and certain other places, due to the unequal normals along the boundaries. The one way that MS could work around this is for it to parse a mesh and treat vertex normals of co-incident vertices in the same way that it would treat multiple vertices on a single vertex, averaging them together so that they become co-incident, IF it was set such that it was supposed to smooth all triangles regardless, or if the triangles on each side of the mesh were angled relative to each other at an angle that was less than the smoothing angle cut-off. [EDIT: It's apparently doing just this thing, or something very much like it.] For a dress mesh, you would want the boundary normals to be averaged together, but for an angular mesh, such as a picture frame, you definitely would not. (I could understand if it were actually able to do this due to the fact that it is created to be a game modding tool, and therefore may have run into this issue on the meshes of previous games. I seriously doubt any other app in the world is doing this.)

Maybe someone could respond to my curiousity, or I'll just have to load the Milkshape demo and check it out. [EDIT: I saw some ZBrush to Milkshape to TS2 output in the clothing mesh tutorial thread that answers my question. It looks good. I'm definitely going to load the Milkshape demo and try passing files from it. I want to use both ZBrush and Silo for modding.]

Anyway, Miche, I will be checking into the .smd import/export scripts in XSI, if they are accessible, to see if the custom normals issue can be addressed. It would be really cool if the ModTool could be adapted to all of our modding needs through use of .smd.

Thanks so much for answering. For some reason I'm still a bit confused about that tutorial, I'll have to got over it again carefully. But let me ask you another question. I have exported the mesh, and just moved a few vertices around and left the shadows absolutely alone and then re-imported it, and left the shaodows and their textures alone. Those objects turn out fine but they have no shadows. It seems like they should have the same ones as the original objects, shouldn't they? I have also done it with new meshes which I renamed to match the old ones but I didn't quite understand how to change the material override... I don't know why my mind gets so confused about here. If you can think of any hints that might help me get it straight, I'd be really greatful. Thanks again.

If you left the shadow groups and textures alone, they should show up in the game as the original ones... Can you see the shadows in the SimPE preview?

If they are there in the preview, this may sound silly but when you look at your objects in the game, make sure your shadows are set to high. Otherwise you probably won't see them. It sounds obvious but it's worth a try.

Yes, they should have the same shadows. The Material Override files are actually *optional*, so you really don't need to worry about them (for more info, see the thread below). I was very confused about this whole thing too... but this thread really helped me:

http://www.modthesims2.com/showthread.php?t=41689

It's a lot to read, but it really helps you understand.

Feel free to ask any more questions.

Btw, Jaycephus, HOLY CRAP. That is a lot. You are good. :D

Regarding Milkshape:

From the clothing tutorial thread, it looks like Milkshape is rebuilding the vertex normals properly, even if they are not present. 'cdelang' used ZBrush to model, and Milkshape to process the .obj from ZBrush, and the output looks great in-game:

http://www.modthesims2.com/showthre...5321#post325321

So all I can say is I gotta get me some of that. $30 dollars is worth it for decent file conversion alone, even if that is all it is good for.

On the other hand, .smd import and export in ModTool and full XSI is done in .dlls, so no easy tweaking of a script for that. There is still the possibility of processing the .smd output from XSI with a helper utility or a plug-in to make it work properly in TS2.

So If I am doing everything right and not messing with the original shadows and they aren't showing up, could this be a SimPE bug?
Thanks for the link, I went over there and started reading, my eyes glazed over and my brain started bouncing around in my head like it was in a pinball machine.
I've been working from the Artistic Habitats tutorials which go nice and slow for me but don't address shadows.
Thanks again for your help, I may be able to ask some more sensible questions later.

Look at this forum... there is a problem with SimPE apparently, so there is nothing wrong with the way you are making your objects but there really isn't anything you can do about it until a newer version of SimPE is released.

http://ambertation.de/simpeforum/viewtopic.php?t=437

Thanks. That helps a lot.

Hi everyone,
I don't think this was answered. I know it was almost answered but then it was cut off kinda. Anyways why don't I ask the queston. Here we go.
Short and sweet: If your using the classic UV Mapper what do you select as the type of UV map? I know in TS1 you would pick planar (this may be wrong because i never really got farther than the transmogrifer green flamingo tut) But what do i pick? This is what happened. I was making an object in wings 3D. 5 hours later i finished and when i went to do the uv map, i got to the part where i have to unfold the object, its gives me an error about there being too many numbers or something. I think its because i have too much object and it wont unwrap without the program freaking out (but at least i didnt loose the table!). So now i need the UV map and as far as i know the only way for me to get it is to use the UV Map program so now it shows me this message - "this object has no uv texture coordinates use Edit -> New UV Map to create some". Thats all great and dandy but when i do it i pick planar and set the size to 512 (just like Granny taught me) and i leave the rest at default (align at z-axis; split by orentation; orentation: horizontal; gaps in mat) i click ok and it basically gives me 2 "pictures" of my table from the bottom. What am i doing wrong? nothing seems to look correct. Some help pease!! i wouldn't mind if the soloution was to import my .obj file into another 3d editor and do the uv map from there if its easier. but anything would help at this point i've been working on this stupid table from 10 this morning and its now 9:30 PM!! thats like.......(brain fries)... 11 1/2 hours!! i havent even eaten!!

It sounds like you need to try aligning it on a different axis.

but back to my problem i have a screen shot (last night it was a bit late so i couldn't upload it ) but here it ishttp://forums.modthesims2.com/attac...tid=45465&stc=1

On the first thing it doesn't matter what type of mapping you use as long as you use some. Secondly you don't need UV mapper classic if you've already mapped your object in your 3D program, all that is going to do is allow you to tweak the existing UV map to make it easier to put your texture on it, what the out of range data means is that the UV map is set up for a particular size and expects to have a certain number of verticies in it - if you're putting your finished object with the shadows into UV mapper it wont know what to do with the shadows. Also when you set up your UV map in your 3D program specify the map to be the same size as the texture you're planning on using for the final object, having a differently sized texture specified will also give the out of range problem. Its a little bit of your damnned if you do and damnned if you don't as to whether or not you correct it because either way its trying to put the shadow meshes on to your one single UV map.

Dean, there's a thread Numenor started that lists things to check why objects are displayed as invisible here

Wow! Wow! Wow!!!!!!!
Jay, I really appreciate that you wrote a thesis about why obj and smd edited in many 3d programs don't work. I wish I was a professional in this field and could understand every single word you said.

As you mentioned, mod tool users can try the obj converter available on the xsi site. I tried it but it didn't work. I installed it by choosing add-on> install. After installation, options 'OBJ Import & Export ' were added. I tried both of them but nothing changed. The picture shows which plugin I tried and what happened after I choose OBJ Import. Is this plugin the right one? I hope this is not.


Btw,I am anticipating that you or some other professionals can fix it soon.

Mabelline,

What happens if you press the "Obj File" selection in the middle of the Import menu?

A window popped up and I choose the file to import but finally no mesh appear.

yes i've done it here's my new mesh it's a bit naf but it is my first so enjoyhttp://www.modthesims2.com/attachme...tid=45732&stc=1

It looks great Dean, congratulations.

thank you .

Don't use UVMapper to map your object. Just use Wings 3D. The only time when you should use Wings 3D is when you get the "Out of range" problem. As far as some tips for Wings:

-> You must have more than 1 "chart" or color on your map

-> When trying the automated "projection" or "unfold" methods, you can't have anything selected

Hope this helps!