Re-writing the "Show Tool"
by John Vanderbeck · in Torque Game Engine · 04/16/2004 (11:22 am) · 32 replies
Disclaimer: Bear with me as this post may drift a bit here and there, as I just got off the can (My best thinking place!) and my thoughts aren't all that collected.
I was scamnning through the Project Manager for Torque to see if there was any bugs/tasks that I could pick up to help the engine out a bit, and would be something i'd have to do eventually for Mayhem 2090 anyways. I found an entry about environment mapping in the show tool, and since we make extensive use of that tool I figured i'd pick that up. I've felt that my understanding of the engine has matrued quite well as of late and I shouldn't have any great difficulties doing this.
So I started digging around in the show tool script code to get a feel for how it worked. I expected it was pretty much just a "mini-game" and would use the basic interface and features that any script side game would use. Made sense.
What I found was defintly not what i'd expected. In fact the Show Tool has pretty much nothing in common with a Torque game. It is really a huge sidetep AROUND that standard interface, using C++ side hooks to bypass the whole "game" interface and directly load and render shapes.
This isn't neccesarily "BAD" it just isn't what I expected. It is essentially a completely seperate program of its own with no relation to a Torque Game.
As I said, this isn't neccesarily bad, but it seems to me that if the Show Tool was in fact a "mini-game" meaning it used the exact same interface a regular Torque game would use, that it would be ab;e to more easily take advantage of everything the user's game might such as shadows, mapping, special whoozits, whatever. Automaticly.
I'd like to see what other peopel think about this. What i'm doing is volunteering my time to write a completely new Show Tool along this concept. It would basically use the exact same interface as a Torque Game, though it would still only be a shape viewer. It wouldn't "be" a game, just use the same concepts. I'd like to expand it a bit anyhow for our own uses, so might as well do it right. This way I can make it do DTS, DIF, 3DS, whatever the engine supports for in games. Shadows, environment mappings, Collision (This was a beef about the Show Tool for me.. no way for our modellers to easily test collision outside of the game itself), etc, etc. It would also be pretty easy to expand this once TSE is out to support not only viewing Shaders, but applying them as well (Since TSE claims to allow shader effects to be applied via script, this re-written Show Tool could easily be used to apply script shader effects to see how they look.
So i'm volunteering my time and skills to do this, what do you all think?
I was scamnning through the Project Manager for Torque to see if there was any bugs/tasks that I could pick up to help the engine out a bit, and would be something i'd have to do eventually for Mayhem 2090 anyways. I found an entry about environment mapping in the show tool, and since we make extensive use of that tool I figured i'd pick that up. I've felt that my understanding of the engine has matrued quite well as of late and I shouldn't have any great difficulties doing this.
So I started digging around in the show tool script code to get a feel for how it worked. I expected it was pretty much just a "mini-game" and would use the basic interface and features that any script side game would use. Made sense.
What I found was defintly not what i'd expected. In fact the Show Tool has pretty much nothing in common with a Torque game. It is really a huge sidetep AROUND that standard interface, using C++ side hooks to bypass the whole "game" interface and directly load and render shapes.
This isn't neccesarily "BAD" it just isn't what I expected. It is essentially a completely seperate program of its own with no relation to a Torque Game.
As I said, this isn't neccesarily bad, but it seems to me that if the Show Tool was in fact a "mini-game" meaning it used the exact same interface a regular Torque game would use, that it would be ab;e to more easily take advantage of everything the user's game might such as shadows, mapping, special whoozits, whatever. Automaticly.
I'd like to see what other peopel think about this. What i'm doing is volunteering my time to write a completely new Show Tool along this concept. It would basically use the exact same interface as a Torque Game, though it would still only be a shape viewer. It wouldn't "be" a game, just use the same concepts. I'd like to expand it a bit anyhow for our own uses, so might as well do it right. This way I can make it do DTS, DIF, 3DS, whatever the engine supports for in games. Shadows, environment mappings, Collision (This was a beef about the Show Tool for me.. no way for our modellers to easily test collision outside of the game itself), etc, etc. It would also be pretty easy to expand this once TSE is out to support not only viewing Shaders, but applying them as well (Since TSE claims to allow shader effects to be applied via script, this re-written Show Tool could easily be used to apply script shader effects to see how they look.
So i'm volunteering my time and skills to do this, what do you all think?
#2
04/16/2004 (11:57 am)
A rewrite of the Show Tool would be great. I'd just like to see it act more like a mini game. I had to convolute some shader initilization code to get the Show Tool going for TSE. A more modular design would be nice as well since there's a bunch of stuff all crammed into showTSShape.
#3
Anyway. Basically with my proposal, the show tool when I was done would support everything a DTS or DIF supports in an actual game, short of dynamic scrpipted behaviour (And heck I could even add in support for basic scrpited objects for testing purposes..wouldn't be that hard).
To make a simple list:
DTS Objects
DIF Objects
Custom Objects coded into the C++ side (such as Matthew's 3DS) Essentially anything supported by the engine and transparent to the scrpit interface
Shadowing
Collision
Environment Maps
Some things that could be done to improve the tool (above what the rewrite would automaticly improve as listed above):
Basic script support for dynamic object behaviour..Easy to test out that water fountain for example
Shader effects when TSE is out..be easy to allow veiwing and application of various scrpit based shaders
Debug rendering such as bounding volumes, collision volumes, etc
More flexible camera and object control
Those are just off the top of my head. I'll run this by my artists and see if they have any requests for the show tool. As i'm no artist myself, i'm sure others in the community that are have some ideas.
04/16/2004 (12:00 pm)
Oh god don't get me started on the crap that is Deep Exploration.Anyway. Basically with my proposal, the show tool when I was done would support everything a DTS or DIF supports in an actual game, short of dynamic scrpipted behaviour (And heck I could even add in support for basic scrpited objects for testing purposes..wouldn't be that hard).
To make a simple list:
DTS Objects
DIF Objects
Custom Objects coded into the C++ side (such as Matthew's 3DS) Essentially anything supported by the engine and transparent to the scrpit interface
Shadowing
Collision
Environment Maps
Some things that could be done to improve the tool (above what the rewrite would automaticly improve as listed above):
Basic script support for dynamic object behaviour..Easy to test out that water fountain for example
Shader effects when TSE is out..be easy to allow veiwing and application of various scrpit based shaders
Debug rendering such as bounding volumes, collision volumes, etc
More flexible camera and object control
Those are just off the top of my head. I'll run this by my artists and see if they have any requests for the show tool. As i'm no artist myself, i'm sure others in the community that are have some ideas.
#4
You hit the nail on the head. Basically thats exactly what I was planning to do.
Sounds like my idea has merit after all so i'm goign to start laying the groundwork and get this thing rolling.
04/16/2004 (12:01 pm)
@BrianYou hit the nail on the head. Basically thats exactly what I was planning to do.
Sounds like my idea has merit after all so i'm goign to start laying the groundwork and get this thing rolling.
#6
04/16/2004 (2:18 pm)
Can you elaborate on Skybox Harold? Are you talking somethign special, or just that is uses a skybox which I already have planned.
#7
04/16/2004 (3:03 pm)
Just that it can have the skybox set.
#8
Also will have the ability to use terrain.
04/16/2004 (3:15 pm)
Ok, yeah defintly will have that ability. Also will have the ability to use terrain.
#9
The show tool loads fast, and it has what it needs for me to check artwork. I would like the ability to see emaps (and choose them), and mount weapons, but right now, I like the fact that it loads the shape, and if the shape is solid, it will work.
I would not want to see this tool get so intertwined with the engine that it shares some of the same script dependenecies with the engine that can cause shapes not to work and make it more difficult to determine whether a bug is art or code related.
04/16/2004 (3:29 pm)
I think all of this is great.. and I am all for it, but I suggest soem restraint be taken in order to make sure that it does not go so feature laden that it becomes ' heavy' and less useful to the end user.The show tool loads fast, and it has what it needs for me to check artwork. I would like the ability to see emaps (and choose them), and mount weapons, but right now, I like the fact that it loads the shape, and if the shape is solid, it will work.
I would not want to see this tool get so intertwined with the engine that it shares some of the same script dependenecies with the engine that can cause shapes not to work and make it more difficult to determine whether a bug is art or code related.
#10
I'm not planning to feature bloat the tool, simply make it more consistant with a normal game, and add in some features that are lacking such as environment maps, skyboxes, shadows, collion, etc.
04/16/2004 (3:54 pm)
Actually Joe the re-write will make it better to determine if the problem is a code issue or art issue. As it is now, since the Show Tool uses a completely seperate method of loading and displaying a shape, it is quite possible to have a shape that will work in one and fail in the other.I'm not planning to feature bloat the tool, simply make it more consistant with a normal game, and add in some features that are lacking such as environment maps, skyboxes, shadows, collion, etc.
#11
04/16/2004 (5:11 pm)
I would err on the side of minimalism for the show tool. Make it easy for people to extend; it doesn't need to be a be-all end-all out of the box. Especially since a lot of people like Joe really want a lightweight tool for model previewing.
#12
I think you guys will be pleased with what I release. I've already laid the basics, and its shaping up well.
04/16/2004 (5:17 pm)
Have faith :)I think you guys will be pleased with what I release. I've already laid the basics, and its shaping up well.
#13
04/16/2004 (7:44 pm)
Glad to hear, John. 
#14
Is this sort-of what you're after?
It allows you to load in any number of DTS objects into layers, and mount any of them to any node in the current layer. You may also watch the animation sequences and view material properties.
It was the beginnings of a commercial DTS Exporter intended to load in a number of file formats. It currently loads the OBJ file format for conversion as a DTS. But, with all of the great native 3D-app DTS exporters floating around now, I've shelved the project for now. It has been quite useful in debugging my own LightWave exporter as of late...
- LightWave Dave
04/16/2004 (8:00 pm)
Greetings!Is this sort-of what you're after?
It allows you to load in any number of DTS objects into layers, and mount any of them to any node in the current layer. You may also watch the animation sequences and view material properties.
It was the beginnings of a commercial DTS Exporter intended to load in a number of file formats. It currently loads the OBJ file format for conversion as a DTS. But, with all of the great native 3D-app DTS exporters floating around now, I've shelved the project for now. It has been quite useful in debugging my own LightWave exporter as of late...
- LightWave Dave
#15
That does look cool though :p
04/16/2004 (8:04 pm)
Not really what I personally had in mind, no. I'm looking at simply an upgrade to the Show Tool to make it more feature complete and consistent with the engine's interface.That does look cool though :p
#16
04/16/2004 (9:06 pm)
Is that in Torque, John? That looks really nice!
#17
If you're referring to my picture above, yup, it's Torque! :o)
- LightWave Dave
04/17/2004 (5:16 am)
Ben,If you're referring to my picture above, yup, it's Torque! :o)
- LightWave Dave
#18
And good luck to John, looking forward to seeing a more game-like ShowTool.
04/17/2004 (5:37 am)
Nice Dave!And good luck to John, looking forward to seeing a more game-like ShowTool.
#19
04/17/2004 (5:37 am)
Hehe.. I think Ben was up past his bedtime last night. David I love the look of that interface. Could I maybe convince you to let me use your GUI profiles?
#20
To achieve my GUI, I had to modify the rendering code. So, my profiles won't actually work with standard Torque.
I will, however, release a bug fix for the drop-down lists. The one in the TGE is just wrong at times...
- LightWave Dave
04/19/2004 (7:30 am)
John,To achieve my GUI, I had to modify the rendering code. So, my profiles won't actually work with standard Torque.
I will, however, release a bug fix for the drop-down lists. The one in the TGE is just wrong at times...
- LightWave Dave
Associate Matt Fairfax
PopCap
I guess the question at hand is what would be "more useful"? What are some of the features/wishes that people would want to see?
I have been playing around with Deep Exporation a lot lately and could see something along those lines with a few more handy game specific tools (you mentioned collision).