Torque 3D Development - Kickoff
by Brett Seyler · 12/17/2008 (9:05 am) · 46 comments
Amidst all the excitement here about shipping a Mac-compatible version of TGEA, we've been doing some serious planning around what we want the next version of our 3D engine to look like. I spoke about this some in my last blog, and now with TGEA 1.8 out the door, we're really ready to start opening up the floodgates with new info about the Torque 3D project.
I thought a lot about what I wanted to share with the community first. There are all the various technical elements of what we're planning to discuss, each broken down feature-by-feature. There's also a whole lot of pretty to show when we're ready. One of the more interesting stories around this project that sort of caught me by surprise involves the composition of the Torque 3D team.
This next release brings an incredible amount of talent to bear on Torque. We've assembled the best team of developers ever on a single Torque project. Have a look at these numbers...
There are currently 31 developers working either directly on Torque 3D development, or on a parallel project that Torque 3D will be leveraging.
These developers are spread across 5 continents and 13 cities.
I was impressed to discover first, that our team was this big, and second, just how much diversity we have in our little project's ranks. Bringing a complex project like this together, especially with so many team members remote from our HQ can be a very tricky process. Matt Fairfax has done a superb job shepherding TGEA along throughout 2008. For 2009, he'll have this, our biggest challenge yet.
I spend a lot of time reading about how products get created, so this kind of thing really interests me. My impulse in writing this, the first official post on Torque 3D development, was threefold. I wanted to:
- Help you get to know the developers who have been building this product.
- Shine some light on our development process by exposing feature targets early, even if they end up being cut for the final release.
- Get you all as excited as I am about what's coming in Torque 3D!
Every week I'm going to introduce two members of the Torque 3D development team and ask them to talk about how their work ties into Torque 3D. Some of these will be short, some longer. There are people you've never met or heard of, or people who've been part of the GG community for a long time. It's a very mixed and talented group, and it will be fun to get to know them all a little better.
To satisfy my other two goals, I'm also going to be posting every week on our feature targets for Torque 3D. Sometimes these will be videos, sometimes just screenshots, maybe even just quick briefing. With all things we have planned, there almost aren't enough weeks before our planned ship date to show everything you everything!
No matter what though, you can bet that Torque 3D development will be worth watching closely. Stay tuned. This is post #1.
Torque 3D development blogs:
- Post #1 - Kickoff
- Post #2 - Apparatus and Warrior Camp
- Post #3 - Luma's racing kit
- Post #4 - Josh Engebretson and Web Publishing
- Post #5 - Pricing and Licensing
- Post #6 - Pricing and Licensing CONTINUED
- Post #7 - Wetness & Precipitation
- Post #8 - Screeen Space Ambient Occlusion (SSAO)
- Post #9 - Matt Langley and the Torque Launcher
- Post #10 - Chris Robertson and Collada
- Post #11 - Depth of Field
- Post #12 - Advanced Lighting
- Post #13 - Soft Particles
- Post #14 - World Editor
- Post #15 - Pricing and Licensing ANNOUNCED!
- Post #16 - GDC Live Edition
- Post #17 - River & Road Editors
- Post #18 - Beta is UP!
- Post #19 - Light Rays, Undercity, and the Material Editor
- Post #20 - Mass Market Hardware
- Post #21 - Beta: Part Deux
- Post #22 - Marching Towards Beta 3
- Post #23 - pureLIGHT
- Post #24 - Lighting, Terrain, and Cloth
- Post #25 - Beta 3!
- Post #26 - Documentation
- Post #27 - Beta 4!
- Post #28 - Shape Editor
- Post #29 - Beta 5!
- Post #30 - Collada Import GUI Dialog
- Post #31 - 1.0 Release!!!
- Post #32 - The only good bug...
- Post #33 - 1.1 Alpha!
- Post #34 - Binary Announcement and Release
- Post #35 - Torque 3D 1.1 Beta 1!
- Post #36 - Coming Soon!
About the author
Since 2007, I've done my best to steer Torque's development and brand toward the best opportunities in games middleware.
#22
12/18/2008 (10:44 pm)
Thanks for the update Brett. I look forward to your new posts so I can stay informed! 
#23
12/19/2008 (5:33 pm)
Thanks for the update. Is there any information yet on whether the DTS format will continue to be used for 3d models in Torque 3d? If so, is it being rewritten at all? What sort of exporters are expected? I'm hoping and praying the Softimage XSI gets some love this time around...
#24
12/19/2008 (5:55 pm)
@Thomas: DTS will still be the in-engine format for models. Softimage can save as Collada files right? Torque 3D will load Collada files directly...no conversion to DTS necessary.
#25
12/19/2008 (6:27 pm)
Collada! That is AWESOME news. Collada is great! Softimage has great Collada support. If I remember correctly, Collada is an evolution of the ".xsi" file format itself. 
#26
Is David Wyand still around? Will ShowToolPro more sophisticated?
12/20/2008 (3:15 am)
@Brett Seyler: I think ShowToolPro is the perfect candidate to import Collada and FBX. Now it would be possible to check and export the model to DTS (maybe a modernised DTS-Format). I dont like the idea to import Collada directly in the engine/game.Is David Wyand still around? Will ShowToolPro more sophisticated?
#27
12/20/2008 (4:09 am)
@Thomas Bang - Why don't you like the idea of importing Collada directly in the game?
#28
Very easy. Each engine has different requirements. So it would be better to develop a newer dts-format which meets the requirements of a AAA-Engine. Additionally GG would not be dependent from Collada and FBX. The Engine has only ONE Importer (dts) and ShowToolPro could have a lot of importer (like dae, fbx, x, ...)
And ShowToolPro could be the one and only MeshViewer AND dts-exporter. Import a collada or fbx into ShowToolPro and check the mesh, Collisionmeshes, Weightmaps, Bones, Animations, Animationnames, Nodes, LODs, Materials & Textures and so on.
Additionally i would love to see MorphMaps in the DTS specification. ShowToolPro could be capable of creating MorphMaps from different Meshes. Something like this.
12/20/2008 (4:28 am)
@Tom: Quote:
Why don't you like the idea of importing Collada directly in the game?
Very easy. Each engine has different requirements. So it would be better to develop a newer dts-format which meets the requirements of a AAA-Engine. Additionally GG would not be dependent from Collada and FBX. The Engine has only ONE Importer (dts) and ShowToolPro could have a lot of importer (like dae, fbx, x, ...)
And ShowToolPro could be the one and only MeshViewer AND dts-exporter. Import a collada or fbx into ShowToolPro and check the mesh, Collisionmeshes, Weightmaps, Bones, Animations, Animationnames, Nodes, LODs, Materials & Textures and so on.
Additionally i would love to see MorphMaps in the DTS specification. ShowToolPro could be capable of creating MorphMaps from different Meshes. Something like this.
#29
This is impossible with a Collada Exporter. Unless i have to rename Layer's or SubMeshes like LOD0, LOD1...
But this would not be a real improved artist-friendly workflow.
12/20/2008 (5:41 am)
One argument i forgot to say: How can i create LOD's? Lightwave's DTS-Exporter from David Wyand is perfect because i can say... this object is LOD1 and this LOD2 and so on. This is impossible with a Collada Exporter. Unless i have to rename Layer's or SubMeshes like LOD0, LOD1...
But this would not be a real improved artist-friendly workflow.
#30
12/20/2008 (8:23 am)
@ThomasBang, the LODs would be designated by the naming convention of the meshes and a corresponding detail node... so basically specified by the names of two nodes. While technically less artist-friendly than the way the Lightwave exporter works that you mentioned, it's not difficult by any stretch of the imagination. 
#31
I find the idea to import any formats directly into the engine also a bit strange. The main reason is: I want to tweak my model before I use it in the game. If I import it through a model editor I want to tweak material parameters to make it good looking. I want to scale it. I want to look how animations work and if lighting works well. I want to see how hard and soft edges interact with the lights and shadows.
These and many other reasons are good reasons to have a model import and show tool, except you want to make cartoony games without the need of polished artworks.
Naming conventions are harder to remember if you as an artist work for more than one engine. A powerful importer would be more helpful. But they are not the biggest problem. I see more problems in terms of polishing your art and adapting it to the renderer.
12/20/2008 (8:41 am)
Russel Fincher:I find the idea to import any formats directly into the engine also a bit strange. The main reason is: I want to tweak my model before I use it in the game. If I import it through a model editor I want to tweak material parameters to make it good looking. I want to scale it. I want to look how animations work and if lighting works well. I want to see how hard and soft edges interact with the lights and shadows.
These and many other reasons are good reasons to have a model import and show tool, except you want to make cartoony games without the need of polished artworks.
Naming conventions are harder to remember if you as an artist work for more than one engine. A powerful importer would be more helpful. But they are not the biggest problem. I see more problems in terms of polishing your art and adapting it to the renderer.
#32
I second you in this. It's better architecture.
@Brett
Thanks for the answer. Actually my point is that when I have to change something in the engine, T3D docs say "you have to extend this class, register your class in this property file" rather than "you have to crawl your way thru this mudball, change a hundred of tiny bits of code and pray that the other features don't break".
It's great to have features, but more important is to have quality code, specially when features can be added by a big enthusiastic community.
12/20/2008 (9:57 am)
@Thomas Bang I second you in this. It's better architecture.
@Brett
Thanks for the answer. Actually my point is that when I have to change something in the engine, T3D docs say "you have to extend this class, register your class in this property file" rather than "you have to crawl your way thru this mudball, change a hundred of tiny bits of code and pray that the other features don't break".
It's great to have features, but more important is to have quality code, specially when features can be added by a big enthusiastic community.
#33
one more suggestion
The applications Constructor and ShowToolPro should always work with the latest engine version.
Example: Torque3D 2.0 is out now. So the user should be able to download Constructor 2.0 (based on Torque3D 2.0) and ShowToolPro 2.0 (based on Torque3D 2.0).
A few months later Torque3D 2.1 is out now and the user can download also Constructor 2.1 (based on Torque3D 2.1) and ShowToolPro 2.1 (based on Torque3D 2.1) and so on...
The advantage is: The developer (and artist) can see DIF and DTS with the current engine version. Maybe Torque3D 2.1 has one type of light more than Torque3D 2.0. In this case the artist can check his DTS and/or DIF with the new type of light. Same with new shaders, postprocessing effects, shadows and and and...
I dont know what GG plans with BSP and Polysoup. But i hope Constructor-DIF-BSP will not die because Valve (with Half Life 2) showed very impressive the power of BSP-based geometry.
12/21/2008 (3:41 am)
@Garagegames:one more suggestion
The applications Constructor and ShowToolPro should always work with the latest engine version.
Example: Torque3D 2.0 is out now. So the user should be able to download Constructor 2.0 (based on Torque3D 2.0) and ShowToolPro 2.0 (based on Torque3D 2.0).
A few months later Torque3D 2.1 is out now and the user can download also Constructor 2.1 (based on Torque3D 2.1) and ShowToolPro 2.1 (based on Torque3D 2.1) and so on...
The advantage is: The developer (and artist) can see DIF and DTS with the current engine version. Maybe Torque3D 2.1 has one type of light more than Torque3D 2.0. In this case the artist can check his DTS and/or DIF with the new type of light. Same with new shaders, postprocessing effects, shadows and and and...
I dont know what GG plans with BSP and Polysoup. But i hope Constructor-DIF-BSP will not die because Valve (with Half Life 2) showed very impressive the power of BSP-based geometry.
#34
Maybe better having Constructor & ShowToolPro "embedded" in the executable...
Then you can run it with a command line parameter
(something like: "torque3d.exe -showtool" / "torque3d.exe -constructor")
to load just the tool interface...
Maybe with the possibility to load the tools while you are in editor mode, for sure the possibility to exclude them from your game executable built...
That's my idea...
I hope the material generator will be further developed and included in T3D :D
12/22/2008 (6:22 am)
@Thomas:Maybe better having Constructor & ShowToolPro "embedded" in the executable...
Then you can run it with a command line parameter
(something like: "torque3d.exe -showtool" / "torque3d.exe -constructor")
to load just the tool interface...
Maybe with the possibility to load the tools while you are in editor mode, for sure the possibility to exclude them from your game executable built...
That's my idea...
I hope the material generator will be further developed and included in T3D :D
#35
Dave Wyand is definitely still around :) He's working full time with us on tool development. You'll get to see more soon as Brett makes his rounds through dev info.
12/22/2008 (10:07 am)
Quote:Is David Wyand still around?
Dave Wyand is definitely still around :) He's working full time with us on tool development. You'll get to see more soon as Brett makes his rounds through dev info.
#36
01/13/2009 (4:29 am)
This is nice. I hope to see great things from all of you.
#37
So now what's the real difference between TGEA and Torque X 3D?
01/29/2009 (5:37 pm)
I see Torque X has gone commercial. I take it you're no longer updating the free binaries (i.e. was Torque X 2.0 the last of the free tools we'll see from you guys)?So now what's the real difference between TGEA and Torque X 3D?
#38
I believe it will still be available through the partner's page on the XNA Creator's Club site.
01/30/2009 (6:14 am)
The version of TX that you see in the store here are going to include the source and builder licenses out of the box; hence the pricetag. There was a huge amount of confusion between which version included what. I had a ton of angry e-mails about pro not including a builder license when they thought that was what they were buying; not the source code to the engine (which they often already thought they had).I believe it will still be available through the partner's page on the XNA Creator's Club site.
#39
Looks like Torque 3d is the fastest way to get on instant action.
01/30/2009 (10:16 am)
MBO baseball is being developed with MMOKit and Torque 1.5. However ultimately it needs to be in a browser. I would like to move it over asap to torque 3d as soon as possible to save development time.Looks like Torque 3d is the fastest way to get on instant action.
#40
01/30/2009 (10:44 am)
Torque 3D has its own browser plug in. InstantAction is technology-neutral. 
Torque Owner Jason "fireVein" Culwell
Just don't let the "it should have been done by now" people discourage you from keeping us updated.