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.
#42
I'm just trying to find that line where we can get the Show Tool to validate models as close to 100% of the time as possible. As it is now, it doesn't and that bothers me.
05/06/2004 (1:04 pm)
My point however is that if we can load the model directly via 3space, we eliminate most issues of game logic assumption. If we then RENDER that through Torque we can further validate the model. Yes Ori's model wasn't workign because of a bad exporter, but the result was a bad model. Invalid detail levels. Something that the Torque rendering code catches, but the Show Tool as it exists doesn not.I'm just trying to find that line where we can get the Show Tool to validate models as close to 100% of the time as possible. As it is now, it doesn't and that bothers me.
#43
Understood. This is a tought question to answer, so I suppose some talking about it will have to happen in order to get community consensus.
In an ideal world, the division of labor should be split so that if it is an issue that can be fixed by the modeler, it should be caught in show. If it needs a coder, then show does not need to catch it.
I agree that the earlier the model is validated the better.. but sometimes it is really out of the aritsts hands and requires code changes. If the artist can not affect the outcome, and they are otherwise doign whatever they can, it should work in -show. Now, I am all for more checking, but if it increases the amount of work and knowledge that one must have in ordrr to get a shape 'working in game' at all, then I don't think it is a good thing. The art path is pretty unforgiving as it is.. making it hardr on those new to it by requiring more of them is probably not a good thing.
Now, there are so few render errors that I personally do not think it wise to definetley include them for validation purposes as it happens so rarely that it does not seem to be worth the effort to add the check.
Now, collsion is another matter altogether.. It is borked so often in model and code modifications that if it is checked then none but those who totally know what is going on will get anything running..
The showtool is never going to be able to be a 100% check of the model. It should be as close as possible to be a 100% check of what the artist can do to make the model 'good'. If 100% of what the artist can influence in the modelign-exporting process is only 60% of what can be checked, I say stay at 60% and call it good. (again it is worth noting that most of what can be checked now in -show accounts for the majority of all the problems that show up)
05/06/2004 (1:19 pm)
Quote:As it is now, it doesn't and that bothers me.
Understood. This is a tought question to answer, so I suppose some talking about it will have to happen in order to get community consensus.
In an ideal world, the division of labor should be split so that if it is an issue that can be fixed by the modeler, it should be caught in show. If it needs a coder, then show does not need to catch it.
I agree that the earlier the model is validated the better.. but sometimes it is really out of the aritsts hands and requires code changes. If the artist can not affect the outcome, and they are otherwise doign whatever they can, it should work in -show. Now, I am all for more checking, but if it increases the amount of work and knowledge that one must have in ordrr to get a shape 'working in game' at all, then I don't think it is a good thing. The art path is pretty unforgiving as it is.. making it hardr on those new to it by requiring more of them is probably not a good thing.
Now, there are so few render errors that I personally do not think it wise to definetley include them for validation purposes as it happens so rarely that it does not seem to be worth the effort to add the check.
Now, collsion is another matter altogether.. It is borked so often in model and code modifications that if it is checked then none but those who totally know what is going on will get anything running..
The showtool is never going to be able to be a 100% check of the model. It should be as close as possible to be a 100% check of what the artist can do to make the model 'good'. If 100% of what the artist can influence in the modelign-exporting process is only 60% of what can be checked, I say stay at 60% and call it good. (again it is worth noting that most of what can be checked now in -show accounts for the majority of all the problems that show up)
#44
It could even share most of the same code. I think once you got the basic showtool in it would be dead easy to write.
The important thing would be to make it clear to artists how they should do their testing - ie, first in showtool, then in game or in the game previewer.
Beyond that thought, though, I think Joe is right on.
05/06/2004 (2:09 pm)
I think a possible path would be, once the basic show tool is done, to make a "game preview" tool that shows the model in a white room with shadows and particles, lets you run it around as a player/vehicle/etc.It could even share most of the same code. I think once you got the basic showtool in it would be dead easy to write.
The important thing would be to make it clear to artists how they should do their testing - ie, first in showtool, then in game or in the game previewer.
Beyond that thought, though, I think Joe is right on.
#45
05/06/2004 (2:12 pm)
Ben is thinking along the lines that I am thinking.. the showtool, then the showtool+, which is an extension of show and includes whatever the team wants fron the game, terrain, skies, particles, giant lizards.. etc.. this way you get the pure show tool and then a fast loading game checking tool. 
#46
Warning: shape starter.fps/data/shapes/barrel/barrel.dts collision detail 0 (Collision-1) bounds exceed that of shape.
Error: shape starter.fps/data/shapes/crossbow/ammo.dts-collision detail 0 (Collision-3) bounds box invalid!
I didnt see it mentioned, if it was already mentioned I appologise.
My log file often has many of these, but they don't seem to cause any real problems so with many other things to do, this gets put on the back burner. Someday I'll dig in and learn what they are all about.
But models with these sorts of errors will have to be worked on again to get rid of these I am assuming.
05/07/2004 (8:36 am)
It would be nice to have a tool to check for these kind of errors as well so they can be fixed while the artist is looking at it:Warning: shape starter.fps/data/shapes/barrel/barrel.dts collision detail 0 (Collision-1) bounds exceed that of shape.
Error: shape starter.fps/data/shapes/crossbow/ammo.dts-collision detail 0 (Collision-3) bounds box invalid!
I didnt see it mentioned, if it was already mentioned I appologise.
My log file often has many of these, but they don't seem to cause any real problems so with many other things to do, this gets put on the back burner. Someday I'll dig in and learn what they are all about.
But models with these sorts of errors will have to be worked on again to get rid of these I am assuming.
#47
05/07/2004 (6:34 pm)
It would probably be possible to both capture those errors in the show tool and render the bounding box. This seems like it might be a worthwhile addition (ie, have a validate button to check for snafus of that nature). Joe might have some feedback here. Most of them are actually benign.
#48
05/07/2004 (6:43 pm)
I apologize that nothing much has happened on this of late. Some key document work had to be done on Mayhem to prevent a stall in development. Combined with me still fighting a cold and not having much time off from work and I just haven't managed to squeeze this in. However I plan to make some headway within the next few days hopefully.
#49
In terms of Ori's shape, you misundertand what the problem was. The export error was that the shape was getting duplicated in the -1 detail level. This resulted in too many polys for shape base to handle in it's collision code. This isn't an illegal shape. It wasn't the shape that Ori meant to export, nor is it the one that the exporter should have exported, but it was a perfectly legal shape. It just turns out that shapebase assumes fairly simply collision shapes. This would not have crashed ThinkTanks because I commented out all of ShapeBase and most of the collision code that ShapeBase uses. It would probably not have crashed BitShifter either because I know Paul thinks like I do.
Also, don't miss the obvious: a tool that has different behavior than the game adds more information not less. There are no if ands or buts. If the tool exhibits the same problems the game does, that gives you no additional information.
05/07/2004 (8:37 pm)
@John, I'd caution against making the ShowObject a StaticShape. That's where the cruft in the engine begins. It would be nice if you could make it a SceneObject or maybe GameBase.In terms of Ori's shape, you misundertand what the problem was. The export error was that the shape was getting duplicated in the -1 detail level. This resulted in too many polys for shape base to handle in it's collision code. This isn't an illegal shape. It wasn't the shape that Ori meant to export, nor is it the one that the exporter should have exported, but it was a perfectly legal shape. It just turns out that shapebase assumes fairly simply collision shapes. This would not have crashed ThinkTanks because I commented out all of ShapeBase and most of the collision code that ShapeBase uses. It would probably not have crashed BitShifter either because I know Paul thinks like I do.
Also, don't miss the obvious: a tool that has different behavior than the game adds more information not less. There are no if ands or buts. If the tool exhibits the same problems the game does, that gives you no additional information.
#50
As far as Ori's shape. I'm confused :) When I pulled up the code and looked at the code that was asserting on Ori it was because of an invalid detail level. In any case I guess it isn't really important.
05/08/2004 (4:14 am)
When I said "static shape class" I actually meant that genericlly. To be exact it would be a descendant of SceneObject similiar to TSStatic.As far as Ori's shape. I'm confused :) When I pulled up the code and looked at the code that was asserting on Ori it was because of an invalid detail level. In any case I guess it isn't really important.
#51
Ori's shape is interesting because it showed an inconsistency in the exporter. The exporter exported a VALID shape. It just happened that the shape it described had a really complex collision mesh, which made ShapeBase complain.
It's like what would happen if photoshop exported a 16kx16k PNG file. It's a valid PNG, it's just likely to make a lot of code break. A PNG viewer should display it, even if "real" programs break.
05/08/2004 (8:52 am)
John's got the right idea for his class hierarchy.Ori's shape is interesting because it showed an inconsistency in the exporter. The exporter exported a VALID shape. It just happened that the shape it described had a really complex collision mesh, which made ShapeBase complain.
It's like what would happen if photoshop exported a 16kx16k PNG file. It's a valid PNG, it's just likely to make a lot of code break. A PNG viewer should display it, even if "real" programs break.
#54
05/11/2004 (7:24 am)
@Ben, you misunderstood my vague reference. By cruft I did't mean that it was deprecated. I meant that ShapeBase makes a lot of assumptions that aren't necessary for using ts shapes. BTW, you should put your original message back...you didn't post any code.
#55
How important would you say the ability to load a file from anywhere, not neccesarily inside the "modPath" settings?
The reaosn I ask is that I messed around with this a bit earlier today and it seems the way the resource manager/engine operates prohibits loading for example a shape form outside the given modPaths. I haven't looked at the code to see how easy this would be to change, but it seems to me that this is a rather core aspect of the engine's behaviour and i'd be a little leary of changing it.
05/11/2004 (8:25 am)
@MatthewQuote:
- Add a nicer file browser with the ability to browse anywhere
How important would you say the ability to load a file from anywhere, not neccesarily inside the "modPath" settings?
The reaosn I ask is that I messed around with this a bit earlier today and it seems the way the resource manager/engine operates prohibits loading for example a shape form outside the given modPaths. I haven't looked at the code to see how easy this would be to change, but it seems to me that this is a rather core aspect of the engine's behaviour and i'd be a little leary of changing it.
#56
05/11/2004 (9:54 am)
John: I'd be leery to use much of anything that changed that behavior (resourcemanager). Torque has a pretty good sandboxing system going - anything that compromises that compromises security for the end user, unless extremely carefully implemented.
#57
05/11/2004 (9:57 am)
Yeah that's my feeling as well.
#58
05/11/2004 (10:01 am)
If they want to be able to play with stuff outside of the project sandbox, have 'em use the windows symbolic linking tool instead of changing the resourcemanager.
#59
It would be neat to have the resmanager reload resources that have changed, though. Maybe after it changes focus.
05/11/2004 (11:34 am)
Yeah, I don't think we need to fundamentally change the resmanager to get what we want. Pretty sure Matt was just referring to a better browser control. :)It would be neat to have the resmanager reload resources that have changed, though. Maybe after it changes focus.
#60
I tend to work out of a bunch of different mod directories and am having to constantly change my cmdline switches. It is especially irritating to do so with the show tool.
It would also be nice if I could download a dts/dif from somewhere, drop it on my desktop, double-click on it, and have a stand-alone show tool automatically fire up and show me the model w/o me having to drop it into some specific TGE folder.
I haven't looked to see how hard it would be to remove this limitation either but it is something I am going to have to tackle soon.
05/11/2004 (12:20 pm)
Well...sandbox makes a lot of sense for end users...keeps people from distributing malicious mod code and whatnot. But why should a developer be limited to a single mod directory when using a tool that should apply to *any* tge model/interior?I tend to work out of a bunch of different mod directories and am having to constantly change my cmdline switches. It is especially irritating to do so with the show tool.
It would also be nice if I could download a dts/dif from somewhere, drop it on my desktop, double-click on it, and have a stand-alone show tool automatically fire up and show me the model w/o me having to drop it into some specific TGE folder.
I haven't looked to see how hard it would be to remove this limitation either but it is something I am going to have to tackle soon.
Torque Owner Joe Maruschak
The artist should always check the model in the show tool first and read the dump file to make sure all required nodes exist in the shape.
These steps should be taken by all artists before even going to the programmer with an error. I would say about 75% of the problems with player shapes are this type. Having it work as it does now, if the process is followed correctly, means that 75% of the model errors should get caught before they even get into the game if the artist is being dilligent.
Now, If everything work in show and it crashes the game and the model 'appears' to have everything it needs (by checking -show and the dump file), then it is a bug, either in the exporter, in threespace, or the game (mayne 5% of the time is this the case). These problems are usually few and far between and by using the tools we have now.. we can look at the model, the dump file, the DTS in the showtool, and the crash, and get a lot of information about where to look.
Ori did just that. He did everything, he did it twice.. he checked, he rechecked, everythign. It should have worked. So he posted the error, emailed us.. asked.. when we started to help him with it, we had all the info we needed. I did not have to go throgh all the steps with him.. did you check this, did you check this... etc..
The process worked. he checked all the normal issues.. he identifed it as a 'should work and does not' issue, and asked for help. This is how it is supposed to work. The person withthe problem askes for help after a issue that cannot be solved comes up, not at the first sign of an error (thus keeping the programmer working on productive stuff and not playing babysitter for the artists)
Additionally, we were able to determine that it was not the 'no animation in player makes game upchuck' issue. Eliminating that as a cause, and speeding up the process of fixing it.