Announcing : Blender Exporter For Torque (0.8)

#21 Ok, looks like my assumptions were correct then. Good, because I didn't see many others ways to do it, :). Maybe my problems will get resolved when you release 0.82, I'll check them out with that and let you know. I'm seeing some motions in my sequences/actions (non IK/baked actions) get greatly exaggerated, like a scale or origin/parent is off somewhere. That's why I was asking about the parenting.

Good on the IPO names. I didn't notice the new Action API. Guess I'll have to get the new blender python docs downloaded, :).

I don't understand why allowing a user to exclude bones for export being risky. Do you just mean because of preserving the skeletal structure ? The types of bones I plan on excluding export on are IK and the corresponding Null bones which aren't skinned nor parents of anything.

As far as using "Write DSQ" for a sequence you don't want exported, that would work as long as the action doesn't crash the exporter. I had some crashes when I was trying to export an unbaked IK action. If that's resolved, this would work. Although I really don't like having the extra step of editing the .cs file as its just too easy to forget. I didn't bring the issue up about the IK action in the earlier post as I just assumed those types of actions still weren't supported.

Right now to export an IK action, you have to make a copy of your .blend file, bake the IK action(s), unmark the action(s) so it can get deleted and then save and re-open the .blend file several times to clear the action and IPOs from the file and memory. Finally you can run the exporter and then rename stuff since it inherited the name of the temporary .blend file you're working from. If you don't like the results, you need to go back to the original file, make the changes and then do that whole process again.

That's the issue I'm trying to get around. Allowing the exclusion of an action from export or figuring out why the IK based actions are crashing the exporter would resolve the problem. Since the "Write DSQ" button existed already, I was just thinking about making it tri-state ("Write Seq to DSQ"/"Write Seq to DTS"/"Don't Process Action at all"). I can see other uses for excluding the processing of an action, but primarily I just need a much better work flow for this now or decide to give up on trying to use IK or other constraints in my actions for torque sequences.

I can see your point about the action renaming, but not 100% sure I agree with it now. I'll admit though that I'm still developing a work flow for the task of modeling in blender and exporting to torque. Also, I'm sure I'm carrying a bunch of baggage around in my blend'ing that will change as I do more for torque and less for animations.

The reason I was thinking about allowing the person to name the actions in the exporter was because I noticed the player sequence in the demo doesn't have the proper names and they do the matching of the actions in the player.cs file. So, I was looking at the torque C++ code a bit and was thinking of ways to make use of what was there and thinking about what I might need to add for my current project. Since the exporter is already generating the .cs file and you've got a nice place to store the config (in the .blend file keeping a lot of information together in one place), getting a few more pieces of information and doing a more complete job of writing the .cs might streamline the process some in certain situations.

Like I said though, my workflow for making models and animations for torque is still developing and highly subject to change, :-).

#22 CONTINUED FROM ABOVE

Also, just to make it clear, I'm not asking you to do these things, unless its just resolving that export problem I mention which will require more testing on my part to give you the input needed to fix it if you want to. I'll be adding some of the features above, like excluding actions and bones to my own versions of the exporter. If I do it for myself though, I'll do it like I did last time more than likely. Then I just added a few lines and hardcoded the exclusions in the .py files since I'm pretty consistant with naming bones and actions. This works, although it creates a new point of maintenance for me that I don't really want to deal with long term.

I'm not arguing though to make a bunch of work for myself though. So, I guess if no one sees any reason for these features other than myself, I'll just do it the hack way and save myself the time of doing a more complete implementation and the UI to support it, :-).

#23 Todd,

I'll see what i can do about adding a sequence exclusion option.
As for renaming the actions, provided the user writes .dsq's, they could easily rename them in the .cs i guess. I could also easily add an override option to the configuration file.
As for excluding bones, i'm still not quite sure about that, though that should be easy.

Send me a .blend which exhibits a crash, or an oddity with the current exporter, and i'll see what i can do to fix the problem before the next release.

Implementing new features is no problem for me; As long as they make sense, and don't over-complicate the export process.

#24 I'm not sure we're talking about the same thing when we're talking about renaming, although there's probably not much of a difference. I was only meaning to allow the user to enter a word that would be used as the tag for the .cs file created.

