Torque 3D 3.6 nearing release
by Daniel Buckmaster · 09/18/2014 (5:12 pm) · 33 comments
That's right! At long last, your new T3D Steering Committee is going to be making our first release. Those of you who follow our GitHub milestones with rapt attention may have noticed that our goal for releasing Torque 3D 3.6 is September 30. That day is rapidly approaching, and we're nearing our goal - as of writing this, GitHub tells me our issue list is 84% complete. But we can't get the rest of the way without you! That's right, you. If you use Torque, we want your input on proposed changes and modifications, to ensure that the engine's development is both democratic, and technically sound.
The goods
So what's in this release? You'll have to wait for the final release blog to get the precise details, but here are some rough statistics for you (with source): we've closed 144 issues or pull requests, of which 36 were bugs (i.e. the engine was broken or behaving wrongly), 47 were defects (code cleanup, more sensible behavior, general improvements) and 23 were new features. And there are still more of all of those to be processed!Notable new features include being able to officially generate projects with CMake for the first time, being able to use English names for common colours (like in T2D), Visual Studio 2013 support, Googletest unit tests, and hopefully one or two more special treats. But beyond those glamorous items, a whole host of improvements have been made throughout the codebase - old/dead code has been removed, compiler warnings resolved, visual glitches ironed out and documentation added.
A departure
At this time we'd like to say a fond farewell to Andrew Mac, who due to work commitments has had to resign from his position on the Steering Committee. He'll still be around in the community, but a bit less active. We thank him for his significant contributions to the engine and the Committee, and wish him the best of luck for the future!And, of course, that means we'll be looking for another Committee member to fill this vacancy. If helping to maintain, develop and grow a large open-source project like Torque sounds like a fun time to you, and you have skills and energy to bring to the Committee, we'd love to hear from you! More information about the Committee is available on our website.
Getting involved
If you're a Torque user and you want to help improve the engine, we need you! Right now especially, we're looking for testers to review this branch with a 64-bit compiler compatible version of the engine, which we'd like to include in the 3.6 release. Otherwise, a great place to start is with our Final Review label. We tag PRs with it when we've looked it over, we like it, and we think it's ready to merge. It's like that moment at weddings when they ask if anyone has any objections. If the final review queue is looking a but short, take a look at the rest of our issue list, which you can point at any milestone we have, and have a look for issues that nobody's commented on.Does the issue affect you? Does it solve a problem you've had? Does it solve it in the right way? Would you have to rewrite parts of your game if this change were accepted? Does the code look stable and useful to lots of users of the engine?
These are the questions we'd like to ask every single user if we could. So give us a hand and make your voice heard!
The future
Torque, and the broader game engine landscape, are changing rapidly these days. After this release, the SC will be taking some time to regroup and discuss what we can do with the engine in the immediate future. We already have over 30 issues lined up for 3.7, and many more to work on that have been assigned to other milestones, or not assigned at all yet. In addition, we (and the community) will be continuing on our personal work with the engine - BeamNG's Linux and OpenGL work, Jeff's entity/component system, etcetera.We'll also be considering Torque's place in the developing engine marketplace - what makes Torque unique? What are its strengths, and why would you choose it over the competition? Especially when there is such good competition out there.
In conclusion,
Torque 3D 3.6 is coming, but we need your help! Much love, peace to all, and see you again at the end of the month when we announce the 3.6 release officially - if all goes well!
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#2
The market has gone through some major changes lately.
Once again the the number of plugins, the freedom to create something and call it your own, Its ease of use(I find Torque 3D easier than many other engines I have tried and worked with).
Which leads me to the the weakness of Torque 3D:
Lack of fbx support(pretty important).
Lack of the ability to import high polygon models(the 65K poly limitation with collada is rather annoying).
Lack of built in lighting features(such as Unity pro has and UE4 has).
Lack of DX11 support(many people has started but stopped).
Lack of Mac support(some people use those mac machines).
Lack of paid developers who dedicate all their time on the engine development.
Lack of strong console support.
Just to mention a few of the big drawbacks.
To mention what other competitors are offering then Epic Games has just donated a huge chunk of cash to Blender Foundation so Blender can get a strong fbx pipeline so people can use Blender when developing games with Unreal 4.
With Unreal 4 as an option now with access to the source codes and easy multi platform access and a built in lighting system that can easily outrun PureLight(which really needs to be built into the Torque 3D World Editor by the way so) then it is becoming harder than ever to justify the use of Torque 3D as a tech for future productions.
The very fact that GG had to opt for Unity(which is fair and understandable as tech is not religion) in one of their projects instead of using their own tech kind of show what competition Torque 3D is up against.
The many drag an drop features of Unity and Unreal also saves time and speeds up the development. Something Torque 3D can only dream about so far.
No matter how we put it then it is very comforting for small firms to pay a small amount every month or even a small royalty fee out of the sales and keep the engine developers full time on the tool and tech one uses.
As it is now many great developers will leave the Torque 3D steering community or the tech development as they get jobs that pay their bills(again that is fair and understandable) and that is a major weakness about our open source tech.
Torque 3D needs full time engine developers if it shall be able to compete on the engine market as the market is right now.
I will end the post with saying that I think that the Steering Community and all the many engine contributors are awesome and without all of you Torque tech would not have made it to where it is now. But we need you on full time and that you cannot deliver as you have other obligations(Schools, jobs etc.).
Hopefully my post is not offending anyone as I am just hoping to shed some light on the competition that Torque 3D MIT is facing in the market at this moment.
09/19/2014 (4:19 am)
Quote:We'll also be considering Torque's place in the developing engine marketplace
The market has gone through some major changes lately.
Quote:- what makes Torque unique?I would say TorqueScript, its many Editors(World/GUI/Particle), MIT license(that goes away with the use of Plugins), its many highly battle tested plugins(especially AFX and UAIK). Its networking.
Quote:What are its strengths, and why would you choose it over the competition?
Once again the the number of plugins, the freedom to create something and call it your own, Its ease of use(I find Torque 3D easier than many other engines I have tried and worked with).
Quote:Especially when there is such good competition out there.
Which leads me to the the weakness of Torque 3D:
Lack of fbx support(pretty important).
Lack of the ability to import high polygon models(the 65K poly limitation with collada is rather annoying).
Lack of built in lighting features(such as Unity pro has and UE4 has).
Lack of DX11 support(many people has started but stopped).
Lack of Mac support(some people use those mac machines).
Lack of paid developers who dedicate all their time on the engine development.
Lack of strong console support.
Just to mention a few of the big drawbacks.
To mention what other competitors are offering then Epic Games has just donated a huge chunk of cash to Blender Foundation so Blender can get a strong fbx pipeline so people can use Blender when developing games with Unreal 4.
With Unreal 4 as an option now with access to the source codes and easy multi platform access and a built in lighting system that can easily outrun PureLight(which really needs to be built into the Torque 3D World Editor by the way so) then it is becoming harder than ever to justify the use of Torque 3D as a tech for future productions.
The very fact that GG had to opt for Unity(which is fair and understandable as tech is not religion) in one of their projects instead of using their own tech kind of show what competition Torque 3D is up against.
The many drag an drop features of Unity and Unreal also saves time and speeds up the development. Something Torque 3D can only dream about so far.
No matter how we put it then it is very comforting for small firms to pay a small amount every month or even a small royalty fee out of the sales and keep the engine developers full time on the tool and tech one uses.
As it is now many great developers will leave the Torque 3D steering community or the tech development as they get jobs that pay their bills(again that is fair and understandable) and that is a major weakness about our open source tech.
Torque 3D needs full time engine developers if it shall be able to compete on the engine market as the market is right now.
I will end the post with saying that I think that the Steering Community and all the many engine contributors are awesome and without all of you Torque tech would not have made it to where it is now. But we need you on full time and that you cannot deliver as you have other obligations(Schools, jobs etc.).
Hopefully my post is not offending anyone as I am just hoping to shed some light on the competition that Torque 3D MIT is facing in the market at this moment.
#3
Unique/Strengths:
OPEN SOURCE
Has the unique mascot of Kork-Chan:
09/19/2014 (6:46 am)
Quote:Awww, it'll be like losing an old friend ... well, like losing that annoying guy who pops round at parties and always calls you Dave ...
compiler warnings resolved
Unique/Strengths:
OPEN SOURCE
Has the unique mascot of Kork-Chan:
#5
Torque by far is an amazing piece of tech. I know, this open source thing that everyone talks about...well it's true. I really don't want to give in the intention of engine bashing but...
A few of my buddies and myself from an online community decided to make a game (which I will provide more details in the upcoming months with a blog or two ;)). We decided for a while to try out Unity free (We can't afford a $1500 just to get fancy effects and still NO engine source code access too). It was good. Until you hit a roadblock. Once you hit a roadblock, you're dead. Let me clarify my point on that. We wanted to have an object have a dynamic cubemap (something that exists in stock Torque3D with a little bit of script to accomplish). Well, it turns out that Render To Texture in unity free, don't exist! There's no easy way to accomplish that through theirAPI that they provide. Sure, they give you access to GL functions in script, but its openGL 1.1 things like glbegin() and glend()...fixed function crap that nobody wants to use in 2014.
Sure, Unity's renderer is awesome, they have Direct3D11 and support like a dozen platforms, but at the end of the day, we couldn't accomplish what we needed.
My point in giving that little story, was to point out a flaw that I see personally in game dev. If you don't get access to the deep parts of the engine without paying a lump some of money, your screwed over. And no, not every game needs this, and prototyping is fine. Unity is an excellent choice for that by far, hands down. But eventually, for anything serious that is being involved, there's a good chance that you will need and want that access deep down inside to the heart of the engine.
09/19/2014 (9:30 am)
Torque's strengths. I could go on all day about Torque's strengths, but I won't as I don't want to bore all of you.Torque by far is an amazing piece of tech. I know, this open source thing that everyone talks about...well it's true. I really don't want to give in the intention of engine bashing but...
A few of my buddies and myself from an online community decided to make a game (which I will provide more details in the upcoming months with a blog or two ;)). We decided for a while to try out Unity free (We can't afford a $1500 just to get fancy effects and still NO engine source code access too). It was good. Until you hit a roadblock. Once you hit a roadblock, you're dead. Let me clarify my point on that. We wanted to have an object have a dynamic cubemap (something that exists in stock Torque3D with a little bit of script to accomplish). Well, it turns out that Render To Texture in unity free, don't exist! There's no easy way to accomplish that through theirAPI that they provide. Sure, they give you access to GL functions in script, but its openGL 1.1 things like glbegin() and glend()...fixed function crap that nobody wants to use in 2014.
Sure, Unity's renderer is awesome, they have Direct3D11 and support like a dozen platforms, but at the end of the day, we couldn't accomplish what we needed.
My point in giving that little story, was to point out a flaw that I see personally in game dev. If you don't get access to the deep parts of the engine without paying a lump some of money, your screwed over. And no, not every game needs this, and prototyping is fine. Unity is an excellent choice for that by far, hands down. But eventually, for anything serious that is being involved, there's a good chance that you will need and want that access deep down inside to the heart of the engine.
#6
Re: strengths and weaknesses of Torque... others have said most of the relevant points, clearly the free source access with unencumbered license and the helpful community are huge, and of course the helpful editors, very effective network code, etc. all add to its appeal.
However, I've struggled for years with the question of whether to leave it behind forever or not. It might be good to recognize the real reason myself and probably a large number of old timers still active in this community are here: the *inertia* of having years spent learning this engine and building our projects around it.
The fact is, it takes a really long time to get good at using a 3D game engine, any 3D game engine, and once you've developed a large and complicated project that is connected to source code hooks all over the engine, it's REALLY hard to move that, even if you do find another open source engine to move it to.
However, that being said, I would have to say that the biggest weakness of Torque is the rendering engine itself. Everything around it is pretty awesome, and its true that it's been whipped up into a pretty shiny state by the hard work of everybody here, but when you dig in deep you will find an engine that was originally written by way too many people, WAY back in the distant past of 3D games. While I was working at Garage Games the next big plans for the engine included a huge revamping of shapebase class and removal of all the massive bloat carried along from its Tribes history, but it seems unlikely that any such huge projects will be undertaken by anyone who can only work on it part time.
What I would really love to see happen to Torque someday is a gradual wedging apart of its features in such a way that we could plug an entirely different rendering engine (specifically one based on OpenSceneGraph, as the biggest open source hub for 3D scenegraph code out there AFAIK) into it and still use the rest of our tools, torquescript, missions, art and editors. That would solve all kinds of import and other problems, and maintenance of the actual rendering engine would rest with a much larger open source project.
Of course, that represents a massive amount of work as well, so who knows, but that's my two cents for the moment.
Oh, also, there has been much talk about FBX, and while this resource is painfully out of date and never did work perfectly, I'm not sure that everyone knows it even exists:
https://github.com/ChrisCalef/Torque3D/tree/fbx
This is a release of my FBX import code from Ecstasy Motion. It has a lot of problems, but in Ecstasy at least I am able to load models from Mixamo, at least, and they seem to work fine. Many other FBX models end up with horrible skeleton problems. It is up on github for anyone to grab and take a look at, and hopefully we can bring it up to date and PR it into the engine someday, that is unless ASSIMP renders it irrelevant (still very interested in that project, Andrew Mac!!)
Don't just grab that repo and try to run with it, btw, as it's two years out of date, but you might want to just pull my commits from it into a new repo. Mostly it's code in the ts folder, plus a hookup to the FBX SDK.
09/19/2014 (9:45 am)
Wow, great job you all! I must say I've been pleasantly surprised to come back to this community after a long break and find so much forward activity. Thank you so much Daniel and all the other SC members for your time and hard work.Re: strengths and weaknesses of Torque... others have said most of the relevant points, clearly the free source access with unencumbered license and the helpful community are huge, and of course the helpful editors, very effective network code, etc. all add to its appeal.
However, I've struggled for years with the question of whether to leave it behind forever or not. It might be good to recognize the real reason myself and probably a large number of old timers still active in this community are here: the *inertia* of having years spent learning this engine and building our projects around it.
The fact is, it takes a really long time to get good at using a 3D game engine, any 3D game engine, and once you've developed a large and complicated project that is connected to source code hooks all over the engine, it's REALLY hard to move that, even if you do find another open source engine to move it to.
However, that being said, I would have to say that the biggest weakness of Torque is the rendering engine itself. Everything around it is pretty awesome, and its true that it's been whipped up into a pretty shiny state by the hard work of everybody here, but when you dig in deep you will find an engine that was originally written by way too many people, WAY back in the distant past of 3D games. While I was working at Garage Games the next big plans for the engine included a huge revamping of shapebase class and removal of all the massive bloat carried along from its Tribes history, but it seems unlikely that any such huge projects will be undertaken by anyone who can only work on it part time.
What I would really love to see happen to Torque someday is a gradual wedging apart of its features in such a way that we could plug an entirely different rendering engine (specifically one based on OpenSceneGraph, as the biggest open source hub for 3D scenegraph code out there AFAIK) into it and still use the rest of our tools, torquescript, missions, art and editors. That would solve all kinds of import and other problems, and maintenance of the actual rendering engine would rest with a much larger open source project.
Of course, that represents a massive amount of work as well, so who knows, but that's my two cents for the moment.
Oh, also, there has been much talk about FBX, and while this resource is painfully out of date and never did work perfectly, I'm not sure that everyone knows it even exists:
https://github.com/ChrisCalef/Torque3D/tree/fbx
This is a release of my FBX import code from Ecstasy Motion. It has a lot of problems, but in Ecstasy at least I am able to load models from Mixamo, at least, and they seem to work fine. Many other FBX models end up with horrible skeleton problems. It is up on github for anyone to grab and take a look at, and hopefully we can bring it up to date and PR it into the engine someday, that is unless ASSIMP renders it irrelevant (still very interested in that project, Andrew Mac!!)
Don't just grab that repo and try to run with it, btw, as it's two years out of date, but you might want to just pull my commits from it into a new repo. Mostly it's code in the ts folder, plus a hookup to the FBX SDK.
#7
Seriously, though, I don't want my previous post to sound too hard on Torque... The editors, the networking code, even the dts/dsq modeling formats, all the shader work people have done, the sound layer, many subcomponents of Torque would be useful on their own. As an example, I've thought a lot about using the Torque mission editor to arrange objects for my big side project using FlightGear (OpenSceneGraph-based GPL flight simulator, flightgear.org) - they have a way of adding objects to the scene but it's terribly inefficient compared to the T3D mission editor. I've also been very happy to know I have the DTS/DSQ format in my back pocket, so to speak, as an efficient and unencumbered free software modeling format with which to potentially handle skeletal mesh deformation and animations in FlightGear, which can't use FBX SDK for GPL reasons.
In terms of the actual engine code though, here is a quote from a conversation on the Ogre3D forums way back in 2009. It's from a guy named Tony Richards, I don't know anything else about him, but the content seems worth looking at here:
The full conversation can be found here:
http://www.ogre3d.org/forums/viewtopic.php?f=1&t=50715
Keep in mind this thread is from five years ago of course... but we all know which things have changed in that time, and which things haven't. :-)
09/19/2014 (11:10 am)
Damn, crickets... c'mon people, what does it take to start a good flame war around here? :-)Seriously, though, I don't want my previous post to sound too hard on Torque... The editors, the networking code, even the dts/dsq modeling formats, all the shader work people have done, the sound layer, many subcomponents of Torque would be useful on their own. As an example, I've thought a lot about using the Torque mission editor to arrange objects for my big side project using FlightGear (OpenSceneGraph-based GPL flight simulator, flightgear.org) - they have a way of adding objects to the scene but it's terribly inefficient compared to the T3D mission editor. I've also been very happy to know I have the DTS/DSQ format in my back pocket, so to speak, as an efficient and unencumbered free software modeling format with which to potentially handle skeletal mesh deformation and animations in FlightGear, which can't use FBX SDK for GPL reasons.
In terms of the actual engine code though, here is a quote from a conversation on the Ogre3D forums way back in 2009. It's from a guy named Tony Richards, I don't know anything else about him, but the content seems worth looking at here:
Quote:
Re: Ogre vs Torque3d
Postby Tony Richards » Thu Jun 18, 2009 3:44 pm
You can't really compare apples to apples very easily with Ogre vs Torque 3D, even if you were only comparing the rendering engines.
I could make claims about how you can push animations off the CPU and onto the GPU, which is true of both Ogre and T3D, but you cannot do it on T3D without writing a whole lot of C++ code. With Ogre it's a cinch... all it takes is a vertex shader and a material script.
It's difficult making comparisons like this. You always get a GG employee or a fanboi saying "Yes, but you can do that with Torque too... you have the source code, all you have to do is write it." :roll:
I could provide dozens of comparisons, but in the end Ogre ends up being more powerful, more flexible, and it has a better design and implementation.
Looking at the source code, Ogre looks like it was written by an extremely talented professional. Torque looks like it was written by a variety of people of a variety of skill levels. Some are talented (Mark Frohnmayer), some amateurish but young and eager (Josh Englebretson), and a wide variety in between. But, the problem now is the bulk of the talent is gone, they've lost a lot of tribal history (pun!), and there's not a good strong talented technical lead holding the keys and performing the required code reviews.
One thing that makes Ogre so much better is because it gives you the ability to do more without modifying a bunch of high-entropy code. That's due to the fantastic Object Oriented Design that the Ogre developers use.
Torque, although it uses C++ and is designed with OO in mind, the design breaks many of the rules of OO. (Inheritance chains involving completely unrelated classes, broken encapsulation, unclear interfaces, and the development view of the architecture is a big ball of MUD... but then that gets into architecture and not design and that opens a whole other can of worms.... don't get me started. ;-) )
The full conversation can be found here:
http://www.ogre3d.org/forums/viewtopic.php?f=1&t=50715
Keep in mind this thread is from five years ago of course... but we all know which things have changed in that time, and which things haven't. :-)
#8
www.garagegames.com/community/blogs/view/22794
/lurk (insert *quickly*, and sure)
Congrats all around on the work so far folks.
09/19/2014 (11:36 am)
/unlurkQuote:While I was working at Garage Games the next big plans for the engine included a huge revamping of shapebase class and removal of all the massive bloat carried along from its Tribes history, but it seems unlikely that any such huge projects will be undertaken by anyone who can only work on it part time.
www.garagegames.com/community/blogs/view/22794
/lurk (insert *quickly*, and sure)
Congrats all around on the work so far folks.
#9
See, there I am, totally out of the loop. Very interested in this "Barebones" thing I hear about as well, Daniel...
While we're on the subject of potential simplifications, though, how about this one... didn't Matt Fairfax once, back in the day, make a client only version of Torque? Is that concept also fleshed out and available as a branch on somebody's repo somewhere? While most of us are probably here to create networked multiplayer games, the usability of T3D for a game or app that is known in advance to be _only_ single player and local is _vastly_ complicated by the internal server/client architecture. I hope this has already been nailed down and someone can merely point me to it, but if not I'd consider putting this on the list of (template?) options.
09/19/2014 (11:57 am)
@Azaezel, Jeff Raab: NOICE!!! See, there I am, totally out of the loop. Very interested in this "Barebones" thing I hear about as well, Daniel...
While we're on the subject of potential simplifications, though, how about this one... didn't Matt Fairfax once, back in the day, make a client only version of Torque? Is that concept also fleshed out and available as a branch on somebody's repo somewhere? While most of us are probably here to create networked multiplayer games, the usability of T3D for a game or app that is known in advance to be _only_ single player and local is _vastly_ complicated by the internal server/client architecture. I hope this has already been nailed down and someone can merely point me to it, but if not I'd consider putting this on the list of (template?) options.
#10
But those are all future plans, however far they are along, and aside from the quick-briefing, won't go into those more in-blog. Far more important at present to aknowlege the yeoman's work that's gone into sprucing up the 3.6 release, and finish crossing the ts and dotting the is on what's left in the queue.
09/19/2014 (12:45 pm)
There's a few things cooking. Would be the tutorial barebones branch, yes. Matter of fact, we had an quickie irc talk earlier this week (that's still here too) about the merits and flaws of setting up interactivity demos in a networked and non-networked environment when it comes to educating new users.But those are all future plans, however far they are along, and aside from the quick-briefing, won't go into those more in-blog. Far more important at present to aknowlege the yeoman's work that's gone into sprucing up the 3.6 release, and finish crossing the ts and dotting the is on what's left in the queue.
#11
@Az: thanks for the links!
09/19/2014 (1:08 pm)
Yes, absolutely, and I hope my comments aren't taken as a thread hijacking. Incredible work thus far, everybody! If you had asked me four years ago, I never would have predicted this much progress. Kudos all around!!!@Az: thanks for the links!
#12
Thanks for your time on the committee Andrew! Good luck in your new endeavors!
And sorry for the partial hijack....
09/19/2014 (2:50 pm)
Is Ogre actually a game engine now? Back in the day it was a freakin' awesome rendering suite, but not a "game engine." In fact, a merger of T3D with the Ogre rendering stuff would be awesome - but I don't think the licences are entirely compatible....Thanks for your time on the committee Andrew! Good luck in your new endeavors!
And sorry for the partial hijack....
#13
Ogre3D is now under MIT as well.
http://www.ogre3d.org/licensing
Nothing stops you or any other from merging, except that is, time and money, which very often stops a lot of people in real life.
09/19/2014 (3:39 pm)
@RanftOgre3D is now under MIT as well.
http://www.ogre3d.org/licensing
Nothing stops you or any other from merging, except that is, time and money, which very often stops a lot of people in real life.
#14
I know that Josh Engbretson successfully spliced Ogre into TGE/TGEA back in the day: www.garagegames.com/community/blogs/view/14036
The concept has fascinated me ever since I heard of it, but I'm not at all sure how much work it actually would entail. Ogre is a hell of a renderer though. Also, since 2010 it's been released under MIT, so I don't think there would be any licensing problems with sharing their code.
09/19/2014 (3:45 pm)
It's still just a rendering engine AFAIK, there is a "mission editor" project called Ogitor that helps a lot with designing levels (but nowhere near as advanced as Torque's), and I think you're still pretty much on your own with regard to sound, networking, etc.I know that Josh Engbretson successfully spliced Ogre into TGE/TGEA back in the day: www.garagegames.com/community/blogs/view/14036
The concept has fascinated me ever since I heard of it, but I'm not at all sure how much work it actually would entail. Ogre is a hell of a renderer though. Also, since 2010 it's been released under MIT, so I don't think there would be any licensing problems with sharing their code.
#15
Glad to see you floating around here still ;)
And yes, I'd suggest if you've got the time, poke around here a bit. There's a lot of pretty solid projects cooking.
My E/C stuff is only one.
09/19/2014 (5:43 pm)
@ChrisGlad to see you floating around here still ;)
And yes, I'd suggest if you've got the time, poke around here a bit. There's a lot of pretty solid projects cooking.
My E/C stuff is only one.
#16
Yeah, I certainly will. Definitely interested in your E/C project, I never did quite understand exactly what that concept looked like in practice even when everybody in the office was talking about it all the time. Will be fun to sit down and see what you're actually doing there when I get a chance.
09/19/2014 (7:03 pm)
Thanks, Jeff! Yeah, I certainly will. Definitely interested in your E/C project, I never did quite understand exactly what that concept looked like in practice even when everybody in the office was talking about it all the time. Will be fun to sit down and see what you're actually doing there when I get a chance.
#17
Yup, if you have any questions, feel free to fire them at me. I'd be happy to answer :D
09/19/2014 (8:30 pm)
Haha, thanks.Yup, if you have any questions, feel free to fire them at me. I'd be happy to answer :D
#18
09/19/2014 (9:25 pm)
wait in hope! 
#19
In last time I most only make collada files and not DTS. Its a nice workflow with blender to torque now.
09/20/2014 (6:47 am)
What i like more and more in T3D is that it work well when u made models with blender and import it as collada.In last time I most only make collada files and not DTS. Its a nice workflow with blender to torque now.
Chris DeBoy
A client with built-in editors(this should be focused on for more Steam Workshop-type stuff, like making mods and what-not), relative ease with which to build up an FPS game(We should also focus on more game type starter packs), levels are essentially just code files.
> What are its strengths?
Comfortably small, tight-knit community full of knowledgeable people who can help out, source code access, low-latency net code, relative ease with which to make modifications to the engine(for the most part(Lookin' at you, inheritance hell.))
> and why would you choose it over the competition? Especially when there is such good competition out there.
Permissible license, built-in editors, Entity Component System(hopefully merged in the relative near future(same for Linux support)), Bare-bones FPS template with which to build off of, and I can build a game with entirely open source tools.
Hopefully that helps.
Also someone please add ragdoll support.