The reason I do not calculate normals on import is exactly because of PlasticBox's problem. Further compounded by the lack of easy vertex normal adjustments in MilkShape (and apparently Blender).

Getting the model right in Maya is easy to do. The art created for the game has the normals at the seams already averaged (where appropriate) so that there is not a visible line.

Some of what we are trying to do here is different from the normal art creation... we are trying to create a method to replicate models and allow small changes. I don't know for a fact, but I would doubt that EA has any 'importers' for Sims 2 or Sims 3 or anything. Just exporters, as they created the assets, or converted them from other art they created. For instance, I wrote a set of plugins for Sims 3 for Maya, there are numerous examples of exporters available, but no importer examples. Outside of game modding, there is essentially no demand for importers, except those for standard formats like Collada or FBX. But custom exporters, game makers write them all the time for each game engine.

There is a very real difference between the way most modeling programs manage normals and the way the game manages them, a fundamental difference between OpenGL and DirectX. In OpenGL-style modeling, each triangle corner has a vertex (may be shared), a normal (may be shared) and a UV (may be shared), implemented as three indices to separate pools of vertices, normals and UVs.

In DirectX, each triangle corner has a vertex (may be shared), implemented as a single index to a pool of data structures, each with a vertex, a normal and a UV. Because of this, this game engine (and many, many others) requires that vertices be duplicated at the triangle corners anywhere that a different UV or normal is needed for a separate face, because the normals and UVs are 'paired up' with each vertex.

I can't say either method is better than the other, but understanding how they differ is important to properly implementing an importer or exporter. For my GEOM exporter, I refuse to export a mesh when the vertices are not already split by the artist, because splitting them programatically ruins the morph alignment, or at least my attempt at doing so did (ask Base1980). For the object mesh exporter, I split them automatically (ask orangemittens). But for Sims 2, Sims 3, The Movies and I forget what all else, my game importers (exporters, too) always transfer the normals without modification. If the users need to smooth something after import, that is education. But when they get changed by the program itself and there is no tool to fix them, then the users are stuck.

At any rate, none of this is criticism at all. I have been very pleased that you undertook to make these plugins, for the benefit of the 'community'. I hope you continue the good work.

Thanks for the script, Ceixari!

I tested it and (after a little tabbing in and out of Edit mode to get the display to work – that's the issue we discussed ages ago in the script thread) checked out the normals, but they look exactly the same as in the object in post #1 here. This is an import from the virgin untouched 00000000 folder as decompiled.

Screenshot below.

I believe this must mean that either the normals are like this in the original EA object too, or – and I think I read that somewhere just yesterday when googling around – that blender recalculates the normals when leaving Edit mode in order to display stuff. I'll try to find a source for this.

See also posts 64 and 65 of the script thread (I had reported that objects don't display properly upon import in an early version of the script, and that I had to tab in and out of Edit to make them show up – see screenshots in that post):



--



This sounds like the type of task that shouldn't be done by humans with calculators, but rather by the big calculator in front of me =P. Unfortunately, the only programming environment I'm comfortable enough with to know how to do this off the top of my head is an audio signal processing thing that I bet nobody else on this site is using.

I would like to try and write a shell script that does this, though (that doesn't look hard to learn and it's the most sensible option I can think of (opinions?)), but here's one thing I'm stuck at before I even started: I thought I could scan the input file for matching vertex positions and then do my thing on those, but if you look at the screenshot in post #6, there's often more than two matching vertex positions (top and bottom of the "open door" for instance – this is a hard edge that I wouldn't want to smooth. There's also unrelated vertex pairs in that one that I wouldn't want to smooth either).

Does anyone have an idea how to determine which pairs need to be averaged? In the case of this particular object, one could go by Z value of the normal since the seam is exactly vertical (in blender Z is up/down, I haven't checked whether this is also the case in the s3ascg) but all I'd need to do is rotate the column to make that approach worthless. Is there anything else in the s3ascg that could be used to differentiate? Or can this not be handled in a meaningful way outside blender (for a script that works within blender, I guess one could use vertex groups or selected edges or edges marked as seam or something like that, to tell the script what to do)?

From Ceixari's script:



What are assignments and tangents? Skin weight I have a rough idea what it means, but I believe it's irrelevant for objects (and it's 1.000000 0.000000 0.000000 everywhere I see in my file). Assignments are also 0 0 0 everywhere, I'm just curious.

The assignments would all be zero if there is only one bone (you can see this in the skin part of the .s3ascg)

Ah, it's *bone* assignments. Thanks!

An assignment is the bone assignment... while there are three slots, objects use only a single bone index, that is repeated for each slot. 0 would be the first bone (computers start counting at zero, not one), and most objects have only one bone, thus the zeroes everywhere. Generally, objects that have some moving part have more than one bone (joint) in them.

Tangent normals are used in bump mapping calculations. They are perpendicular to a line pointing straight out (using the averaged normals from all of the adjacent faces at that point) from each vertex, and aligned to either U or V. A tangent normal and the inverse of it (which points in the exact opposite direction) form a line that touches the surface at the vertex at only one point. If you laid a cylinder on a flat plane, like a tube on a table top, the tangent would lie on the plane at the point where the cylinder and plane met.

I don't think the object meshes are actually rendering bump maps, but if so, the tangents are there for it to use.

Thanks for the info, Wes. So from that I'd conclude there is no way to do this outside blender except by "manual" numbercrunching (which I'm not going to do), which may or may not leave the option of a script running *in* blender (whether that's feasible I can't judge).

Don't know if this is interesting or just the expected behaviour in more detail, but I just imported the EA object again (with the test script that Ceixari posted), this time entering Object mode immediately, turning on normals display, taking a screenshot, then tabbing out and taking another screenshot.

Immediately after import, face normals are displayed but vertex normals are not. The object displays black.

Tabbing to Edit mode makes the vertex normals show up, and now the object is shaded (in the sense of like on the screenshot, not Shaded view mode – view mode is Solid on both screenshots).

Screenshots below. I don't know how blender deals with normals internally and how display of the object and display of the face/vertex normal vectors are related, just wanted to give some sdditional detail. I thought this was a bit funky since Ceixari says he doesn't recalculate the normals, yet the face normals are there right from the start.

If there are normals I import them and I add them to the face as standard. It was my understanding at the time that those are face normals. I only started recalculating the normals because of the black view.

Ah .. ok. Yeah. Recalculate != import, of course. Thanks for the heads-up =P

I'll spend some time this week re-writing a new bare import script based on information from this thread plus lessons I've learned during writing the .wso script. The .wso isn't perfect, but it was a new write and I've been able to get a better understanding of Python. I, of course, also need to prepare for Blender 2.5's API changes.