Hi there! You are currently browsing as a guest. Why not create an account? Then you get less ads, can thank creators, post feedback, keep a list of your favourites, and more!
Guest
#26 Old 3rd Apr 2005 at 11:33 PM
jaycephus
the main problem is, that maya export three normals for one vertice, and mesh tool only need one. other thing is, that a maya exported obj, through milkshape doesn't work properly, some polygons are gone far to hell, plus maya doesn't export the same values for triangles as milkshape does, however the object is the same.
i try to attach my object files for you to look out, one is the original exported from sims2, one is exported from maya, one from milkshape, and the last is from maya then through milkshape.
Attached files:
File Type: rar  obj.rar (237.3 KB, 19 downloads)
Advertisement
Test Subject
#27 Old 4th Apr 2005 at 7:21 AM Last edited by HellBorn : 4th Apr 2005 at 8:13 AM.
I will try and install .Net. Think I tried before but that I did run into some problems installing (or I was just to lazy to start half a day of installations at that point)

It's true that I will move the vertices but I will only need to move the ones that not are uniqe to begin with.

One thing that complicates matter is that some 3D apps not use a specific number of decimals at all but rather a number of significant digits. Wings3D works that way and it was a promlem when I wrote my Poser app. I did however talk to the developer and he incresed the number of significant digits to 8 a couple of releases ago with solved it for me then.

It does however mean that differen 3D apps migh have to be handled differently.

I have XSI Foundation myself and as you I have not seen any vertice reordering myself, so far the only indication I have on the fact that it should exist was a post at CG Talk from someone that had such a problem.
Lab Assistant
#28 Old 4th Apr 2005 at 10:24 AM
For information, obj files produced by Lightwave have the following structure.

v X, Y, Y
....

and for each face

vt U0, V0
vt U1, V1
vt U2, V2
f point1/-1, point2/-2, point3/-3

where point1, point2 and point3 are the indices of the points in the "v" declaration table. and -1, -2 and -3 must be read as "one or two or three lines above this one".

Quite different from what we are used to.

Note that the vt are not exported and must be recalculated.
Lab Assistant
#29 Old 4th Apr 2005 at 7:52 PM
Jay,I understand. I know the only file type for modding TS2 in mod tool is smd after many failures of loading user plugins including obj convertor. I really appreciate that you are going to write a program for creators who don't have XSI foundation. I wish I could help you. Good luck!
Test Subject
#30 Old 5th Apr 2005 at 1:00 PM Last edited by HellBorn : 5th Apr 2005 at 1:08 PM.
talemon:
That's a wierd one .
I do however think that the use of the negative values should be read as (the vt at the totalnumber of vts - number).

But I can't check so I could be wrong, it's just that I find it strange to make relative comparisons inside the file itself.

-----
I got sick tonight and thought that I should make use of that fact and do some programming. However, I mostly find myself sitting and starring into the .Net eviroment, I think I got a bit to sick;(
Lab Assistant
#31 Old 6th Apr 2005 at 2:38 AM
I confirm my understanding. I made a simple box, created a weird UV Map and I checked the structure of the obj file. It is exactly as written here

Maybe we should do the same exercice and store the obj file here.
Test Subject
#32 Old 13th Apr 2005 at 7:29 AM
talemon:
I don't now if you post was meant for me but if so.
The reason I don't think i t should be read as 'lines above this' is that there could be more or less rows between the v data and the f data witch means that the number of rows may change inside the file.

The way I describe it adding rows in the file wont have any effect on the references made in the file.

For a simple model such as a cube the resulting file might be the same. In order to make a more valid check do the same again but before exporting assign different materials to all side of the cube and compare that to the other cube.

The negative values are however annoying as it means that specific coding must be done for lightwave.

Apart from that I tink I know how I could write an app that fixes 99% of the problems when using other applications than Milkshape.

The problem I have is in getting the time to actually do it, at least before my summer vacation ...
Lab Assistant
#33 Old 14th Apr 2005 at 3:51 PM
Ahh, MTS2 is back up, but I may have lost my thread subscriptions.

Telemon,

The .obj format specifies that you can either use a pure reference to a list of data (f 1/1/1 2/2/2 3/3/3) or you can use a 'relative' reference. The relative reference uses negative numbers to indicate that you should look up above the face definition a certain number of definitions to find the relevant one. So this scheme lets the .obj data be organized completely by face. I have seen it done this way in one other application (Silo?).

I have been really busy at work. I also don't have internet at home due to living in the Texas Hill Country, where even wireless is hard to get. (Verizon just laid some fiber optic down our road, and a nearby company is starting to sell internet-over-powerline, so I may have an option soon. Don't mention dial-up: 26.6 is too slow!) I ordered the new C# Express beta on CD from MS a few days ago, and should be able to use that to work on a solution, or help out. I have VS 7.0, but it doesn't work well with .NET 1.1 and the latest DirectX, and I want to be able to use features in DirectX, such as vector and matrix math functions.

