TGE Exporters
by Ron Yacketta · in Torque Game Engine · 03/01/2003 (8:11 pm) · 9 replies
All,
I spoke to JT before he left for GDC in regards to helping them out, one of the things he mentioned was
So, could those of you having issues with the exports please post here. Be as specific as possible and provide step-by-step procedures to reproduce your problem. Also, if you wish to provide a file that would aid in problem recreation please email it to [email]ryacketta@criber.com[email]
Regards,
Ron
I spoke to JT before he left for GDC in regards to helping them out, one of the things he mentioned was
Quote:
Another area is the exporter. Without any changes in functionality at all,
it would be nice if it spit out nice error messages when things go wrong.
So, could those of you having issues with the exports please post here. Be as specific as possible and provide step-by-step procedures to reproduce your problem. Also, if you wish to provide a file that would aid in problem recreation please email it to [email]ryacketta@criber.com[email]
Regards,
Ron
#2
-Ron
03/02/2003 (10:21 am)
I think Jeff is speaking of the max2dts exporters. I will have to ping him again after GDC to see if he was speaking in terms of all exporters. For know I will focus on the max2dts ones.-Ron
#3
Those two issues might be better dealt with on the engine side. Both are good suggestions, but just not issues the exporter is best at dealing with. In particular:
1) the exporter only deals with texture names and doesn't actually load the texture into memory. Detecting that it isn't a power of two would require an extra step that the engine can just as well perform.
2) the exporter is a general purpose exporter, and doesn't know what you are planning to do with the exported shape. Vehicle specifications have changed fast and furious over the lifetime of the Torque engine whereas the exporter has remained the same. The engine really should assert if you are trying to use an innappropriate shape as a vehicle (although, check out the Car content pack: Joe was able to take a rock and make a vehicle out of it, so I'm not sure that the minimal requirements are that high -- you can look at the screenshot slideshow to see this).
I'd also like to suggest that anyone who has problems with the exporter should grab the version here. For some reason the version that comes with the Torque results in more errors and longer exports than any other version I've seen. I believe it's a compile flag issue, as the MaxSDK has some particular requirements on building (although, all I did to build the verson on Joe's site, as far as I remember, is to build in release mode).
03/02/2003 (11:06 am)
@Fredrick - Those two issues might be better dealt with on the engine side. Both are good suggestions, but just not issues the exporter is best at dealing with. In particular:
1) the exporter only deals with texture names and doesn't actually load the texture into memory. Detecting that it isn't a power of two would require an extra step that the engine can just as well perform.
2) the exporter is a general purpose exporter, and doesn't know what you are planning to do with the exported shape. Vehicle specifications have changed fast and furious over the lifetime of the Torque engine whereas the exporter has remained the same. The engine really should assert if you are trying to use an innappropriate shape as a vehicle (although, check out the Car content pack: Joe was able to take a rock and make a vehicle out of it, so I'm not sure that the minimal requirements are that high -- you can look at the screenshot slideshow to see this).
I'd also like to suggest that anyone who has problems with the exporter should grab the version here. For some reason the version that comes with the Torque results in more errors and longer exports than any other version I've seen. I believe it's a compile flag issue, as the MaxSDK has some particular requirements on building (although, all I did to build the verson on Joe's site, as far as I remember, is to build in release mode).
#4
For my 2nd suggestion maybe it could be done via configuration, like they are a popup where you tell what kind of shape/model you want to export (character, vehicle, simple shape, etc...). And maybe the setting could be read from files (so easily configurable for future release, similar to what the cfg file contains but have some presets).
The tutorial we have read so far always are missing some elements that give us some headaches! (another area of improvement for the exporters is to have better documentation).
Like currently i have another problem with my models that make the torquedemo crash. It tell me the following :
"Error, ran over the shapebase assumptions about convex hulls."
And i have no ideas where to start and what should i look into in our model to what cause this problems 8-(.
And another feature i forgot to mention is to have a progress status/bar. Each time we export we just that windows hourglass and have to wait. Not knowing how long it is going to take.
03/02/2003 (7:48 pm)
I know it could make the exporter get heavy, but i just find it frustrating to only know they are a problem with the model once it got into the engine. The sooner the problem can be detected the better in my opinion.For my 2nd suggestion maybe it could be done via configuration, like they are a popup where you tell what kind of shape/model you want to export (character, vehicle, simple shape, etc...). And maybe the setting could be read from files (so easily configurable for future release, similar to what the cfg file contains but have some presets).
The tutorial we have read so far always are missing some elements that give us some headaches! (another area of improvement for the exporters is to have better documentation).
Like currently i have another problem with my models that make the torquedemo crash. It tell me the following :
"Error, ran over the shapebase assumptions about convex hulls."
And i have no ideas where to start and what should i look into in our model to what cause this problems 8-(.
And another feature i forgot to mention is to have a progress status/bar. Each time we export we just that windows hourglass and have to wait. Not knowing how long it is going to take.
#5
If you are using a well built version of the exporter, this should be un-necesary. Exports should takes seconds, not minutes.
03/02/2003 (8:12 pm)
Quote:And another feature i forgot to mention is to have a progress status/bar.
If you are using a well built version of the exporter, this should be un-necesary. Exports should takes seconds, not minutes.
#6
-Ron
03/02/2003 (8:14 pm)
I agree with Joe, the export from max to dts should not be timed with an hour glass ;) I am looking to fix issues within the exporter code itself (at least that is how I view Jeff's request).-Ron
#7
I realize it's not an "issue" per se, but it seems like it would be a minor addition that would give huge benefits in sanity-checking.
Maybe if it doesn't get implemented this time around, it can be added to the wishlist ;)
(Or maybe I'll buy Max, and add it myself :P. Not too likely, though, I'm just a starving college student.)
03/03/2003 (1:08 pm)
I agree that a configurable warning system would be really, really handy for the arists ("Oh, you forgot the N node!"). I envision this as simply being a flat file that the programmers edit ("required_nodes=head, Lleg, Rleg...") as they get the source made up. It would be optional.I realize it's not an "issue" per se, but it seems like it would be a minor addition that would give huge benefits in sanity-checking.
Maybe if it doesn't get implemented this time around, it can be added to the wishlist ;)
(Or maybe I'll buy Max, and add it myself :P. Not too likely, though, I'm just a starving college student.)
#8
On the point of catching errors as soon as possible: that's all well and good, but one also wants to maintain a stream-lined tool. One also wants to minimize the sources of error (e.g., multiple versions). One wants to even minimize effort maintaining features that don't make the art pipeline any more efficient.
I'm not trying to argue that the points made above aren't reasonable, I'm just suggesting that they are putting the error at the wrong location. Fixes of this nature should go into the exporter last not first.
Finally, if you are having slow exports you are using the wrong version of the exporter. Use the one that I linked to above. Exports happen in a few seconds or less if you use that one rather than minutes. Don't know what is wrong with the "bad" exporter, just know it is "bad".
03/03/2003 (2:03 pm)
I think a "syntax" checker on shapes could be helpful. Maybe it could take advantage of the Torque scripting language to make it very configurable. However, I don't think it addresses the problems people are having. People are trying to get vehicles in the game and can't. That isn't an exporter problem. First the information on how to get vehicles in the game has to be clear to the artist. That information obviously isn't getting there. Second the engine needs to tell the artist if the vehicle shape they are trying to use is missing something. If the engine doesn't warn about it why should the exporter? The vehicle code has changed quite a bit and might change more. How would you like to have to worry about what version of the exporter you are using and what version of the game? Third, the reason for this failure needs to be clear (consider the above posters complaining that all it told him was that the shape exceeded the max convex hull count). Again, the engine needs to do this not the exporter. The exporter doesn't export "ShapeBase" shapes. It exports "TSShapes" which can be used for many purposes. We don't even include ShapeBase in ThinkTanks, so I'd hate to think our exports would be limited by ShapeBase constraints. Finally, if solving those two issues one still thinks they are losing time checking things in the game after exporting, then it would make sense to add some type of "syntax" checker to the exporter. My guess, though, is that if you go about fixing the issues in that order, it won't be worth it to make the addition you are talking about.On the point of catching errors as soon as possible: that's all well and good, but one also wants to maintain a stream-lined tool. One also wants to minimize the sources of error (e.g., multiple versions). One wants to even minimize effort maintaining features that don't make the art pipeline any more efficient.
I'm not trying to argue that the points made above aren't reasonable, I'm just suggesting that they are putting the error at the wrong location. Fixes of this nature should go into the exporter last not first.
Finally, if you are having slow exports you are using the wrong version of the exporter. Use the one that I linked to above. Exports happen in a few seconds or less if you use that one rather than minutes. Don't know what is wrong with the "bad" exporter, just know it is "bad".
#9
As the problem with the models today our modeler was able to succesfully export it and get it running under the Torquedemo ;-). What was the errors? Well it was quite silly, but neither the engine nor the exporter told us. It was that when we create the vehicle (which consist of several parts), is that we only give the number to the main object (vehicle#, in our case vechicle110), but we need to also add 110 to all the other sub-object like motors, cockpit etc... Once we did that it work like a charm!
It is indeed not easy to decide where to put the error checking, it could be done in the exporter (probably making it more slow and complex) or on runtime in the engine. But it definately need to be implemented somewhere with the appropriate errors message so that we can easily find the problems and fix it.
And like i mention earlier better documentation on how to create models and to export them will reduce the number of errors.
03/03/2003 (3:40 pm)
Ok ill go grab the DTS exporter link above and hopefully it will already and not having to wait for a long time ;-).As the problem with the models today our modeler was able to succesfully export it and get it running under the Torquedemo ;-). What was the errors? Well it was quite silly, but neither the engine nor the exporter told us. It was that when we create the vehicle (which consist of several parts), is that we only give the number to the main object (vehicle#, in our case vechicle110), but we need to also add 110 to all the other sub-object like motors, cockpit etc... Once we did that it work like a charm!
It is indeed not easy to decide where to put the error checking, it could be done in the exporter (probably making it more slow and complex) or on runtime in the engine. But it definately need to be implemented somewhere with the appropriate errors message so that we can easily find the problems and fix it.
And like i mention earlier better documentation on how to create models and to export them will reduce the number of errors.
Torque Owner Frederic "Intruder" Tessier
(max2dts, max2map, map2dif, ms2dts, etc...)
For the max2dts :
- Display an error/warning when the texture size arent a power of 2. It has take me a while before i check the texture as the source problem, since when we export the model it did tell us anything. So i though everything in the model was ok.
- Display an error/warning if they are some missing node for a player or vehicle (if for example no mount, cam, eye, collision, etc...)
I know if the 2 things above were part of the exporter then we will have know much more sooner that our model had errors inside. I find about the problems in the model after having to debug for a while the torquedemo and try to understand why it was crashing.