Show Tool v2 - Request for Comments

#21

Quote: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.

Hmm.. I coulda sworn when I was lookign through things that it seemed the model got its emap settings from the loaded sky, but i'm not god :)

It is however MUCH easier lol. Its automaticly done if you load a sky. I'll have to dig a bit on this issue.

#22 The old version would look for a map called emap. We used to have to copy/paste it from one of the sky images in the mission into the image and it worked fine. It would be nice to be able to pick which emap you wanted (from a mission) but it would be preferable (to me and many others) for there to be no sky displayed in the tool (unless someone chooses to have it)

Note that the TSE has one define a cubemap reflection in a datablock (at least it was like this for the stuff I was working on) With the TSE there will be both dynamic environmental reflection and predefined cube maps. Not 100% sure on how this will end up working with the showtool, but care should be taken that this is implemented in such a way that it is not going to be non-comaptible with TSE. Maybe Ben or Brain would want to comment on this.

#23 I'm workign off of guesswork when it comes to trying to make it future compatible with TSE :)

Just for my own education, why is it that you DON'T want a sky/groundplane?

#24 When I am looking at a model, I am looking at the model. I am looking for seams where textures don't match up, shading glitches, watching animations loop looking for pops, etc..

The ground and sky are visially distracting and make it more difficult to do this.

It would be like asking someone why they want to work in an text editor that has a blank background instead of one that has an image on it. Most people like typing on blank pages..

#25 Cool ok I see. Thanks for that. I'm a coder not an artist so its tough sometimes lol.

#26 Re: designing with TSE in mind and guesswork. John, feel free to email us any time with questions. If you have not signed an NDA yet, you may have to, but we would very much like to coordinate with you on this.

#27 John,

Remember, we're willing to work with you on code changes if you're meeting the needs of the artists. I think that a custom ShowObject would get its data from where-ever you specified, not from the Sky, so the Sky would be unnecessary.

Or perhaps a ShowSky subclass could solve the problem.

If you have questions about valid architecture choices for a showtool, feel free to contact me. In addition, since Joe is right down the hall from me, feel free to contact me if you have trouble understanding the irrational demands of the artists. ;) I can help bridge the communication gap.

Ben

#28

Quote:In addition, since Joe is right down the hall from me, feel free to contact me if you have trouble understanding the irrational demands of the artists. ;) I can help bridge the communication gap.

lol

My main concern on things liek the sky is that my understanding of Torque is obviously not 100%, so there are things where I can do them by the way I was originally thinking, but I may not know how to get them woekring by rerouting things in Torque. I'll have to lean on you for that stuff :)

#29 Indeed it does look like the way to go is to build a new C++ class to handle all of this, and then hook into it for flexability and customization.

So i'll be lyaing out the framework tomorrow, and hopefully get that released tomorrow as well so you all can see if i'm going in the right direction.

#30 Okay, a lot of this will be redundant with what others have said - here is a checklist of what I would view as highly useful:

-ability to work at above 800x600 (I change this by hand in the GUI editor everytime I launch a new copy of the showtool currently... should probably just be in there by default)
-Ability to Mount shapes and view mount points
-View Collision / LOS meshes
-View Bones, see what bone nodes are effected when previewing animations
-Load/display env.maps and various lighting values (by hand or autoload from a mission)
-easier control of lighting direction (especially when we are working more w/ normal maps)
-toggle 100% ambient w/out screwing up current light settings
-Scale reference grid toggle
-texture/model reload (perhaps check for changed files whenever the ap regains focus?)
-preview of interiors (support existing debug render modes, flat render, render without lightmaps or with lightmaps only)
-customize background color
-better/working thread playback controls
-claim ownership of .dts/.dif files on all OSes, and launch/load a DTS file when it is doubleclicked in the finder/explorer/window manager
-only loads one model at a time unless multiple models are specifically chosen
?ability to choose new skins for currently loaded model

Things about the current showtool that I like
-launches FAST
-has a clear purpose, and does that job well - shows DTS models