- Jay
Test Subject
#34 Old 14th Apr 2005 at 10:08 PM
Ahh..
Would be nice to know how to use the DirectX stuff but it's one of those things I can't figure out how I should get some time over to learn.

I have however dom some experimenting.
I was thinking of an app working like this.

1. Load the file exported by SimsPE.
2. The app welds identical vertices.
3. It the creates a new .obj file.
4. This file is loaded into a 3D app.
5. In the 3D app save in it's native format and then also export to .obj.
6. Load that .obj file into the app.
7. The app locates the vertices and notes any changes in vertice order.
8. The app exports a mapping file that hold the neccesary information needed in order to unweld and reestablish original vertice order.

Now it just to go working in the 3D app.
When all remodeling is done export to .obj format.
9. Load it into the app.
10. Load the mapping file.
11. The app should now get the new xyz values (also unwelds) and calculate new normals.
12. And export a correct .obj file.

Now for some thoughts around this refering to the steps:
Step 1.
As I said before I must have unique. But instead of moving them a little in order to make them unique I could just as well weld them. The plus of this is that unless one intentionally want to pull them apart editing will get a lot more easy as one wont risk to part them by misstake. It's also a BIG plus for Wings editing as it closes most of the model witch also makes editing a lot more easy.

On the negative side is the fact that when welding I dont really know what happens with the face vertice order. Welding could probably change the order from counterclockwise to clockwise witch may flip the normal in some applications.

Step2.
When it welds it will weld every identical vertice, it will probably be right to do so in 99% of the cases.

Step3.
If I am to edit a model I will probably do it in Wings.
And if I would do this as a Wings only app I can get away with only exporting vertices, face and group data.

I dont need the normals. As Wings needs to keep the model closed it will create new normals anyway.

I'm not shure if the UVdata is needed either. No matter witch app I use I can't s se a big need for an UV mapp when editing the mesh.

I did a test with welding and exporting only the vertice, face and groups and it worked very well in Wings.

Step7.
Restoring the original file is done by transfering the new xyz values to a copy of the original file. As this file also have texture coordinates that will also be restored automatically. What remains is the creation of new normal values.
If it's just about averaging the normals for identical vertices it would probably not be a big deal. Question is, how often will it create an unwanted result because the original modelers wanted a sharp edge or two vertices just happend to have the same coordinates.

Any thoughts on this solution and the problems,limitations.

I will probably wrapp something up that solves my own needs in order to get this to work using Wings. I do however not think that I will ever get enough time to make a more flexible app that can handle to different .obj files.
Making it work in Wings would probably help the majority of people as Wings is free and pretty easy to learn.
Alchemist
#35 Old 15th Apr 2005 at 3:55 AM
Quote: Originally posted by HellBorn
7. The app locates the vertices and notes any changes in vertice order.

Step7.
Restoring the original file is done by transfering the new xyz values to a copy of the original file. As this file also have texture coordinates that will also be restored automatically. What remains is the creation of new normal values.
If it's just about averaging the normals for identical vertices it would probably not be a big deal. Question is, how often will it create an unwanted result because the original modelers wanted a sharp edge or two vertices just happend to have the same coordinates.


I hate to rain on your parade, but the only identifiers for a vertice in the GMDC is the offset location of the vertice, and of course it's value (XYZ). All the other data items (normals, UVs, bone assignments, skin weights and blend data items) are held in arrays with the same offset position. It's a whole bunch of matching arrays. As long as all the data pieces are properly matched together, the actual order is irrelevant. And so is the vertice count (except, of course, the effect excessive vertice counts might have on game performance). But when the order of the vertices changes and some of the original data is carried over in the original order, things go to H*LL pretty quickly.

