|Search this Thread|
|27th Mar 2005, 10:30 PM||Solution thread for meshing problems caused by .obj editors other than Milkshape #1|
Update:I have figured out the solution to invisible meshes, and meshes that don't change - at least for WINGS 3D. If anyone could please post .obj files for the other editors having problems so I can examine the code, I would appreciate it. I will be happy to repost the working code for the first of each editor's .obj I can sucessfully import. Also anyone working on objects (tables, a new bed, whatever) having problems related to editors other than Milkshape, please feel free to join in. I would like to use this thread to eventually find solutions to all of the problems relating to using editors other than Milkshape.
I started this post to find solutions to using editors other than Milkshape. I went through the tutorial by WDS BRIANNA for creating a new clothing mesh. I used the WINGS editor. I had the original mesh showing up in import problem. I had the Invisible mesh in bodyshop problem. I solved it. It has to do with a variety of factors, and I am putting tips at the bottom of this first post.
If you can get to the step where you have an invisible mesh or a mesh that shows only the original mesh in SimPE, it is not always you messing up on the tutorials. I had those problems, and I redid the tutorial step-by-step, noting each step down in notepad as I went. I was sure that the problem lay in the import mesh process, and after experimenting, and experimenting, I got a mesh to import! From am editor OTHER THAN Milkshape. It can be done.
Like I said, if anyone cares, and is interested in helping me crack this problem, I will keep this post updated.
(Postnote:Regardless of difficulties I am having in this process, Many thanks from me go out to WDS Brianna for her dead on tutorial. It is not her fault that Milkshape is the only editor that seems to work with it. And Multiple thanks to Delphy etc for making a Mesh import tool in the first place. And for those using Milkshape as their preferred editor, no offense is intended in any way to the editor of their choice or those using it. It is just not the editor of MY choice.)
1). The first thing I have noticed coming up a lot, so the first thing I will suggest is to open your .obj file in notepad, and make absolutely sure that there is a line in it that says g something. "g body" if it is an outfit, "g top" if it is a shirt, and "g bottom" if it is pants or a skirt. (yes I know most of us have done this repeatedly. I just put it there for people new to the topic. If anyone can tell me if the same applies to object meshes, I would appreciate it.)
2). Open your .obj file in Notepad. Check your .obj file for lines that do not belong. Compare it to the original .obj export, and remove any lines that do not match except for the ones with all the numbers on them. (Will clarify this soon).
|27th Mar 2005, 10:50 PM||#2|
The only thing that I know is that almost every program exports the obj file differently though obj is a standard. For instance:
the sims 2 mesh tool utilises the following formatting:
-- X v (vertices)
- X vt (UV coordinates)
- X vn (vertex normals)
faces are declared as follows
f i/i/i j/j/j k/k/k
This means each point (vertex) has a single normal and a single set of UV coordinates and all of them have the same identification number.
I have seen other packages mixing vertex normals and face normals. Therefore the sims 2 mesh tools has problems to deal with the objects.
|28th Mar 2005, 2:28 AM||#3|
This is what i do and i have never had a problem
I make my object in Wings 3d. When im done uv maping it and everything i export it as an .obj Then i go over to milkshape and open the obj then save it again (i don't even touch the mesh) i usually just add a 1 to it. ex.
i made the object 'table.obj' in wings
i uv map it and get it ready to go.
I export it as an obj
i go into milkshape and open the obj
then i imediately export the obj to the file 'table1.obj' (the file name doesn't mader im just telling you that its easy just to add a 1 to the end so you know it has been though Milkshape)
then i use the mesh tool and put it into and do the rest
Basically all milkshape does is clean up the obj (as far as i know)
Its the easiest way and it only took me 6 hours to figure it out! hope this helps other people because it would be a shame not to be able to use wings, its a really easy editor.
|28th Mar 2005, 3:13 AM||#4|
I agree about wings. I downloaded Milkshape, Wings 3D, Maya, and something else, and spent about a day with each. The only one that I got the faintest idea of how to use functionally was wings. I couldn't even figure out how to import an .obj file with Maya. And as far as I can tell you need to use a plugin on milkshape to even select more than just an entire object. A plugin that says "Use at your own risk"!
I will try your suggestion. Maybe that was what I did. If no then, I'll keep trying other things, since I am working with a clothing mesh. I hope it is that easy though.
BTW, what versions of SimPE, and MTS2 Mesh tool are any of the other people having problems using? Maybe it is a version problem? I am using the versions that were current as of 03/23/05. v0.32.1907.27047
MTS2 Mesh tool v0.9.29 Beta
|28th Mar 2005, 10:04 AM||#5|
Well I went through my .obj code line by line comparing it with the code from the exported .obj, and found things that did not belong. Extra lines for g blah blah, and a line relating to mtllib. On removing them, I sucessfully imported a mesh from wings. But the strange thing is that I am getting them when I export from Milkshape also (which I have started experimenting with out of frustration). And the imported mesh has serious flaws, like gaps in the mesh, and parts that stick out a mile. The original one I did had no serious issues (except that I lost it trying to recreate the process), and the new mesh looks fine in all of the editors, the MTS2 Mesh tool, and SimPE. Just not in bodyshop or the game. I am starting to think about giving up if I can't figure this out sometime in the next several days...
If anyone cares, what I am trying to make is a WIDE leg pants mesh for teen males, and females - like JNCO, and if that ever works right I was going to make a saggers pants mesh for teen and adult males.
|28th Mar 2005, 11:49 AM||#6|
This works with most of the software for any object with sharp edges because there is little need for vertex maps. The main problem is the import/export of meshes like the body meshes or equivalent.
In fact when you look at body meshes, you will see that they are split into parts for UV mapping reasons. The only way to avoid creases and smoothing artefacts at the seams, is to have the vertex normals data stored in the obj file. That is what the sims uses and what Delphy's plugin exports.
My problem ATM is to find a way to export properly the "vn" vertex normal data.
Could you please post the obj structure as exported by wings3D.
|28th Mar 2005, 9:11 PM||#7|
I think all the posted info here is correct so far. I just have been investigating this and have a more complete picture.
TS2 needs one normal and one texture vertex per vertex definition. Furthermore, the vertex normals on the edges of meshes that line up with other meshes need to match. In other words, at the edge of each mesh boundary that lines up with another mesh boundary, each co-incident vertex has a normal that should also be co-incident (two normals appearing to be one), or the boundaries will render wrong.
Unfortunately, all 3D applications, including Milkshape, will export .obj files that are not exactly what TS2 wants. They may look correct in the preview, but they won't work right in TS2. However, Milkshape is one of the best applications, in terms of .obj output, because it can output good .obj files in many situations. I'm just saying that it is not perfect, or some magic translator that will fix all problems. People that use it successfully are usually only importing the 'vertex' information through the Mesh Tool. That means they are keeping the normal information in TS2 as it was, and only importing the vertex editing that they did in Milkshape or elsewhere. This is fine for light editing, but can result in rendering issues if making more extreme edits.
The issue is that some applications, such as Silo or ZBrush, strip out all vertex normals. Another major issue is that most 3D apps, including all the highend apps, utilize one vertex normal per face per vertex, meaning that they use a total number of normals that is equal to the polys times the number of the vertices used by each poly. So for a TS2 mesh, most apps that export normals in the .obj file, the number of normals they export is three per face, because a TS2 mesh always has three vertices per face. This means that a vertex that is shared by three faces will have three normals associated with it, even if all the normals are co-incident. Also, since the UV mapping is handled in a similar way, these applications will export .obj files that have a total number of texture vertices that equals the total number of vertex normals. I'm not sure if TS2 can handle the extra texture vertices or not.
What we need is a helper application, or a plug-in to the Mesh Tool that will process an .obj file and build the correct normals from the mesh. It needs to work with the assumption that only one normal per vertex is allowed. It also needs to look at mesh boundaries and smooth across the boundary.
The two things I am working on right now is creating an .obj export script for XSI that will export a 'good' .obj file, and then try to create a helper app that would process any .obj and export the ideal TS2 .obj file.
|28th Mar 2005, 10:48 PM||#8|
the trick is to merge the points at the seams, calculate the normal, unweld them and apply the calculated normal to them. I do not know how to do that
|28th Mar 2005, 11:38 PM||#9|
Don't know if it's a problem with Sims but when it comes to Poser morphs the vertice order must not change. Have you checked that this not is the case?
I do know for a fact that the order can change in some cases when using Wings3D and I have heard by others that XSI do so to. I'm totally new to Sims mods so it can be that I'm wrong. I do however not understand how anything else than missplaced vertices or incorrect v refs in the face data can make an object explode (the way it usually is described).
In an .obj, if you have several normals with identical values it should be OK to replace those with just one and have the faces involved reference it instead. This is also something that is done on the uv data (This creates smaller files).
So, as I did a small app for my own needs a while ago that recreates a correct vertice order (at least in most cases) any chance the vertice order is the problem?
|29th Mar 2005, 7:07 PM||#10|
In the cases I have checked, the vertex order is retained, but I haven't checked all the files I have been testing with. But you are right: if the mesh is 'exploded' it is probably a vertex order problem.
Basically, if the mesh comes in and looks fine except for shading problems and blockiness, this means that the vertex order is fine, but the normals are not quite right. (I'll double-check that all the apps I've been working with keep the vertex order correct, but I know that it is probably only in a certain case with a certain export setting that it might screw up the order for me.)
There are two separate things that can affect vertex position, and that is the order, and also the bone weighting or assignments. Or actually, the order is important BECAUSE of the bones. The order is important because the Mesh Tool is trying to associate a given vertex back with a certain bone. In other words, in the TS2 data, there is a bone weighting for each vertex, and some are weighted with up to three different bones. If a vertex on the other side of the body is switched to be influenced by a bone in the right hand, then you get the 'exploded' mesh problem. In this case, the mesh may look right in and the Mesh Tool, but explode in the game. If you open up one of these meshes in CAS or the game and cause them to go through animations, you might see a vertex in a foot swinging wildly around the body, and then notice that it is in sync with the head motions. That vertex has become associated with a bone in the head due to it being out of order in the .obj file. When the Mesh Tool tried to merge the .obj file data back with the original TS2 data, it can only assume that the order is the same as what was originally exported. There is no way to check this or re-determine the correct order.
This is what will be great about getting the .smd export from TS2 to work right (normals lost by XSI, not sure about MS), or about Wes's MS pluging that grabs bone data. Then order is not important as long as all the data is self-consistent, i.e., bones, normals, and UV's are kept consistent with the vertices. So then you can add vertices and create new faces, and even though the order of the original vertices may have changed, all the data is still referencing the correct vertices. I have added a frill to a dress in XSI and successfully imported it into the game using the .smd format, which has all the data, including bone weights. The frill works perfectly with the animation in-game because I used the same bone weighting for each new vertex as the other vertices in the hem of the dress. The only problem was the normal data being improperly imported and then exported by XSI. (Blocky arm syndrome)
I think the one tool we could really use is a Re-normalizer helper app or plug-in to the Mesh Tool. It would read through all vertices and determine the face normals, then for each vertex, add all the normals associated with that vertex together and re-normalize it's length (i.e. average the normals to end up with one normal per vertex), and then do the same thing across mesh boundaries by treating two co-incident vertices as a single vertex (each normal would be set to the averaged position, making them coincident; the two co-incident vertices would still have one normal each).
This kind of app would work much better than cycling meshes through Milkshape since MS doesn't actually fix normals. A program like ZBrush or Silo that strips the normals out completely could now be used for modding. (They 'can' be used now by using MS to create a fake normal, which gets the file into Mesh Tool, and then Mesh Tool must be set to import vertex data only.) The free ModTool could now be used with .smd data to mod TS2 dresses. XSI, Maya, and Max could be used, and their normal data could be corrected to match what TS2 expects to see.
I'm developing an XSI script for exporting the correct data from XSI to an .obj file, and it is almost debugged. It will then be trivial to switch this script to output the TS2-correct .smd file. Unfortunately, I believe that user scripts won't work in the free XSI ModTool, so this is only a solution for owners of XSI. So I am gathering the code for a .NET helper app that will process .obj and .smd files, and will try to write an app to do this.
|29th Mar 2005, 11:56 PM||#11|
Jay, this sounds great - although I don't pretend to understand all of what you said, I do understand about the "normals" problem.
I use MilkShape, and Wes' BodyChop plugins, and with MilkShape and these plug-ins, it is possible to mostly correct the normals by selecting and welding each mesh group (the plugins use three, to save secondary assignments as well as possible in MilkShape, which really doesn't support multiple assignments)
Anyway, this does an overall correction to the normals and does pretty much eliminate the angular, blocky, look from the edited mesh.
One that I did this way is posted here, if you want to look:
It's still not perfect, though, since there is no way in MilkShape to manually adjust each normal, it's an all-or-nothing automatic thing.
|30th Mar 2005, 7:10 AM||#12|
OK. now I understand why the vertice order is important in SIms as well.
The way my little app was used was like this:
I loaded a .obj into Wings3D(or XSI) and then exported it without making any changes.
Then I run my app and it created knowleadge about how how the vertices was reordered.
Then after saving the modified .obj file my app rather transfered the xyz values from the modified .obj file to the original file. That way I changed nothing but the xyz values. As I made it for Poser I actually removed the Normal data as Poser don't use it anyway.
It should probably also be possible to transfer the normals.
In Wings3D problems with vertice ordering seems to appear when it has to create extra faces in order to keep the model a valid closed object (as that is the way wings works).
Seems to be a god idea to use SMD files (as i have the XSI Foundation )
There is however one think I don't understand in how to use them . When exporting from there is no option to export to .smd (or do you only mean to use smd for export from the 3D app)?
Also, after reading, I get the impression that you are saying that there could be more than one normal per vertice?
I suppose a 3D app internally could have that (by maybe using the face normal also for vertices) but would it then not have to average them when exporting to .obj file as a vertice in a .obj file can reference one normal only?
Also to give co-incident vertices a averaged normal might not be whats wanted. In Poser (and I suppose Sims is the same), all edges sharing the same vertices are allways smoothed. The only way to create sharp edges (exept for adding more of geometry) is to not connect the edges thus having co-incident vertices that not has the same normal. As far as I know, if whe would give them an averaged normal instead whe would get a smooth transition over the edge even though it not is sheared and I'm not sure this is wanted.
|30th Mar 2005, 6:34 PM||#13|
Most 3D apps deal with one normal per face per vertex, even if that is only internal, and never really displayed. An app may display a single normal in the middle of a face so that you can tell which direction it is facing, but internally, they have to keep track of a normal and a UV coord for each point a face uses, so if a point is shared by three faces, it will have three normals and UV coords associated with it.
This is because that without the extra normals, a model could not have crease or smoothing angles. With only one normal per vertex, all faces would have to be smoothed together at render-time. In order to show a crease or sharp edge between two polys, the program has to keep track of or create on the fly the value of the vertex normals for each poly that shares a vertex.
If you have XSI, you can see this by simply creating a cube and displaying the Normals (regular Normals, not Poly Normals). There will be three blue normals per vertex. If you change the crease angle, the cube will be smoothed by averaging the normals together. Now the cube will appear to have one normal sticking out from each vertex oriented on a line from the center of the cube. But in reality, there are still three normals, and they are now co-incident. So for most 3D apps that export normals, even if the cube is smoothed with all vertex normals co-incident, the exported .obj file will still contain the extra normals and UV coords, 24 of each in the case of a 6-poly, 8-vertex cube. Since Milkshape was made for modding games, it is actually better in this respect. It doesn't export the extra vertices if the original .obj import didn't have them.
Regarding the UV coords, since you can separate each poly out and move it to a different place on the texture, then the program, and .obj file, need to store a unique UV coord for each vertex per poly, i.e., 24 coords for a 6-poly, 8-vertex cube. Even if you don't separate the polys in the texture mapping, XSI still exports all 24 coords.
In an .obj file, the vertices don't reference anything. A vertex definition only defines its actual 3D location. A normal does not reference anything. A vertex normal definition only defines a unit vector, but not where it's 'origin' or base vertex is located. Same for texture vertices. It is the face definition that ties it all together. The face will specify a certain vertex, texture vertex, and vertex normal for each point the face uses, in a specific order, which indicates the direction the face is facing. For TS2 meshes, a face should always consist of three vertices, so it would look like this:
f 1/1/1 2/2/2 3/3/3
This face uses the first, second, and third vertex, texture vertex, and vertex normal definitions in the file.
A second face, f 4/4/4 2/2/2 3/3/3, would share two of the vertices, normals and UV coords of the first face. This is exactly the kind of face definitions TS2 needs. However, most 3D apps will output a variation of the below:
f 1/1/1 2/2/2 3/3/3
f 4/4/4 2/5/5 3/6/6
The faces share vertices, but not normals or UV coords.
From what I know, and I don't have Maya or Max .obj files to say for certain, some applications include things in the .obj file that are objectionable, for various reasons. Some apps don't export any normals (ZBrush, Silo), and the Mesh Tool currently checks that normals are included, and therefore rejects those files. Some apps add object and material definitions, or 'non-standard' characters that may or may not screw up Mesh Tool. So then people are running these .obj files through Milkshape, and it is able to handle these various files. Then its exported .obj file is usually acceptable to the Mesh Tool, because it exports a file that doesn't have these problems. In the case of an .obj with no normals, MS creates a dummy normal and references it from all the face definitions. The result is an all-black model, but since it has normals, the Mesh Tool will now accept it, and then user are simply checking "use vertex information" only, and unchecking everything else. This means that the screwed-up normals are ignored, and only the vertex data is imported into the new GMDC. (It gets the rest of the data from the original GMDC.) Milkshape is not perfect, or ideal, but it can 'fix' certain things adequately.
Since .obj files are just text, it is sometimes easy to fix these files manually in Wordpad. If all you want to do is tweak points and re-import that data into TS2, then you can take the .obj file from whatever 3D app you have, open it, copy all the 'v' definitions, and paste them over the 'v' definitions of the original .obj file. Then create the new GMDC with the Mesh Tool using that edited file. This works fine if you just want to fatten up or thin down a mesh. If you want to add ridges to a mesh (i.e., change a face orientation by 90-degrees), then it will work, but the old normals will not render exactly right on the new ridges. The normal is still facing out, while some of the polys affected by that normal are facing up or down.
Regarding .smd files, you get those from Mesh Tool version .9.46. It has an option to open an 'original' GMDC and export the mesh data as an .smd file. Before I learned the ins and outs of the .obj file format, the .smd file was the only way I could get data from XSI back into TS2. The great thing about the .smd format is that it includes the bone assignments, so that means it is possible to add new vertices, and no longer worry about vertex order. The only problem with .smd files is related to normals. the Valve addon for importing .smd files doesn't keep the original normals, apparently. And therefore doesn't export them either. It does work with and export one normal per vertex, BUT the normals at the boundaries of a mesh are not averaged across the boundary, so you get 'blocky arm syndrome' in the game. (It also causes slight shading discontinuities along all the boundaries in a mesh.) It still almost looks good, but not good enough.
Regarding smoothing across boundaries, in general you are right. But in a dress mesh, most or all boundaries should be smoothed. In a mechanical object, the boundaries often should not be smoothed. The solution is to implement a crease or smoothing angle setting so that you can control whether it smooths everything, or only across boundaries that are at a more obtuse angle than the smoothing angle setting.
I've got the math to do this, but it will take me some time to get something together, since I only have an hour or two each evening to work on it.
|30th Mar 2005, 8:42 PM||#14|
Yeah and I suppose you wasted at least an hour of that time on that nice explanation.
As you say each vertice has its own xyz value and normal and texture coordinate.
That is true inside an application but not inside the .obj file. Say you have two separate triangles laying flat on ground next to eachother.
In the best of worlds it would look like this:
v -1.0 1.0 1.0
v 1.0 1.0 1.0
v -1.0 1.0 -1.0
v 1.0 1.0 1.0
v -1.0 1.0 -1.0
v 1.0 1.0 -1.0
vt 1.0 0.5
vt 0.5 1.0
vt 0.5 0.0
vt 0.5 1.0
vt 0.5 1.0
vt 0.0 0.5
vn 0.0 1.0 0.0
vn 0.0 1.0 0.0
vn 0.0 1.0 0.0
vn 0.0 1.0 0.0
vn 0.0 1.0 0.0
vn 0.0 1.0 0.0
f 3/3/3 1/1/1 2/2/2
f 4/4/4 6/6/6 5/5/5
But as far as I know the following is a totally legal .obj file for the same model:
v -1.0 1.0 1.0
v 1.0 1.0 1.0
v -1.0 1.0 -1.0
v 1.0 1.0 1.0
v -1.0 1.0 -1.0
v 1.0 1.0 -1.0
vt 1.0 0.5
vt 0.5 1.0
vt 0.5 0.0
vt 0.0 0.5
vn 0.0 1.0 0.0
f 3/3/1 1/1/1 2/2/1
f 4/3/1 6/4/1 5/2/1
Because of this a program should never expect to get a face looking like
f 1/1/1 2/2/2 3/3/3 etc. so in my opinion the
Mesh Tool does wrong to expect it.
The way the import code works in my little app is by reading all the vertice data while creating my vertice objects and setting x,y and z. All the other data is stored in temporary arrays. Then I loops throug the face data creating face objects and at the same time it fills the vertice objects with the missing normal values and texture values, based on the temp arrays and the references in the face data.
After that process I do in practice have a f 1/1/1 2/2/2 3/3/3 structured model in memory.
|30th Mar 2005, 10:45 PM||#15|
Yes, both those .obj examples are legal, but so is the case of 3 vn and 3 vt per v. And this is exactly what ZBrush, Silo, Cinema 4D, and XSI are exporting, although ZB and Silo don't export normals, and C4D appears to be flipping everything or treating the data as left-hand coordinates instead of right-hand, or something wierd. I've been using a 1341 vertex, 2084 poly dress mesh for testing, and all these apps will export 6252 normals and/or texture coordinates. (3 x 2084 = 6252)
I'm not sure that the Mesh Tool can do anything about the missing or extra normals and UV coords, short of re-normalizing the faces as I have outlined above, because TS2 expects the mesh data a certain way. Miche has said something about adding plug-in capability to the Mesh Tool so that .obj importers could be written for a certain app or apps. Given the way XSI exports the data, it would be a fairly simple algorithm to process the XSI .obj and get the TS2-compatible version out of it. (The correct data is present, including smooth boundaries where they were smooth in the original file, but Mesh Tool or TS2 can't handle the extra normals and UV coords that XSI exports. That's why I working on a .obj export script for XSI first. Since the data is all present, I just need to grab the correct normals and UVs, and reference them correctly in the face definitions. It currently outputs a correctly formatted .obj file, but I am not quite grabbing the right normals in the right order, so the re-imported model has shading errors because of 'random' normals.)
The full re-normalising capability is needed for apps that don't export normals in their .obj files, or that export unsmoothed boundaries.
Is your program an import script for an app, or a standalone helper app? I'm not sure, but it sounds like you are doing exactly what I am talking about for the XSI data: use the face definitions as a map to the correct vn and vt definitions for a given vertex, keep the selected ones, delete the others, and then recreate the face definitions.
Unfortunately for .smd files, XSI doesn't seem to import the actual normals in the .smd file, because the boundary smoothing is lost on import. For .obj import, there is a User_Normal folder in the Clusters folder, but for .smd import, no User Normals are created. It appears to just recalculate default normals. The interesting thing is that you can import the same dress mesh as .obj and .smd, and then drag the User Normals from the .obj mesh to the .smd mesh, and XSI will render the .smd mesh with the newly added normals. Then these new normals on the .smd mesh are actually exported when saving a new .smd file, and will show up in the game. This would be a simple solution, but unfortunately the normals of the .obj are 90-degrees out from the .smd mesh, due to it being imported 'upright', as opposed to the .obj, which comes in on its back.
|31st Mar 2005, 10:49 AM||#16|
OK, now I understand your problem.
I have actually never looked into an .obj file that has more normals than vertices as it allways been the other way around.
My app is a helperapp written mainly in order to recreate the correct vertice order. As the only thing I transfered was vertice positions it worked OK.
As your working on an solution for XSI I was thinking that maybe I should try to write a normal correction tool for .obj files. I need a reason to do a c# project anyway. I would however need some help with the math for calculating the averaged normals.
It would had been nice if such an app also fixed the problem with vertice reordering but I can't se how that could be solved together with normals as I can see no way for me to know witch vertice is witch if several vertices exists in the same coordinates and belongs to the same model.
It's annoying that the models in the .obj files are laying down ( I suppose It makes some 3D Studio users happy as it should show up correct for them unless they have change the axis system the last years) so an option to rotate the model would probably be nice to.
Do you think such an app would be usefull even if it only can fix the normals and not the vertice order and if so could you help with the math for the normals?
|31st Mar 2005, 11:03 AM||#17|
averaged normals :
X = (X1+X2)/2 should do the trick.
|31st Mar 2005, 11:07 AM||#18|
rotation : do a small vectorial multiplication routine.
mathematically, have two vectors : A (x0, y0, z0) and B (x1, y0, z0)
the vectorial multiplication A^B = (y0*z1-z0*y1; z0 * x1 - x0 * z1 ;x0*y1 - y0 * z1)
B is the rotator. If you want to rotate the object around the X axis, B is (1,0,0) around Y: B(0,1,0) around Z(0,0,1)
|31st Mar 2005, 5:04 PM||#19|
Well, I learned something a little dissapointing, but not surprising.
I got the export script in XSI to work. It just had a '0'-based collection that I was reading as '1'-based.
However, in XSI, it doesn't change User Normals as you edit a mesh, which means the .obj my script exports is no different than if I simply copied the original normal and face definitions over the definitions in an edited XSI .obj. The normals are never changed, no matter how much the vertices are moved.
So, this means that I really do need a 'Re-normalizer' for both .obj and .smd files created by XSI. Since XSI scripting has the vector and matrix functions for this kind of thing, I'm going to add 're-normalization' to my export script as a way to prototype the code, and then I should be able to create a C# version as a standalone app.
Telemon, a good site for 3D math is http://www.euclideanspace.com/maths/index.htm
You can find a normal of a vertex relative to a face by treating three adjacent points of the face as the origin and endpoints of 3D vectors, and then finding the cross product of those two vectors. Finally, you need to 'normalize' the resulting vector by converting it's length to one unit.
Doing the above for one vertex of each face, you could copy the normal to the other vertices of each face since they will all be the same, and then average all normals associated with a single vertex together to get the 'smooth' normal. (Since all TS2 faces are triangles, most vertices are shared by three faces, and therefore will have three vertex normals to average together. Cases of 2 and 4 or 5 are fairly common.) You will end up with one normal whose value will depend ultimately on the orientation of the three faces sharing the vertex. To average across boundaries, you need to determine if a vertex is co-incident with another vertex
You average the normals by vector addition, adding them together to get one vector, and then 'normalizing' this new vector, i.e., converting it back to one unit length. Here is a C++ normalization routine:
double t = Math::Sqrt(x*x + y*y + z*z);
x /= t;
y /= t;
z /= t;
|1st Apr 2005, 5:11 AM||#20|
Join Date: Feb 2005
'Re-normalizer'!?? It will be one of the greatest inventions on the planet and mod tool will be a perfect program for editing smd meshes. Hope you will succeed, Jay.
|1st Apr 2005, 6:16 AM||#21|
You seems to be quite on the way with your solution.
How far away from delivering a free standing solution do you think that you are. Are whe talking about weeks, a month or more?
Don't feel any pressure, I just need to know if I should try and write a 'qick and dirty' fix for my own needs in the meantime.
What about vertice reordering.
Do you have any solutions on that part?
As I said before, I did an app to fix this when using Wings3D for Poser morphs.
In short it did work this way.
1 Export the part(s) you wanted to edit to .obj format.
2 Load it into your 3D editor end export it again to .obj
3 Run the app by loading both files and it creates a 'translation file' that knows how the file has been reordered.
4 Reshape you model and export to .obj
5 Run the app by loading all three files and it will transfer the new vertice position to the original file that then can be used as a morph
There is a problem working like this when it comes to several vertices having the same xyz values as I dont know witch is witch. When this happened in the Poser case I just moved them all to the xyz of one of them. The chance that anyone should pull them apart on purpose was almost non existen and as I not transfered normals (Poser creates new and thus ignores any existing normals in an imported file) it was not really a problem.
So, in order to correct the vertice order before import using MTS2 normals must be moved together with the vertice. I suppose that you Normalizer app will fix normals but not change the vertice order thus keep that part as it is exported from the 3D application.
If so I might have an idea on how to be able to correct vertice order.
If a step was added between step1 and 2 that simply did go trough the .obj file and moved apart (as little as possible) all vertices that occupied the same xyz so that they got uniqe xyz values creating a new file.Then this file is loaded instead in steep 2.
Then in step 4 the original file is loaded for editing.
I know this means a lot of loading and saving but as long as one use the same say dress mesh as the base for differen modified dresses only step 4 and 5 has to be run.
What do you think?
Any other ideas on how to do it?
|1st Apr 2005, 8:42 AM||#22|
Thanks, that is a great resource I have been looking for ages...
My post on normal averaging is only a trick. I did not pretent it was accurate. It is a tricky calculation to get a "good result" insofar as the triangles at the seams are almost of the same size (the influence of each side is almost equal).
Great to see that you make tremendous progress at least on the understanding of the problematics.
|3rd Apr 2005, 5:11 PM||#23|
maybe i won't be much help, but since i'm using maya 6, and i find it quite user-friendly, and easy to learn, i would like some solution to be able to export a useable .obj from it.
i tried milkshape, and find that it creates a totally useful .obj, when you export a mesh to wavefront obj, but maya (which is a wavefront product) can't do a proper one (proper for the mesh tool).
soooooo what i suggest is, that someone could make a plugin file for other 3d programmes, like maya, max, xsi, etc. from the milkshape .obj exporter plugin.
the problem is, that .obj exporter is a built-in one in milkshape.
maybe someone could make its programmers somehow to give us their .obj exporter procedure, so someone could make a useable plugin....
|3rd Apr 2005, 7:06 PM||#24|
I'm currently also adding an OBJ and SMD page to the MTS2 Wiki under FileFormats. OBJ is mostly complete, but still lacking some details and discussion that I want to add to it. I haven't started the SMD page yet (I have the basic format as exported by the Mesh Tool figured out, but I don't have an official spec to work from, yet). I'm adding them so that we all can just refer file format and translation questions to these pages in the MTS2 Wiki.
I think it is definitely what is needed for ModTool, and I think it could benefit all users if it is a standalone app. I have downloaded and tested the ModTool and found out a few dissapointing things. The Softimage site states that ModTool can use any 'signed' addon, and also states that the script editor will work. Also, the site states that ModTool has had certain specific things disabled, including IGES import/export, but it says nothing about OBJ import/export, which leads me to believe that if you are registered, you should be able to import/export OBJ files. I have learned that this is not the case. No export is possible except throught the Valve and Unreal addons that they have created. No user addons can work, except the specially created ones, such as the Valve and Unreal (ActorX) addons. There are many scripting commands that are disabled in the ModTool, so even though some scripting works, I can not read normals or point data, and therefore cannot write them to an .obj file with my own script. So a standalone app will have to be created to add 're-normalization' capability to .smd output from the ModTool.
After testing in the ModTool, I think I will work on this as a standalone tool.
To get this working in XSI Foundation, with just .obj, I would say I need a week or less (maybe only one late night, since the only thing I need to add is the re-normalization). I've got .NET, so I'm working with that now.
I only just now understand how you are retaining the order of vertices (by mapping prior to editing). Since I haven't had an issue with XSI re-ordering vertices when I export a tweaked dress mesh, I haven't really considered the problem. Your solution would work, for example, treating the 3rd through the fifth decimal place of a coordinate of a vertex that is co-incident as a 'code', making them unique in the test file, then replacing them with the original data once the re-order map has been derived. You could use three places of one coordinate and then be able to handle up to about 999 co-incident vertices, or you could use three places of all three coordinates to handle more, but that's overkill for TS2 meshes. The only thing to watch for is that your 'code' vertex doesn't end up being identical to a pre-existing, originally non-coincident vertex. For the typical TS2 mesh, this could be a problem if the third decimal place is significant enough, and it is always a possibilty in general. And I'm suggesting the third through the fifth place because most 3D apps round to the sixth place, and therefore the fifth place should not be altered by rounding. If you pre-round to the sixth place, you might be safe in using the sixth place with most apps. I made my XSI .obj export round to the seventh place, since TS2 models are smaller than the average XSI model.
You're welcome, Telemon.
|3rd Apr 2005, 7:12 PM||#25|
gold, I'm looking at a maya.obj for someone else right now to see what the issue is with output from that. I'm checking that it keeps the vertex order, but since maya.obj files can be used by cycling through Milkshape, I'm pretty sure that it does keep the order, and that the problem is something minor with how the Mesh Tool wants the data. I've opened it up in a text editor, and it looks very similar to XSI output. I'll write back to here on Monday or Tuesday.