My knowledge here is a bit limited as I'm just starting to look at this, so I might be wrong. The references I'm using are from player.cs and the source code. The lines below are what I'm referring to from player.cs:

datablock TSShapeConstructor(PlayerDts)
{
   baseShape = "./player.dts";
   sequence0 = "./player_root.dsq root";
   sequence1 = "./player_forward.dsq run";
   sequence2 = "./player_back.dsq back";

So, if I had an action called Idle, I would be able to assign the "root" tag to it in the exporter. This would be nice since, if I read the code right in player.cc and player.h, the engine looks for animations based on the tags/names from the sequenceXX variables in the datablock.

I don't mean to actually rename the action/sequence. The sequence would still be exported as Idle.dsq and/or be called Idle in the .dts file. The only change I'm proposing would be to add the UI necessary to get the name/tag and add the sequence line to the .cs file created by the exporter.

Of course, I'm making assumptions that the engine still finds the sequences with the same naming/tag convention if you don't export them as .dsqs. I could very well be wrong on that as I haven't looked to see what the process is when the sequences are stored in the .dts file. This may not apply at all in that case.

Is this necessary for the operation of the exporter ? Nope since you can always just edit/create your own shape.cs script, but it would be nice to have this information managed in one place, i.e. the configuration of the exporter.

As far as crashes and oddities, I'm still looking at the oddities at least and have some ideas why they are happening. I'll try to reproduce the crashes as I've worked my way around them by staying away from IK based actions and haven't had any lately.

I'll be spending some time looking at these two problems tonight and should be able to provide fixes or more complete descriptions of the circumstances under which I see them.

#25 Zaz,

Quote:
So, if I had an action called Idle, I would be able to assign the "root" tag to it in the exporter. This would be nice since, if I read the code right in player.cc and player.h, the engine looks for animations based on the tags/names from the sequenceXX variables in the datablock.

The player code just looks for an animation called "root", "idle", "run", whatever. Your player doesn't have to have .dsq's.
The shape script you are referring to tells torque to load certain .dsq files along with the shape, and assign certain sequence names to them.
There is no specific naming convention required; Except that your shape files end in .dts, and the external sequence data files end in .dsq, and (optionally) you have a .cs file in the same folder as your .dts shape for the show tool to load the external sequences in the dsq's.

I have fixed numerous problems with the exporter in regard to sequences (with the aid of walter), so there may be a chance that i have already fixed a problem you are experiencing in my copy. But still, i'd like to hear about it just in case its a new issue :)

Thanks again for your input.

#26

Quote:The shape script you are referring to tells torque to load certain .dsq files along with the shape, and assign certain sequence names to them.

That's the behavior I expected when you store the sequences in .dsqs. I was thinking it might work the same when you put the sequences in the .dts file also. I haven't tested that though.

As far as the problems I'm up against, I wasn't able to pin anything down specifically as to what it causing the problems. As you say, maybe you fixed it already, so I'll just list the problems here.

The structure of my armature is pretty basic, each lower limb is composed of a Thigh, Leg, Foot and Toe bone, with the Thigh being the parent of the chain. The Thigh is also the parent of the Pelvis bone (the root bone of the armature), but is not directly connected to it (the base of the Thigh bone is not coincident with the end of the Pelvis bone).

The backbone is composed of the Pelvis, Spine1, Spine2, Neck and Head bones. These are all parented and have IK turned on, although there are no IK contraints in the armature at all now.

Also parented to Spine 2 are the Bicep bones, again the Bicep bone bases aren't coincident with Spine2's end (dashed lines showing parent relationship in blender). The arms are composed of the Bicep, Foreare and Hand bones, all parented and IK, but no IK constraints right now.

Besides the above, I have two Eyelid bones that are parented to the Head bone, dashed lines and all that again.

There are several problems I'm seeing. The first of these is that several rotations are getting exported apparently reversed. In my Walk animation, my Toe bones have a rotation that rotates the toes towards the shin, i.e. "up." When exported and tested in -show, the rotation of the Toes is down in torque.

A similar problem happens with my arm swing. The Bicep bone appears to be rotating properly to swing the arm back and forth, however it appears that the rotations of at least the Hand bone and maybe the Forearm bones are reversed. This causes the upper arm to swing back and forth, but the Hand to remain more or less in the same place.

In a different test animation, I lean the body of the model to the right and raise the right arm and leg. The body rotates properly as does the leg, but the right arm doesn't raise like it is supposed to. Again, this appears that a rotation is reversed somehow.

The eyelids on my model are simple hemispheres, so to blink, I need to rotate my Eyelid bones 170 degrees or so on one axis and 30 degrees or so on another axis. I also reposition the Eyelid bones and have a small scale factor animated on them. When I export the Blink sequence, it appears the Eyelid bones are rotating around some point off to the left and in front of the model with a very large radius, approx. the height of the armature.

I have been trying to make my Walk animation cyclic along with my test animation. It appears that to make them cyclic successfully, I had to make the extend mode of the IPO curves Cyclic as well. My test animation is getting exported first all the time now and it is animating cyclically, i.e. it repeats forever in -show. I am unable to get any other animation to export cyclically, i.e. when I test the Walk animation in -show, it runs once and stops. The player model with the demo animates continuously on those cyclic animations.

The things I tried to eliminate these problems include, insuring all the bone roll angles are set properly in blender (select all bones in edit mode and CTRL-NKEY), clear the bone roll angles back to zero and force all non-coincident parent/child relationships to be coicident (moved the base of the Thigh bones to the end of the Pelvis bone, etc.). The good and bad of the testing is that none of the changes I made mattered as I always got the same results.

CONTINUED IN NEXT POST

#27 CONTINUED FROM ABOVE

I did spend some time looking at the code, but didn't notice anything obviously wrong. However, my time in the code was pretty minimal, there's a fair amount of code and I'm not an expert on quarterions, so this isn't saying much.

One other problem I've seen has to do with the triangle strips. I have VTK 4.2.2 installed and when I enable triangle strips on the mesh, I have one triangle that is either flipped or missing when it gets exported (there's a triangular hole in my model in torque). When I disable strips, the hole is gone.