The ideal solution would be to create a program that would translate the native format of Wings or the program of your choice into a GMDC. That's what the mesh tool does (the input format being .obj) and that is what my MilkShape plugins do. I'm not married to MilkShape, but there ain't enough of me to go around to all the other programs.

Miche, Delphy, the DatGen people and I have contributed all the layout information on the GMDC we know to the Wiki area here. If someone wants more definition on some aspect, it's available for the asking. I would hope someone else will eventually decide to write a plugin/translator for additional editors... world fame and fortune (cough, cough) await.

<* Wes *>

If you like to say what you think, be sure you know which to do first.
Test Subject
#36 Old 15th Apr 2005 at 8:37 AM Last edited by HellBorn : 15th Apr 2005 at 8:44 AM.
wes_h:
I think you did missunderstand how it is supposed to works, probably becase of my bad English

Also this is to solve the problem that happens when using other editors than Milksape and for my own case with main interest on using Wings.

I have allready done this (recreating a correct vertice order) for Poser morphing.

My way of doing it will not change the order of anything at all.

Of couse, if the following statement is wrong my solution wont work.

'If you export the mesh from SimPE and then imediatly import it back using the Mesh Tool there should be no problem'

But if that is correct then what I plan to do should work.

What my app will do in it's first step is to figure out if and how Wings reorders the vertices. It does so by comparing the file from SimsPE with the same file imported and exported from WIngs (without doing any changes in Wings). It identifies the matching vertices by comparing the xyz values. This means of course that there must be only unique xyz values in the files and this is accomplished either by either temporary welding of identical xyz or by moving them apart a little so that they get unigue before import to Wings. Both ways has god and bad sides.

When the reshaping is done inside Wings the knowleadge about the verticeorder Wings produce for the file is used to transfer the xyz values from an .obj file created by Wings to the .obj file that was exported from SimsPE.

This means that at this moment the only thing that has changed in that file is the xyz values, nothing has been reordered.

Now one problem remains. As some vertices has been moved the original normals might not work well.

The normal problem has been discused before in this tread and based on that I need to replace the existing normal value with an averaged value based on the file exported from Wings. So now the app loops trough all the vertices one by one, finds the matching vertices and the normal values belonging to them in the Wings .obj file and calculates an averaged normal and replaces the existing normal in the SimsPE .obj file with that averaged value.

Still no reordering of any kind has happened inside the SimsPE .obj file, it just has some changed xyz and normal values and should import well trough the MeshTool.

The problem I see is in averaging a new normal is that it actually could be that a model is split up not only for the purpose of UVmapping but also in order to make it possible to have a sharp edges somewere and it will be hard to see the difference. The options here could be to leve the original value, average or by the use of a smoothing angle or maybe by some analyse of the original normals average some but not all normals.

I cant's see why this not should work.

Of course, a plugin would be really nice.
It would solve most problems but it would still not solve the vertice reordering that will happen when editing existing meshes in some 3Dapps. This reordering is what my app will try to take care of by only transfering the values and not the order.
Test Subject
#37 Old 16th Apr 2005 at 1:11 AM
Just tested to use Wings and my helper app in the cloth mod tutorial and it worked just great.

No more explosions

Currently I only transfer vertice data and leave the normals as they where exported from SimsPE, I will try to adress that later on.

For now, I will consentrate on making it more user friendly.
Alchemist
#38 Old 16th Apr 2005 at 3:05 AM
Quote: Originally posted by HellBorn
I have allready done this (recreating a correct vertice order) for Poser morphing.

My way of doing it will not change the order of anything at all.

Of course, a plugin would be really nice.


