What would you like to see addressed in Torque 3D?
by Matt Fairfax · in Torque Game Engine Advanced · 01/09/2009 (7:10 pm) · 281 replies
Hi all,
We've asked before but I thought I would take the opportunity to build a fresh list of what you would like to see addressed in Torque.
This can be everything from a long-standing bug, to a resource that is so useful you find yourself integrating it over and over, to a complete wish for something. Whatever it is we want to hear it!
Please keep in mind that just because you ask for it doesn't mean that you will get it. I am making no promises but it is always helpful to us to hear what you are interested in or concerned about.
Our community is hugely diverse and something that is absolutely essential and of the highest priority to you and your game may actually be something that other games never use so don't take it personally if we don't address your specific concern.
I am going to make sure that everything specific that you mention gets logged into our task tacker so that it can be prioritized and reviewed even if we don't get to it for Torque 3D. I say "specific" because statements like "vehicles suck" aren't useful to us however if you can narrow it down to "FlyingVehicles crash when they run into the ground too fast" then it is something we can look into.
I am very serious about this...if you ever want a chance at having your concerns addressed then you need to speak up.
We've asked before but I thought I would take the opportunity to build a fresh list of what you would like to see addressed in Torque.
This can be everything from a long-standing bug, to a resource that is so useful you find yourself integrating it over and over, to a complete wish for something. Whatever it is we want to hear it!
Please keep in mind that just because you ask for it doesn't mean that you will get it. I am making no promises but it is always helpful to us to hear what you are interested in or concerned about.
Our community is hugely diverse and something that is absolutely essential and of the highest priority to you and your game may actually be something that other games never use so don't take it personally if we don't address your specific concern.
I am going to make sure that everything specific that you mention gets logged into our task tacker so that it can be prioritized and reviewed even if we don't get to it for Torque 3D. I say "specific" because statements like "vehicles suck" aren't useful to us however if you can narrow it down to "FlyingVehicles crash when they run into the ground too fast" then it is something we can look into.
I am very serious about this...if you ever want a chance at having your concerns addressed then you need to speak up.
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.
#82
Yes! Yes! I have been beating that drum hard around here =)
.3DS is actually limited to 8.3 names for "materials", nodes, and meshes and doesn't actually map very well to modern game artists (not to mention the complete lack of skinned mesh support). To make proper use of .X pretty much requires using the DirectX tools/loaders which doesn't play nice with our goal of cross-platform support. We have been working with .OBJ over in GG Studios but I am not sure exactly how much of that is usable for Torque 3D and honestly I would rather not bloat our TSShape loading code *too* much (it gets hard to maintain and confusing to the end user).
Instead we decided to go with Collada. It is the first format that we've seen that includes enough power and features to be truly useful in a wide variety of games and engines while also being non-platform and/or modeling app specific (.X has a *ton* of the same power/flexibility as Collada but Microsoft pushed it as a DirectX only feature rather than releasing a cross-platform loader like the Collada folks). It has been gaining a *ton* of support across the industry as real standard and we think it is the right choice for the future.
You are right though...there is no reason why static geometry shouldn't *just work* when loaded into an engine. You shouldn't have to mess with hierarchies, naming conventions, bounds, etc if you just want to drop a textured cube onto your terrain. When you start to get into more complicated things like animated, skinned character meshes it is ok to require the artist to tweak it a little more to get it to work with your engine and it is very reasonable to ask them to read your documentation but for the simple stuff it should *just work*. We think this is one of the biggest hurdles in the Torque art pipeline and we intend to address that in Torque 3D.
16-bit indices aren't necessarily a bad thing...they do use a lot less memory and run a *lot* faster on most video cards. However, you are correct that we shouldn't be limited by them.
This is a tall order in the current Torque architecture. I should know...I'm probably one of the very few people who has done it =) This will likely have to wait for the new stuff coming from Torque R&D (where they are actively working on the problem).
It won't happen in Torque 3D but at some point we are going to move away from TorqueScript as the "official" scripting language. There has been a lot of R&D on this already internally but we aren't quite ready to talk about it.
We are hoping to clean some of this up and to better document it all.
01/12/2009 (2:26 pm)
Quote:
1. Pain-free, 100% correct, basic, static model imports.
Yes! Yes! I have been beating that drum hard around here =)
Quote:
Any modern game engine/platform should be able to load a .obj, a .x, and a .3ds model into the engine for rapid prototyping with one line of script or a simple dialog box.
.3DS is actually limited to 8.3 names for "materials", nodes, and meshes and doesn't actually map very well to modern game artists (not to mention the complete lack of skinned mesh support). To make proper use of .X pretty much requires using the DirectX tools/loaders which doesn't play nice with our goal of cross-platform support. We have been working with .OBJ over in GG Studios but I am not sure exactly how much of that is usable for Torque 3D and honestly I would rather not bloat our TSShape loading code *too* much (it gets hard to maintain and confusing to the end user).
Instead we decided to go with Collada. It is the first format that we've seen that includes enough power and features to be truly useful in a wide variety of games and engines while also being non-platform and/or modeling app specific (.X has a *ton* of the same power/flexibility as Collada but Microsoft pushed it as a DirectX only feature rather than releasing a cross-platform loader like the Collada folks). It has been gaining a *ton* of support across the industry as real standard and we think it is the right choice for the future.
You are right though...there is no reason why static geometry shouldn't *just work* when loaded into an engine. You shouldn't have to mess with hierarchies, naming conventions, bounds, etc if you just want to drop a textured cube onto your terrain. When you start to get into more complicated things like animated, skinned character meshes it is ok to require the artist to tweak it a little more to get it to work with your engine and it is very reasonable to ask them to read your documentation but for the simple stuff it should *just work*. We think this is one of the biggest hurdles in the Torque art pipeline and we intend to address that in Torque 3D.
Quote:
2. A modern 3D model format that doesn't have fundamental limits because of 16-bit indices.
16-bit indices aren't necessarily a bad thing...they do use a lot less memory and run a *lot* faster on most video cards. However, you are correct that we shouldn't be limited by them.
Quote:
4. The ability to disable/replace *all* client/server/networking/ghosting abstractions for single player games, or for games with far larger numbers of objects in motion than the TGE/TGEA architecture currently allows.
This is a tall order in the current Torque architecture. I should know...I'm probably one of the very few people who has done it =) This will likely have to wait for the new stuff coming from Torque R&D (where they are actively working on the problem).
Quote:
7. Python for scripting. Torquescript should become a backwards-compatible mechanism for legacy code.
It won't happen in Torque 3D but at some point we are going to move away from TorqueScript as the "official" scripting language. There has been a lot of R&D on this already internally but we aren't quite ready to talk about it.
Quote:
followed by a great deal of head scratching trying to figure out what script is where and when it's run and why someone thought it was right to put it there...
We are hoping to clean some of this up and to better document it all.
#83
As Brett mentioned in that thread, we are working closely with Gerhard and you will be seeing the results of that in relation to Torque 3D.
01/12/2009 (2:28 pm)
Quote:
Basically I need all the features that been done by the guy in his spare time as he stated in the NextGen TGEA Gaming thread:www.garagegames.com/mg/forums/result.thread.php?qt=79304. Why? Simply because it's been proved doable. The most important features of his work, in my point of view, is the FX material system and the HLSLFX enhancement which lay a solid foundation to quickly import thousand of shaders already made.
As Brett mentioned in that thread, we are working closely with Gerhard and you will be seeing the results of that in relation to Torque 3D.
#84
Already on it =)
01/12/2009 (2:29 pm)
Quote:
Built in batching for objects, like ShapeReplicator but being able to choose exact positions rather than use random seeding. (though there might be a very good reason why this can't happen)
Already on it =)
#85
A *huge* amount of the effort going into Torque 3D is focused on improving the editor experience. We would definitely like to hear any ideas or details you guys would like to see included in this pass.
Can you give me more specifics?
I'll make sure this is on the World Editor devs' list to look at.
01/12/2009 (2:33 pm)
Quote:
- Really big advancements in the editors
(let's say facilities, on the way of those rolled out by the PlasticGems series but a bit more polished)
A *huge* amount of the effort going into Torque 3D is focused on improving the editor experience. We would definitely like to hear any ideas or details you guys would like to see included in this pass.
Quote:
- Include better audio managing capabilities (something on the road this is something we yet integrated many times on and on with every release)
Can you give me more specifics?
Quote:
- Built in datablock editor
I'll make sure this is on the World Editor devs' list to look at.
#86
This is a *great* idea and fairly easy for us to implement in time for Torque 3D =)
01/12/2009 (2:34 pm)
Quote:
Blockers that don't cast shadows. Blockers that can block any (or all) of the following:
a) Missiles.
b) Players
c) AI Players
d) Vehicles (by kind)
e) Players that are not in vehicles.
f) Blockers that have a generic script callback that let you check specifically whether to include it in collision detection or not.
This is a *great* idea and fairly easy for us to implement in time for Torque 3D =)
#87
I was told that this was non-trivial by Alex Scarborough due to how Apple implements their OpenGL layer and he opted to cut fullscreen support for the Mac.
01/12/2009 (2:36 pm)
Quote:
The only other thing I would request other than the normal "enhanced performance" or "better stability" is fullscreen support for Mac OS.
I was told that this was non-trivial by Alex Scarborough due to how Apple implements their OpenGL layer and he opted to cut fullscreen support for the Mac.
#88
Sold! Checks in the mail...:)
01/12/2009 (2:42 pm)
Quote:
Instead we decided to go with Collada. It is the first format that we've seen that includes enough power and features to be truly useful in a wide variety of games and engines while also being non-platform and/or modeling app specific (.X has a *ton* of the same power/flexibility as Collada but Microsoft pushed it as a DirectX only feature rather than releasing a cross-platform loader like the Collada folks)
Sold! Checks in the mail...:)
#89
The biggest problem with enable portals with polysoup models is figuring out if a point (or Player or Camera) is inside the zone that the portal defines or not. With sealed convex brushes like over in the Interiors you can use a BSP tree to quickly figure out if something is inside the zone or not. Since there are no requirements on polysoup that it be sealed *or* convex it becomes a much harder and ultimately more cpu intensive problem to solve. Ultimately, on modern video cards it actually becomes a lot slower to try to have such fine-grained control over the visibility of the polygons. Instead it is better to be smarter about how you are sending large batches of polygons to the video card.
There is some pretty cool, in-depth research happening in GG Studios into this problem but it has not been easy (which is why no one else really does it...Unreal 3 still uses convex volumes to control visibility occlusion). In the meantime, for Torque 3D, we are looking into some cheaper solutions that aren't quite as robust but could give some nice performance boosts (like sub-mesh frustrum occlusion).
There is actually a working car in the TGEA "T3D" GameExample (you can add it in from the Mission Editor) as well as a *ton* of working Players with animations.
Ultimately, I think what you are asking for is a working example of all of the major gameplay objects. This is definitely a goal for Torque 3D.
This is something we are working on.
No promises on any of these.
01/12/2009 (2:47 pm)
Quote:
.Portals! exported in polysoup models or added in mission editor
The biggest problem with enable portals with polysoup models is figuring out if a point (or Player or Camera) is inside the zone that the portal defines or not. With sealed convex brushes like over in the Interiors you can use a BSP tree to quickly figure out if something is inside the zone or not. Since there are no requirements on polysoup that it be sealed *or* convex it becomes a much harder and ultimately more cpu intensive problem to solve. Ultimately, on modern video cards it actually becomes a lot slower to try to have such fine-grained control over the visibility of the polygons. Instead it is better to be smarter about how you are sending large batches of polygons to the video card.
There is some pretty cool, in-depth research happening in GG Studios into this problem but it has not been easy (which is why no one else really does it...Unreal 3 still uses convex volumes to control visibility occlusion). In the meantime, for Torque 3D, we are looking into some cheaper solutions that aren't quite as robust but could give some nice performance boosts (like sub-mesh frustrum occlusion).
Quote:
.Working examples of Cars,players,with animations to go along with the updated Docs for all supported 3d tools.
There is actually a working car in the TGEA "T3D" GameExample (you can add it in from the Mission Editor) as well as a *ton* of working Players with animations.
Ultimately, I think what you are asking for is a working example of all of the major gameplay objects. This is definitely a goal for Torque 3D.
Quote:
.Incorporated show tool/model viewer that has T3D shader support.
This is something we are working on.
Quote:
.full screen ambient occlusion, Dynamic lighting, stencil shadows,<----YES please.
No promises on any of these.
#90
Atlas is going to be removed from Torque 3D
We've been working closely with Rene Damm for nearly a year now and, while he has some interesting R&D, we haven't been able to make Atlas everything that it deserves to be. At this point we have decided to learn what we can from Atlas and to refocus those efforts on something much more robust and stable in the future.
I know this will be a shock for some of you and I apologize. As part of our efforts to improve upon TerrainBlock for Torque 3D we are going to be looking closely at how to address as much of the needs that Atlas was trying to fill.
In the long run this will be better for all of us.
We will continue to offer Atlas as part of TGEA 1.7.1 and TGEA 1.8 and when those go away (at some point in the future) if we haven't completely replaced the functionality of Atlas with something better we will look at releasing the Atlas code as a resource (or maybe GPL).
01/12/2009 (2:53 pm)
I guess this is as good a time as any to make a major (non-marketing) announcement about Torque 3D:Atlas is going to be removed from Torque 3D
We've been working closely with Rene Damm for nearly a year now and, while he has some interesting R&D, we haven't been able to make Atlas everything that it deserves to be. At this point we have decided to learn what we can from Atlas and to refocus those efforts on something much more robust and stable in the future.
I know this will be a shock for some of you and I apologize. As part of our efforts to improve upon TerrainBlock for Torque 3D we are going to be looking closely at how to address as much of the needs that Atlas was trying to fill.
In the long run this will be better for all of us.
We will continue to offer Atlas as part of TGEA 1.7.1 and TGEA 1.8 and when those go away (at some point in the future) if we haven't completely replaced the functionality of Atlas with something better we will look at releasing the Atlas code as a resource (or maybe GPL).
#91
Will there be a means to convert existing Atlas terrains to any new solutions you guys come up with? This is important because I'd like to keep upgrading and porting the source even after the game is out. At that time it will be crucial for me to be able to hide the fact that the terrain system is different. If that'd be possible, it'd be great news.
01/12/2009 (3:00 pm)
@Matt: I have to be honest, that felt like a break-up. I guess this is for the better...Will there be a means to convert existing Atlas terrains to any new solutions you guys come up with? This is important because I'd like to keep upgrading and porting the source even after the game is out. At that time it will be crucial for me to be able to hide the fact that the terrain system is different. If that'd be possible, it'd be great news.
#92
01/12/2009 (3:14 pm)
Quote:We will continue to offer Atlas as part of TGEA 1.7.1 and TGEA 1.8 and when those go awayWhatever happened to the idea that TGEA would stay around for anyone who didn't buy T3D? Please tell me that I just misinterpreted that statement.
#93
01/12/2009 (3:14 pm)
Quote:Atlas is going to be removed from Torque 3DOw! Now that hurt! But...
Quote:*skirt* *skirt* *skirt* *looks over his shoulder at the marketing people* *shifty eyes*...that sounds good, I hope ;)
#94
They're not going to drive over to your house and delete it from your hard drive. I think you're safe.
01/12/2009 (3:21 pm)
Quote:Whatever happened to the idea that TGEA would stay around for anyone who didn't buy T3D? Please tell me that I just misinterpreted that statement.
They're not going to drive over to your house and delete it from your hard drive. I think you're safe.
#96
I like BSP, regardless of how old it is.
01/12/2009 (3:49 pm)
I know it's early days and all, but is BSP/DIF going to continue in T3D?I like BSP, regardless of how old it is.
#97
01/12/2009 (3:51 pm)
I would like the ability to have in-game sounds fire events to objects in their audible vicinity. That way we can have AI that *actually* can hear things instead of the hacks we have been using.
#98
As Brett has said over his blog, at *some* point we will likely replace TGEA 1.8 with a version of Torque 3D that costs the same but doesn't have all of the shiny new features and content. Since Torque 3D is based on TGEA 1.8 this means you'll essentially have the same product just with a different name (and a few tweaks hither and yon...like a better World Editor).
01/12/2009 (4:35 pm)
Quote:
Whatever happened to the idea that TGEA would stay around for anyone who didn't buy T3D? Please tell me that I just misinterpreted that statement.
As Brett has said over his blog, at *some* point we will likely replace TGEA 1.8 with a version of Torque 3D that costs the same but doesn't have all of the shiny new features and content. Since Torque 3D is based on TGEA 1.8 this means you'll essentially have the same product just with a different name (and a few tweaks hither and yon...like a better World Editor).
#99
-Your Reply: > A *huge* amount of the effort going into Torque 3D is focused on improving the editor experience. We would definitely like to hear any ideas or details you guys would like to see included in this pass.
Better user interface like
- right click contest menu (like in the collaborative design tool)
- menu structure reworked (more logical and more intuitive)
- fields like position, rotation scale etc having now a unique field to be splitted in X, Y, Z fileds every with is own spin +/-)
- world inspector & similar windows semitransparent (better if you can select the amount of transp.)
- world inspector and world creator windows unified with collapsible sections for each
- in inspector windows a sections giving hints about the field you're editing
- in inspector a way to edit a simfolder(simgroup) position, rotation, scale and have all obects inside it moving/scaling the same amount???
- for fields image related (as detail texture and so on) a select window with a preview of the image files so you can visually choose it
- for many fields where you have constraints in editing (ie I can choose only power of 2 values) a spin to choose it or a select box with valid values
- for fileds where you choose shapes (like in replicators) a select window with preview of it
- for shapes listed in world creator the possibility to rightclick>preview to see a window with a preview of that shape...
(GULP!: I'd like to ask also for Atlas editing... I'm very sad for the Atlas funeral announced! :-( )
Ok, I was meaning something like VMPlayer, giving the ablity to easily play, pause, stop, fade tracks, load and play Playlists, react to event call (for example the player entering a trigger area or the player die and the tracks currently playing fade into another track...) something like that :D
-------------------------------------------------------------------------------------------
BTW: ok some plan possibly to integrate showtool if I understand correctly... also some plan to integrate constructor and to bring to it shaders?
01/12/2009 (4:39 pm)
@Matt: Quote:
- Really big advancements in the editors
(let\\\'s say facilities, on the way of those rolled out by the PlasticGems series but a bit more polished)
-Your Reply: > A *huge* amount of the effort going into Torque 3D is focused on improving the editor experience. We would definitely like to hear any ideas or details you guys would like to see included in this pass.
Better user interface like
- right click contest menu (like in the collaborative design tool)
- menu structure reworked (more logical and more intuitive)
- fields like position, rotation scale etc having now a unique field to be splitted in X, Y, Z fileds every with is own spin +/-)
- world inspector & similar windows semitransparent (better if you can select the amount of transp.)
- world inspector and world creator windows unified with collapsible sections for each
- in inspector windows a sections giving hints about the field you're editing
- in inspector a way to edit a simfolder(simgroup) position, rotation, scale and have all obects inside it moving/scaling the same amount???
- for fields image related (as detail texture and so on) a select window with a preview of the image files so you can visually choose it
- for many fields where you have constraints in editing (ie I can choose only power of 2 values) a spin to choose it or a select box with valid values
- for fileds where you choose shapes (like in replicators) a select window with preview of it
- for shapes listed in world creator the possibility to rightclick>preview to see a window with a preview of that shape...
(GULP!: I'd like to ask also for Atlas editing... I'm very sad for the Atlas funeral announced! :-( )
Quote:-Your Reply: > Can you give me more specifics?
- Include better audio managing capabilities (something on the road this is something we yet integrated many times on and on with every release)
Ok, I was meaning something like VMPlayer, giving the ablity to easily play, pause, stop, fade tracks, load and play Playlists, react to event call (for example the player entering a trigger area or the player die and the tracks currently playing fade into another track...) something like that :D
-------------------------------------------------------------------------------------------
BTW: ok some plan possibly to integrate showtool if I understand correctly... also some plan to integrate constructor and to bring to it shaders?
#100
We are going to have to switch the terrain in Barricade to the new solution so I certainly hope that we can automate that =)
It is going to be a lot easier to convert a "blended textures" Atlas terrain (since Atlas and TerrainBlock share the same basic blender you really only need to convert the heightfield).
For a "unique texture" Atlas terrain it will probably be possible to convert some automatically but it will depend on how big your unique texture is and how big your terrain is.
Unfortunately, it won't be possible to do a 1-to-1 port from Atlas to the new stuff for all terrains but it will be more than sufficient for a reasonably sized terrain *and* you could end up with a *much* nicer looking terrain that renders faster and doesn't have weird collision issues.
What we are targeting with the improvements to the terrain system is people who want middling sized terrains (up to 2X MegaTerrain) with a *lot* of detail/texel density and very fast and efficient rendering. Having watched the uses of terrain with our engine (TerrainBlock and Atlas) we think this will serve 98% of our customers outside of the simulation space.
Ultimately, as with every upgrade, you guys are going have to look at what new features Torque 3D brings to the table and weigh that against the "cost" of switching/porting your existing project. It can be really easy to get caught up in chasing new tech for new tech's sake but a lot of times it is worth it to stick it out on your current project and start your new project with the shiny new engine.
01/12/2009 (4:45 pm)
Quote:
Will there be a means to convert existing Atlas terrains to any new solutions you guys come up with?
We are going to have to switch the terrain in Barricade to the new solution so I certainly hope that we can automate that =)
It is going to be a lot easier to convert a "blended textures" Atlas terrain (since Atlas and TerrainBlock share the same basic blender you really only need to convert the heightfield).
For a "unique texture" Atlas terrain it will probably be possible to convert some automatically but it will depend on how big your unique texture is and how big your terrain is.
Unfortunately, it won't be possible to do a 1-to-1 port from Atlas to the new stuff for all terrains but it will be more than sufficient for a reasonably sized terrain *and* you could end up with a *much* nicer looking terrain that renders faster and doesn't have weird collision issues.
What we are targeting with the improvements to the terrain system is people who want middling sized terrains (up to 2X MegaTerrain) with a *lot* of detail/texel density and very fast and efficient rendering. Having watched the uses of terrain with our engine (TerrainBlock and Atlas) we think this will serve 98% of our customers outside of the simulation space.
Ultimately, as with every upgrade, you guys are going have to look at what new features Torque 3D brings to the table and weigh that against the "cost" of switching/porting your existing project. It can be really easy to get caught up in chasing new tech for new tech's sake but a lot of times it is worth it to stick it out on your current project and start your new project with the shiny new engine.
Associate Matt Fairfax
PopCap
Sadly this kind of functionality requires far too large an engineering effort for us to include it in Torque 3D. However, this is the direction we are headed for future versions of Torque and we have already committed quite a bit of resources towards it.