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!
Lab Assistant
#51 Old 17th Feb 2005 at 10:25 PM Last edited by fleabay : 17th Feb 2005 at 10:28 PM.
Quote: Originally posted by Miche
There isn`t really a simple solution as different 3d programs treat up as either z or y.


Maya gives you the option to change. :P
Screenshots

.
Advertisement
Test Subject
#52 Old 20th Feb 2005 at 12:16 PM
Ugh.
In the only python .SMD export script I can find for Blender, it looks like there is no skeleton data being exported at all, since the skeleton is composed of 0 bones and 0 nodes are listed in the 'bones header'. It looks like the script only works for exporting stationary, non-animated models with no skeletons and no animations. Section attached below:

file.write("version 1\n")
file.write("nodes\n")
file.write("0 \"joint0\" -1\n")
file.write("end\n")
file.write("skeleton\n")
file.write("time 0\n")
file.write("0 %f %f %f %f %f %f\n" % (0, 0, 0, 0, 0, 0))
file.write("end\n")
file.write("triangles\n")

:blah:
Also, in the script header notes, smoothing and animation are noted to be missing. Unfortunately, it doesn't just look like animation, but the entire skeleton export that's missing.

Luckily, Blender handles .OBJs. But I haven't been keeping up on the success that people have been having with Blender exported Wavefront OBJs. It looks like Blender can be scratched off the .SMD test list right now, since no one on the Elysiun forums knows of an import script, and this export script is severely limited. I guess when the writer discovered Milkshake, he dropped this script like a hot potato.

Any chance you could post a .obj of the same two objects you have in your testmesh package so I can fiddle with this script a bit? As you said, the .SMD format doesn't look spectacularly complex, but I dread what Blender's internal data structures are going to look like.
Test Subject
#53 Old 21st Feb 2005 at 8:24 AM
I've actually been speaking a little with the guy who made that script, on the Valve-ERC forums. He said that he had fixed the smoothing part, and he was still working on the bones/animation stuff. There's no IMporter, but I'm trying to get him to do one.
I'm keeping my fingers crossed.

As for the OBJ's, they don't work very well. Blender can import them just fine, but the exported ones "explode" in-game.
Test Subject
#54 Old 22nd Feb 2005 at 1:39 AM
Bleh. So it wasn't just my quad usage making things go boom. Yet another reason to write my own damn importer/exporter script. I need to find a better resource on the .smd file format. I'm sure that the Sims hardcodes its animations at the moment for the body meshes, so all that is needed is the first frame of animation. There are a couple of fields that are kind of obtuse in this format, and I'm digging around for some info on them. I guess I'll end up buying a copy of HL2 if I can find it for cheap in the used bin somewhere. Bleh.
Test Subject
#55 Old 22nd Feb 2005 at 5:07 AM Last edited by Freddy Froglok : 22nd Feb 2005 at 5:11 AM.
Miche: I dug around on the internet and found some SMD resource material, namely a few import scripts for other platforms. When digging through the data in the example files you posted, I happend to noticed one minor detail in the exported .SMD file. The weights assigned to all bones for a triangle do not always add up to 1.00. I suspect rounding errors are causing sum of weights to vary from .99 to 1.01. I'm not sure if this will cause problems with programs that import the .SMD file, so I thought I'd mention it in passing.

Thanks to a 3ds script, I've got a lot of the .smd format decoded, and soon I'll have to wade through figuring out how to import it into blender. If you know, could you confirm that the second set of triples for triangle vertex data is the vertex normal for that triangle at that point, and that it is used for smoothing?

Ah well. Back to messing with this thing a bit before I go shoot my lab teacher tomorrow. :read:
Nearly alive
Original Poster
#56 Old 22nd Feb 2005 at 11:23 AM Last edited by Miche : 22nd Feb 2005 at 11:34 AM.
there are two different versions of the smd format (though they both keep the version number set to 1 in the file), and really your plugin will need to support both as it`s best when exporting a object from a gmdc file which only uses one bone per vetice, to export it in the old version. (I think ther current version of the mesh tool will give a error if you try to export it in a multiple bone per vertice format)

The first one is for half life 1 and as I said supports one bone per vertice, and the second is the changes made for half life 2 and supports multiple bones and weights.

they are both the same untill you get to the triangle data.

The half life 1 version is of the format:

bone# this vertice is assigned to, vert x (vertice x), vert y, vert z, normal x, normal y, normal z, texture u, texture v.

Half life 2 version is:
reference , vert x, vert y, vert z, normal x, normal y, normal z, texture u, texture v, number of bones this vertice is attached to, first bone #, first bone weight , then repeats the last two for however many bones it is attached to.

