New player.dts works in showtool but not in game
by Ori Cohen · in Torque Game Engine · 04/26/2004 (6:26 am) · 37 replies
I imported a new model instead of the orc, it works perfectly in the showtool.
but in torque it crashed on 2 occasions in BOLD:
1. when i am close to a static object "unhandled exception in function "rendershadow"
2. when i am close to an npc (which is the same model as me) "access violation in void TSShapeInstance::animate(S32 dl) in line 834: U32 dirtyFlags = mDirtyFlags[ss];
**** a small update, when i play the real orc, elf or Fman nothing like this happens
another update 27.4.2004
using john's showtool v.2 i was able to get a new set of errors.. anyone can share a light on the subject ?
Loading compiled script show2/client/GenericPlayerDatablock.cs.
Validation required for shape: kq9/data/shapes/kq9/player/player.dts
Could not locate texture:
Could not register dust emitter for class: GenericPlayer
Could not register dust emitter for class: GenericPlayer
Could not register dust emitter for class: GenericPlayer
Fatal: (f:\torque\torque.16.04.2004\engine\ts\tsshapeinstance.cc @ 1582) TSShapeInstance::renderShadow
but in torque it crashed on 2 occasions in BOLD:
1. when i am close to a static object "unhandled exception in function "rendershadow"
void TSShapeInstance::renderShadow(S32 dl, const MatrixF & mat, S32 dim, U32 * bits)
{
// if dl==-1, nothing to do
if (dl==-1)
return;
[b] AssertFatal(dl>=0 && dl<mShape->details.size(),"TSShapeInstance::renderShadow");[/b]2. when i am close to an npc (which is the same model as me) "access violation in void TSShapeInstance::animate(S32 dl) in line 834: U32 dirtyFlags = mDirtyFlags[ss];
void TSShapeInstance::animate(S32 dl)
{
if (dl==-1)
// nothing to do
return;
S32 ss = mShape->details[dl].subShapeNum;
// this is a billboard detail...
if (ss<0)
return;
[b] U32 dirtyFlags = mDirtyFlags[ss];[/b]**** a small update, when i play the real orc, elf or Fman nothing like this happens
another update 27.4.2004
using john's showtool v.2 i was able to get a new set of errors.. anyone can share a light on the subject ?
Loading compiled script show2/client/GenericPlayerDatablock.cs.
Validation required for shape: kq9/data/shapes/kq9/player/player.dts
Could not locate texture:
Could not register dust emitter for class: GenericPlayer
Could not register dust emitter for class: GenericPlayer
Could not register dust emitter for class: GenericPlayer
Fatal: (f:\torque\torque.16.04.2004\engine\ts\tsshapeinstance.cc @ 1582) TSShapeInstance::renderShadow
#2
Sorry that doesn't help much, but once the new tool is out at least you won't be tearing your hair out saying "But it works fine in show tool!".
04/26/2004 (6:41 am)
This is one main reason i'm making this new show tool. The existing Show Tool uses a completely seperate interface from what a standard game uses, so its quite possible for there to be discrepancies between the two.Sorry that doesn't help much, but once the new tool is out at least you won't be tearing your hair out saying "But it works fine in show tool!".
#4
is there some working version of your showtool ? i would like to try it out on my model.
maybe it can give me a whole new direction, and help you with your project.
my model is made of 1 dts and 30 dsq's
04/26/2004 (6:51 am)
John,is there some working version of your showtool ? i would like to try it out on my model.
maybe it can give me a whole new direction, and help you with your project.
my model is made of 1 dts and 30 dsq's
#5
04/26/2004 (7:12 am)
I'm actually about to release the first alpha. It isn't complete by any means, but the basica re there. You can load a DTS and play animations.
#6
not to be rude and all, any chance i can prealpha it. maybe today?
this is simply annoying, and i cant do anything about it.
04/26/2004 (7:16 am)
John, not to be rude and all, any chance i can prealpha it. maybe today?
this is simply annoying, and i cant do anything about it.
#7
I am a little confused.. how is this going to make it better? Not trying to be antagonistic, just not understanding the logic. When a shape works in the -showtool.. but not in game, we know that the problem is most likely somewhere in the game code that does not exist in the showtool. This allows us to isolate very quickly where the problem might be.
I am not getting how integrating the two is going to help. Particularly in this instance, it seems that this problem instead of crashing the game and not the showtool, would instead now crash the game and the showtool. I fail to see how this is an improvement.
I am probably missing something here..
04/26/2004 (7:45 am)
Quote:This is one main reason i'm making this new show tool. The existing Show Tool uses a completely seperate interface from what a standard game uses, so its quite possible for there to be discrepancies between the two.
Sorry that doesn't help much, but once the new tool is out at least you won't be tearing your hair out saying "But it works fine in show tool!".
I am a little confused.. how is this going to make it better? Not trying to be antagonistic, just not understanding the logic. When a shape works in the -showtool.. but not in game, we know that the problem is most likely somewhere in the game code that does not exist in the showtool. This allows us to isolate very quickly where the problem might be.
I am not getting how integrating the two is going to help. Particularly in this instance, it seems that this problem instead of crashing the game and not the showtool, would instead now crash the game and the showtool. I fail to see how this is an improvement.
I am probably missing something here..
#8
I'm pretty sure its a problem with the model and/or how it was exported... you spoke of it perhaps not being contained in the bounds box for all animations... maybe thats the reason its crashing?
that would explain why it seems to crash when you do certain things.. maybe its the animation that causes the mesh to exit the bounds
I dont have a tonne of experience with this, just my advice though, you should try fixing that.
04/26/2004 (8:02 am)
I dont think you're missing anything... I think there is a problem though and ori cant seem to get a fix, so he wants to try everythingI'm pretty sure its a problem with the model and/or how it was exported... you spoke of it perhaps not being contained in the bounds box for all animations... maybe thats the reason its crashing?
that would explain why it seems to crash when you do certain things.. maybe its the animation that causes the mesh to exit the bounds
I dont have a tonne of experience with this, just my advice though, you should try fixing that.
#9
this time i used one dts file with all the animations in it. and changed the .cs file to hold only the shapebase.
fixed the bounds box, the model have room to breath now. anything else :)
04/26/2004 (8:14 am)
Guys,this time i used one dts file with all the animations in it. and changed the .cs file to hold only the shapebase.
fixed the bounds box, the model have room to breath now. anything else :)
#10
make a nurbbox_50 and register its details. change it to detail_50 (negetive).
export. and voila.
the new exporter version will have this fixed.
04/27/2004 (10:49 am)
I will now tell you guys how to fix this issue, all thanks to joe maru.make a nurbbox_50 and register its details. change it to detail_50 (negetive).
export. and voila.
the new exporter version will have this fixed.
#11
I'm certainly not saying it will magicly fix his model.
In fact you're above statements are exactly WHY the show tool rewrite was a good thing. Because now you CAN safely assume that if it works in the show tool but not your game that its game logic that's at fault. With the old show tool you can NOT make that assumption.
The problem with the existing Show Tool though is it uses a completely different method of displaying models than a game. Its a hack. Displaying a model in Show Tool is really no test of how well it will work in game, thus leading to issues like this "Well wtf it works fine in show tool!". With the existing set it is quite possible to have a model that shows fine in Show Tool but not in game or the other way around. They don't do things the same way.
There is little point in using a "test" program that uses a completely different method than your application :)
04/27/2004 (10:56 am)
@JoeQuote:I am a little confused.. how is this going to make it better? Not trying to be antagonistic, just not understanding the logic. When a shape works in the -showtool.. but not in game, we know that the problem is most likely somewhere in the game code that does not exist in the showtool. This allows us to isolate very quickly where the problem might be.
I am not getting how integrating the two is going to help. Particularly in this instance, it seems that this problem instead of crashing the game and not the showtool, would instead now crash the game and the showtool. I fail to see how this is an improvement.
I am probably missing something here..
I'm certainly not saying it will magicly fix his model.
Quote:When a shape works in the -showtool.. but not in game, we know that the problem is most likely somewhere in the game code that does not exist in the showtool.Unfortunately, no you don't. Why don't you? Because the show tool doesn't load and display or animate models the same way you would in a game. It uses hardcoded C++ to do all its work rather than script.
Quote:Particularly in this instance, it seems that this problem instead of crashing the game and not the showtool, would instead now crash the game and the showtool. I fail to see how this is an improvement.That IS an improvement because you know its a problem with your model. If it works in the show tool but not in your game, you're left thinking maybe you're doing something wrong in your game (as you stated above) so you don't look at the model. After all the model must be fine since it worked in the show tool right?
In fact you're above statements are exactly WHY the show tool rewrite was a good thing. Because now you CAN safely assume that if it works in the show tool but not your game that its game logic that's at fault. With the old show tool you can NOT make that assumption.
The problem with the existing Show Tool though is it uses a completely different method of displaying models than a game. Its a hack. Displaying a model in Show Tool is really no test of how well it will work in game, thus leading to issues like this "Well wtf it works fine in show tool!". With the existing set it is quite possible to have a model that shows fine in Show Tool but not in game or the other way around. They don't do things the same way.
There is little point in using a "test" program that uses a completely different method than your application :)
#12
04/27/2004 (10:57 am)
Told ya it was an issue with detail levels :p Glad to hear you got it working.
#13
04/27/2004 (11:02 am)
Well its not what you would expect though.. a negetive detail level wtf ???
#14
With that said, I still see value in what you are doing. Unfortunately, loading a shape, say, as a player requires a bunch of script changes. You are providing a way to test if the shape is properly set up as a player (or vehicle or whatever) without making those changes. That's a good thing, and very useful. But I think it's important to keep the old functionality too, because, as Joe poointed out, it's a very important debugging device (if your artist tells you "it works in the show tool", don't take that as a bad thing, that means you have more info to go on).
BTW, I also don't agree that the show tool being C++ based makes it less valid. In the end it's all C++. The C++ in the show tool is implementing the basic TS functionality without making additional assumptions. The reason it is so non-standard in the way it was written is because it was written before the Gui system was completed (or even designed). But that doesn't really affect it's functionality. I would like to see it brought up to date, though, and the hooks in the main game loop removed.
05/01/2004 (4:50 pm)
John - I'm confused how you could miss Joe's point. If the show tool errors if and only if the game errors, then it gives you no additional information. If a shape can work in the show tool but not the game, you have more information. In fact, in practice we have used the fact that the show tool is a purer test of shapes all the time. The player, vehicle, and other shapebase game objects in the Torque make a lot of assumptions that result in asserts or crashes when they are wrong. This means that if you want to use the shape as a player/vehicle/shapebase object you need to fix something. But it doesn't mean the shape didn't export correctly or that it isn't set up correctly for other purposes. If you want to check to see if a shape is set up correctly to use as a player, then load it as a player. With that said, I still see value in what you are doing. Unfortunately, loading a shape, say, as a player requires a bunch of script changes. You are providing a way to test if the shape is properly set up as a player (or vehicle or whatever) without making those changes. That's a good thing, and very useful. But I think it's important to keep the old functionality too, because, as Joe poointed out, it's a very important debugging device (if your artist tells you "it works in the show tool", don't take that as a bad thing, that means you have more info to go on).
BTW, I also don't agree that the show tool being C++ based makes it less valid. In the end it's all C++. The C++ in the show tool is implementing the basic TS functionality without making additional assumptions. The reason it is so non-standard in the way it was written is because it was written before the Gui system was completed (or even designed). But that doesn't really affect it's functionality. I would like to see it brought up to date, though, and the hooks in the main game loop removed.
#15
05/01/2004 (9:23 pm)
Clark, do you think a "ShowTool" gui control would be a good way to deal with this? Or perhaps even a ShowObject to fit in John's preview stuff?
#16
A show object that fits in John's preview gui would be great. If the preview object/gui were then also made into a mod (in addition to in game) then that would be even better. The reason you want the gui in a mod is that when working on shapes the artist is going in and out of the tool frequently, so you want something that loads quickly with low overhead. You might think that another solution would be to have easier reload of shapes, but that would still require the game running in the background as the artist edited the shape, which is not the best solution.
In terms of features you want supported in the show gui, ask some artists. The show gui isn't just there for testing whether shapes work in game. The artist will use the tool to view the shape and look for artifacts. I know that Joe has mentioned a couple lighting features he'd like to see (I think the ability to trackball lighting just like you can trackball camera after hitting tab). There might be other similar features that would be useful.
In any case, when making changes to the tool, make sure not to ruin a good thing. The show gui, as primitive as may be, has been a very useful tool to the artists (hence Joe's questions). I find it prudent to be conservative when changing a useful tool.
05/01/2004 (9:41 pm)
Ben - my 2 cents...A show object that fits in John's preview gui would be great. If the preview object/gui were then also made into a mod (in addition to in game) then that would be even better. The reason you want the gui in a mod is that when working on shapes the artist is going in and out of the tool frequently, so you want something that loads quickly with low overhead. You might think that another solution would be to have easier reload of shapes, but that would still require the game running in the background as the artist edited the shape, which is not the best solution.
In terms of features you want supported in the show gui, ask some artists. The show gui isn't just there for testing whether shapes work in game. The artist will use the tool to view the shape and look for artifacts. I know that Joe has mentioned a couple lighting features he'd like to see (I think the ability to trackball lighting just like you can trackball camera after hitting tab). There might be other similar features that would be useful.
In any case, when making changes to the tool, make sure not to ruin a good thing. The show gui, as primitive as may be, has been a very useful tool to the artists (hence Joe's questions). I find it prudent to be conservative when changing a useful tool.
#17
05/02/2004 (4:48 am)
My plan was to imbed the functionality of the old tool in the new one. In other words, if you wanted to use the old interface you could.
#18
and maybe one is so convinced it is a model issue they refuse to look at the code..
I fail to see this as an improvment and I suppose this is why I am not getting where you are coming from. The showtool was not (and in my opinion) should not be a tool to check game logic or any other game realted functionality, or even to check if the shape adheres to any game imposed requiements. It was designed to be a tool to test art assets, nothing more...
The show tool is one of many tests tools that a team can use to test different aspects of the production process. The showtool was designed to test to see if a model loads, to check the ligthing, the Level of Detail and to check the animation.
Often times art assets will work in -show and not in the game. Sometimes it is the art that needs to change, sometimes it is the code, but in all instances where it has to change, it is usually a problem where the game code is assuming something about the art assets that may or may not be present in the model. Always, it is the teams resposibility to determine the problem and correct it. Usually the coder has some level of involvment in the process as it is he/she who can more easily determine what the issue is and why it is not working in the game.
In the meantime, the artist can continue to work and refine the look of the asset while the cause of the problem is determined instead of scratching their head if the coder sends them back with a 'problem is the model' explanation without any research as to what the cause of the problem is and what the solution is.
---
I find your repeated assertion that checking the animation in the showtool and checking it in the game as not being valid as questionable. The implementation of how it works in shapebase shapes and in the acutal model (as shown in the showtool) may be different, but the animation itself is exactly the same.
It is my opinion that the showtool is an excellent tool to make sure that animations are loading onto the model properly before sending them into the game and checking to see tif they work. If the animation loads on the model in -show, and does not play in game, it is most probably a code issue in the way the animation is being called, and not a issue with the model. The solution is usually in the code or in script, and I am not going to suggest a proper division of labor for anyone's team, but this does give the team members an idea of where to look for the problem.
Now, unless the team has gone and made serious changes to the way models and animations are loaded in the game, using the showtool to test if animations are loading on the skeleton is a valid test to see if the animation is working.
I respect that you do not think so, but I don't agree. On this point, I suppose we will have to agree to disagree
05/02/2004 (8:05 pm)
Quote:That IS an improvement because you know its a problem with your model. If it works in the show tool but not in your game, you're left thinking maybe you're doing something wrong in your game (as you stated above) so you don't look at the model. After all the model must be fine since it worked in the show tool right? In fact you're above statements are exactly WHY the show tool rewrite was a good thing. Because now you CAN safely assume that if it works in the show tool but not your game that its game logic that's at fault. With the old show tool you can NOT make that assumption.
and maybe one is so convinced it is a model issue they refuse to look at the code..
I fail to see this as an improvment and I suppose this is why I am not getting where you are coming from. The showtool was not (and in my opinion) should not be a tool to check game logic or any other game realted functionality, or even to check if the shape adheres to any game imposed requiements. It was designed to be a tool to test art assets, nothing more...
The show tool is one of many tests tools that a team can use to test different aspects of the production process. The showtool was designed to test to see if a model loads, to check the ligthing, the Level of Detail and to check the animation.
Often times art assets will work in -show and not in the game. Sometimes it is the art that needs to change, sometimes it is the code, but in all instances where it has to change, it is usually a problem where the game code is assuming something about the art assets that may or may not be present in the model. Always, it is the teams resposibility to determine the problem and correct it. Usually the coder has some level of involvment in the process as it is he/she who can more easily determine what the issue is and why it is not working in the game.
In the meantime, the artist can continue to work and refine the look of the asset while the cause of the problem is determined instead of scratching their head if the coder sends them back with a 'problem is the model' explanation without any research as to what the cause of the problem is and what the solution is.
---
I find your repeated assertion that checking the animation in the showtool and checking it in the game as not being valid as questionable. The implementation of how it works in shapebase shapes and in the acutal model (as shown in the showtool) may be different, but the animation itself is exactly the same.
It is my opinion that the showtool is an excellent tool to make sure that animations are loading onto the model properly before sending them into the game and checking to see tif they work. If the animation loads on the model in -show, and does not play in game, it is most probably a code issue in the way the animation is being called, and not a issue with the model. The solution is usually in the code or in script, and I am not going to suggest a proper division of labor for anyone's team, but this does give the team members an idea of where to look for the problem.
Now, unless the team has gone and made serious changes to the way models and animations are loaded in the game, using the showtool to test if animations are loading on the skeleton is a valid test to see if the animation is working.
I respect that you do not think so, but I don't agree. On this point, I suppose we will have to agree to disagree
#19
I am not suggesting the artist 'pass the buck' and not check the shapes in game.. it is but one of many tools we can use to make qualtiy assets but I am against moving the art test tool into a more game like enviroment with the same dependencies.
Secondly, and again, I dont want to sound negative..as I think what you are attempting is great. But, I am noticing a pattern of you asking for feedback and then ignoring or discounting much of what people are saying if it does not fall in line with your opinion.
I tried out the first version of the new showtool2, and I personally don't like the direction you are taking in terms of what you are focusing on first or where you are going with the primary interface. It remains to be seen what the final version will be, but your behavior here and in other threads is leaving me not so conviced that what you come up with will be something that will be a useful addition to our production process and will not be something an artist will want to use. I understand you have your reasons for doing what you are doing, your own needs for your team, and your idea of what a proper interface and implementation should be, but if you undertake the re-writing of a tool that is used by an entire community, it is my opinion that you should proceed a little slower and listen a little more carefully to the members of the community before implementing yourvision.
I am glad that you are choosing to include the old interface.. I would be quite upset to lose any of the existing features if your version of the new showtool becomes 'official'.
I have many ideas of what I would like to see in an updated showtool, and as an aritst (and the showtool being primarily an artist tool) I have some strong opinion as to what the interface should (and should not) be... I find it disturbing that you are undertaking this endevour without getting more feedback from aritsts about their needs for an artists tool.
If you are interested in what sort of features I want out of a new showtool, I can post them here.. but given your behavior thus far on all threads related to this issue, I expect fully for you to glaze over this and not even try to understand what it is I am trying to say or be interested in my opinion.
05/02/2004 (8:07 pm)
Now on the topic of the new showtool I see some problems with the approach you are taking. The first being that getting complicated art assets working in game is a little demanding as they have quite a few requirements based on assumptions the game makes. Moving the art testing interface to a more 'game like' environment places a greater burden on the artist. With a severe lack of artists around here already, and a pretty stiff art pipeline as it is, I think this is going to make it harder on an artist new to the TGE, not easier.I am not suggesting the artist 'pass the buck' and not check the shapes in game.. it is but one of many tools we can use to make qualtiy assets but I am against moving the art test tool into a more game like enviroment with the same dependencies.
Secondly, and again, I dont want to sound negative..as I think what you are attempting is great. But, I am noticing a pattern of you asking for feedback and then ignoring or discounting much of what people are saying if it does not fall in line with your opinion.
I tried out the first version of the new showtool2, and I personally don't like the direction you are taking in terms of what you are focusing on first or where you are going with the primary interface. It remains to be seen what the final version will be, but your behavior here and in other threads is leaving me not so conviced that what you come up with will be something that will be a useful addition to our production process and will not be something an artist will want to use. I understand you have your reasons for doing what you are doing, your own needs for your team, and your idea of what a proper interface and implementation should be, but if you undertake the re-writing of a tool that is used by an entire community, it is my opinion that you should proceed a little slower and listen a little more carefully to the members of the community before implementing yourvision.
I am glad that you are choosing to include the old interface.. I would be quite upset to lose any of the existing features if your version of the new showtool becomes 'official'.
I have many ideas of what I would like to see in an updated showtool, and as an aritst (and the showtool being primarily an artist tool) I have some strong opinion as to what the interface should (and should not) be... I find it disturbing that you are undertaking this endevour without getting more feedback from aritsts about their needs for an artists tool.
If you are interested in what sort of features I want out of a new showtool, I can post them here.. but given your behavior thus far on all threads related to this issue, I expect fully for you to glaze over this and not even try to understand what it is I am trying to say or be interested in my opinion.
#20
I am all for new and better tools, but I don't want to see a tool that I do not feel is broken replaced by a tool that is less functional for the purpose it was designed for. If you make a tool that is more useful for you, that is ok.. If you want to make a different and very useful tool for testing game shapes, that is great....but if you are going to replace a tool with another one, then it should be more useful than the old tool for the purpose for which it was designed and not be repurposed to be something else entirely.
I have been using this tool (or versions of it) for going on six years.. and it is one of the most stable and most useful tools that I use to get work done. I do not want to see it changed into THE new showtool unless it offers an improvement over the existing tool.
And to make this all a little topical.. I think it should be noted that this particular issue was a bug in the exporter code, and not a problem with the way the model was built. The additional of the detail level in Ori's shape was a temporary workaround to get him moving forward.
05/02/2004 (8:07 pm)
If a screwdriver does not make a good hammer, it is not that fault of the screwdriver, the person who designed and built the screw driver, or the people using the screwdriver to good effect. If you want to make a hammer and call it ScrewDriver2, that is your business, but as you originally volunteered to re-write the 'official' showtool in another thread, I wanted to add my two cents in before the screwdriver I use every day gets turned into a hammer.I am all for new and better tools, but I don't want to see a tool that I do not feel is broken replaced by a tool that is less functional for the purpose it was designed for. If you make a tool that is more useful for you, that is ok.. If you want to make a different and very useful tool for testing game shapes, that is great....but if you are going to replace a tool with another one, then it should be more useful than the old tool for the purpose for which it was designed and not be repurposed to be something else entirely.
I have been using this tool (or versions of it) for going on six years.. and it is one of the most stable and most useful tools that I use to get work done. I do not want to see it changed into THE new showtool unless it offers an improvement over the existing tool.
And to make this all a little topical.. I think it should be noted that this particular issue was a bug in the exporter code, and not a problem with the way the model was built. The additional of the detail level in Ori's shape was a temporary workaround to get him moving forward.
Torque 3D Owner Helk