I do not necessarilly think that it would be bad to make it use the regular Torque codebase for rendering, etc, but I do think that it would be a mistake to succumb to extraneous feature creep. I don't need my email client to be a spreadsheet editor. While it might occasionally be handy, the effect it would have on the useability and speed of my email client would be counterproductive.

I think that most of the features I listed above still fall in the "examining the DTS model" functionality goal. - basically the tool should work equally well for any DTS or DIF model for any game, and should be in no way reliant or tied to any game specific features (physics tests, player control of characters, etc) Testing of those things should happen in-game, or in a custom utility tailored to a specific game.

Edit: I do think that a "play all animation threads" button could be a useful feature. It would be nice to sit back and watch the model go through all animations without having to click from one to the next. However, it is certainly not a major requirement, and I would rank many of the features listed above as much more useful.

#31

Quote: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.

Quote:
When I am looking at a model, I am looking at the model. I am looking for seams where textures don't match up, shading glitches, watching animations loop looking for pops, etc..

The ground and sky are visially distracting and make it more difficult to do this.

It would be like asking someone why they want to work in an text editor that has a blank background instead of one that has an image on it. Most people like typing on blank pages..

I apologize ahead of time for loss of quote attribution, but these two quotes point out an underlying fundamental aspect of a tool that you seem to be describing...

--who says we are using the "mission" aspect of Torque?
--who says that the "expected" (from a tool developer's standpoint) environmental characteristics apply?

My team is making a (gasp!) MMPIE (Massively Multiplayer Persistant Interactive Environment)--something that is somewhat rare in the community. The concept of "missions" has been entirely ripped out of the core functionality. We may not even -have- skyboxes in certain situations, so any assumptions in parallel to a "skybox" that a tool like this would make are fundamentally too restrictive. I think it's a great project, but define the core, fundamental characteristics, and leave it at that level. Once you start making assumptions about the developer's environment/goals, and therefore forcing scenarios upon them, the tool becomes much less useful.

#32 Hello Everybody,

Sounds like it will be a great tool when its finished. Good luck John. One thing that would be interesting is to be able to control the speed of the animation playback.

Ben

#33 @Stephen you're beating a dead horse. We've already worked that part out lol.

@Ben Woodhead, i'll look into that but i'm not sure Torque is designed to have variable speed animations. I've never looked before but it isn't exposed to scrpit which makes me think it isn't designed to do it.

#34 In the existing show tool, you can press the 'edit scale' button in thread control, and change he time scale. This will control the speed of the animation. You can also hit the stop button and use the scrub bar in thread control to scrub through the animation (although I am not sure if this is working i the latest head, it was broken for a while, and is an easy fix)

Also note that in the player animations, you can have them use or ignore ground transforms. If it ignores them, the animation runs at full speed. If you use them, the aniamtion is scaled to match the speed set in the player.cs, sped up or slowed down, so the feet stick to the ground.

On that note, it would be better to make this interface a lot more like the standard controls in 3d apps with a start, stop, play pause button, and to make it so the scrub bar can be grabbed at any time during the animation and it would stop the animation and change to 'scrub' mode. It would also be great to have the scrub bar larger. As it is now, it is very small, and it would be nice to have it use a standrad 3d app interface (take a look at how 3dsmax, maya, lightwave, etc.. do it)

#35 John- I think it would be wise for you to go through the existing showtool and look at the functionality is there, and try to figure out what it does, why it is there, and how it is used by the artist to test shapes..

I use just about everything in the showtool, and I can try my best to explain how it is used by the artists to test shapes, what the issues with it are, and what might be an improvment. Particularly important is the thread control window and the transtion sub window that you can launch out of the thread control.

#36 One additional idea I would put, is to use the same camera control interface as in max/maya etc.

I.e. ctrl alt modifiers and being able to select and object and rotate round relative to it with the mouse etc.

Forgive me if thats already in there.. never seems to work right for me at least :)

#37 One interesting thing to think about:

The show tool is more than a model viewer. It is also a model verifier and a model debugger. This is a very important distinction. It makes a lot of sense to have a viewer show the model like it would be "in-game" (your first approach).

I would model the show tool as a stand-alone app that will be compatible with *any* TGE game with unaltered dts and dif file formats. This will keep you clear of extraneous game logic creeping into the code.