The documents what I have found aren`t very clear what the game half life 2 actually uses the reference for but it should be set to the root bone , so normally set to 0 (this is what the mesh tool will set all vertices to when exporting a smd file), however some programs like the plugins for 3d max will add a new "root" bone to the end of the bone lists and then set the reference number to this. The mesh tool however doesn`t use the reference number , so as long as all vertice are set to the same number then it shouldn`t matter.

Also note that with this format that Z is up.
As for the normals they are vertex normals and used for lighting etc.

Also before each set of three vertices which makes up a triangle there should be a name for a texture map, some programs seem to complain if it isn`t there, so I made it so that the mesh tool will create a non existing name and will expect some name to be there in files it is reading, it doesn`t matter if the file doesn`t exist as the mesh tool doesn`t use it (at least currently it doesn`t) and non of the other programs seem to complain too much if the file doesn`t exist.

I don`t know if you have downloaded the last version of the mesh tool (from this forum) , but that will export gmdc files to smd files for you, so you won`t be stuck with those two example ones I included in this post.
Test Subject
#57 Old 23rd Feb 2005 at 7:36 AM
Everything you have said seems to agree with what I've gathered from dissecting the SMD to 3ds importer I've found. The only thing I saw in the bone weight data that was exported was that if you had multiple bone assignments to a vertex in a triangle, the total weights assigned to the bones added up sometimes to .99, sometimes to 1.00, and sometimes to 1.01, whereas when there is only a single bone assigned to a vertex in a triangle, it's always a 1.00 weight. It's a minor thing, and the Sims isn't exactly a photorealistic renderer. I'm not sure if it will make a difference for any software package or not. I just thought I'd mention it since I saw it in passing.

Since this format includes animation data and skeleton data, and it's text based, it looks like a nice format alternative, and it's easy to see where errors are. I'm sure when I start up the im/exporter, my script will blow up into a billion thousand million shards because of errors, and at least I won't have to write a tool to browse the data.

The big thing is going to be figuring out how to weight the vertices on a face in blender for smoothing. I know you can assign a normal to a face, and a normal to a vertex, but I'm not sure if you can assign multiple normals to a vertex for different faces in blender. I'll have to dig around in some .SMD files and see if smoothed vertexes all share the same normal across different faces, and if non-smoothed vertexes common to a single face all share the same normal. Luckily, I use my linear algebra book on one side to prop my laptop up above the table for better cooling, so the matrix operations are all listed in there for when I do have to calculate things.

Ah well. Back to the salt mines. Woo hoo. :weep:
Test Subject
#58 Old 24th Feb 2005 at 10:34 AM
Where did you find docs on the .smd format?

I'm trying to learn Python and possibly do my own smd import/export scripts for Blender. I understand you're trying to do that as well, Freddy, but I still wanna give it a go. For fun, and for learning.

So, do you know where to find some documentation?
Test Subject
#59 Old 24th Feb 2005 at 6:16 PM Last edited by Freddy Froglok : 24th Feb 2005 at 6:20 PM.
I started at the Valve website and went from there, but the biggest insights I got into the SMD format actually came from looking at importer scripts for other software. I shouldn't say insights, since it was more like looking at a blueprint someone else had made. Go find a few .SMD import scripts for things like Maya and 3ds, and look at them.

You'll also need to learn how to use Python, and how to interface Python with Blender, and how to create and manipulate the Blender object hierarchy, so as to not end up with a huge frigging mess of stuff and overwrite previous assignments you may have made. The Blender SMD exporter has some basic IO implementation in it, and I'm sure you can find a couple other Python import scripts for various formats that can help you along the path to emptiness and Nirvana.

One thing that might be a huge bastard to implement is bone to joint conversion. It looks like SMD bases itself off of joints, and I haven't messed with Blenders armatures much, so I'm not sure exactly how Blender assigns distortion weights. This is like 4 projects in one, and I"m just glad it's not going to turn into 5 (which would be full animation export/import).
Test Subject
#60 Old 24th Feb 2005 at 7:57 PM
Thanks for the reply. I started messing around a little with Blender and Python scripts today, and I've actually started writing an Import script. So far it imports the bones, or at least what I thought were bones until I read you post... But, I don't understand what you mean. To me it looks like the bones have two sets of 3D coordinates and a reference to one other bone. Now, I don't exactly know how joints work but I figure It would need only one set of coordinates but two references... But I really don't know.

From what I can tell, it looks like the script is going the right way, though. Except the bones all point to a spot right beside the model... I'll post a pic so you can see what I mean.

It looks wierd, but I think I remember Miche saying something about the bones all connecting to the root bone and that it didn't mean anything to the Mesh Tool.

I don't know... Maybe you can tell me, Miche, is this because of the Mesh Tools smd's or because of my importer?
Screenshots
Nearly alive
Original Poster
#61 Old 24th Feb 2005 at 10:44 PM
Quote: Originally posted by atavera
Thats how they are supposed to be. With this version of the mesh tool, the only data that you need to worry about with the bones is which vertices are attached to them. That screenshot looks just like the bones are in Milkshape, and 3ds. They should not connect to anything but the root(like it looks like in the picture).


I`m actually not sure that screen shot shows the bones set up correctly, it looks like the bones start at one point (which from the screen shot is hard to tell if it`s the root) and then the bone goes to the location where the joint should be, and it looks like if the rotation of the bone was changed that, that rotation would be applied at the root bone location not at the real location. So if that is true then I think that`s not right. the bones should start at the location of the joint. the only connection in the smd file to the root bone that each other bone have is that they are set to have that as it`s parent, but as it`s been a while since I`ve looked at how bones work in blender, I could be missreading that screenshot.
Lab Assistant
#62 Old 24th Feb 2005 at 11:25 PM Last edited by fleabay : 24th Feb 2005 at 11:28 PM.
Vinther, looks like your on the right track!

I have some python ebooks if you need any material on python.

And i would be very suprised if you have not ran across this yet, but just in case...
http://www.blender3d.org/cms/Import___Export.5.0.html
Test Subject
#63 Old 25th Feb 2005 at 8:06 AM
Miche -
So, you mean the I should swap the "head's" location for the "tail's", and vice versa? 'Cause that may well be the case, I actually did it the other way around first, but thought it looked wrong so I changed it. But, I was wondering though, even if all bones connected to the root bone, why would the root bone be way out there on the side?

One thing about the smd's that I think might cause a little bit of a problem, is that each face seems to have three separate vertices. In other words, no one vertice can be used by more than one face. That's wierd isn't it?

Atavera -
Yeah, that's probably a good idea. Thanks.

Fleabay -
Thanks, man! I think the Python docs from their site, and the the Blender Python API docs from blender.org will do, though.
Test Subject
#64 Old 25th Feb 2005 at 3:03 PM
Quote: Originally posted by Vinther
Miche -
So, you mean the I should swap the "head's" location for the "tail's", and vice versa? 'Cause that may well be the case, I actually did it the other way around first, but thought it looked wrong so I changed it. But, I was wondering though, even if all bones connected to the root bone, why would the root bone be way out there on the side?

One thing about the smd's that I think might cause a little bit of a problem, is that each face seems to have three separate vertices. In other words, no one vertice can be used by more than one face. That's wierd isn't it?



All SMD faces are tris. A triangle has 3 vertexes. For smoothing purposes, each vertex of the FACE has a normal attached to it. The vertexes aren't listed seperately from the faces in .SMD format. You will actually have duplicate vertexes out the wazoo when decoding this format. Tri Alpha has vertexes at (1,0,0), (0,1,0), (1,1,0). Tri Beta has (1,0,0), (0,1,0), and (0,0,1). The SMD face data will look like this:

generic.bmp
1 0 0 (norx) (nory) (norz) (u) (v) (distortion data...)
0 1 0 ....
1 0 0 ....
generic.bmp
1 0 0 ....
0 1 0 .....
0 0 1 ......
end

They're not listed seperately, but as part of faces. Vertexes are commonly shared, but you have to search and de-dup them while maintaining normals. If all the normals for a vertex that shares the same space are common, you can consolidate them. I haven't done a thorough search, but any vertex that has seperate normal information has to be kept seperate from this consolidation, as far as I can tell. This would allow you to place a flat edge next to a curved surface, like the top of a cylinder, and this has to be taken into consideration when building the object.

If that's how the bones look in Milkshake, then I feel better now. I was wondering just how the hell I had to decode those damn things. I was getting a simliar mess to what he was showing, and scratching my head.

Here's an assumption I'm making while working on this: All vertexes that share the exact same coordinates must share the same bone weighting. Can anyone confirm or deny this?
Test Subject
#65 Old 25th Feb 2005 at 8:05 PM
Quote: Originally posted by Freddy Froglok
All SMD faces are tris. A triangle has 3 vertexes. For smoothing purposes, each vertex of the FACE has a normal attached to it. The vertexes aren't listed seperately from the faces in .SMD format. You will actually have duplicate vertexes out the wazoo when decoding this format.


Yeah, I figured as much... But it seems stupid, and it will be a nightmare to edit a mesh in which every other vertex has like a hundred duplicates.
There must be another way! :weep:
Test Subject
#66 Old 26th Feb 2005 at 11:21 AM
That's why you go through and dedup everything. It's only grunt labor, and that's what computers are good at. That's why people made them in the first place, and it's why I can't add fourteen and seventeen reliably.

And remember, a vertex only has as many duplicates as there are faces that share it in the mesh, and when you're exporting a mesh, you're not going to have all these duplicates. Just remember to keep an eye out for seperate normals on the vertex, because those do make a difference in the way the thing is displayed.

It's not that bad. You're not going to be dealing with deduping 300,000 tris in a sims2 mesh. I think the supervillain mesh has about 4000 verts total, and I'm not sure if that's with duplicate vertexes or not (I never tried to dedup, I just used it to scale my dumpster.) One of the imported samples has like 362 tris, which is only 1080ish verts to have to dedup.
Page 3 of 3
Back to top