Truespace 7.6 - game industry standard?

About Truespace Archives

These pages are a copy of the official truespace forums prior to their removal somewhere around 2011.

They are retained here for archive purposes only.

Truespace 7.6 - game industry standard? // Game Development

1  2  3  |  

Post by DavidAWinter // Mar 14, 2009, 8:29am

DavidAWinter
Total Posts: 36
Have you tried doing bones animation in Workspace side and use the ts 7.6 exporter rather than the older on in modelside, the newer one does export animation, but as yet I've never had textures attached


None of my existing TS6.0 animated models will load into TS7.6. They simply explode or crash the application when I attempt to do anything with them.


TS7.6 is not a tool I can use unless I want to start everything from scratch, and I have too many models and animations to support for that.

Post by nigec // Mar 14, 2009, 9:55am

nigec
Total Posts: 314
pic
It might be worth having a word with Mr Bones, he may have a solution to get them into there? His bone animation have evolved through various versions of TS so if anyone can come up with an answer, it'll be him

Post by mrbones // Mar 14, 2009, 10:56am

mrbones
Total Posts: 1280
pic
Hi David,


Will your character meshs load without bones?


Can you tell us some more details regarding the size and scope of your project?





None of my existing TS6.0 animated models will load into TS7.6. They simply explode or crash the application when I attempt to do anything with them.


TS7.6 is not a tool I can use unless I want to start everything from scratch, and I have too many models and animations to support for that.

Post by DavidAWinter // Mar 14, 2009, 4:16pm

DavidAWinter
Total Posts: 36
Hi David,


Will your character meshs load without bones?


Yes, but that sort of is beside the point because I need the full model ported forward



Can you tell us some more details regarding the size and scope of your project?


They're commercial video games.


http://www.maximum-football.com/


I'm currently working on version 3.0 which has a lot of graphical improvements planned.

Post by mrbones // Mar 14, 2009, 4:48pm

mrbones
Total Posts: 1280
pic
I think you should start over by importing the meshs and re attaching to a standard BVH skeleton.


Once attached multiple motions can be applied




Yes, but that sort of is beside the point because I need the full model ported forward





They're commercial video games.


http://www.maximum-football.com/


I'm currently working on version 3.0 which has a lot of graphical improvements planned.

Post by DavidAWinter // Mar 14, 2009, 4:49pm

DavidAWinter
Total Posts: 36
Well if I didn't have over 200 animations that I don't want to redo, I would start over.

Post by mrbones // Mar 14, 2009, 5:09pm

mrbones
Total Posts: 1280
pic
I just redid 2000 animations in a week with the help of this community..


I think you should just redo them, Can you show us a couple of the animations,

or tell us some specifics like fps and #number of frames per animation.




Well if I didn't have over 200 animations that I don't want to redo, I would start over.

Post by DavidAWinter // Mar 14, 2009, 5:28pm

DavidAWinter
Total Posts: 36
2000 in a week? Seems highly unlikely considering it can take me 3 to 4 days to get something that I like for one animation. Plus there's the IP ownership concerns.


The website for the game has a game play video that shows lots of animations.


All animations are timed to 30 FPS. They range in size from say, 1 frame (a static 3 point stance) to various 5 second tackle and stand up animations. The majority are under 2 seconds worth but some are longer. Some need to be zero location based (like run cycles), others need to be zero location start based but can move off of zero (like hits and falls). Many need to start from the same frame another ends with (so they properly blend). Others are sectional so I can create variations via code by running different combinations (normally these are the catching animations)


I just redid 2000 animations in a week with the help of this community..


I think you should just redo them, Can you show us a couple of the animations,

or tell us some specifics like fps and #number of frames per animation.

Post by mrbones // Mar 14, 2009, 9:59pm

mrbones
Total Posts: 1280
pic
Hi David,


Can you provide a list of all the seperate moves required or a screenshot of your files that need to be opened?


Maybee you could find a vertex animation solution like Bone to vertex tool?


Or Export out of GameSPace as an X file, Then open in fragMotion.


Then you could turn the animation into a BVH file maybee?:confused:



2000 in a week? Seems highly unlikely considering it can take me 3 to 4 days to get something that I like for one animation. Plus there's the IP ownership concerns.