Let me know if there's anything you want me to do to help with fixing these problems. I can test something or make a simple version of the .blend to send to you for your testing if that works best.

#28 Zaz,

I wil be releasing a copy of 0.82 shortly which should solve quite a few problems with the animation export, aswell as improve on, or add new features.

I have noticed a few problems with the VTK stripper; Though i am not exactly sure what is casuing them. I will see if i can get round to some debugging on that end.

If the problems still persist(in the newer version), then send me a .blend that illustrates one or more of them.

#29 I'll wait with baited breath for the release, :).

The triangle stripping isn't a big deal to me, at least now. My models are very low polygon count. If there's much of a performance benefit to this in torque, it might be nice to have later though.

I'll be on the road most of the day today, so if by "shortly," you mean today, its likely I won't be able to test anything until tomorrow. I'll let you know the results after I've done some testing.

#30 Walter "PsychoKick" Yoon - You said you were getting long pauses in your animation, I had the same issue yesterday. In cyclic animations you need not have a final key that is the same as the first, as the key before that will move to the beginning when it loops. So, if your first and last key are the same you will have a pause that lasts about 1/(the number of total keys). Hope that helps. I'll be digging in to the code to help out some today and tommorow. Feel free to post issues here or come discuss them with me in irc.

#31 First off i want to say thanks to James Urquhart for this exporter, it seems like the beginning of a beautiful friendship between blender and torque.

I am, however, having problems with exporting textures properly. I have been careful to name the material the same as the mapped image texture, but this only works successfully with the example cube. I have appended different objects, already uv mapped, and making them the child of the "Detail32" empty. Exporting works, only no texture appears in the torque demo with which i am testing them.

Any ideas? I'll be happy to send a blend or dts to anyone interested.

#32 Ben,

For the actual texturing information, the exporter picks up whatever material is assigned to the mesh / mesh faces.

Try looking in the console after loading yur shape in the -show tool. You might be missing textures. e.g. if you had a material named "Wood" in blender, torque would look for "Wood.png" / "Wood.jpg" / etc for the base texture.

