What you see here is Bodylow.solid together with its associated Skeleton (Basic Figurelow).

The black thing is the solid mesh. The left purple thing is the skeleton of the mesh.The right purple thing is the ragdoll structure.

Associating solid vertices with its skeleton edges is done via vertex groups in Blender.So let's say a skeleton edge s_n is associated with vertices v_u1 ... v_un.The result would be that the 2 vertices of s_n belong to vertex group sn, and v_u1 ... v_un belong to the same vertex group.

Some skeleton edges don't have associated vertices or weights; in Lugaru's shipping state, that would be the shoulders and the pelvis crossing of Basic Figurelow. Skeleton edges without associated vertices or weights don't get a vertex group.

Everything's done except for ragdoll weights. I don't quite understand how the values work, unfortunately. And I don't know how to represent them yet.But my hope is that I'll figure that out eventually as well.

Yeah, but there are no weaponry-related things whatsoever in the skeleton (you know, where a holstered knife ends up and whatnot). They're either in animations or hard-coded. The latter would be a bummer, but what can you do.

This is a completely custom Body.solid. I didn't bother fixing the UV map / texturing, as you can see, but rest assured that that is something that's been working anyway, so there's no point in doing that for a proof-of-concept mesh in my opinion.

Note though that the skeleton is basically the same, and the reason for that is that right now, I don't think anyone is really asking for a full-blown skeleton editor with ragdoll editing and whatnot.

So your skeleton _always_ has 20 vertices, and the ragdoll stays as it is right now in Lugaru, same goes for what pairs of skeleton vertices affect stuff and so forth.

I disregard translated skeleton vertices now because that's really more of an animation thing, and animation is the next big thing to do (should be done in the next few weeks, actually).

Things that still irritate me:- The stock skeleton "Basic Figure" addresses 9 extra vertices the stock Body.solid doesn't hold (I just drop the references, seems to work out fine after testing it extensively).- I haven't tested the boundaries of this yet, can't tell at what number of addressed vertices the game starts to crash, but a quick-and-dirty test revealed that it DOES crash with a high number of addressed vertices (I just subdivided the stock Body.solid). So making Body.solid's with a similar number of vertices / faces as the stock one is probably a good idea.

When will this be released? Well, there's still documentation to make. This includes some text and video stuff.

jo-shadow wrote:I'm curious, since you have seperate import/export paths for each, what are the differences, code wise, between the Body, Weapon, and immobile *.solid models?

Bodies have clockwise-defined triangles, weapons and immobiles have counter-clockwise-defined triangles. (The latter is front-facing default in OpenGL).Immobiles are 1/200th the size of weapons.Bodies are 1/10th the size of weapons.

So upon import, body triangles are inversely imported (the index order of a triangle is inverse).And also, all vertex coordinates (x, y, z) are scaled with the above factor (weapon/1000, body/100, immo/5).

These changes are done in reverse upon export. So body triangles are inversely exported, vertex coordinates are scaled again (weapon*1000, body*100, immo*5).

Meaning that the first float read is f0 and so on.The UV coordinates contain garbage bytes, these are omitted.

Upon export, the UV coordinates are reassembled inversely (the mapping is reversed) and garbage bytes are being added.To understand what that means, it's best to write the complete remapping down, but I've gotta go right now.

Is that what you wanted to know?

The python scripts are plaintext, by the way. You can read the source.

I've been using the scripts for blender for mac a bit now and they have worked flawlessly.

My only comment would be that I wish we could have a drag+drop application like the Wolfire Graphic Converter, since I don't use blender for my modeling.

Maybe we can ask jeff for the code for that, since it's cross platform and just converts the provided file into a another file, and saves it as the same name, but with changed extension in the same location as the original. We'd just need to allow for *.obj conversion to and from *.solid(body), *.solid(weapon) and *.solid(immobile)

The drop-down menu would allow you to select which solid format. If the user drops in a *.obj it would convert to the selected *.solid and if a solid is provided it correctly would convert it to *.obj

Sounds like a good plan. The thing is though that I personally always want to address all 3 platforms because the game's on all 3 platforms. Before, I tried to achieve that with a standalone Java tool that supported drag&drop on Windows, but there were some platform-specific pitfalls I didn't want to bother with. Hence the switch to Blender integration.

I guess a good way to handle it cross-platform could be Air (if it supports drag&drop).

Maybe I'll have a stab at it after finishing animation and level import / export for Blender. So wait a year or so..

Hey rudel, I've been meaning to ask you about this for a while, but could you perhaps add an "Export as Triangles" option? I got so used to the Collada exporter doing that part for me, I've forgotten to do it a number of times with the new imex tools.

Lotus Wolf wrote:Hey rudel, I've been meaning to ask you about this for a while, but could you perhaps add an "Export as Triangles" option? I got so used to the Collada exporter doing that part for me, I've forgotten to do it a number of times with the new imex tools.

I'll look into it - will probably just use the triangulation thing that's already in Blender or something.