Torque 3D Status - 6/30/2010
by Matt Fairfax · in Torque 3D Professional · 06/30/2010 (9:42 pm) · 96 replies
Hey all,
In an effort to improve communication with the Torque 3D community I am going to start posting regular updates on the current status of Torque 3D.
As part of these updates, I plan to offer some rough estimates of when to expect upcoming releases. These estimates will not be perfect and they will change, sometimes with little warning. They should not be considered a "promise" and they will be wrong at times.
We are now at the end of June and, unfortunately, things are taking a little longer than we anticipated and it is now highly unlikely that Torque 3D 1.1 Final will be released in July.
We have had a number of our other products reach releasable states all at the same time and it is taking some time to get them all through the proper amount of QA and out the door.
We have been progressing nicely on bugfixing Torque 3D 1.1 Beta 2 but it needs some more thorough focus from QA before it will be ready for release.
Disclaimer: All timeframes in this thread are estimates and should not be considered final
In an effort to improve communication with the Torque 3D community I am going to start posting regular updates on the current status of Torque 3D.
As part of these updates, I plan to offer some rough estimates of when to expect upcoming releases. These estimates will not be perfect and they will change, sometimes with little warning. They should not be considered a "promise" and they will be wrong at times.
Where are we?
At the beginning of June, Eric posted this update where he stated that we expected to release Torque 3D 1.1 Final in July.We are now at the end of June and, unfortunately, things are taking a little longer than we anticipated and it is now highly unlikely that Torque 3D 1.1 Final will be released in July.
We have had a number of our other products reach releasable states all at the same time and it is taking some time to get them all through the proper amount of QA and out the door.
We have been progressing nicely on bugfixing Torque 3D 1.1 Beta 2 but it needs some more thorough focus from QA before it will be ready for release.
When is it coming?
At this point we expect Torque 3D 1.1 Beta 2 to ship in late July after iT2D 1.4 and Torque X 3.1.5 have shipped. We think that we will be able to ship Torque 3D 1.1 Final fairly quickly after Beta 2 goes out but that will depend a bit on what the results of the Beta are.Disclaimer: All timeframes in this thread are estimates and should not be considered final
About the author
I am a Game Designer at PopCap who has worked on PvZ Adventures, PvZ2, Peggle Blast, and Bejeweled Skies. I am an ex-GarageGames employee who helped ship TGE, TGEA, Torque 3D, and Constructor.
#22
I know the power is there, just not sure how to get the same results as those screenshots, Prophecy Ressurection, Alan James work or the likes of Buccanneer.
A definate class above in the art stakes and would love to know the secrets to getting such quality and definition in the textures.
07/05/2010 (4:05 am)
I'd agree probably nothing in there that isn't in T3D already, although did I read somewhere that 1.1 would include the pacific level? or am I just dreaming that up.I know the power is there, just not sure how to get the same results as those screenshots, Prophecy Ressurection, Alan James work or the likes of Buccanneer.
A definate class above in the art stakes and would love to know the secrets to getting such quality and definition in the textures.
#23
It's really the artist that brings it out. It's also one reason I decided not to go for AAA graphics in my game: It takes huge amounts of time. You can make a level that looks like Gears of War (TP already did, it was called the "Gears of Torque" level), but you have to have top-notch artists, and you have to have lots of time and/or money.
The real secret to games that look like that is that it has very little to do with the engines and everything to do with the artists creating the content for it.
07/05/2010 (5:47 am)
Quote:would love to know the secrets to getting such quality and definition in the textures
It's really the artist that brings it out. It's also one reason I decided not to go for AAA graphics in my game: It takes huge amounts of time. You can make a level that looks like Gears of War (TP already did, it was called the "Gears of Torque" level), but you have to have top-notch artists, and you have to have lots of time and/or money.
The real secret to games that look like that is that it has very little to do with the engines and everything to do with the artists creating the content for it.
#24
But not sure if that's used for all textures or whether they just use higher quality textures or what.
Would give something to aspire to in order to improve
07/05/2010 (8:59 am)
Yeah I know it's the art side Ted but still intrigued to know the secrets of what extra steps they take - obviously character wise I know sculpting in z-brush or similar to generate a normal map is a big part.But not sure if that's used for all textures or whether they just use higher quality textures or what.
Would give something to aspire to in order to improve
#25
However, I did see one thing down in the responses that made me cringe in fear:
While a new script-to-engine interface that is cleaner and has better handling of enums and callbacks is certainly welcome, please please please FTLOG tell me the existing system of ConsoleMethods and ConsuleFunction macros will be kept intact and fully functional. We have added dozens upon dozens of these methods, hundres of enums, and many callbacks, and the notion of possible overhauling all the code to integrate the new release quite frankly gives me shivers.. :)
Thanks in advance for the reply if you get a chance..
Dusty
07/06/2010 (1:00 pm)
This is the thread I was looking for! The latest news on T3D, and while I'd hoped we would see it in July, as long as it doesn't get pushed too far into the September/October timeframe, we're still good to go! Thanks Matt for posting the update:However, I did see one thing down in the responses that made me cringe in fear:
Quote:
We introduced a new engine to script interface that has largely superseded the Console macros like ConsoleFunction and ConsoleMethod. This was primarily done to make it much, much easier to document the engine-script interface but in a lot of ways it does make things a *lot* easier and cleaner (like property enums and callbacks).
While a new script-to-engine interface that is cleaner and has better handling of enums and callbacks is certainly welcome, please please please FTLOG tell me the existing system of ConsoleMethods and ConsuleFunction macros will be kept intact and fully functional. We have added dozens upon dozens of these methods, hundres of enums, and many callbacks, and the notion of possible overhauling all the code to integrate the new release quite frankly gives me shivers.. :)
Thanks in advance for the reply if you get a chance..
Dusty
#26
07/06/2010 (1:14 pm)
We left those macros in place =) 
#27
07/08/2010 (12:15 pm)
Can we have a status update by next Friday? that will be our mid July update. 
#28
07/08/2010 (12:41 pm)
I think this is all VERY good news, and I like the way the disclaimer was worded to keep those that are less than happy at least somewhat quiet. ...and from here I almost went on a bit of a rant at the feeling I am getting from some of the posters, and I am concerned. What problem has anyone run into that has made it so they could not complete of still develop their game, because I know of none that do that. I create a full working FPS with menus and such for a class project and the only problems I had were related to me not having good docs, but the community was eager to help, and I have not seen it otherwise, this community is topnotch, and I am glad to be part of it. Ive tried UDK, but other than a great FPS engine it isnt very flexible.
#29
I ran into a issue where collisions with forest brushed trees that have a collision mesh were not reliable, it is a serious bug and destroys our AStar implementation.
Not only does the collision take a long time (it could take many hours to autonav mesh a level) but they flat out don't work, providing links through solid objects and such.
We have over 20 missions, not all of which include forest brushes but most of them do, the levels used for path finding nav and dev have never had a forest and we just assumed that collision mesh trees would work fantastic.
This is a perfect example of a show stopper bug that has prevented us from releasing any type of closed beta because none of our production missions will work.
07/08/2010 (12:48 pm)
@BobbyI ran into a issue where collisions with forest brushed trees that have a collision mesh were not reliable, it is a serious bug and destroys our AStar implementation.
Not only does the collision take a long time (it could take many hours to autonav mesh a level) but they flat out don't work, providing links through solid objects and such.
We have over 20 missions, not all of which include forest brushes but most of them do, the levels used for path finding nav and dev have never had a forest and we just assumed that collision mesh trees would work fantastic.
This is a perfect example of a show stopper bug that has prevented us from releasing any type of closed beta because none of our production missions will work.
#30
07/08/2010 (12:55 pm)
Chris, have you added ForestObjectType to your raycast typemasks?
#31
www.torquepowered.com/community/forums/viewthread/117079
that thread has all the info
07/08/2010 (12:57 pm)
Yes I've tried it both ways, its not that the raycast fails its just incorrect (Missing sometimes, not contacting the correct point, etc) -- if you want more infowww.torquepowered.com/community/forums/viewthread/117079
that thread has all the info
#32
07/08/2010 (1:24 pm)
I will attempt to post an update next week but I am going to be out of town a lot over the next couple of weeks and it may delay my update.
#33
I understand you very valid reasoning but correct me if I am wrong, but this isnt code that comes with T3D but is your code with their Engine that is not working right? This is not meant to belittle your problem but just know that I don't think that is a showstopper for creating a game. If I was making a more serious simulation i would not use software that is in Beta but at the same time there has to be workarounds as I have had problem with the "Forest" system with relation to Collision, so I just did it the old fashioned way a created a forest by hand with lots of LOD, and all Pathing that we experimented with went fine with those object. Please don't take this the wrong way but is T3D supposed to Work out of the box with this type of pathing? Believe me I understand how frustrating it can be to not have something working that really should, especially something that has probably worked well in other engines you have might have tried?
But about A*, when creating your algorithm i know that it uses a distance-plus-cost heuristic function for creating node placement, can you not edit you nodes by hand? perhaps I don't know enough about your simulation. I apologize if my questions seem rude(especially in the context of this thread), but they are not intended that way, another reading over my should says I was but I don't think you will see it that way, I am really just trying to understand others points of view in this manner.
Bobby
07/08/2010 (2:13 pm)
@ChrisI understand you very valid reasoning but correct me if I am wrong, but this isnt code that comes with T3D but is your code with their Engine that is not working right? This is not meant to belittle your problem but just know that I don't think that is a showstopper for creating a game. If I was making a more serious simulation i would not use software that is in Beta but at the same time there has to be workarounds as I have had problem with the "Forest" system with relation to Collision, so I just did it the old fashioned way a created a forest by hand with lots of LOD, and all Pathing that we experimented with went fine with those object. Please don't take this the wrong way but is T3D supposed to Work out of the box with this type of pathing? Believe me I understand how frustrating it can be to not have something working that really should, especially something that has probably worked well in other engines you have might have tried?
But about A*, when creating your algorithm i know that it uses a distance-plus-cost heuristic function for creating node placement, can you not edit you nodes by hand? perhaps I don't know enough about your simulation. I apologize if my questions seem rude(especially in the context of this thread), but they are not intended that way, another reading over my should says I was but I don't think you will see it that way, I am really just trying to understand others points of view in this manner.
Bobby
#34
Bobby; It is truth that often BUGS may be overcome with some creative problem solving, but often a creative solution is not the optimal solution.
Assumptions built from experience is just the beginning of knowledge, after some experience one will learn just how little they originally knew.
07/08/2010 (2:34 pm)
My point of view is; Just because some people can work on there project and never stumble into a stinging hive of bugs, do not mean T3D is bug free and working great.Bobby; It is truth that often BUGS may be overcome with some creative problem solving, but often a creative solution is not the optimal solution.
Assumptions built from experience is just the beginning of knowledge, after some experience one will learn just how little they originally knew.
#35
07/08/2010 (2:40 pm)
If you need to ask weather or not a "ray cast" is standard engine functionality, you shouldn't be answering the question.
#36
And your are totally correct, this does not kill our project. If I have to I can manually increase the H value around trees, I can purchase a different forest solution and pay to have it integrated with torque such as SpeedTree, I can even pay someone with more internal knowledge to go fix the bug.
My point is I should not have to do any of these things because the castRay should be quite reliable and accurate, IMO this bug has more data posted than is necessary to visualize and verify the problem exists 100% of the time.
We banked on using the torque forest system, to make great looking environments and we still believe in Torque and that this bug will be fixed without us fixing it.
Every time I bring this bug up it seems like people just want it over looked like its not a problem or that our bug is less important or that we should settle for less, or that maybe our project is less important than the bugs that effect their project.
Just because I don't post impressive progress screen shots, or videos or even talk about our project does not mean we should have to settle for anything less than others who have problems.
I am ready to buy SpeedTree and have it integrated with torque to meet our specs if we don't solve this in the next release, and maybe even if the problem is fixed.
07/08/2010 (2:45 pm)
Your question does indeed seem rude. Just because your game does not require this to work right does not mean I should have to live without it.And your are totally correct, this does not kill our project. If I have to I can manually increase the H value around trees, I can purchase a different forest solution and pay to have it integrated with torque such as SpeedTree, I can even pay someone with more internal knowledge to go fix the bug.
My point is I should not have to do any of these things because the castRay should be quite reliable and accurate, IMO this bug has more data posted than is necessary to visualize and verify the problem exists 100% of the time.
We banked on using the torque forest system, to make great looking environments and we still believe in Torque and that this bug will be fixed without us fixing it.
Every time I bring this bug up it seems like people just want it over looked like its not a problem or that our bug is less important or that we should settle for less, or that maybe our project is less important than the bugs that effect their project.
Just because I don't post impressive progress screen shots, or videos or even talk about our project does not mean we should have to settle for anything less than others who have problems.
I am ready to buy SpeedTree and have it integrated with torque to meet our specs if we don't solve this in the next release, and maybe even if the problem is fixed.
#39
We'll get there though, either that or I'm flying to Vegas to bring some pain muahahaha
07/14/2010 (9:20 pm)
Me three, four and five :) We'll get there though, either that or I'm flying to Vegas to bring some pain muahahaha
#40
But we also want to make sure we are meeting a reasonable quality bar. The past 5 months since 1.1 beta 1 have flown by so quickly.
07/14/2010 (9:48 pm)
We are all waiting for it...trust me, we want it out too. But we also want to make sure we are meeting a reasonable quality bar. The past 5 months since 1.1 beta 1 have flown by so quickly.
Associate Konrad Kiss
Bitgap Games