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
#22
I really don't know where the heck that attitude comes from. I quite often ask for comments and listen to them. I didin't just start making a new show tool out of the blue. I posted the idea and got lots of interest in a more game-like rewrite. So I started on the path. I posted a very early preview (And it is just that. a very early preview) and got positive feedback so I continued.
Quite honestly, after working as hard as I have then reading your posts, I was quite upset. I have worked very hard in what little free time I have over the last few weeks to put this thing together and I was THIS close to just giving it all up after reading your negative comments. I had to count to 10 before posting because I was afraid i'd be rude. You are msot welcome to disagree. You are most welcome to offer suggestions. But next time please don't do them in such a negative and argumentative manner. I think it slights the work i've done for this community; and i've done a lot for it.
I do in fact see where you are coming from, hence the reason for intending to embedd the original show tool in here, but I also think you are not entirely seeing where I am coming from. I'm building a VERY thin layer of game-like behaviour. 99.99% of the time you will have no reason to drop back to the older code. Most of the "Works in show tool but not in game, so its a game related problem" situations arise from customized and specific game code. Also bear in mind one key point I think you aren't thinking about; v2 is compared to v1. Which means that i'm going to make sure it works reliably. If I run into a model that works in v1 and not in v2 and it turns out to be a problem with v2 not the model, them i'm going to fix that.
In any case, i'm probably rambling a bit since I just woke up. I'd like to hear your suggestions just as much as anyone elses.
05/03/2004 (5:24 am)
Quote: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.
I really don't know where the heck that attitude comes from. I quite often ask for comments and listen to them. I didin't just start making a new show tool out of the blue. I posted the idea and got lots of interest in a more game-like rewrite. So I started on the path. I posted a very early preview (And it is just that. a very early preview) and got positive feedback so I continued.
Quite honestly, after working as hard as I have then reading your posts, I was quite upset. I have worked very hard in what little free time I have over the last few weeks to put this thing together and I was THIS close to just giving it all up after reading your negative comments. I had to count to 10 before posting because I was afraid i'd be rude. You are msot welcome to disagree. You are most welcome to offer suggestions. But next time please don't do them in such a negative and argumentative manner. I think it slights the work i've done for this community; and i've done a lot for it.
I do in fact see where you are coming from, hence the reason for intending to embedd the original show tool in here, but I also think you are not entirely seeing where I am coming from. I'm building a VERY thin layer of game-like behaviour. 99.99% of the time you will have no reason to drop back to the older code. Most of the "Works in show tool but not in game, so its a game related problem" situations arise from customized and specific game code. Also bear in mind one key point I think you aren't thinking about; v2 is compared to v1. Which means that i'm going to make sure it works reliably. If I run into a model that works in v1 and not in v2 and it turns out to be a problem with v2 not the model, them i'm going to fix that.
In any case, i'm probably rambling a bit since I just woke up. I'd like to hear your suggestions just as much as anyone elses.
#23
Okay, then I will give you a clue. You started a thread about starting this on April 16th. One of the first responses was from Matt Fairfax, who has done more for the community in the way of content creation tools than probably everyone else on GarageGames put together, and instead of taking any interest in his comments, you basically went ..pfft... next.
You never posted (at least as far as I could find) in the non-private forums. Most artists are not SDK owners and never saw the thread, so you effectively removed them from the feedback process. This being chiefly an artist tool, it seemed like you were not really trying all that hard to get much feedback at all.
I posted warning about new features, and my concern about feature bloat, and you said, don't worry. So I did not.
Then 3 days later.. a first pass.. I had not even completed my wishlist list of things I wanted to add.
So, instead of taking the showtool and implementing the standard show tool interface as it exists in the 'standard' TGE way, you added new features. I was thinking.. huh? what happened? 3 days of feedback from programmers to re-write an art tool, promises that it will retain the old functionality, and then after that, pretty much no old functionality and new features? Yeah, it is early. I got that.. but when the first thing out departs so drastically from what did exist.. I think there is reason for concern.
So you posted, Ben, said cool.. good start, and others complained about key events not working. So one person, a programmer, gave positive feedback.
Then, Ori started this thread, and it got turned into a 'why the showtool is not good for checking shapes thread', like you are on some evangelistic crusade to convince everyone that the showtool sucks,
The feedback you are hearing hear on this thread is......
"John, your obsession with the showtool not being a valid testbed in it's current form is misguided." But you don't want to hear it. We have been using it (successfully) for the past 6 years or so. We are trying to let you in on how it is used, and you are pretty much saying, repeatedly, ...pfft....."There is little point in using a "test" program that uses a completely different method than your application
You are coming across as dismissive. Acting like the people that are questioning you just got off the boat. It is quite insulting and I know for a fact that others are perceiving your behavior in the same way.
You are basically saying to me.. you don't know what you are doing, I know better.
So, the attitude you are getting is in response to the attitude you are projecting.
I respect that you may have experience.. but so does my team, having worked on 4 shipped titles with this engine (and in the process of working on 2 more that will ship).
You are coming across like an expert, telling us we are a bunch of idiots and are POV is not valid. I am responding to this in kind. I may have come across a little strong, but I felt I need to to get your attention as you seem to be ignoring what I (and others) in this thread have been saying.
05/03/2004 (12:02 pm)
Multi part post:Quote:I really don't know where the heck that attitude comes from. I quite often ask for comments and listen to them. I didin't just start making a new show tool out of the blue. I posted the idea and got lots of interest in a more game-like rewrite. So I started on the path. I posted a very early preview (And it is just that. a very early preview) and got positive feedback so I continued.
Okay, then I will give you a clue. You started a thread about starting this on April 16th. One of the first responses was from Matt Fairfax, who has done more for the community in the way of content creation tools than probably everyone else on GarageGames put together, and instead of taking any interest in his comments, you basically went ..pfft... next.
You never posted (at least as far as I could find) in the non-private forums. Most artists are not SDK owners and never saw the thread, so you effectively removed them from the feedback process. This being chiefly an artist tool, it seemed like you were not really trying all that hard to get much feedback at all.
I posted warning about new features, and my concern about feature bloat, and you said, don't worry. So I did not.
Then 3 days later.. a first pass.. I had not even completed my wishlist list of things I wanted to add.
So, instead of taking the showtool and implementing the standard show tool interface as it exists in the 'standard' TGE way, you added new features. I was thinking.. huh? what happened? 3 days of feedback from programmers to re-write an art tool, promises that it will retain the old functionality, and then after that, pretty much no old functionality and new features? Yeah, it is early. I got that.. but when the first thing out departs so drastically from what did exist.. I think there is reason for concern.
So you posted, Ben, said cool.. good start, and others complained about key events not working. So one person, a programmer, gave positive feedback.
Then, Ori started this thread, and it got turned into a 'why the showtool is not good for checking shapes thread', like you are on some evangelistic crusade to convince everyone that the showtool sucks,
The feedback you are hearing hear on this thread is......
"John, your obsession with the showtool not being a valid testbed in it's current form is misguided." But you don't want to hear it. We have been using it (successfully) for the past 6 years or so. We are trying to let you in on how it is used, and you are pretty much saying, repeatedly, ...pfft....."There is little point in using a "test" program that uses a completely different method than your application
You are coming across as dismissive. Acting like the people that are questioning you just got off the boat. It is quite insulting and I know for a fact that others are perceiving your behavior in the same way.
You are basically saying to me.. you don't know what you are doing, I know better.
So, the attitude you are getting is in response to the attitude you are projecting.
I respect that you may have experience.. but so does my team, having worked on 4 shipped titles with this engine (and in the process of working on 2 more that will ship).
You are coming across like an expert, telling us we are a bunch of idiots and are POV is not valid. I am responding to this in kind. I may have come across a little strong, but I felt I need to to get your attention as you seem to be ignoring what I (and others) in this thread have been saying.
#24
It should be pointed out here, that your testing process on Ori's shape was able to provide him with a better view of the problem, and ours was able to provide him with a solution (two in fact, one being a workaround, the other being a bug fix).
I point this out only because repeatedly you keep going, pfft... you guys are fools, there is no point in having a testing process that does yada yada... like we are children that have absolutely no concept of what we are doing.
I have been giving you feedback all along. Here it is again..
It is my belief that the -showtool is and should remain a tool for checking art. Any game dependencies that rely on shapebase specific implementation of shapes should NOT be in there, or, if they are, in there as an optional MOD of the base showtool. I also want to make sure that if game dependencies do get implemented into the showtool, that the way that they are integrated is done so in such a way that people that are using custom shapes or not using shapebase as a base for their game are not left to sink or swim in regard to removing functionality.
To Clarify.. continue with your tool... recreate the showtool we have now.. in the way you are doing it (TGE gui style).. when that is done, make a new tool, Showtool+, that brings in the thin game layer. Now, I would actually add more functionality into the 'base' showtool than currently exists, but what goes where I will save for later.
05/03/2004 (12:03 pm)
Now as to your point of it not being a valid test too, I disagree. There is every point in having a test application that has some (but not all) of the functionality of the main application. It allows one to draw an imaginary line to localize the possible point of the problem. You draw yours at game logic, I draw mine much closer to the 'guts'. No right or wrong here, our ways works for us. It should be pointed out here, that your testing process on Ori's shape was able to provide him with a better view of the problem, and ours was able to provide him with a solution (two in fact, one being a workaround, the other being a bug fix).
I point this out only because repeatedly you keep going, pfft... you guys are fools, there is no point in having a testing process that does yada yada... like we are children that have absolutely no concept of what we are doing.
I have been giving you feedback all along. Here it is again..
It is my belief that the -showtool is and should remain a tool for checking art. Any game dependencies that rely on shapebase specific implementation of shapes should NOT be in there, or, if they are, in there as an optional MOD of the base showtool. I also want to make sure that if game dependencies do get implemented into the showtool, that the way that they are integrated is done so in such a way that people that are using custom shapes or not using shapebase as a base for their game are not left to sink or swim in regard to removing functionality.
To Clarify.. continue with your tool... recreate the showtool we have now.. in the way you are doing it (TGE gui style).. when that is done, make a new tool, Showtool+, that brings in the thin game layer. Now, I would actually add more functionality into the 'base' showtool than currently exists, but what goes where I will save for later.
#25
Pot calling the kettle black. Maybe you should put more work into reading the feedback and trying to understand what people are saying before forging ahead.
There is no point in reworking an tool for artists without asking the artists. You are basically ignoring everything everyone is saying in terms of what we use as a testing process that works for us. It is you business if you decide to drop it, and I won't be too concerned if you do. I am advocating on behalf of the artists in the community as to what I think an artist wants out of an art tool. If my response offends, that is your business. If you decide to drop it, that is also your business.
And I think that your attitude in terms of how you are responding to the people posting in these threads is slighting all of our contributions, which, I might add, are also considerable.
05/03/2004 (12:03 pm)
Quote:Quite honestly, after working as hard as I have then reading your posts, I was quite upset. I have worked very hard in what little free time I have over the last few weeks to put this thing together and I was THIS close to just giving it all up after reading your negative comments. I had to count to 10 before posting because I was afraid i'd be rude. You are msot welcome to disagree. You are most welcome to offer suggestions. But next time please don't do them in such a negative and argumentative manner.
Pot calling the kettle black. Maybe you should put more work into reading the feedback and trying to understand what people are saying before forging ahead.
There is no point in reworking an tool for artists without asking the artists. You are basically ignoring everything everyone is saying in terms of what we use as a testing process that works for us. It is you business if you decide to drop it, and I won't be too concerned if you do. I am advocating on behalf of the artists in the community as to what I think an artist wants out of an art tool. If my response offends, that is your business. If you decide to drop it, that is also your business.
Quote: I think it slights the work i've done for this community; and i've done a lot for it.
And I think that your attitude in terms of how you are responding to the people posting in these threads is slighting all of our contributions, which, I might add, are also considerable.
#26
How do you figure? I respect that this may be your belief, but my experience, based on using this engine for a number of years, and walking more artists than I can count through the art path, is that your supposition is incorrect.
Most of the problems are in fact situations where the engine is making assumptions about certain types of shapes, and what they should contain. My experience is that half of the time it is a model problem (missing node or collision shape) and half the time it is a error in some very basic logic in script (syntax error in datablock, bad path to a image resource, etc..). I have seen a few strange implementations done, and in nearly all of those instances the people making the modifications knew that the 'broken' parts were in their new code.
This is from experience helping artist debug shapes. I understand that your opinion differs from mine, but in this case, I will place more weight on my experience actually performing the task of getting shapes working.
05/03/2004 (12:04 pm)
Quote: Most of the "Works in show tool but not in game, so its a game related problem" situations arise from customized and specific game code.
How do you figure? I respect that this may be your belief, but my experience, based on using this engine for a number of years, and walking more artists than I can count through the art path, is that your supposition is incorrect.
Most of the problems are in fact situations where the engine is making assumptions about certain types of shapes, and what they should contain. My experience is that half of the time it is a model problem (missing node or collision shape) and half the time it is a error in some very basic logic in script (syntax error in datablock, bad path to a image resource, etc..). I have seen a few strange implementations done, and in nearly all of those instances the people making the modifications knew that the 'broken' parts were in their new code.
This is from experience helping artist debug shapes. I understand that your opinion differs from mine, but in this case, I will place more weight on my experience actually performing the task of getting shapes working.
#27
If you are interested, I would suggest that another non-private thread be started and artists actively encouraged to give input on this. I would also suggest that if others reply and want to add to the discussion (people like Matt Fairfax) that you don't shut them down by saying things like "don't get me started on the crap that is deep exploration" without hearing them out about what their ideas are and what they are wanting to see in a tool.
I would also really like it that instead of telling us we are full of shit and that your way is better just because you think it is, that you take the time to engage in an active dialogue regarding everyones concerns instead of continuing to say 'don't worry', when it is fairly obvious to me that you are being willfully ignorant of much of what people are trying to say.
I do want to see better tools. I applaud what you are trying to do. I am having some issues with the way you are going about it, and I have some concerns about what the tool may become if I don't voice my concerns. Again, I am here as an advocate for the artists in the community. I have my own opinions about what I want the art tools in the TGE to be.. it is not right or wrong.. it is just an opinion. I have reasons for my opinions, and feel compelled to voice them so that we end up taking steps forward and not back. I don't want to argue with you. I want to bury the hatchet and start working together toward a toolset that best serves the community. I want to see progress, but I feel a little bit of caution should be taken about how the tools are implemented.
Here are a few of the things I would like to see:
*button and keybind for flushing the texture cache (in effect reloading the textures)
*one button toggle on/off 100% ambient lighting
*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.
*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)
* a window that will display the shape hierarchy
* turn on the bounding box and collision hulls (much like turning them on in game)
*change the background color of the showtool window dynamically.
more to follow when I have more time and I have given it more thought...
05/03/2004 (12:04 pm)
Quote:In any case, i'm probably rambling a bit since I just woke up. I'd like to hear your suggestions just as much as anyone elses.
If you are interested, I would suggest that another non-private thread be started and artists actively encouraged to give input on this. I would also suggest that if others reply and want to add to the discussion (people like Matt Fairfax) that you don't shut them down by saying things like "don't get me started on the crap that is deep exploration" without hearing them out about what their ideas are and what they are wanting to see in a tool.
I would also really like it that instead of telling us we are full of shit and that your way is better just because you think it is, that you take the time to engage in an active dialogue regarding everyones concerns instead of continuing to say 'don't worry', when it is fairly obvious to me that you are being willfully ignorant of much of what people are trying to say.
I do want to see better tools. I applaud what you are trying to do. I am having some issues with the way you are going about it, and I have some concerns about what the tool may become if I don't voice my concerns. Again, I am here as an advocate for the artists in the community. I have my own opinions about what I want the art tools in the TGE to be.. it is not right or wrong.. it is just an opinion. I have reasons for my opinions, and feel compelled to voice them so that we end up taking steps forward and not back. I don't want to argue with you. I want to bury the hatchet and start working together toward a toolset that best serves the community. I want to see progress, but I feel a little bit of caution should be taken about how the tools are implemented.
Here are a few of the things I would like to see:
*button and keybind for flushing the texture cache (in effect reloading the textures)
*one button toggle on/off 100% ambient lighting
*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.
*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)
* a window that will display the shape hierarchy
* turn on the bounding box and collision hulls (much like turning them on in game)
*change the background color of the showtool window dynamically.
more to follow when I have more time and I have given it more thought...
#28
05/03/2004 (12:12 pm)
Joe, did you write all of that on the fly?
#29
05/03/2004 (12:17 pm)
I started this morning and wrote between conversations with Ben and Clark.. I am suprised it ended up being as long as it ended up being. One of these days I have to tkae some time and write a .plan instead....
#30
Just a force of habit really, not intentional. I just tend to post in the private forums. I had never considered this but you have a good point.
Perhaps I should not have released that early version. I can see how you can get that impression, but it was really nothing more than thats what I had done first. You are looking at only one very small piece of the whole thing.
05/03/2004 (12:37 pm)
Quote:
You never posted (at least as far as I could find) in the non-private forums. Most artists are not SDK owners and never saw the thread, so you effectively removed them from the feedback process. This being chiefly an artist tool, it seemed like you were not really trying all that hard to get much feedback at all.
Just a force of habit really, not intentional. I just tend to post in the private forums. I had never considered this but you have a good point.
Quote:So, instead of taking the showtool and implementing the standard show tool interface as it exists in the 'standard' TGE way, you added new features. I was thinking.. huh? what happened? 3 days of feedback from programmers to re-write an art tool, promises that it will retain the old functionality, and then after that, pretty much no old functionality and new features? Yeah, it is early. I got that.. but when the first thing out departs so drastically from what did exist.. I think there is reason for concern.
Perhaps I should not have released that early version. I can see how you can get that impression, but it was really nothing more than thats what I had done first. You are looking at only one very small piece of the whole thing.
Quote:You are basically saying to me.. you don't know what you are doing, I know better.You are reading WAAY too much into my text.
#31
To give you an idea of things, here is my to-do sheet
Implement Movement of Object (DONE)
Provide control to switch between controlling camera and object
Collision on camera movements (DONE)
control to toggle camera collision
load "scale reference" shape
provide pick box for selecting animation threads when using DSQs
model check feature that uses original TSShow code to validate models
control for choosing skybox
loading/displaying of lights
loading/displaying of interiors
stop animation button
pause animation button
dynamic ui
plugins
view levels of detail
load/display particle effects
load datablock
load hover vehicle (DONE)
load wheeled vehicle
load flying vehicle
fix camera collision (DONE)
allow mounting of shapes
unmount shapes
loading/saving of lighting rigs
05/03/2004 (12:43 pm)
I don't think some of the things you want are going to be possible. I'm doing this entirely scrpit side. I can't make code changes because then it won't work with a stock Torque build. Not unless GG is willing to make official code changes to go along with it.To give you an idea of things, here is my to-do sheet
Implement Movement of Object (DONE)
Provide control to switch between controlling camera and object
Collision on camera movements (DONE)
control to toggle camera collision
load "scale reference" shape
provide pick box for selecting animation threads when using DSQs
model check feature that uses original TSShow code to validate models
control for choosing skybox
loading/displaying of lights
loading/displaying of interiors
stop animation button
pause animation button
dynamic ui
plugins
view levels of detail
load/display particle effects
load datablock
load hover vehicle (DONE)
load wheeled vehicle
load flying vehicle
fix camera collision (DONE)
allow mounting of shapes
unmount shapes
loading/saving of lighting rigs
#32
These should all be possible.
05/03/2004 (1:02 pm)
Quote:
*one button toggle on/off 100% ambient lighting
*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.
*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)
These should all be possible.
#33
As Joe mentioned, Clark, he, and I had a discussion about the new show tool work earlier today.
If the show tool meets GG's needs, we'll be more than happy to make changes to HEAD for it. We recognize the need for a new and better show tool; if there is one out in the community then we'd like to use it instead of writing our own.
That said, it needs to fulfill some basic requirements:
- Direct and easy to use. Tools are a huge priority right now at GG, and we absolutely need ones that are simple and easy to use. That probably means seperating the basic test-model functionality and the fancier test-game stuff, so that newbies aren't tempted to jump ahead of themselves.
- Should be useful as a debugging tool. There should be a tool which provides a direct interface to 3space, like the current showtool does.
- Fast loading time. Anything over about 4-5 seconds is too slow.
- Features. It doesn't need to be feature rich, but it should cover basically what Joe outlined. Much more than that in the basic interface is overkill. It should default to spawning things in black empty space - ie, with no dependencies on game code or special rendering at all.
And, of course, the developer needs to be someone that we're comfortable working with. :)
I think what you have is a good start in that direction, but it needs to be steered a bit to really be in line with what Torque needs, which is a good art preview and test tool. Right now it's feeling sort of schizophrenic, though.
Anyway, what I would say is this - focus on getting the show tool functionality reimplemented cleanly in Torque. That's where there is a need. The rest is frosting, and some of it really takes away from the goals of the show tool.
If you're willing to give us what we need, then we're willing to make changes to the official source - because in essence, what you'll be writing will _be_ the official show tool. But if it's not what we need, then we'll write our own...
Anyway, hope that clears things up. We're all about community contribution, and your show tool has the potential to be really useful. It just seems like there's been a sort of breakdown in communication, that needs to be rectified. Hopefully, we'll be able to do that.
Thanks,
Ben
05/03/2004 (5:15 pm)
John,As Joe mentioned, Clark, he, and I had a discussion about the new show tool work earlier today.
If the show tool meets GG's needs, we'll be more than happy to make changes to HEAD for it. We recognize the need for a new and better show tool; if there is one out in the community then we'd like to use it instead of writing our own.
That said, it needs to fulfill some basic requirements:
- Direct and easy to use. Tools are a huge priority right now at GG, and we absolutely need ones that are simple and easy to use. That probably means seperating the basic test-model functionality and the fancier test-game stuff, so that newbies aren't tempted to jump ahead of themselves.
- Should be useful as a debugging tool. There should be a tool which provides a direct interface to 3space, like the current showtool does.
- Fast loading time. Anything over about 4-5 seconds is too slow.
- Features. It doesn't need to be feature rich, but it should cover basically what Joe outlined. Much more than that in the basic interface is overkill. It should default to spawning things in black empty space - ie, with no dependencies on game code or special rendering at all.
And, of course, the developer needs to be someone that we're comfortable working with. :)
I think what you have is a good start in that direction, but it needs to be steered a bit to really be in line with what Torque needs, which is a good art preview and test tool. Right now it's feeling sort of schizophrenic, though.
Anyway, what I would say is this - focus on getting the show tool functionality reimplemented cleanly in Torque. That's where there is a need. The rest is frosting, and some of it really takes away from the goals of the show tool.
If you're willing to give us what we need, then we're willing to make changes to the official source - because in essence, what you'll be writing will _be_ the official show tool. But if it's not what we need, then we'll write our own...
Anyway, hope that clears things up. We're all about community contribution, and your show tool has the potential to be really useful. It just seems like there's been a sort of breakdown in communication, that needs to be rectified. Hopefully, we'll be able to do that.
Thanks,
Ben
#34
05/03/2004 (5:53 pm)
Tomorrow evenening I will take a step back, re-evaluate the direction i'm moving and then post a nice detailed roadmap of what i'm planning and open it for input. This will delay the completion of the tool, but should help us all get back on the track we want to be on.
#35
05/03/2004 (6:10 pm)
Thanks. That sounds like a good plan. Feel free to drop me mail if you have any questions.
#36
Perhaps I am , and if so, I aplogize.
I will attempt to explain where I was offended, so that you may understand why I came back so strongly.
I asked a few questions relating to why you thought the change was an improvement.. and you did not respond with anything other than repeating in different forms,
"There is little point in using a "test" program that uses a completely different method than your application"
particularly this statement:
fter all the model must be fine since it worked in the show tool right?
I found both the fact that you did not even try to formulate a response that answered my question and the fact that you assume that I would think that I believe that if the 'model works in the showtool it must be fine' extremely condescending.
I hold no grudge, and I will do what I can, if you are willing, to give input on the process so that the tool becomes something that is a definite improvment over what we have now.
05/03/2004 (10:09 pm)
Quote:You are reading WAAY too much into my text.
Perhaps I am , and if so, I aplogize.
I will attempt to explain where I was offended, so that you may understand why I came back so strongly.
I asked a few questions relating to why you thought the change was an improvement.. and you did not respond with anything other than repeating in different forms,
"There is little point in using a "test" program that uses a completely different method than your application"
particularly this statement:
fter all the model must be fine since it worked in the show tool right?
I found both the fact that you did not even try to formulate a response that answered my question and the fact that you assume that I would think that I believe that if the 'model works in the showtool it must be fine' extremely condescending.
I hold no grudge, and I will do what I can, if you are willing, to give input on the process so that the tool becomes something that is a definite improvment over what we have now.
#37
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.
05/03/2004 (10:40 pm)
Feature request: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.
Torque Owner Ori Cohen
Ori Cohen
i am interested in your ideas. please post them.
thanks.