DSQ exporter for milkshape !!!!

#1 I don't know of anyone working on DSQ support for Milkshape. DSQ's are nice if your going to share animation between shapes, but otherwise they are not of much use. What are you planning to use them for?

#2 Greetings,
Yes, someone IS working on a DSQ tool of sorts. We are working on a tool to import a DTS file, then spit out the DSQ's as seperate files so we can reuse them over a set of different models. The DTS SDK importer is the current problem, since it was never actually completed. We have been upgrading it piece by piece to get it working, but it still has problems. We can now import and export "weapon.dts" successfully, but not "player.dts" yet. It is a backburner task, so I don't know when it will be completed.

Another thought we have is to use the "SHOW" mod to load the DTS file, then add a routine and control to save the DSQ sequences. That route might be easier than fixing the SDK.

#3 Tim,

[semi-hijack]
does the engine keep a refence to a loaded dsq and give that reference out when it's used again, or does it maintain each and every dsq individually. I'm asking because if it's using the memory anyway I might as well imbed them in every shape even if they are the same.
[/semi-hijack]

-brad

#4 I believe the DSQs are not shared in memory, which means every time you load one it's duplicated... the only advantage to keeping the animations in DSQs is that you can share them more easily, there is no run-time advantage.

#5 WHO CARES JUST FIND SOMEONE< OR WRITE ONE< AND WHILE YUR AT IT SEND IT TO ME PLEASE< JICETTY2000@cs.com

#6 @Tim: So, the DSQ's are basically more utilitarian in function in that it saves the art guys time by not having them redo animations for every shape? If that's true, then any application that allows you to share animation between skeletons(just about every app that uses skeletons) mitigates the use of DSQ's?

#7 Basically. It's convenient in that you can change animations without having to go back and re-export every shape that uses it, it makes the individual mesh files simpler (since they don't need animation), and probably speeds up their exporting as well :) It's a nice feature to have, but there is no run-time advantage; the animation data is not shared, but copied and "patched" up into every shape that uses it.

It's not a feature that's used much though. At least in the sense that only the player shapes have ever shared DSQ files in every Torque based game that I know of.

#8 @Ted - this is the same conclusion I came to, since Lightwave has MotionMixer and I am using ACS4 for rigging, the DSQ advantage goes out the window except for the "re-export" every time that Tim mentions, which will probably not be as much of a problem with a little bit of automation, or if all else fails an intern :)

#9 @Tim: That kinda begs the question of how hard it is to get the engine to share those DSQ files instead to get some sort of runtime advantage. Or is the advantage large enough to be worth it?

Of course, in the big scheme of things I'd rather see the network code rewritten to allow support for as many client connections as a server can bear before turning into a hot, bubbling mass, but a performance boost by sharing DSQ's(if possible) would be cool too.

#10 I'm not all that familiar with that part of the code, but it would definitely make sense for the shapes to share that data. Though it may not benifit very many games.

From what I remember, the animation code was designed and implemented without DSQ support in mind. DSQ support was added later to facilitate the art processes, but was implemented with minimal animation code changes. I'm not sure what amount of effort it would require to share that data.