The website for the game has a game play video that shows lots of animations.


All animations are timed to 30 FPS. They range in size from say, 1 frame (a static 3 point stance) to various 5 second tackle and stand up animations. The majority are under 2 seconds worth but some are longer. Some need to be zero location based (like run cycles), others need to be zero location start based but can move off of zero (like hits and falls). Many need to start from the same frame another ends with (so they properly blend). Others are sectional so I can create variations via code by running different combinations (normally these are the catching animations)

Post by DavidAWinter // Mar 15, 2009, 8:59am

DavidAWinter
Total Posts: 36
Here's a partial list of actions. This doesn't include the stances.


I'm not sure what you're going to gleam from it because you're not going to know what the animation is for them. I'm not sure how a list of names is useful.

Post by mrbones // Mar 15, 2009, 10:19am

mrbones
Total Posts: 1280
pic
What is a .bak file? I thought you were working with .cob files,

Also it looks like the size of each file is pretty close and consistent.


Here's a partial list of actions. This doesn't include the stances.

I'm not sure what you're going to gleam from it because you're not going to know what the animation is for them. I'm not sure how a list of names is useful.

Post by DavidAWinter // Mar 15, 2009, 1:03pm

DavidAWinter
Total Posts: 36
A .bak file is an automatically generated truespace backup file. They're just .scn files renamed. If a .scn file gets messed up (which happens a lot), you can just delete it, rename the .bak file to .scn, and you're 'back' up and running as it were. Truespace has been doing that for years (since version 2 I think).


Each animation is its own scene and I export the scene into the final output file. I created a base scene with the rigged character. Each animation is a copy of the base scene with a different animation. (I append each animation to the end of the .X file). I would have prefered to have simply saved the animation data but you can't do that in truespace for some reason.


They will all be roughly the same size because each scene contains the same mesh. But the size of the file means nothing. It has nothing to do with the animation.


What is a .bak file? I thought you were working with .cob files,


Also it looks like the size of each file is pretty close and consistent.

Post by mrbones // Mar 15, 2009, 1:48pm

mrbones
Total Posts: 1280
pic
Ok, I forgot obout the .bak thing and hoping it was an animation format, thanks for the information.


Do you still have gameSpace as it might save your saved .cob from scene as an .x file (as long as its attached to any mesh it will save the animation data.)

Post by DavidAWinter // Mar 15, 2009, 2:59pm