This is a big project with a lot of featurelist items. Rather daunting for a single person. If you continue to show that you are willing to work with the community then I am sure more people would be willing to lend a hand =)

#38 There is still one thing that conerns me about the direction we're going vs the direction I was originally going.

The argument for the original show tool implementation, the direct to 3space method, is tha it allows you to seperate problems with models from problems with game code. Presumably if a model works in the show tool but not in game then it is game logic causing the problem and the model is good. However if the model does not work in the show tool then because show tool uses a direct 3space interface the problem must lie in the model itself. Correct?

Then I think to the issue Ori Cohen had with a model. It worked fine in the Show Tool but barfed when brought in game. According to the above logic, then the problem must lie in the game logic. But it didn't. In fact the problem was indeed the model. It was abug in the exporter that caused a malformed model. However the show tool didn't catch this or have any problems. Why? Because of the fact that it used that direct 3space connection. In this case it hurt it. By using this direct 3space interface, the show tool either rewrites existing Torque code or simply doesn't use that feature. In the case of this model, the Torque rendering code's built in checks noticed the problem with the model, whereas the show tool by bypassing everything did not.

I'm concerned that by going the same direct to 3space route, we're simply retaining the same exact problem that is going to occur again and again in the future.

There has to be some line we can walk that allows us to use Torque engine code so that things like the above will get noticed, without ending up game specific which is something we need to avoid. I thought I was goign that route before but no one felt so.

So i'd like to hear some suggestions on this issue before I get too deep in rewriting things as a direct to 3space interface.

#39 Ok this is what i'm thinking.

Create a new C++ object, something like ShowShape, or whatever. This would be a static shape class which worked tightly with 3space thereby eliminating the "game assumptions" which are the issue when using existing shape classes, yet at the same time it would allow the Torque framework to be used for things like rendering.

#40 edit:

Hope the following makes sense, if not.. let me know and I will try to explain more.

end edit

In the instance of Ori's model, it worked in the showtool.. it should have worked in the game. When thrown in the game, it barfed. There was something in the shadow rendering code that did not like this model. By all appearances, the model was built correctly, so we looked into the exporter to see what it was spitting out and what exactly the game code was barfing on.

This problem did not hurt the testing process.. it actually helped a great deal. The model was exported and looked just fine in -show.. it crashed in game. The model, as far as player models go, looked fine. Nothing strange about it at all. It should have worked. It did not.

That is not normal and got our attention enough to look deeper. It was an exporter bug, not a modeler error, so this particualr instance is not really a good example. The exporter in question (maya) is in beta.

Now, people are trying stuff all the time with the 3d apps. I often look at people scene files and say.. WTF? how did you build this? the exporters may have bugs... and eventualluy they will be found. Not every possible thing that people CAN do has been tried.

WIth the tool we have now, at least an artist can get far enough to have it export and show up. If it shows up, and still crashes.. it is casue to look deeper into either the rendering code or the exporter.. These cases are very rare indeed and there is a very clear signal, and that is.. all the normal avenues of exploration have been checked, all looked fine, and the crash is occuring in either the rendering or collision code.
Now, in other situations, the most normal 'crash in game but not in -show' scenario, is when a model loads with NO animations, and the game crashes (it expects at least 1). If the model loads in show with no animations, then it is either a problem with the model, or a problem with the script that assembles the animations and the model into one shape (my experience says 75% of th etime). If it works in -show, it is a problem with the game script (most usually a bad path to the image file, or a bad bitmap resource in the footprint or footpuffs particle emitter, and this is about 20% of the time) in player.cs.

In normal circumstances, the line is drawn there.. if the animations load in show, and not in game, it is a game script issue. If no animations load in -show, it is a model issue or an issue with one or several of the animations or the script file that assembles them.

People need to check to see if it is one or the other. I consider the 'anims not loading in show' to be a modeler fix, and the 'works in show but not in game' a coder/scripter fix as it is either game code or exporter code and rarely, a model issue. If it is a model issue, it is usually esaily idenitifed ..(oh, the code is looking for mountNode foofoo and is not finding it) but it still takes a coder to look in the debugger to see what it is choking on.