Show Tool v2 - Request for Comments
by John Vanderbeck · in Torque Game Engine · 05/05/2004 (5:26 am) · 66 replies
Show Tool v2
For those of you not aware, I am in the process of writing a new Show Tool for the Torque engine.
The goal is to provide a functional replacement for the existing Show Tool, while at the same time adding enhancing the feature set without causing bloat.
The original plan for doing this was to create in essence a mini-game inside of which the tool would exist. This would allow for many of the enhanced features almost automatically, as well as using a script to engine interface that is consistent with how a standard game would operate.
However, recently concerns have been raised that by changing that underlying interface, the show tool would be less useful than it is now. Therefore, the point of this document is to present a roadmap for development of this new show tool and then solicit responses, comments, suggestions on to best accomplish the goal.
The main problem as I see it is the core interface. I believe that the best way to improve the tool with up to date features such as environment maps, shadows, shaders, etc, is to build it as a mini-game. The argument against that is that the tool becomes LESS useful if it uses a more game-like interface rather than the existing direct hooks into 3space.
What I propose is that the tool indeed be built as a mini-game allowing the advanced features, but that the GUI provide the user with the ability to also use those existing direct hooks. My original goal was to do that by means of a "Model Check" button that would then automatically load the shape using the direct 3space interface and then automatically run it through all of its animations threads. This would presumably be enough to verify the model as being correctly built, and then the user can use the rest of the tool which uses the new mini-game interface to more closely inspect, test, and tweak the model.
So I guess the biggest question is this:
Which method would you prefer? "Check Model" button which would then automatically load the model through the direct 3space interface and run it through its paces, or the ability to manually load the model through the 3space interface and manually run it through animations and what not. Basically just like the existing show tool.
Essentially it comes down to remaking the existing show tool as a subset of the new one, or encapsulating it into a one click model check feature.
The rest of the feature set I think is best left to the mini-game interface. But again I'd like comments.
I had intended to post a planned feature list but I don't have time to do that right now. I'll have to do it after work.
For those of you not aware, I am in the process of writing a new Show Tool for the Torque engine.
The goal is to provide a functional replacement for the existing Show Tool, while at the same time adding enhancing the feature set without causing bloat.
The original plan for doing this was to create in essence a mini-game inside of which the tool would exist. This would allow for many of the enhanced features almost automatically, as well as using a script to engine interface that is consistent with how a standard game would operate.
However, recently concerns have been raised that by changing that underlying interface, the show tool would be less useful than it is now. Therefore, the point of this document is to present a roadmap for development of this new show tool and then solicit responses, comments, suggestions on to best accomplish the goal.
The main problem as I see it is the core interface. I believe that the best way to improve the tool with up to date features such as environment maps, shadows, shaders, etc, is to build it as a mini-game. The argument against that is that the tool becomes LESS useful if it uses a more game-like interface rather than the existing direct hooks into 3space.
What I propose is that the tool indeed be built as a mini-game allowing the advanced features, but that the GUI provide the user with the ability to also use those existing direct hooks. My original goal was to do that by means of a "Model Check" button that would then automatically load the shape using the direct 3space interface and then automatically run it through all of its animations threads. This would presumably be enough to verify the model as being correctly built, and then the user can use the rest of the tool which uses the new mini-game interface to more closely inspect, test, and tweak the model.
So I guess the biggest question is this:
Which method would you prefer? "Check Model" button which would then automatically load the model through the direct 3space interface and run it through its paces, or the ability to manually load the model through the 3space interface and manually run it through animations and what not. Basically just like the existing show tool.
Essentially it comes down to remaking the existing show tool as a subset of the new one, or encapsulating it into a one click model check feature.
The rest of the feature set I think is best left to the mini-game interface. But again I'd like comments.
I had intended to post a planned feature list but I don't have time to do that right now. I'll have to do it after work.
#62
05/11/2004 (12:26 pm)
One of the teams I worked on when I was at Dynamix had a stand-alone dts viewer. We just double-clicked a dts file and it loaded in the viewer (texture had to be in the same directory as the dts file). So, it can be done. Don't ask me how though. I'm just an artist. :)
#63
05/11/2004 (2:54 pm)
Would it be possible for someone to provide me with a test model. Made in Milkshape (or some other app+exporter that does NOT support DSQs) with a couple animations in it? In otherwords i'm looking for a test model that has animations embedded in the DTS file and not in seperate DSQs. It seems that the demo models all use DSQs unless i'm mistaken.
#64
Any particular reason you need this?
05/11/2004 (3:10 pm)
I'm pretty sure that some of the sample models like the flag in the demo have animations on them. Of course, all the exporters support embedded animations. DSQ's are just provided for instances when you want to share animations.Any particular reason you need this?
#65
The reason I wanted it was just to test my code against both types of models. Wanted to make sure it worked against embedded animation as well as DSQs
05/11/2004 (3:14 pm)
Well all of them support embedded, but not all support DSQ right?The reason I wanted it was just to test my code against both types of models. Wanted to make sure it worked against embedded animation as well as DSQs
#66
In theory, TS takes care of all the DSQ-related stuff. But like I said, I think the flag does have embedded animations.
05/11/2004 (3:43 pm)
That is correct. Not all exporters support DSQ.In theory, TS takes care of all the DSQ-related stuff. But like I said, I think the flag does have embedded animations.
Associate Ben Garney
AFTER we have the basic working tool, THEN things like that would be handy. But right now it seems like a risky rabbit hole.