Jump to content

Torque 3D 3.7 released

Recommended Posts

3.7 is out in the wild! We've run a bit into overtime, but the additional work squeaked in at the end was worth it. You can grab a package with the Project Manager and Windows binaries from here, or simply 'git pull' the master branch to get the latest version of the source.

We've seen a lot of work go into 3.7 and it's been a pretty hefty batch of polishing, improvement and fixes, with a dash of new stuff in for flavor. Over 200 issues and pull requests were closed for 3.7, plus another 40 or so which were categorised under the OpenGL milestone. Of all those, around 100 were bug/fixes, 40 were new features, and the rest were general improvements to performance or code quality.

As always, you can see the full list of changes in the release notes, but here are some highlights:


New stuff




Torque 3D running on top of my XMonad desktop, for extra street cred

As if you haven't heard this enough already, T3D now supports a Linux client with OpenGL rendering. This has been a herculean effort by some dedicated and talented programmers, so everyone give them a huge pat on the back! Particular thanks goes to Luis, who has spearheaded the effort, Lopuska, who has helped hugely, Azaezel, who has been diligent as usual, and BeamNG, who have supported Luis's efforts and the engine in general.

Note that not everything is working quite right in Linux just yet - there's still work to be done, especially around the platform layer, and some graphical bugs that no doubt lurk in different GFX/driver combinations. But this is a huge step towards full cross-platform support for the engine, and we're really happy to have Linux back.

Accumulation volumes


A demonstration of Sahara, from BitGap Games' site

After Konrad Kiss kindly released Sahara under an open-source license, Quinton Delpeche and Andrew Mac set about getting it ready to use with the current version of the engine. Andrew even made some improvements, so you can use multiple different accumulation types in the same level, defined by volumes you can place like triggers. We reckon this is a pretty cool feature, letting you reuse assets while tying your envionments together in a more cohesive style.



Ribbon projectile being tested in Airship Dragoon

Another fun litle graphical upgrade is the new Ribbon class, which can be attached to projectiles as in the image above, or even

. You can make all sorts of



A large navmesh in the new navmesh editor, formerly known as Walkabout

A little while ago, I open-sourced Walkabout, a formerly-commercial addon providing Recast/Detour integration. Thanks to popular demand I've cleaned it up a little and PRed it into the main engine, so everyone can enjoy the power of those fantastic libraries with Torque.

Bits and pieces


A subtle vignette and a tweaked atmospheric ray effect

One of my personal favourites is that you can now write anonymous functions in TorqueScript. Though they don't capture any surrounding variables, they're still useful for scheduling and callbacks! There's also a new vignette PostFX shader courtesy of J0linar, and an in-depth tweaking interface for the god-ray shader, thanks to Chelaru's first PR. Lukas also managed to get particles rendering to the glow buffer, which means fancy glowing particles!




As always, you can find the full changelog the wiki. But here I want to mention a couple of significant changes that may have implications for your project.


  • Most uses of ConsoleMethod have been changed to use DefineEngineMethod. The old macros haven't been removed, and are in fact still used for variadic script functions, which aren't currently possible with the DefineEngineMethod macros. But be warned that there are a lot of changes in this area, which may cause conflicts if you've modified any of the console methods.
  • James Urquhart's major console function call refactor has finally found its way in, which has meant significant refactoring to the way TorqueScript works under the hood, including new wrappers for console types. This has introduced some subtle bugs we've managed to find, but if you're relying on custom console methods and behaviour, we urge you to double-check those and make sure they still behave exactly as expected.
  • A bug in quaternion math has been fixed, but you might find that code relying on the broken behaviour needs to be changed.
  • There's a new version of the SimDictionary based on the C++11 STL hashmap. You'll find a commented-out #define in torqueConfig.h which you can enable if you like. According to the contributors, it's worth doing if you have a lot of SimObjects about at the same time.
  • The projects.xml file is now part of the main repo, instead of being part of the Project Manager repo. Just so you know, and don't go looking for it there.
  • isObject is now stricter about what's actually an object. Where before, the string "3.14" would be cast to the integer "3" and resolved to object ID 3, the whole string is now validated first, and if it's not a valid integer, it won't count as an object ID. (Note that the method still also accepts object names as usual.) This logic expands to other types of object resolution as well - so "3.14".getClassName() now won't work.

Extra goodies