I see what you are attempting to do a little better.
I bought Poser 5 specifically to try to make a bodymesh GMDC builder, but so far, partly due to personal issues (move to Texas, primarily) it has fallen off the radar.
After looking at the package, I believe you could use Poser to create all the data needed to make a bodymesh that would work in the game.
The default models are too complex, as is the skeleton, but it does support the multiple skinweights and morph data needed to make good bodymeshes.
What is needed is a tool that would convert the saved poser file into a GMDC... a "compiler" of sorts.
I say that because I was unable to locate any documented programming interface to Poser except the Python one. I know there is an interface for external DLLs, because Poser uses them, but the details apparently are proprietary.
But all the data needed for TS2 (and a lot that isn't) is in the saved file.
The bones would have to be built to mirror the standard 65 bone model that TS2 uses.
As long as all the data elements get paired up correctly, the vertice number and order are irrelevant to the game.
<* Wes *>

If you like to say what you think, be sure you know which to do first.
Test Subject
#39 Old 16th Apr 2005 at 4:39 PM Last edited by Freddy Froglok : 16th Apr 2005 at 4:42 PM.
Default Got a few days before hell starts again
Wait, raw GMDC mesh/animation data format wheresa? Hell, writing seperate exporters/importers for apps would be a hell of a lot easier than running files through three different converters, which is what people are doing now. If there was something like a GMDC -> Generic Text Sims Mesh Format exporter, then everyone can write the Generic Text Sims Mesh Format importer for their own 3d application.

You say the specific GMDC format is in the Wiki forum? I'd much rather have the raw data availible so that I can yank from it what I need with a little script/application. I've got a few days before my twenty credit hours and my job batters me back into incoherency (yay, 20 credit hours with a design project course, I'm soooo fubared), so I'll take a gander and see what I can do with it.

Edit: Uh, could I get a link to the Wiki forums with the GMDC info? I am kind of missing it horribly, the way a drunk man misses that pedestrian crossing in front of him when he decides to run the red light...
Instructor
#40 Old 16th Apr 2005 at 5:38 PM
you find info about GMDC at wiki:

http://www.modthesims2.com/wiki/AC4F8687

Alchemist
#41 Old 17th Apr 2005 at 4:15 AM
Quote: Originally posted by Freddy Froglok
If there was something like a GMDC -> Generic Text Sims Mesh Format exporter, then everyone can write the Generic Text Sims Mesh Format importer for their own 3d application.


I have a very similar critter here, although it is a command-line tool. I use it to split the gmdc up into pieces for research.
Converting it to make a text script would not be hard, but the majority of the script would be line after line, in the thousands, of hex or floating point numbers. Not very intuitive.

Once you look at the layout of the GMDC (the Maxis DBPF format) you will see it was designed to be readable from start to finish in a single pass without any reverse seeks.

In my opinion it would be easier to just parse the binary file and read the data straight into an array or structure. The data length precedes each element, or is implicit, thus allowing code something like:

int len;
char array[10000];
fread(&len, 4, 1, fp);
fread(&array[0], len, 1, fp);

I applaud your enthusiasm. There are a lot of quirks in the GMDC related to how the elements are utilized by the game... I have learned many of these the hard way, so if you would like some pointers on some aspect, just ask.

<* Wes *>

If you like to say what you think, be sure you know which to do first.
Test Subject
#42 Old 17th Apr 2005 at 3:32 PM
OK.
If you tried using Wings3D when doing the "Tutorial: MTS2 Mesh Tool Clothing (now with pics)" tutorial and the model looked as it exploded inside sims then you can give this little application a try.

I did not make a compleate setup for the app, I just put the exe in a zip archive.
You must of course have the .NET framework installed but if SimsPE works on your computer you allready have it so it should just be a matter of unzipping it and doubleclick it to run.

I will make a proper setup when I get the time.

You should at least use Wings3D version 0.98.26b.
Attached files:
File Type: zip  Vertice Mapper.zip (10.5 KB, 24 downloads) - View custom content
Test Subject
#43 Old 17th Apr 2005 at 5:34 PM
Quote: Originally posted by wes_h
I have a very similar critter here, although it is a command-line tool. I use it to split the gmdc up into pieces for research.
Converting it to make a text script would not be hard, but the majority of the script would be line after line, in the thousands, of hex or floating point numbers. Not very intuitive.

Once you look at the layout of the GMDC (the Maxis DBPF format) you will see it was designed to be readable from start to finish in a single pass without any reverse seeks.

In my opinion it would be easier to just parse the binary file and read the data straight into an array or structure. The data length precedes each element, or is implicit, thus allowing code something like:


I myself also agree that from a programmer's standpoint, I'm going to have to pull the data into memory some time, so I may as well do it while I'm extracting the data, especially if I'm using my own homebaked tool.

The reason I was suggesting a text based export (which makes it a much bigger 'export') is for ease of export/import conversions between applications which do not support every aspect of the Maxis animation, mesh, and uv formats. Right now, people are jumping from GMDC to .smd to Maya .obj to .smd to wings .obj, and losing data at each pass. If the people can just jump from GMDCText to wings .obj, then back to GMDCText in a fashion that preserves the data that Wings3d did not modify, then I feel that's a significant step.

Because there are so many frigging 3d apps out there which each have their own quirks (ex. Milkshake only handles one bone weight for a vert), a text based format would allow for easy cut/paste of modified objects - you could do the design in Milkshake, say, and then run something like Wings to assign the weight, and use Blender for UV mapping (Blender has excellent UV unmapping options, by the way). Then anyone could simply hack apart the sections and put them together using a simple text editor, without needing to know the exact binary location to split/join the files in each location and without dedicated binary utilities to modify things (although the lazier ones will probably write their own utilities to do this - people don't realize just how lazy programmers actually are).

Also, with the text format, a person can use damn near anything in which they can write a macro, even Excel and Word, to perform certain actions, such as replacing the UV assignments in the middle of a data line or slightly tweaking certain vertex locations, or merging the data your application exports with original GMDC->text'ed data, like bone weights. User oriented text manipulation applications have far outpaced binary manipulation applications, and nearly any application that would support a binary format would support a text based format.

Finally, and most important in my view, a text based format allows easy identification of just where your exporter/importer blows the hell up and starts turning your Pamela Anderson with the jiggly DDs into an H.R. Giger model with strechy tentacles.

I had to make these points to convince myself that it's worthwhile to try to do something like this... :kami:

Quote:
I applaud your enthusiasm. There are a lot of quirks in the GMDC related to how the elements are utilized by the game... I have learned many of these the hard way, so if you would like some pointers on some aspect, just ask.
<* Wes *>


Thank you for the offer. I've done a few hack jobs on some older games years ago when games were much simpler, but this is much more complex, and I have no doubt at some point in time I'll be yelling, "Why in the hell is this thing 2 bytes longer than it should be? Why is there a 3F 2A at the end?"

Time to go attack the wiki forum and get overwhelmed by the total raw data, I guess. :read:
Alchemist
#44 Old 19th Apr 2005 at 4:03 AM
Well, a text intermediate file might be of some use.
The Poser package has a text-based save format, and some Poser users have written various macros that perform special things for these files. The Poser file format uses the main part of the .obj format syntax to store the vertices/normals/UVs and faces.
The biggest issue I have seen is that once you export the file, one vertice looks the same as another to the eye. And much of what you would want to do to the GMDC has to be done to multiple elements at the same time, as there are equal numbers of Vertices, Normals and UVs, as well as bone-assignments and skin weights, morph deltas and tangent normals, if present.
So they are much easier to operate on once they have been read into matching arrays.
Happy coding on your endeavor. I'm sure anything useful you create will quicly gain an audience, as good tools are scarce.
<* Wes *>

If you like to say what you think, be sure you know which to do first.
Field Researcher
#45 Old 22nd Apr 2005 at 8:59 AM
Hia, I've been running some experiments using gmax and SimWardrobe's SW-GMAX-OBJ-EXPORT.MS script to capture all the data for the listener window. I made a very basic sphere two ways (with smooth either on or off at object creation). I ran the script for these and copied down the data from the window in each case. I ran auto smoothing operations on them with a threshold of 45 degrees at which point the three or four normals from each vertex combined into one. Then I copied the NEW data from the listener window again. All four times the data was exactly the same (before and after smoothing operations - even though the normals had changed). Even using the gmax2obj.ms script gave the same results. The modified normal information is just not getting through.

I've been readying the above thread about copying and pasting the v definitions from a maxis .obj over our own v definitions and I had a thought. If I temporarily run a mesh smooth operation (which achieves smoothing in a physical way by subdividing faces and then guessing an average position for each new vertex), then copy the v definitions from the meshsmoothed object and paste them over the v definitions of the unsmoothed object - will that make any difference to the smoothness or will it just be ignored by the meshtool? I'm going to have a go now.
Page 2 of 2
Back to top