|Search this Thread|
|29th Jan 2010, 05:50 PM||Blender Object (S3ASC) Import/Export Scripts #1|
The Python scripts contained in this post are the Blender object import/exports scripts based partly on the specification from the wiki, having a look at the current GEOM .py script (against its wiki specification) and the .s3ascg files extracted with S3ObjTool. These scripts are still evolving and I expect that this will be the case for a while yet. That said, they are workable in most cases.
For different operating systems this is:
How to use:
I'll load simplistic videos on Youtube for this as we go along and I find people having particular issues which might be better explained through that medium:
These scripts are for objects only. If you wish to do Body Meshing (GEOM), please see the Blender GEOM Mesh Plugin
0.1.0 - First test script
0.1.1 - Rewrite, much smaller, less complex code, learnt more Python
0.1.2 - Added UV code
0.1.3 - Fix for UV Code due to extra UV lines in some .s3ascg files
0.1.4 - UV now the right way round
0.1.5 - Smoothing per face (causing black faces on my laptop)
0.1.6 - Calculation of Normals = Blackness gone
0.1.7 - Quick fix for files without UV
0.2.8 - Added Armature/Bones / Upped the w/o to keep it in sync
0.3.9 - Added the text objects that was necessary for the export to function
0.3.10 - Added a check to ensure one import is not done while another import is active
0.4.11 - Rewrite of the script to accommodate multiple UVs
0.4.12 - Sometimes there's a skin line with zero quantity and no lines
0.4.13 - Fix needed for Vertex Groups where the related bone was a duplicate and therefor removed
0.4.14 - Removed some debug print lines I left in.
0.5.0 - Setting the version same as export script. Both seems stable.
0.1.0 - First test script
0.2.1 - Skipped to keep minor versions in sync
0.3.2 - Test version for initial testing
0.3.3 - Fixed an error where the imported assignments were zero and weren't stored by Blender
0.3.4 - Added a check to ensure it can parse the group names. Added a check to ensure a prior .s3asc import was done
0.3.5 - Fixed another error where the imported assignments were zero and weren't stored by Blender
0.4.6 - Changes necessary for multiple UVs
0.4.7 - Error on no default UV Texture now provides a better error message. Making provision for VRTF-6 and non-sequenced VRTF/VBUF sections
0.4.8 - Ensuring no errors are reported for meshes which do not have/should not have UV textures
0.4.9 - A further fix to the VRTF/VBUF sequencing when multiple UVs aren't next to each other
0.5.0 - Fixed an error with assignments. Been using this version for some time while writing the .wso scripts. Seems stable so far.
Delete any scripts in your Blender scripts directory starting with S3ASC. Now that we have the proper scripts, we no longer need files specifying with and without bones, so a simple import and export name is sufficient.
These scripts, especially the export script, is still in testing phase until the version is upped to 1.0. If any problems in the process is experienced while using these scripts, even if you see the error in S3ObjTool, please report the error here. We'll be able to tell if the error is with the scripts or with another tool.
|30th Jan 2010, 01:04 AM||#2|
oh wow this rocks! i'm still just starting out in all this but i've always liked blender best out of the 3d modelers. mostly because of it's boolean options since i can't seem to figure that out in the other programs. not to mention it's free.
i'd be glad to guinea pig and cheer on the sidelines. that's about as useful as i can be haha. good luck and you are great for doing this YAY.
just wanted to add moral support XD
|1st Feb 2010, 08:51 AM||#3|
I thought I should give an update, incase people were wondering.
I'm working on the Import script first and I've been able to import the first .s3asc (or rather directly from the .s3ascg). I need to debug the script today as some of the vertices were totally out of place, so the object looked weird. I used on of the simplest objects (a bowl) to play with initially.
The script is extremely bare and thin at the moment, which is why it's basically importing per group rather than loading all the files at once. For now I'm only importing vertices and faces to create the basic mesh, but hope to move on the the rest of the script by tomorrow.
|1st Feb 2010, 12:28 PM||#4|
If you could spare me ever having to touch Milkshape again, I'd love you forever.
Do you know that there is a (small, inactive) "Blender users" group on this site? http://www.modthesims.info/forumdis...546&groupid=245 <-- if you need testers or something, you could post there, I imagine most of them will have subscribed to posts in that group (even though it looks a bit dead).
|1st Feb 2010, 03:23 PM||#5|
Didn't know about that one. Thanks for the link, I'll bookmark it
|1st Feb 2010, 05:58 PM||#6|
To echo Plasticbox, this script would be GREATLY apppreciated. I think Blender users feel a bit left out (which I also think explains the inactivity of the group), and only a few have put their gloves on and used MS. I was close to going to beg in some Blender forums, but you're saving my dignity
I will be more than happy to test and help in any way (not much of a script writer though )
|3rd Feb 2010, 01:20 AM||#7|
Me too! Let us know if we can help in any way. Blender is such an awesome tool for ts3 stuff, if only it weren't for that ridiculously long ->obj -> Milkshape -> s3asc -> converter production chain.
|3rd Feb 2010, 01:31 AM||#8|
I would tell you that we're all lucky someone sat down and spent a lot of time thinking about how to get these EA things out of the game and into a format editable by the average user but, then, I'm sure you know that.
Quite honestly, it's one thing to hope your favored tool is added to the list of tools that can be used as a primary corridor between your mesh and the game, it's another to say what has already been provided to you is "ridiculous".
If the major lifting hadn't already been done, I seriously doubt you'd be complaining about this issue...you'd be sitting there hoping someone would create something...*anything*...that would allow you to edit Sims 3 objects.
I would suggest a little gratitude, but then, I'm hoping after considering how your post comes across you might show some without any hints.
Just my two cents.
|3rd Feb 2010, 02:19 AM||#9|
Huh? I think you are over-interpreting my post a little.
If one works in Tool A, it is more complicated to go through Tool B and back rather than using Tool A directly. It doesn't matter who made them, how good they are, etc .. it's a detour, and if there were a Tool A script, that detour wouldn't be necessary. That's all. In comparison to TS2 (where one could make stuff with just blender and simPE), going through > > converter > milkshape > blender > milkshape > converter > > *is* a very long chain – a script that could eliminate one or two of these stations would almost cut it in half. This is why it matters for blender users.
|3rd Feb 2010, 02:44 AM||#10|
And that's if you get it right the first time through, which never happens.
|3rd Feb 2010, 02:48 AM||#11|
LOL – tell me about it!
I got it to work in the end (the presets too, yay!), and the shadows look super awesome now. Thanks again for your help.
|3rd Feb 2010, 02:50 AM||#12|
I think everyone gets the issue PB. It's possible to discuss the means of object editing without belittling the method that is already there...cmo has.
In my opinion calling that means ridiculous in some way is a belittling thing to say. I don't think it is "over-interpreting " to think so. It is far different than saying you would like a more stream-lined avenue which it seems like what you really meant. If that's what you mean then you should stick to what you mean and not add in a pejorative concept like "ridiculous" IMO.
I'm not going to argue the point further. I've said my piece.
|3rd Feb 2010, 10:13 PM||#13|
Well, back to the scripts then
The script can do the vert positions, the faces and the texture coordinates. The .obj import script does not import normals and for now I'm going to let Blender automaticaly recalculate the normals as well, but of course the export script will have to include those, but that's not a problem.
I do have a question though and that's about the VRTF section. I can see form the WIKI specs that the VBUF and VRTF has some relationship and I can relate it in the file as well.
I extracted the Garden Gnome object and one of it's files has the following:
vrtf 6 28
0 0 0 7 0
1 1 0 5 8
2 2 0 6 12
3 3 0 4 16
4 4 0 5 20
5 5 0 5 24
0 1C5C004B 1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 0.112335
0 0 -0.153813 0.045656 0.022614
0 1 -0.156250 -0.976563 0.164063
0 2 0.109702 0.062361
0 3 0 0 0 0
0 4 1.000000 0.000000 0.000000
0 5 0.953125 -0.265625 0.093750
1 0 -0.199377 0.051820 0.017457
1 1 -0.156250 -0.976563 0.164063
1 2 0.038329 0.067287
1 3 0 0 0 0
1 4 1.000000 0.000000 0.000000
1 5 0.960938 -0.250000 0.000000
Now I know that the first character is the line column represents a counter (line number if you wish). In VBUF it's more like a grouping counter, but you know what I mean.
For column 2 in VBUF 0=position, 1=normal, 2=UV, 3=assignment, 4=skin weight, 5=tangent and I'm taking that it means the same in VRTF. In the VBUF section I'm kind of covered with the rest of the columns, but the VRTF columns still escapes me.
|3rd Feb 2010, 10:45 PM||#14|
Join Date: Sep 2004
Orangemittens, the phrase was "ridiculously long" not "ridiculous" and the target of the epithet was not a person or a person's work. I'd like to know just *who* you thought the poster might have upset with their comments?
Please do not PM me with questions about modding. Please post in an appropriate forum and send me a link to the thread if you would like me to try and help.
|3rd Feb 2010, 11:53 PM||#15|
Why me, of course, Inge. That's why I said, "in my opinion."
Sorry to go off topic in your thread again Ceixari...I'm very glad you're moving forward with this project
|4th Feb 2010, 03:03 AM||#16|
The first line has the item count  and total bytes-per-vertex  .
Then, for each of the  specified lines you have:
The "counter" in the first column... it is there to maintain a check on line sync.
The second column is the item type, position, normal, etc. from the list.
The third column is the instance number... usually this is zero, but some files have multiple UV maps, so for those [type 2 in column 2] you may see a "2 0" and then a "2 1", the first is the first UV map (instance 0) and the next would be UV map 2 (instance 1). There is not an example of multiple UV maps in that file, but they will be in others.
The fourth column is a compression type... you don't need to keep this, but the recompiler needs that to make sure it produces the proper format on the binary end. The decompiler has converted the compressed binary to ascii floats or ints.
The last column is the byte offset... again, this is needed for recompilation, but of little use to an import script.
When writing the export, you need to first read in the vrtf section, so you can write it out following the format. While position is usually the first thing, followed by normals and then UVs, this is not a requirement, and things are not always ordered 0, 1, 2, 3, 4, 5. The list of types can be in any order.
How I manage this is I build an array from the vrtf, and then when I read the vbuf I loop in this case 731 times, with each of those loops expecting to read six lines (a nested loop) following the mapping laid out in the vrtf. Each line read should match the first column in the vbuf to the outer loop counter (0 to 730) and the second column should match the type of the item (position, normal, UV...). The remaining columns are the proper number of operands... 3 for position, normal and tangent, 2 for UV, 4 for bone assignments and 3 for skin weights.
If a skin weight is zero, the the matching bone assignment is immaterial, although you will probably always see zeroes for anything unused. Now there are only three skin weights and four assignments, how that works is the fourth skin weight is implied, when used, it is 1.0 minus the sum of the three other weights.
Not that object meshes use anything but a single weight, always 1.0 (or 0.0 for unassigned vertices). But the text format is really a simplified version of the binary, with all the data reordered from separate parts (vrtf, vbuf, ibuf and skin) into one file (per group).
I hope this doesn't make your head explode, because then everybody will be mad at me for bumping off their new hero.
If you like to say what you think, be sure you know which to do first.
|4th Feb 2010, 03:15 AM||#17|
Never mad at you, Wes. We can rebuild him. We have the technology. We can make him better than he was before. Better, stronger, faster...
|4th Feb 2010, 03:55 AM||#18|
Glad to see you're getting this thread back on track.
|4th Feb 2010, 05:01 AM||#19|
Gee. Steve Austin.
Only nowadays, 6 million simoleans won't get you a yacht, much less a bionic man.
If you like to say what you think, be sure you know which to do first.
|4th Feb 2010, 08:30 AM||#20|
Thank you Wes.
This will take some reading and re-reading, but the VRTF section and the loop through the VBUF section is straight-forward enough.
|9th Feb 2010, 07:39 PM||#21|
Okay, this is sort of an alpha import script which I'm attaching.
For Windows mine goes into D:\Blender\.blender\scripts, but that's just how I organised mine. I didn't download the installer just the file. It may also be in your user directory depending on how you installed it. I have no idea how other OSes will handle these scripts.
You may also just put it anywhere and open it with the text editor and execute it from there. This is what I normally do while I'm developing it. Once you run it, just select any file in the directory which you wish to load from, it will automatically select the .s3ascg files.
This script will basically open all (*.s3ascg) files in a directory, so please make sure the only files in the directory is to do with one of the .lod or .model files and not mixed. The popup that shows can be used as is for defaults, but you can play around with other selections if you want, just make sure you export (when it is ready) the same amount of groups as went in.
As I said I'm still learning Blender, so the groups are still a bit above what I know. I played around with single objects on a single layer before now.
For instance, to test this particular file I loaded the Business Building's first .lod exports and that has 27 groups. I can confirm it loaded all 27 groups, but because of my lack of knowledge I could only view each group one at a time and not together to see the whole building as one view.
I did consider loading each group into a seperate layer, but I'm not sure (after seeing the building) whether you could have 27 layers. I can only see about 16 layer buttons on my views.
At the moment it will load the vertex positions, faces and UV positions. I'm still playing with the bones and materials. That said it will create a basic material for each group.
If anyone wonders, this is a conversion of the .obj script which is given with the blender installation, of course with new code to read the .s3ascg format. The python debugger is a bit iffy which slows the work down a bit
|9th Feb 2010, 09:35 PM||#22|
Shiny. I'll test as soon as I'm done with the map that I've got in the works here. Thank you.
Groups are a bit of a science in blender, since there's a few different concepts of "group" – it's pretty simple to reorganise stuff though (once it's in blender), so as long as everything gets imported it's probably going to work out somehow.
|9th Feb 2010, 10:21 PM||#23|
I tried it out and it works just as you said.
Something is wrong with the UVs, though. In the UV Editor it's just a dot in the general location of where it should be.
As for the groups, one thing I noticed is all the groups imported had different DataBlocks, but the same object name. It seems the object name is taken from the last group imported. For example, the mesh I imported had 4 groups, and all of the object names were group03. For comparison, in an obj. datablock "group00" = object name "group00", and so on.
Hope that helps you figure something out, and thanks a lot for you hard work.
|9th Feb 2010, 10:36 PM||#24|
Wes, for SKIN I've been able to work out some of the fields, but others arestill a mystery:
0 F393EB45 -1.000000 0.000000 0.000000 -0.159300 0.000000 0.000000 1.000000 -0.427463 0.000000 1.000000 0.000000 -0.715816
Position 1: Counter
Position 2: Name
Position 3: Parent maybe? With -1 indicating none?
Position 5: Rotation X (?)
Position 6: Position X
Position 9: Rotation Y (?)
Position 10: Position Y
Position 13: Rotation Z (?)
Position 14: Position Z
The rotations are wrong, but for now that's my guesses until shown otherwise
|9th Feb 2010, 10:44 PM||#25|
To be honest, I imported the UV coordinates, but didn't look at where they went as I was more concerned with the mesh, but thank you very much for pointing this out.
This one is a bit strange, because when I imported the building, each group had a different name. I'll test with some other objects as well to make sure.
And, of course, thanks for taking the time to have a look at it