#33 Thanks for the feedback James. I don't want to bog down the forum with this problem, but...

I have placed the texture file along with the dts file in the static mesh folder. The blender material and texture file are named the same.

I place the mesh using the world editor creator (f4). When I look at the console at any point running the demo, I see no info. Nor do I know what or where the "show tool" is. Could you point me in the right direction?

thanks.

#34 Ben,

The show tool can be invoked by running torque with the "-show" commandline option, or "-mod show".

#35 ...

#36 Joseph,

I wouldn't know about animating UV coordinates in blender; Though it sure is possible in the .dts format.

#37 I'm happy and embarrassed to say that my problem with textures was just due to the fact that some of my textures were 1028 instead of 1024. The exporter works beautifully.

#38 The new version, 0.82, has fixed some problems, but not all.

The animations that weren't properly working as cyclic now appear to be working cyclically.

The bone tree printed towards the beginning of the export process now appears correct and doesn't repeat some of the bones. Note, I never reported this, but I did notice it.

I still have some problems with some bones rotating properly. My foot/leg bone chain is composed of Thigh, Leg, Foot and Toe bones. The Thigh bone is parented to the Pelvis bone, but the origin of the Thigh bone is not coincidental with the end of the Pelvis bone. The Pelvis bone's origin is at the crotch and its end near the belly button. The origin of the Thigh bones is at the same height as the end of the Pelvis bone, but that bone runs in the opposite direction. My arm bone chains are constructed similarly. The animation of these chains in the walk sequence is only composed of rotations, although I have added LocRotSize key frames.

My Walk animation is generally correct in that it doesn't completely blow up the model. However, the rotations of some of the bones appear exaggerated (Thigh and Leg, maybe Foot) and other bones appear to either have the opposite rotation or the end of the bone is stationary (Toe and Hand).

In my Blink animation, the center point of the rotation of the eyelids moved between 0.81 and 0.82, but is still very wrong. This animation is composed of rotating the two Eyelid bones. These bones are parented to my Head bone which runs horizonatally from approx. the horizontal center of the head near the base of the head to about the chin. The head is the end of the chain of bones that starts at the Pelvis bone and includes the spine bones and Neck bone.

When I select the Blink animation in -show under Thread control, the eyelids immediately move from their normal position near the top of the head to about one body length outside of either shoulder. When properly animated, the eyelids (hemi-spheres) should rotate about 170 degrees around their spherical center. When animated in -show, the eyelids describe approx a 170 degree arc who's center point appears to be the origin of the armature causing them to swing through an arc starting near the shoulders to about one body length in front of the character.

Normally I've exported this as a blended animation and what I describe above is what happens when it is exported blended. When I turn off blending, the eyelids start in the proper place, but will still move through what appears to be the same arc.

Let me know if there's something I can do to help you resolve these problems. I can send you a .blend that exhibits the problems if you can't reproduce them by following my descriptions above.

#39 Joseph:
Not as definitive as I like to give answers, but I'm unaware of being able to animate UV mapping in blender. Everything you can animate eventually ends up creating an IPO and I don't see any IPO types that would make me think they would store UV coordinates.

I've been using blender several years and can remember discussions about animating UV mappings, but I believe they were simply discussions about getting it implemented or working around not having it. In blender you can animate the textures by using either .AVIs or using Tiled textures/images.

Depending on how you actually want to animate the UV coordinates, its possible that the Tiled textures might be the same or similar to what you need. I don't know what kind of support torque has for animated UV coordinates as I've never needed them myself in torque. Also, I'd be surprised if the exporter supports this feature.

If you want to play with this feature in blender, you can access the settings via the View->View Properties menu item in the header of the UV/Image Editor window in recent versions. Older versions of blender simply had some controls in the same header.

Note, this isn't true animation in that you can set key frames for UV mappings. It simply allows you to tell blender how your texture is tiled on the image and a speed at which to cycle through the tiles.

#40 Zaz,

There are indeed problems with BLEND animations; Though this has partly been fixed, and so, should be included in the next release.

Sending me a .blend which demonstrates this problem would be useful; Since i cannot accuratly determine what is causing the problem from a description.