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.
#2
a way to create, mount, and test particle systems with the model easily would be cool too
05/05/2004 (7:48 am)
Be nice if there was an easy way to test mount points...gui to select a weapon, flag, whatever, and which mountpoint on the main model to attach it to, so I could check orientation easilya way to create, mount, and test particle systems with the model easily would be cool too
#3
I honestly feel that your idea for a mini-game is somewhat rediculous as it removes the reason for the show tool, and that is to check your model or animations before introducing various scripts and features that can cause the engine to crash. If people want to check their models in an in-game setting then they can load the model into their game. See my point?
I think you need to go back to the drawing board and do some reasearch in regards to what exactly people who use the show tool do with it and what they might need because as of right now nothing you have suggested sounds great, interesting or worth anyones time implimenting.
Logan
05/05/2004 (7:58 am)
I am with Pascal on this, I frequently use the Show Tool and do not find any problems with it so I don't honestly see the need for reinventing the wheel.I honestly feel that your idea for a mini-game is somewhat rediculous as it removes the reason for the show tool, and that is to check your model or animations before introducing various scripts and features that can cause the engine to crash. If people want to check their models in an in-game setting then they can load the model into their game. See my point?
I think you need to go back to the drawing board and do some reasearch in regards to what exactly people who use the show tool do with it and what they might need because as of right now nothing you have suggested sounds great, interesting or worth anyones time implimenting.
Logan
#4
The only thing I can even think of adding is a ground plane or grid to use as visual reference for viewing transform animations. That and being able to resize the showtool window to something larger than 800x600. Otherwise, I'm happy with the showtool.
05/05/2004 (7:59 am)
What would be the point of a mini-game? The showtool is meant for viewing shapes and animations, not playing a game. If I wanted to play a game, I would, well, get a game and play it. The showtool is fast, simple, clean, and does what it is suppose to do -- show stuff. Manual loading of shapes and animations works great for me. Autoloading anything generally pisses me off.The only thing I can even think of adding is a ground plane or grid to use as visual reference for viewing transform animations. That and being able to resize the showtool window to something larger than 800x600. Otherwise, I'm happy with the showtool.
#5
However I think what you call a "mini-game" solution is the wrong solution. The reason I say this is because it does not fit the needs of experienced artists and coders who work with the existing tools and know what they are actually used for.
I am a coder and will let the artists speak for themselves, and yet as a coder I am directly involved with exactly the same issues. An artist hands me a .dts file and my first move is to load the show tool and verify it is built correctly.
But here is the main point. The show tool verifys for a coder that the LOWER LEVEL animation threads and LOD and all that are built as the coder expects. The game on the other hand uses this data to create HIGHER LEVEL behaviour. As a coder one of the MAIN uses of the show tool is that it does NOT HAVE MY BUGS IN IT.
In otherwords I not only use the show tool to verify that the artist has handed me a file built the way I need it. I also use it when I find a bug in the game to figure out if the flaw is in my code or is in the model.
For this reason I would certainly not use a show tool that was heavily modified merely cause it lessens it's use for finding and verifying problems.
That being said the type of features I would want out of the show tool woudl be support for LOWER LEVEL features that it does not currently have. In TGE most or all LOWER LEVEL behaviours can already be verified with the show tool. The most important change would be supporting the upcoming TSE which defines new features not supported by the show tool.
I will give one example of a LOW LEVEL feature the existing show tool does not have that could be added.
I agree with chem. Be nice to verify the location and orientation of your mount points. I would not want to mount an actual object there...taht is HIGHER LEVEL game logic. But it would be nice to have a LIST of defined mount points and visually be able to see WHERE they are and HOW THEY ARE ORIENTED.
I would see it this way...some list that shows the moutn points and lets you select any # of mount points. WHen selected they show up as a little axis system with their own lil x/y/z lines drawn in diff colors. When you run an aniomation you can wathc the mount points rotate to see if the animation does what you expect to the mount point.
So you see...it's tempting to say "ill allow you to mount any object on this object for testing" but that is not really teh BEST solution to this problem.
I would like other artits like Chem/Pascal/Joe etc to pipe up and agree or disagree with my breakdown of what sort of features you want in a Show tool and which you dont.
05/05/2004 (8:10 am)
I understand the motivation for being able to check the correctness of a model prior to placing it in game and that is what the show tool is for so I understand the motivation to improve on the show tool.However I think what you call a "mini-game" solution is the wrong solution. The reason I say this is because it does not fit the needs of experienced artists and coders who work with the existing tools and know what they are actually used for.
I am a coder and will let the artists speak for themselves, and yet as a coder I am directly involved with exactly the same issues. An artist hands me a .dts file and my first move is to load the show tool and verify it is built correctly.
But here is the main point. The show tool verifys for a coder that the LOWER LEVEL animation threads and LOD and all that are built as the coder expects. The game on the other hand uses this data to create HIGHER LEVEL behaviour. As a coder one of the MAIN uses of the show tool is that it does NOT HAVE MY BUGS IN IT.
In otherwords I not only use the show tool to verify that the artist has handed me a file built the way I need it. I also use it when I find a bug in the game to figure out if the flaw is in my code or is in the model.
For this reason I would certainly not use a show tool that was heavily modified merely cause it lessens it's use for finding and verifying problems.
That being said the type of features I would want out of the show tool woudl be support for LOWER LEVEL features that it does not currently have. In TGE most or all LOWER LEVEL behaviours can already be verified with the show tool. The most important change would be supporting the upcoming TSE which defines new features not supported by the show tool.
I will give one example of a LOW LEVEL feature the existing show tool does not have that could be added.
I agree with chem. Be nice to verify the location and orientation of your mount points. I would not want to mount an actual object there...taht is HIGHER LEVEL game logic. But it would be nice to have a LIST of defined mount points and visually be able to see WHERE they are and HOW THEY ARE ORIENTED.
I would see it this way...some list that shows the moutn points and lets you select any # of mount points. WHen selected they show up as a little axis system with their own lil x/y/z lines drawn in diff colors. When you run an aniomation you can wathc the mount points rotate to see if the animation does what you expect to the mount point.
So you see...it's tempting to say "ill allow you to mount any object on this object for testing" but that is not really teh BEST solution to this problem.
I would like other artits like Chem/Pascal/Joe etc to pipe up and agree or disagree with my breakdown of what sort of features you want in a Show tool and which you dont.
#6
- Clean up the gui (make it nicer looking and easier to use)
- Add a nicer file browser with the ability to browse anywhere
- Make it load one model at a time unless you select more than one in the file browser
- Make the camera control a bit more inuitive (orbit cam by default)
- Add support for more advanced ts features like emap
- Make the animation viewer simpler to use
- Tie a lot more of the configuration for the show tool into script (stuff like the background color)
- Toggle collision hulls rendering and maybe show a convexity analysis (like in my 3ds code)
- A hierarchy viewer would be really handy (sometimes the exporter does odd things). This would also allow people to show a snapshot of their in-game hierachy to other people to speed up debugging. Maybe even have a "Save to image" button on it.
- Mounting shapes to each other
- Improved lighting options
- A couple of model checker tools that look for common problems
- A tool to resize textures to the nearest power of 2 (I have code for this)
- A TSShapeConstructor script exporter
- Ability to preview interiors (and any other TGE file formats that can be directly loaded i.e. no scripts needed)
- Interiors: be sure to include the debug render views (like zone colors)
- Interiors: maybe include entity icons as well as toggle things like portal and detail brushes
- One thing the HL MDL Viewer does is allow you to change the texture/skin that is applied to the model and resave the model. Btw: the HL MDL Viewer is an excellent example of the a model viewer also.
Seriously, the less scripts loaded the better (aside from the editor's scripts). The less rendered the better. Why would you need to load the terrain? Why would you need to do actual collision (just seeing the hulls should be plenty)? *Nothing* about this tools should be tied to a specific game...even the stock ones that ship with the sdk.
Don't be shy about changing engine code. If you build a tool that works then it will become the "official" show tool and those changes will be added to the engine. For older codebases we can offer a stand-alone show tool (something I have long thought would be handy).
My recomendation is to take your time. Modify the existing show tool to include some of your improvements and to include features like Joe and other have mentioned. Show us incremental changes to the current show tool and when you deviate in a way the artists don't like then they can steer you back with minimal effort lost.
You have done some amazing work in the short time you have worked with Torque. You just need to slow down a bit and listen to the community more. There is a large group of us working together on the key issues that we have recognized over years of working in/with developers in this community (sometimes the most requested feature isn't the most needed feature *cough*mmo*cough*). Talk to us more and keep up the good work =)
05/05/2004 (8:31 am)
I would take the current show tool and do the following:- Clean up the gui (make it nicer looking and easier to use)
- Add a nicer file browser with the ability to browse anywhere
- Make it load one model at a time unless you select more than one in the file browser
- Make the camera control a bit more inuitive (orbit cam by default)
- Add support for more advanced ts features like emap
- Make the animation viewer simpler to use
- Tie a lot more of the configuration for the show tool into script (stuff like the background color)
- Toggle collision hulls rendering and maybe show a convexity analysis (like in my 3ds code)
- A hierarchy viewer would be really handy (sometimes the exporter does odd things). This would also allow people to show a snapshot of their in-game hierachy to other people to speed up debugging. Maybe even have a "Save to image" button on it.
- Mounting shapes to each other
- Improved lighting options
- A couple of model checker tools that look for common problems
- A tool to resize textures to the nearest power of 2 (I have code for this)
- A TSShapeConstructor script exporter
- Ability to preview interiors (and any other TGE file formats that can be directly loaded i.e. no scripts needed)
- Interiors: be sure to include the debug render views (like zone colors)
- Interiors: maybe include entity icons as well as toggle things like portal and detail brushes
- One thing the HL MDL Viewer does is allow you to change the texture/skin that is applied to the model and resave the model. Btw: the HL MDL Viewer is an excellent example of the a model viewer also.
Seriously, the less scripts loaded the better (aside from the editor's scripts). The less rendered the better. Why would you need to load the terrain? Why would you need to do actual collision (just seeing the hulls should be plenty)? *Nothing* about this tools should be tied to a specific game...even the stock ones that ship with the sdk.
Don't be shy about changing engine code. If you build a tool that works then it will become the "official" show tool and those changes will be added to the engine. For older codebases we can offer a stand-alone show tool (something I have long thought would be handy).
My recomendation is to take your time. Modify the existing show tool to include some of your improvements and to include features like Joe and other have mentioned. Show us incremental changes to the current show tool and when you deviate in a way the artists don't like then they can steer you back with minimal effort lost.
You have done some amazing work in the short time you have worked with Torque. You just need to slow down a bit and listen to the community more. There is a large group of us working together on the key issues that we have recognized over years of working in/with developers in this community (sometimes the most requested feature isn't the most needed feature *cough*mmo*cough*). Talk to us more and keep up the good work =)
#7
There is room for improvement, though, and previewing of mount nodes/collision meshes/etc would be pretty handy. Joe also had some neat ideas which he posted in the private forum version of this thread (now mostly dead, I think). Hopefully he or John will dredge them out here for y'all to poke at.
I have a lot of hope for this rewrite. If just stays on target with what the community needs, I think it will become a significant benefit to the community, both for the artists (better show tool) and the coders (cleaner code base). :)
05/05/2004 (8:32 am)
Just as an aside: from GG's perspective a new show tool would be good. The current one's code is kinda crusty and is giving us maintenance headaches in TSE. We don't want to significantly change what it does, though. It is a very good tool as is.There is room for improvement, though, and previewing of mount nodes/collision meshes/etc would be pretty handy. Joe also had some neat ideas which he posted in the private forum version of this thread (now mostly dead, I think). Hopefully he or John will dredge them out here for y'all to poke at.
I have a lot of hope for this rewrite. If just stays on target with what the community needs, I think it will become a significant benefit to the community, both for the artists (better show tool) and the coders (cleaner code base). :)
#8
Basically what I am saying is that the show tool has to "SHOW" all that I need meaning all the nodes, functionalities and visuals that the model will have in game. What I don't need is a game, I don't want to play I just want to look at my model as effectively as possible. I would pick, "quick, effective but not to good looking" over "jaw dropping but wait, wait I wanted to see that die anim again and I really don't have time to wait for the whole anim cycle" any time.
05/05/2004 (8:48 am)
Well basically i agree Paul although i must say that i don't care about some of the "HIGHER" level stuff being in there. I like to be able to have the same functionality in show as I would have in a game but I like to manually select what need, so I can evaluate all the separate parts, textures, shaders, animations, mounts or what ever when I want to so I can have a good look at them apart from all the other stuff around.Basically what I am saying is that the show tool has to "SHOW" all that I need meaning all the nodes, functionalities and visuals that the model will have in game. What I don't need is a game, I don't want to play I just want to look at my model as effectively as possible. I would pick, "quick, effective but not to good looking" over "jaw dropping but wait, wait I wanted to see that die anim again and I really don't have time to wait for the whole anim cycle" any time.
#9
My understanding of John's meaning of the mini-game was that it was actually scripted and uses the same structure and rendering pipeline as the games themselves.
I personally think that the show tool could make for a great example of people starting with torque as well as a good tool to take a look at your model. I also think the show tool should use the same rendering pipeline as the game itself.
I think that you should be able to play a specific animation or just run them all but colition detection may be a little over the top.
One thing that would be great for me is to be able to change the texture or add textures and resave the model inside the tool would be great.
In the original descussion about the new show tool there was a screen shot of a show tool that would be really nice.
Basically Matthew Fairfax did a great job listing what would be nice.
Ben
05/05/2004 (9:42 am)
Hello Everybody, My understanding of John's meaning of the mini-game was that it was actually scripted and uses the same structure and rendering pipeline as the games themselves.
I personally think that the show tool could make for a great example of people starting with torque as well as a good tool to take a look at your model. I also think the show tool should use the same rendering pipeline as the game itself.
I think that you should be able to play a specific animation or just run them all but colition detection may be a little over the top.
One thing that would be great for me is to be able to change the texture or add textures and resave the model inside the tool would be great.
In the original descussion about the new show tool there was a screen shot of a show tool that would be really nice.
Basically Matthew Fairfax did a great job listing what would be nice.
Ben
#10
* button and keybind for flushing the texture cache (in effect reloading the textures)
* turn off textures to see a polygon only version
* wireframe overlay on shaded model with solid wireframe colors
* faceted view of poly model
* one button toggle on/off 100% ambient lighting (good for checkign textures with no shading)
* Trackball directional lighting. Right now you can bring the lighting dialog and set the direction. I want this bound to a keypress and be able to trackball it around. If you let go, light will stick.
* Lighting presets.. ideally, being able to read any lighting settings from any of the .mis files in the game folder and possibly write them out as well. This way the artist can check the lighting as it would appear in a particular mission or in all the missions.
* Emaps.. make them work, also the ability to turn them on and off. also the ability to choose different emaps. nice if it was tied to the lighting presets so one could again check how it would look in game on any particular level.
* Mount an object to a mountpoint (gun, etc...) in a very direct way (no scripting to make it happen) pick a mount, mount shape from a picklist, pick node from picklist to use as mounted shape transform
* view nodes on models (mounts, other defined 'hidden' nodes), and a heriarchy view (skeletons) for node mounting and display, it would be nice to see axis markers tht use the XYZ-RGB coloring scheme.
* a window that will display the shape hierarchy
* turn on the bounding box and collision hulls (much like turning them on in game)- see matt's comments above. I would like to see this work so that you see the collision over the shape with the ghost red polygons (like what happens if you do the $gamebase::boundingbox=true; thing in game)
* change the background color of the showtool window dynamically with a color picker.
* a way to manually push the mip levels while the model is close up would be handy. Often times the mipping will exhibit artifacts on any seams. These can be noticed usually as discolored lines where a part of the texture map not on the model 'bleeds' into the seams when it mips down. You can see them when you zoom out in -show, but it would be better to be able to fix them when looking at the full size model and not one that is 20 pixels tall.
* TSE - button or keybind to re exec the shader scripts and reload the shader.
* ground plane with measurement grid (see danny's comments) preferable if this were see through or wire and not solid (need to be able to go under the model)
*keep the thread control window with all it has now
* move the trasition testing tools to the thread control main view
* extend the scrub bar in thread control..
* make it so you can quit without closing dialogs
05/05/2004 (9:53 am)
Here is my feature request list from the other thread.. with a few additions.* button and keybind for flushing the texture cache (in effect reloading the textures)
* turn off textures to see a polygon only version
* wireframe overlay on shaded model with solid wireframe colors
* faceted view of poly model
* one button toggle on/off 100% ambient lighting (good for checkign textures with no shading)
* Trackball directional lighting. Right now you can bring the lighting dialog and set the direction. I want this bound to a keypress and be able to trackball it around. If you let go, light will stick.
* Lighting presets.. ideally, being able to read any lighting settings from any of the .mis files in the game folder and possibly write them out as well. This way the artist can check the lighting as it would appear in a particular mission or in all the missions.
* Emaps.. make them work, also the ability to turn them on and off. also the ability to choose different emaps. nice if it was tied to the lighting presets so one could again check how it would look in game on any particular level.
* Mount an object to a mountpoint (gun, etc...) in a very direct way (no scripting to make it happen) pick a mount, mount shape from a picklist, pick node from picklist to use as mounted shape transform
* view nodes on models (mounts, other defined 'hidden' nodes), and a heriarchy view (skeletons) for node mounting and display, it would be nice to see axis markers tht use the XYZ-RGB coloring scheme.
* a window that will display the shape hierarchy
* turn on the bounding box and collision hulls (much like turning them on in game)- see matt's comments above. I would like to see this work so that you see the collision over the shape with the ghost red polygons (like what happens if you do the $gamebase::boundingbox=true; thing in game)
* change the background color of the showtool window dynamically with a color picker.
* a way to manually push the mip levels while the model is close up would be handy. Often times the mipping will exhibit artifacts on any seams. These can be noticed usually as discolored lines where a part of the texture map not on the model 'bleeds' into the seams when it mips down. You can see them when you zoom out in -show, but it would be better to be able to fix them when looking at the full size model and not one that is 20 pixels tall.
* TSE - button or keybind to re exec the shader scripts and reload the shader.
* ground plane with measurement grid (see danny's comments) preferable if this were see through or wire and not solid (need to be able to go under the model)
*keep the thread control window with all it has now
* move the trasition testing tools to the thread control main view
* extend the scrub bar in thread control..
* make it so you can quit without closing dialogs
#11
05/05/2004 (10:37 am)
I think that the show tool is probably not a good tutorial item. It's fairly complex and it needs to work directly with the 3space library in a lot of ways that people are unlikely to need for their game (how many people need to render collision meshes?). It might be nice to have documentation for it but it's more important that it works and works well than that it's 100% clear and easy to follow the code.
#12
Super useful for the animators would be a mode where you turn on the skeleton, and it becomes visible. Selecting any sequqnce from the sequence list in the thread control would highlight the nodes that any particular sequence effects. It would also be nice to know if the sequence was a normal sequence or a blend, the sampel rate it was exported at, what paraemeters it was exporter with (ifl On visibility on, etc..) in some sort of inspector. Thsi would help as one could debug model by looking at the model and not have to get the scene or pick through someones dump file.
05/05/2004 (11:30 am)
Another thoughtSuper useful for the animators would be a mode where you turn on the skeleton, and it becomes visible. Selecting any sequqnce from the sequence list in the thread control would highlight the nodes that any particular sequence effects. It would also be nice to know if the sequence was a normal sequence or a blend, the sampel rate it was exported at, what paraemeters it was exporter with (ifl On visibility on, etc..) in some sort of inspector. Thsi would help as one could debug model by looking at the model and not have to get the scene or pick through someones dump file.
#13
*Ability to reload textures (with one click on the main screen.)
*Ability to reload the current model (again, with one click.)
*Ability to reload the currently playing animation (again, with one click.)
*Ability to control the placement of multiple models.
*Ability to switch the focus between multiple models (a model list).
*The mount point stuff mentioned above.
*A function that watches the currently loaded files, so when there are changes to the file, it automatically reloads it.
Current showtool workflow: Edit model in 3d application (Max, Maya, Milkshape) when the model starts to look good you export the model. Then you launch the showtool (wait for it to load). Click a button and scroll through a list of models, select the model you want and load it. Then zoom in to the model and check how it will look in game. Go back to 3d app, make changes, export, relaunch showtool.... etc...
Showtool workflow to improve artist productivity: Have the showtool open on one monitor with the model I'm currently working on displayed. On my other monitor I have my 3d App. When I hit export, the model in the ShowTool updates so I can see the current version. I continue to work in my 3d app and make adjustments. Export, see changes, repeat.
Decreasing the amount of time it takes to get feedback makes artists work faster. Working faster means better art, since more time can be spent making small tweaks and changes, instead of waiting for the showtool to load.
I don't need a minigame to run my model through all it's paces, since I'm only working on one animation at a time. I'd like to just have my animation playing, with my model walking (or running, sidestepping, or whatever I'm working on) in place. Then export and see changes immediately.
05/05/2004 (11:35 am)
Another Artist's perspective (starting with the current show tool), things that would improve workflow and increase productivity:*Ability to reload textures (with one click on the main screen.)
*Ability to reload the current model (again, with one click.)
*Ability to reload the currently playing animation (again, with one click.)
*Ability to control the placement of multiple models.
*Ability to switch the focus between multiple models (a model list).
*The mount point stuff mentioned above.
*A function that watches the currently loaded files, so when there are changes to the file, it automatically reloads it.
Current showtool workflow: Edit model in 3d application (Max, Maya, Milkshape) when the model starts to look good you export the model. Then you launch the showtool (wait for it to load). Click a button and scroll through a list of models, select the model you want and load it. Then zoom in to the model and check how it will look in game. Go back to 3d app, make changes, export, relaunch showtool.... etc...
Showtool workflow to improve artist productivity: Have the showtool open on one monitor with the model I'm currently working on displayed. On my other monitor I have my 3d App. When I hit export, the model in the ShowTool updates so I can see the current version. I continue to work in my 3d app and make adjustments. Export, see changes, repeat.
Decreasing the amount of time it takes to get feedback makes artists work faster. Working faster means better art, since more time can be spent making small tweaks and changes, instead of waiting for the showtool to load.
I don't need a minigame to run my model through all it's paces, since I'm only working on one animation at a time. I'd like to just have my animation playing, with my model walking (or running, sidestepping, or whatever I'm working on) in place. Then export and see changes immediately.
#14
This approach would be entirely inadequate for checking characters (not to mention annoying as hell).
Additionally, as I use the show tool a lot, and use the game a s afinal testing step, loading the tool and then pressing another button to get into the mode I would be using 95% of the time would be really, really bothersome. Seems that that approach is a bit backward.
05/05/2004 (11:37 am)
Quote: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
This approach would be entirely inadequate for checking characters (not to mention annoying as hell).
Additionally, as I use the show tool a lot, and use the game a s afinal testing step, loading the tool and then pressing another button to get into the mode I would be using 95% of the time would be really, really bothersome. Seems that that approach is a bit backward.
#15
Ideally i'd still like to build the tool in this manner unless someone can give me a good reason not to. That doesn't mean I can't use a direct 3space interface. I still can and from the input given here I guess I will have to now :) It just makes it a few thousand times easier to add in some of the extra features that are requested if I do it this way.
Anyway, i'm home from work now and battling a nasty cold but i'm going to go through everything that has been posted so far and work out a feature list then i'll post that.
05/05/2004 (1:42 pm)
I want to clarify something. When I say "mini-game" that's just my way of describing it. It isn't actually a mini-game. What I mean byt that is that the tool loads a mission to put the model into. Why? Because it allows a lot more power. It makes it much much easier for me to do things like e-maps for example. As long as it happens fast, I don't neccesarily see why loading the shape into a mission is a BAD thing, though I might be missing something.Ideally i'd still like to build the tool in this manner unless someone can give me a good reason not to. That doesn't mean I can't use a direct 3space interface. I still can and from the input given here I guess I will have to now :) It just makes it a few thousand times easier to add in some of the extra features that are requested if I do it this way.
Anyway, i'm home from work now and battling a nasty cold but i'm going to go through everything that has been posted so far and work out a feature list then i'll post that.
#16
I think that the idea of loading stuff in a mission is good. It makes stuff a lot more consistent. But you're probably going to get a lot of pushback (and rightly so in my opinion) if you move away from the existing "shape in blank space" sort of interface. The artists aren't protesting that code (ie, that of having the mission based loading) so much as the implications (not having quick access to the powerful sort of 3space manipulation that show currently provides).
Hope you feel better! It's always hard to do productive work when you're sick.
Ben
05/05/2004 (1:52 pm)
John,I think that the idea of loading stuff in a mission is good. It makes stuff a lot more consistent. But you're probably going to get a lot of pushback (and rightly so in my opinion) if you move away from the existing "shape in blank space" sort of interface. The artists aren't protesting that code (ie, that of having the mission based loading) so much as the implications (not having quick access to the powerful sort of 3space manipulation that show currently provides).
Hope you feel better! It's always hard to do productive work when you're sick.
Ben
#17
In certain cases, it would be useful to have a grid, and alphad floor plane, and a solid floor plane, but I would not want them there by default.
05/05/2004 (1:53 pm)
As long as the mission contains nothing, no sky, no terrain, by default, and it loads as fast as it does now, I don't see a problem with it.In certain cases, it would be useful to have a grid, and alphad floor plane, and a solid floor plane, but I would not want them there by default.
#18
05/05/2004 (1:54 pm)
John - it seems like the best way to deal with this problem might be to implement a ShowObject in C++ and then build the app/mission around that. If you want any help doing that, let me know. I'm sure that we could blow through it in a few days (especially since I can pester Clark ;).
#19
Perhaps by default there is no terrain and no sky, but you can load either or both as you see fit.
I still plan to have that direct to 3space interface, just inside the mission :)
After dinner i'll hammer out a starting direction.
05/05/2004 (2:45 pm)
Well if you have no sky you don't have emaps. Loading different skys would allow you to see how your emaps respond.Perhaps by default there is no terrain and no sky, but you can load either or both as you see fit.
Quote:The artists aren't protesting that code (ie, that of having the mission based loading) so much as the implications (not having quick access to the powerful sort of 3space manipulation that show currently provides).
I still plan to have that direct to 3space interface, just inside the mission :)
After dinner i'll hammer out a starting direction.
#20
Before the path changes in the TGE were done, emaps worked fine in the showtool with no sky. But if you say it cannot be done, I will take your word for it.
05/05/2004 (2:48 pm)
Quote:Well if you have no sky you don't have emaps
Before the path changes in the TGE were done, emaps worked fine in the showtool with no sky. But if you say it cannot be done, I will take your word for it.
Torque Owner Pascal Bos
Do give us a feature list, i'm very intrested in this project. The show tool works ok but i'm sure you can get much more out of a tool like that especially with all the new stuf comming.