DavidAWinter
Total Posts: 36
But what's that going to accomplish? I can get to .x format from TrueSpace 6. That's not the challenge. The problem is not being able to load TS6 scenes into TS7.6. The problem is my output tools not working with TS7.6 (Puppeteer doesn't function at all). And even if I could load the scenes, it doesn't make any difference because I'm not using those meshes anymore. I've replaced the model with a completely different mesh.


Ok, I forgot obout the .bak thing and hoping it was an animation format, thanks for the information.


Do you still have gameSpace as it might save your saved .cob from scene as an .x file (as long as its attached to any mesh it will save the animation data.)

Post by TomG // Mar 16, 2009, 5:08am

TomG
Total Posts: 3397
Mr Bones is looking for a way to convert your current animations into BVH format. tS7.6 can load BVH format into the workspace, the new part of tS7.6 with the new bones. If you can get to .x from tS6.6 / gS, then there are tools that exist that can load that and save out a BVH. The plus / minus of that is that you will find yourself working in the workspace if you follow that route, and no longer with Puppeteer and the Model side bones.


You could try disabling the bridge before you load the models into the Model side. Switch it to Off so tS doesn't try to move the item over to the workspace.


Not sure if Puppeteer was one of those plug-ins that worked in tS7.6 or not, there were one or two items that stopped working - anyone with Puppeteer confirm whether it works, and whether you can load old tS files using it?


BTW, do the models load without the skeletons attached? Do they load with skeletons attached but no animations created for the skeleton (ie no Puppeteer used)? That would give a clue as to where the problem comes from, which could give clues as to how to get around it.


HTH!

Tom

Post by DavidAWinter // Mar 16, 2009, 7:57am

DavidAWinter
Total Posts: 36
Well, I guess I'm going to sound like an old fogy and perhaps a whiner, but I've been over this so many times before I've lost track. Even during the beta for TS7. I sent model and scene after model and scene to the developers and nothing was ever fixed. All I was ever presented with was 'you should redo all your work in the new system'. Sorry, but that is simply unacceptable. I can not spend months redoing all my animations and hope that the game engine actually knows how to use the exported results. And that in of itself seems unlikely. So far, I've yet to get a single .x format model with animation generated from TS7.6 to work in any D3D application. None. Not the DirectX utilities, not my game engine, not 3rd party tools. So at the end of the day, what's the point? Not only does TS7.6 not load my scenes, but it doesn't export the results properly either.


If I'm going to scrap years of pipeline, code and work, I might as well bite the bullet and spend the money on 3D Max. At least their stuff properly migrates from version to version.


I have been using TS longer than most. Going back to version2.0 The TS6 interface worked and while there were known bugs, didn't need to be overhauled. I've disliked the TS7 workspace system from the moment I first tried to use it in beta and said was a bad idea to begin with. What was asked for, by everyone involved, was bugs fixed in TS6. I personally did not ask for tools I didn't use and having the pipeline I'd used for years broken.


The most recent version of Puppeteer I have (2.1) does not work. Yes you can load it, but none of the sliders work. The reason I use that tool is because it's a more effective tool that the 'click and drag a bone' process that TS uses natively. Heck in workspace mode I have 5 buttons! I don't even have the tools to move the bones I did in TS6.


And it seems I'm not the only one looking to have this tool fixed. http://forums1.caligari.com/truespace/showthread.php?t=4784 Others are asking for a slider system too.


The only .x format plug in created for TS that generated viable files does not work with TS7. I even sent you the plug-in during the beta so you could take a look at it. This was in what 2003?


Yes, models without skeletons load. I can load my static stadium models without too much of a problem but that doesn't really help much.


The workspace mode is simply horrible. I brought it up in beta. Roman even called me directly so he could get a better understanding of what I was after. I told him bug fixes and stability. What we wound up with was more bugs and a pipeline that's unusable at best and simply broken at worst.


In one hour of trying to get my scenes to load with TS7.6 I generated 6 crashes. 6 crashes!


I started using MS Word with version 1. I'm now using version 9 (Word2k7). I can still load documents I wrote in version 1 without fail. My C++ code generated in Visual Studio 95 loads in Visual Studio 2009.


Please just fix the bugs and give us back our working tool set and issue a patch for TrueSpace.


I'm sorry if this comes across as harsh or whiny, but I'm just tired of the decision making process at Caligari. I just want my tools to actually work.

Post by TomG // Mar 16, 2009, 8:31am

TomG
Total Posts: 3397
Unfortunately, the fixes were not possible in the tS6.6 architecture - bone problems existed because the underlying system was broken. It needed to be thrown out, and a new one built from the ground up, and that is what happened.


This is true for most of the fixes and features people wanted to tS6.6 - the underlying data structures and code meant they were impossible to add. Not just hard, but impossible. To restructure the code enough to allow them would mean that backwards compatibility would be lost, and it was just easier to start an entirely new code base.


This is why tS7 was created, and why that decision was taken. What was asked for, the improvements users wanted to see to tS6.6, would not have been possible.


Mostly there is backwards compatibility, but not in all cases. And the programs you cite are not always backward compatible, I have versions of Microsoft Works documents that neither Works nor Word can load any more - progress sometimes means old formats just no longer work.


Bones were the largest thing affected, as they were the most problematic in the old system. This has not affected too many people, as the old bones were so poor, few people ever dared use them! This means that compatibility issues for loading old files have only affected a few, and it is unfortunate that you are one of those.


That said, there is no way we can fix the old tS6.6 code. That was the very reason for the difficult decision to move to an entirely new code base. It's a decision we stand by, even though it does bring difficulties for some existing users. The new bones system though, despite still needing to grow and expand in terms of functionality and stability, is already much better. I've been able to create animated characters, and in only an hour or two, as opposed to spending about a week just to get a static posed hand in the old bones system.


As a note, the "flying apart and exploding when loaded" used to happen in tS6.6 and gS too, it happened to my hand model. I would rig it, pose it, save it, come back to it next day, and on loading, it would rip apart. This was one of the reasons for abandoning the old system, and may be an issue you are seeing here. Used to be solutions involving "don't record a keyframe at keyframe 0" or "detach the skeleton and mesh then save, and just reattach when you load", though these were tricky to remember and usually people forgot with destructive results.


So hard to say if what you are seeing is maybe just because the old code is so buggy and problematic :( And of course plug-ins that work with that aspect are the ones most likely to have problems also.


Either way, we will not be seeing work done on the tS6.6 (Model) side of tS7.6. The longer term intention would in fact be for that side to disappear altogether at some point.


For using tS7.6, it may be best to import mesh, import skeleton with animation via BVH, and redo the weight painting. Yes, it would be quite a bit of work, but you would be moving onto an easier and friendlier bones system, which could pay off long term.


The re-write of tS7 really made it a totally different program, so compatibility is much more like moving from one application to another, rather than moving from one version to another - usually with versions people just tweak or expand an existing code base and don't take the bigger step of saying "You know what, the future is going to need something TOTALLY different, let's scrap everything we have and redo it from the ground up!" It is a bold step, and we think the right one, but it will have the unfortunate effect of causing a break of some sort with older files to some extent.


As it is, 95% of older files should work, anything without bones should work, most old plugins should work - we think we did a pretty good job on compatibility there, kind of releasing brand new software that handles 95% of something created in other software!


As for x format, it really is not a format at all, as has been discussed elsewhere. It has so many different flavors and interpretations and implementations that it is far from standard, and is quite a nightmare to export to or import from as a result. What works great in one app won't work so great in another, and finding the right combination of values and settings is hard. Unfortunate, but part of the format itself more than part of tS. That said, I'd love to see imports and exports that do their best to accomodate the variablilities of the format, it would sure be helpful.


Sorry the news is not better in terms of compatibility with these older files, but hope this helps clarify how and why we reached this particular position. It was a decision made to be in the best interests of the majority of our users, since we wanted code that COULD expand and grow and change in the ways they wanted, and much of that was simply impossible with the old code.


HTH!

Tom

Post by DavidAWinter // Mar 16, 2009, 9:00am

DavidAWinter
Total Posts: 36
For using tS7.6, it may be best to import mesh, import skeleton with animation via BVH, and redo the weight painting. Yes, it would be quite a bit of work, but you would be moving onto an easier and friendlier bones system, which could pay off long term.


So what do I tell my customers then? Sorry.. no new version for a long time because my tools became broken and I have to redo months of work. Do you really think that's acceptable? If you were my customer, would you accept that?


Why not build a migration tool? Visual Studio does that. Oh.. you have VB6 code, let us upgrade that for you...a few minutes later, the code is converted and it compiles.


There could have been a TS6 migration tool. Oh.. you're using the old bone system, here, lets upgrade it to this type...


Then add the slider type animation system people were asking for (and the reason they purchased Puppeteer) and you would have had 90% of the battle won. Then fix the TS6 series interface bugs (like needing to click a button 2 or 3 times before it actually clicked) and you would have been set.


The interface for TS7.6 is unusable. All the tools are hidden and nothing is where it should be. Nothing is in a logical location. As I said, in one hour of use, I had 6 crashes. At one point I actually lost all buttons. I had 100 tabs along the top of the window (why?) and no way to close them. I finally had to uninstall the software and reinstall it just to get rid of the tabs so I could find the model view again. You had this feedback during beta too and it was not listened to.


But lets move beyond that. Lets say I do spend months rebuilding these animations in a completely new system that has an illogical and unfriendly interface and I deal with 6 or more crashes in an evening.


How do I get it into game? The exporter doesn't work. It simply doesn't. The closest thing I've had to a working animated X format model from TS7.6 is a player model that doesn't bend at the joints, but rather bounces around the screen as a solid mass with no arms.. yep.. whole sections of the mesh are missing based on the material applied to that mesh.


So even if I do redo all the bones (using a interface that doesn't work nearly as well as TS6) and redo all the animations (without a tool that's as effective as a TS6 plugin) I have no way to get it into game.


As for x format, it really is not a format at all, as has been discussed elsewhere. It has so many different flavors and interpretations and implementations that it is far from standard, and is quite a nightmare to export to or import from as a result. What works great in one app won't work so great in another, and finding the right combination of values and settings is hard. Unfortunate, but part of the format itself more than part of tS. That said, I'd love to see imports and exports that do their best to accomodate the variablilities of the format, it would sure be helpful.


The only one I've not had work, is the native TrueSpace exporter. Microsoft provides, free of charge, the code to export and import to and from that format. It's a standard format for game use.

Post by mrbones // Mar 16, 2009, 9:04am

mrbones
Total Posts: 1280
pic
Hi David,

Your game and animations should be a testament to your skills and puppeteer
I was looking at the movies They are indeed very good,

Is this when your trueSpace workflow worked or GameSpace?

Tomg, He would only have to rerigg and paint each different character once,
Not reattach each and every motion.

Hopefully a solution will present itself.

I have succesfully exported an animated .X file with exception of the texture working.

What is your Game Engine?

Post by DavidAWinter // Mar 16, 2009, 9:09am

DavidAWinter
Total Posts: 36
Hi David,


Your game and animations should be a testament to your skills and puppeteer

I was looking at the movies They are indeed very good,


Is this when your trueSpace workflow worked or GameSpace?


Tomg, He would only have to rerigg and paint each different character once,

Not reattach each and every motion.


Hopefully a solution will present itself.


I have succesfully exported an animated .X file with exception of the texture working.


What is your Game Engine?


Thank you.


Everything you see in those screens and movies was done in TS6.0 using Puppeteer as the animation tool, and TrueX as the exporter. (actually TrueX was officially only supposed to work in TS5, but nobody I know ever ran into trouble with it in 6).


I use TrueVision 6.5 for my game engine. It's DirectX 9 based. (I think it supports DX10 too but that limits games to only vista).


Tomg, He would only have to rerigg and paint each different character once,

Not reattach each and every motion.


But it sounds like each and every motion would need to be redone anyway. So I'm starting from scratch.


I have succesfully exported an animated .X file with exception of the texture working.


Kind of a big deal not having working textures, but what settings did you use? I've had cases where the model would move around the screen, but not animate. It was also missing parts that has specific textures applied.

Post by TomG // Mar 16, 2009, 10:07am

TomG
Total Posts: 3397
"The interface for TS7.6 is unusable. "


It is different from tS6.6, but if it was unusable, we wouldn't be seeing some of the great work we see from people. And many happily combine the old and the new tools to great effect too, since most of tS6.6 is functional in there, and old scenes usually load with no problem.


It is unfortunate that your use of bones has meant you are in the situation of experiencing incompabilities between the old and new. There is no convertor because the two systems are so different it would be incredibly hard to make such a thing, and would take development time away from other areas of tS6.6. It would in the end also only benefit a small minority of tS users (those who happened to persevere enough with the old bones system to have files they want to move across), and sadly we have to focus on work that benefits the majority of users.


A slider interface would certainly be nice, it was implemented for vertex morphs. As I say, while improved, the bones system in tS7.6 is not static and perfect, there is room for improvement! That's the kind of improvement I would like to see :)


HTH!

Tom

Post by DavidAWinter // Mar 16, 2009, 10:22am

DavidAWinter
Total Posts: 36
"The interface for TS7.6 is unusable. "


It is different from tS6.6, but if it was unusable, we wouldn't be seeing some of the great work we see from people. And many happily combine the old and the new tools to great effect too, since most of tS6.6 is functional in there, and old scenes usually load with no problem.


It is unfortunate that your use of bones has meant you are in the situation of experiencing incompabilities between the old and new. There is no convertor because the two systems are so different it would be incredibly hard to make such a thing, and would take development time away from other areas of tS6.6. It would in the end also only benefit a small minority of tS users (those who happened to persevere enough with the old bones system to have files they want to move across), and sadly we have to focus on work that benefits the majority of users.


A slider interface would certainly be nice, it was implemented for vertex morphs. As I say, while improved, the bones system in tS7.6 is not static and perfect, there is room for improvement! That's the kind of improvement I would like to see :)


HTH!

Tom


A slider system is critical. I'm not sure how it wasn't implemented. It's pretty near impossible to get effective symmetrical animations when dragging bones around. It's why I used puppeteer. When using the drag method, the animations were never symmetrical and when viewed in game, the actors would look like they're limping or something. Very noticeable for looped animations. Slider based systems, like puppeteer allow for sliding to, or entering via text, a very specific value. So you can get the knee to bend to exactly the same point on the first and last frame, as well as the other knee to bend to exactly that point in the middle frame.


Not to mention the continual and annoying need to move the nail around so that you're only dragging the appropriate limb. A slider system removes that all together making animation creation faster and more accurate. Just take Puppeteer and copy it.


That said, you still haven't answer my question. Do you really think forcing customers into lengthy delays because their tools were broken is acceptable? If you were my customer, would you accept such a lengthy delay due to forced rework? If your developers had to throw away all their C++ code and start again because existing code didn't work in the new version of MS Visual Studio, do you think you or Roman would stand for it? This is no different.


This is not a minor inconvenience, this is putting project completion at risk.


A migration tool strikes me as certainly possible. In TS6 you have a bone with a start point and an end point. The ends have a end type and each end type has a rotation type and movement caps. Each bone and cap has an array of vertices that are attached to it. Surely it should be possible to take that information and convert it to the new system. Heck, that's all a format exporter does. Converts from one system to another.


"It is different from tS6.6, but if it was unusable, we wouldn't be seeing some of the great work we see from people."


And I wonder how many of them started with TS when it was free and haven't used anything prior to? I wonder how many of them simply use TS for pretty static pictures? Those of us that use TS for game pipeline seem to have been shafted.


Nor does this address the fact functionality is not logically placed. How did I end up with a whole slew of tabs on my caption bar? Who puts functionality like that on a caption bar? Changing a back end to correct flaws is fine, but it doesn't require a completely new front end. And it doesn't address the continual crashes. I'm not the only one to see this. There are already huge threads in these forums talking about crashes. Every day I'm reading about someone else, a valued member of the community, leaving TS behind due to it's front end and woeful instability.

Post by RAYMAN // Mar 16, 2009, 10:37am

RAYMAN
Total Posts: 1496
pic
Well I wouldnt say the interface of TS7.6 is unusable because

you can customise it so that its useable... but i always wondered why some of

the ideas that came from the beta never appeared in production....

I have high hopes that we will see things like pupetter for workspace from 3d party same as workable X format from 3d party...

Peter

Post by TomG // Mar 16, 2009, 10:42am

TomG
Total Posts: 3397
Hi David,


I can't comment on your customers, as that is not our area. We couldn't maintain tS6.6 as it was and not take the bold step of re-writing based on the fact that some people have customers of their tS6.6 work. We still had to do the re-write, even though some people have customers of their tS6.6 work, otherwise tS was locked into a dead end and couldn't grow and improve any further.


Like I say, this is like moving to an entirely new program. We have maintained compatibility where we can, and we achieved very good compatibility considering it is like two separate programs with little in common underneath the hood.


But like moving to entirely new software, some things are not compatible, and like any piece of software, someone will have been relying on that feature. Unfortunate, but it happens with a complete reworking of the code in this way. Again, we stand by that being the correct thing to have done.


This leaves users with the choices of either staying with the old version that they currently use, which no longer sees any upgrades or support, or making the move to the new version, with the associated compatbility issues. As I say, a very small number of users are affected, as so few worked with tS6.6 bones and gS bones.


It is unfortunate that you are one who finds themselves in that position. There would likely be more compatibility were it not for the use of a third party plugin, that adds another layer of complexity. Again most plugins are supported, but some are not, and those working with bones are the ones most likely to be affected.


HTH,

Tom

Post by DavidAWinter // Mar 16, 2009, 10:53am

DavidAWinter
Total Posts: 36
Hi David,


I can't comment on your customers, as that is not our area. We couldn't maintain tS6.6 as it was and not take the bold step of re-writing based on the fact that some people have customers of their tS6.6 work. We still had to do the re-write, even though some people have customers of their tS6.6 work, otherwise tS was locked into a dead end and couldn't grow and improve any further.


Like I say, this is like moving to an entirely new program. We have maintained compatibility where we can, and we achieved very good compatibility considering it is like two separate programs with little in common underneath the hood.


But like moving to entirely new software, some things are not compatible, and like any piece of software, someone will have been relying on that feature. Unfortunate, but it happens with a complete reworking of the code in this way. Again, we stand by that being the correct thing to have done.


This leaves users with the choices of either staying with the old version that they currently use, which no longer sees any upgrades or support, or making the move to the new version, with the associated compatbility issues. As I say, a very small number of users are affected, as so few worked with tS6.6 bones and gS bones.


It is unfortunate that you are one who finds themselves in that position. There would likely be more compatibility were it not for the use of a third party plugin, that adds another layer of complexity. Again most plugins are supported, but some are not, and those working with bones are the ones most likely to be affected.


HTH,

Tom


Completely unacceptable answer.


Caligari makes a pipeline tool no different than 3D Max, Maya, or Visual Studio, or MS Office. Do you have any idea what the uproar would be like if 3D Max completely broke their piped system without offering a migration process? Microsoft still supports VB6 even though there's a reasonable migration tool to move away from it. Can you imagine what would happen if MSFT decided to drop support for Office95 documents? You sell (or at least sold) a tool to people that make a living off of doing this sort of work. Of course your customers will have customers of their own. People have invested time (and at one point money) into this tool and you've told them none of that is important.


And this is only 1/2 the problem. Even if there was some magical way to get things up and working, there's no way to get them back out again.


I had to use a 3rd party tool (two them actually) because TrueSpace didn't offer two basic features.

Post by splinters // Mar 16, 2009, 10:54am

splinters
Total Posts: 4148
pic
Unusable is a bit harsh but I definitely agree that the UI needs finishing and improving. It really is a WIP but I see no sign of it being brought up to date.

Post by DavidAWinter // Mar 16, 2009, 10:57am

DavidAWinter
Total Posts: 36
Unusable is a bit harsh but I definitely agree that the UI needs finishing and improving. It really is a WIP but I see no sign of it being brought up to date.


I don't think it's harsh. How is crashing 6 times in an hour usable? How is spending 10 minutes hunting for functionality I could get to in 1 button click in previous versions usable?

Post by RAYMAN // Mar 16, 2009, 11:04am

RAYMAN
Total Posts: 1496
pic
David A Winter I had 2 bad crashes in Houdini on Saturday......

so its not a privleg of Truespace to badly crash.... Theres just not enough

people who have tested TS 7 as I am a friend of an open beta....:)

Post by DavidAWinter // Mar 16, 2009, 11:16am

DavidAWinter
Total Posts: 36
At any rate, the original poster asked why TS isn't becoming the industry standard. These sorts of problems are why. I can show TS to people that have been in the game industry for a lot longer than I have been, and these last few posts are one of the reasons they'd jump on as to not switch over. No studio is going to invest in a tool that is likely to break their work in the next version.

Post by RAYMAN // Mar 16, 2009, 11:34am

RAYMAN
Total Posts: 1496
pic
At any rate, the original poster asked why TS isn't becoming the industry standard. These sorts of problems are why. I can show TS to people that have been in the game industry for a lot longer than I have been, and these last few posts are one of the reasons they'd jump on as to not switch over. No studio is going to invest in a tool that is likely to break their work in the next version.

David we all had our troubles with Ts in the last 2 years and If youve read some of my posts in the past you will know that I am one of them and

I never believed in it to become an industry standard... its not going to happen;) But I dont believe in industry standards. Why should those people who are happy with what they are using now jump ship ?

I see TS7 as a platform for lots of people to build things upon......

TS7 is by no mean there where it can be in some time from now...but thats going slowly and steadily thats something we have to accept because its not changing... just waited to long to materialise.....;)

If you find something that suits your needs just use it ...there´s lots of soft with sliders...:D
Awportals.com is a privately held community resource website dedicated to Active Worlds.
Copyright (c) Mark Randall 2006 - 2024. All Rights Reserved.
Awportals.com   ·   ProLibraries Live   ·   Twitter   ·   LinkedIn