The folks at GarageGames were kind enough to let the SC get access to some of the older Torque 3D demos - so we're really happy that we will soon be presenting them to you, reworked to use the latest engine version and totally open-source! This means that the Pacific, Sector T3D, and Deathball Desert demos will be coming to you soon. Jeff Raab has been taking the responsibility of getting them ported, and we're really excited to be able to give them to you soon.

While the Sector and Deathball demos are still being worked on, the Pacific demo and package are good to go. So, here are a couple of high resolution screen shots, and the links!

Pacific Demo

Pacific art and level package.

To utilize the Pacific package, just create a new Full template project, and drag-and-drop the package files over top of it, replacing the files it asks. Once you do, you'll have the assets and the level in the project, ready to use.


How many months overdue?


Five, sadly, according to our GitHub milestone. I can't remember how long I've been assuring people that it's okay, the release candidate will be out next week! And, after that, that we're just waiting for more tests and to fix the remaining issues before releasing properly. We on the SC will be the first to admit that we've been pretty slow to wrap this one up. What with this and that, and BeamNG's recent release tying up some of our most productive reviewers, we've been a little slow to get through that last 10% of work for the release.

So, with that in mind, let's chat a bit about what you can expect in the next release.


What's next


I had to double-check using my calculator, but it tells me that 3.8 would be the next step in line. What's on the docket for 3.8, you ask? We on the Steering Committee have been mulling over stuff we feel is pretty critical to Torque's advancement. A lot of it is the finalization and integration of several projects people in the community have been working on for a while now, while other parts pertaining to cleaning up the weak aspects you guys have to deal with constantly. Specifically:


  • Continue merging our massive backlog of pull requests! Seriously, it's hard to keep up with you lot.
  • Jeff's entity/component system. This is a massive and important refactoring, which is going to hit like a tsunami.
  • Some sort of plugin or package system for C++/scripts/content. This will be supported by
  • Improving the Project Manager - specifically, we want to rewrite it as a Torque application, instead of it using Qt, and beef it up with new features.
  • Improve Linux and OpenGL work - in particular, stability, and making sure we have feature parity across platforms.
  • Refactor ugly/old code. This is a constant war.
  • Review the physics layer. Common consensus dictates that the builtin 'Torque physics' shouldn't be privileged, but should be a backend the same way Bullet and PhysX are, meaning no more duplicated RigidShape/PhysicsShape split.

Quite a few of these are already far along, such as the entity/component work, and only need to be pushed to the finish line so they can be rolled in properly. Others are things that need to happen to keep the engine as pleasant and easy to use as possible.

But now, before I get too far ahead of myself - obviously not all of these are going to make it into 3.8, due to sheer impracticality. One of our biggest issues right now is that we're not doing a great job of providing a stable codebase for you, the users. The mix of lack of testing, huge codebase, large PRs with sweeping changes, and just a general shortage of eyes on the code has meant some projects like DHMC haven't been able to upgrade past 3.5.

This is a big problem for us, and we plan on taking it seriously. Our recent internal discussions have focused on the possibility of making 3.8 a 'boring' release focused on stability and improving our processes. We've also been encouraged to focus on some of the community projects out there, like James's hardware skinning, which will bring large benefits to most users of the engine with minimal pain.

So, as usual, we want to hear from you! Some people in the community we hear from a lot, but others tend not to be involved in the same channels of communication as frequently, and though others do an admirable job passing the message along to us in the SC when they can, we want to hear your opinions! Share your thoughts in the comments or in the forums - what would you like to see us focus on, and what would you like to do with the engine?




In no particular order, here are the people who contributed to this release's GitHub issues - we thank and salute you! If anyone's been left off this list, I apologise in advance - I got lazy and used a script to run through the authors of all closed PRs and issues, but we might have let a few slip through the cracks in odd circumstances!


  • jamesu
  • Levitator1
  • eightyeight
  • Azaezel
  • Areloch
  • LuisAntonRebollo
  • J0linar
  • John3
  • brakhane
  • bpay
  • pbrand
  • adambeer
  • antonyjones67
  • MusicMonkey5555
  • SteveYorkshire
  • JeffProgrammer
  • Lopuska
  • dragutux
  • Packer
  • ChelaruCatalin
  • rextimmy
  • cornytrace
  • Winterleaf
  • GuyAllard
  • lukaspj
  • chieling
  • skaughtx0r
  • qdelpeche
  • andr3wmac
  • just-bank
  • rasteron
  • thecelloman
  • aurodev

If I've forgotten anyone, I apologise profusely - it's not personal!

Link to comment
Share on other sites

  • Replies 57
  • Created
  • Last Reply

Top Posters In This Topic

Great work guys!

As far as suggestions for what I'd like to see in the engine, Hardware occlusion would be nice, I remember someone started work on it and didn't have a huge amount left to do, just a few things. For the engine plugin thing, perhaps have various interchangeable parts of the engine non-statically compiled and put in some sort of linked library, for example the physics engine could be in a "physics.dll" in the same directory as the engine and it could contain Bullet or PhysX and the abstraction layer for the engine. That way if I wanted to switch between Bullet or PhysX, I could just copy/paste a DLL instead of recompiling.


...Improving the Project Manager - specifically, we want to rewrite it as a Torque application, instead of it using Qt, and beef it up with new features.


Oooh, what kinda features?

Link to comment
Share on other sites

We've always talked about switching script templates to use packages, so you can automatically copy over more modular bits than just getting the whole enormous Full template every time you want to start a project. That's my main one. That would ideally include the ability to browse and download packages from some online registry.

That said, given the way things are going this might not be on the table for 3.8.

Link to comment
Share on other sites

Thank you for the Linux support! I must admit that I have no idea how to build this release on Linux. Could you guys please point me toward an updated tutorial/instructions on how to install this release. Am I missing something, as I cannot find a Linux binary.


Link to comment
Share on other sites

Just as an FYI, the OP has been updated to link to these!

Pacific Demo

Pacific art and level package.

To utilize the Pacific package, just create a new Full template project, and drag-and-drop the package files over top of it, replacing the files it asks. Once you do, you'll have the assets and the level in the project, ready to use.

If you guys note any oddities or issues, let us know!

Also, because the Pacific demo contains a majority of features of the engine, if you ever want to test something, I heartily recommend testing it with the pacific level. It makes for an excellent, standard benchmark.

Link to comment
Share on other sites

JeffR, thanks for the heads up with the pacific demo. I jsut tried it, and it is indeed very cool. However, I noticed that the Performance seems to be very bad on my machine. I get around 30 fps in the cave, and around 20 outdoors. My machine runs win8 X64, has 8gb ram, an AMD R9 270X 2048 MB graphics Card and the cpu is a AMD Phenom II X6 1070T. Note the demo does not stuttter, but i am still surprised of the low fps. Shouldn't I get better fps?

Link to comment
Share on other sites

I get from 35fps in the worst case to 70fps in the best case. All settings at max anisoptric filtering 16x, full HD 1920x1080.

So average maybe 45-50 fps for me and I got an AMD R9 280X.

Yes not the best performance, other games with similar graphics can give me maybe around double the fps, but playable.


Your performance is really a bit low, are you running under Linux? Or what settings do you use? I could still play the pacific demo with 20fps on my ancient PC with dual core and a low end graphics card.

Link to comment
Share on other sites

Duio, it's running under win 8 X64. 1920 x 1080, Fullscreen, all Settings maxed out. Can it be that the AMD processor is that slow? Also, I wonder how the Performance would be in a real game with lots of moving objects.

Link to comment
Share on other sites

OK, I was able to figure out that I needed to copy the Full template, into the My Projects folder. I then compiled, built, and Ninja. I got an executable file in my game folder along with all the folders like, art, core, levels, scripts, shaders, tools, web. I ran the executable in terminal. The splash screen came up. I clicked on the Empty Room option. Then my screen locked up. I don't know how to attach the full console.log. Seems I'm getting a repeating opengl error that locks up everything.


OPENGL: GL_INVALID_OPERATION error generated. <location> is invalid.


I'm getting that message about 1000 times. Please let me know if you need more information. I'm newbie, but I'll try to figure out how to get the info.


Edited by triggerfish
Link to comment
Share on other sites

When you say you get 20fps outside and I get 45fps outside and you have a R9 270x and I have a R9 280x you can get some comparison charts between those.


Yes maybe it's jsut the Card. However, I still think the Performance is really low. Is this a generel Problem of T3D right now? Performancewise, how does it compare to other engines? I think it's quite important for T3D to offer a good Performance also on low end Hardware.

Link to comment
Share on other sites

The 280x is is only around 10%-50% faster than the 270x depending on the game, so no idea why you only get 20fps while I get 45fps outside. May depend on the other hardware or the scene, since the demo has physics and sometimes when a lot of physics is going on this can kill the framerate.

Torque overall may be slower but you can still optimize it easily for lower hardware, you just have to leave out the more advanced features. Things like realtime lighting and postfx systems use the most performace.

Link to comment
Share on other sites

  • Create New...