Meant to be Seen

Greetings!

I'm David Wyand, Head of Torque 3D Development at GarageGames. I'm also the owner of Gnometech Inc. hence my handle on these forums. I hope to be posting here about my experiences as I start to work on my first Rift game, but today I wanted to talk about Torque 3D.

Torque 3D is a complete game engine that went open source under a MIT license back on September 2012. All of its source is available on GitHub: https://github.com/GarageGames/Torque3D I've seen a few people bring up the engine here on MTBS (I've been a lurker since the Rift Kickstarter), especially following my blog talking about my first steps in having the Rift work with it.

This week I merged in all of my changes for the Rift to our development branch and today I have posted a blog with our announcement. You may head over there to read more about what was done and what is still left to do.

We have also put together a new demo game that anyone may download and try out: Rift Valley. The download link is near the bottom of my blog. Please give it a try (don't forget to put on headphones) and I would appreciate any feedback you may have.



Enjoy!

- Dave

Wow, that looks stunning!

Any plans for Hydra integration? The gun begs for the Hydra

@Parallaxis:
Last month we did add Razer Hydra support to Torque 3D. You may read about it and download our Hydra Ryder demo on my blog. And I have experimented with combing the Hydra with the Rift within Torque 3D. Here's a picture of it in action from one of my other blogs:



There is still some work to be done, especially at the calibration stage. But my plan is to release a combined demo in the coming weeks. Now that the Torque 3D Rift support is mature enough, it is time to have some fun with it.

- Dave

How capable is the engine in regards to procedural geometry? Would I be able to easily generate new meshes and textures with code? Is it easy to modify existing meshes? What is the memory management like? How much support for IK is there?

@Mystify:
You have complete access to the source code so in essence you can make the engine do whatever you want. But as for generating your own geometry on the fly you can certainly do that. I would recommend checking out the T3D/examples source directory for some examples on how to do this: https://github.com/GarageGames/Torque3D ... D/examples.

The memory management uses a system of pools where possible to reuse resources. This includes the graphics pipeline.

Unfortunately, there isn't any IK support in our Player class at the moment.

- Dave

Yesss, the thread I've been waiting for! Every day I see a bunch of posts pondering Unity and UDK and lamenting that we don't have more choices for Rift development - guys, we do! The Torque 3D team is frankly doing an obviously better job of Rift integration than the Unity team (Dave, they could apparently use your helping sorting out their own deferred rendering implementation ), and all for zero dollars and with the source code yours to fork, spindle, and mutilate. Don't like UDK's licensing terms and lack of an asset store? The MIT license Torque uses allows for totally unrestricted use for free, forever, and the Torque Store has more high-quality art packs and special effects tools available all the time - you can even create your own content and submit it for sale (just contact Derek Bronson).

I'm still not sure if UDK or Torque 3D is right for my game projects, but I'd be an idiot to not thoroughly explore the totally free and open option (and the one with serious procedural generation possibilities, OMG ). There are only two questions I haven't been able to fully answer that are holding me back:

Is there any latency mitigation stuff UDK is doing that Torque 3D can't or won't be exploring? 16 milliseconds per frame is damned impressive, under even the ideal latency Abrash suggests is necessary for VR to feel really good, and I was thrilled to read this line in the announcement: "Two strategies that I think could be put into Torque 3D include preventing GPU buffering, and view bypass." Carmack goes way over my head with stuff like that blog post, so even after muddling through his discussion I'm left wondering: Is "view bypass" the same thing Epic mentioned in KS Update #25, "sensor update on the render thread"? Is Torque 3D on the verge of being the lowest-latency engine in existence that features drop-in Rift support?

Also, what's the deal with the FPS Tutorial? It appears to be one of the most elegantly constructed tutorials I've ever seen, but that warning about it being out of date has kept me from diving in. The steering committee notes suggest there's only one chapter that still needs reworking, and it's been on the verge of completion for a couple weeks - are all the other updated chapters already live on the website, or will the whole tutorial change once chapter 8 is finished? Can you give us any kind of ETA?

To Gnometech and the rest of the Torque family, thank you. It's entirely clear from my conversations here that UDK and Unity simply were not enough options for us prospective Rift devs, and Torque's features and licensing terms are beyond impressive. I greatly look forward to experimenting with your engine, picking apart some code, and seeing what you continue to add to it and what everyone else cooks up with it.

Somebody with a Rift go download the Rift Valley demo and report back!

That does sound pretty good, but I've come to despise working in C++.

Very cool that you support the Rift, and that the Linux port is getting in shape. The engine has unlimited potential now beeing open source. Maybe even a branch dedicated to VR appears one day

@ Mystify

I'd use Blender to create terrain and then export it f.e into Torque. http://projects.blender.org/frs/?group_ ... ase_id=342

Here's a nice example for creating terrain in Blender:

[youtube-hd]https://www.youtube.com/watch?v=Af6A1uvNhyM[/youtube-hd]

STRZ wrote:Very cool that you support the Rift, and that the Linux port is getting in shape. The engine has unlimited potential now beeing open source. Maybe even a branch dedicated to VR appears one day

@ Mystify

I'd use Blender to create terrain and then export it f.e into Torque. http://projects.blender.org/frs/?group_ ... ase_id=342

Here's a nice example for creating terrain in Blender:

[youtube-hd]https://www.youtube.com/watch?v=Af6A1uvNhyM[/youtube-hd]

That's great, but I really, really need procedural content generation for my game. Not just for terrain, but I am generating entire levels, buildings, doors, etc. Its part of my coding style, I can get a lot of content with practically no external resources.

Mystify wrote:I really, really need procedural content generation for my game. Not just for terrain, but I am generating entire levels, buildings, doors, etc.

Wait, you're a procgen guy but you refuse to work in C++? OMG guys, Notch is on MTBS! I really like Minecraft a lot, sir, but your engine is terrible!

Seriously, though, I'm also fascinated by this stuff. I don't know much about procgen support in UDK, but I get the sense that's mostly because you can't really do much of it with the access UDK provides to the underlying code. Unity has some impressive procgen options, but the other limitations of the engine (not to mention the $1500 pricetag) make it unattractive to me. I really think Torque is the best bet us procgen coders have right now short of maybe cooking up our own Rift implementation in Ogre3D. I'm building an FPS game here, there are only so many wheels I want to reinvent...




EDIT: Additional paragraph.

Mystify wrote: That's great, but I really, really need procedural content generation for my game. Not just for terrain, but I am generating entire levels, buildings, doors, etc. Its part of my coding style, I can get a lot of content with practically no external resources.

Then you may spend 500$ for this program http://www.esri.com/software/cityengine ... royed-city

Blender has a Esri importer since january http://blenderartists.org/forum/showthr ... r-importer

The guy who created the scene in the provided esri link imported it all into Ogre3d, and this should be possible with Torque too. There may be even a equally capable open source alternative to the esri stuff. But you may need Linux http://sourcepole.ch/the-state-of-qgis-globe

nateight wrote:

Mystify wrote:I really, really need procedural content generation for my game. Not just for terrain, but I am generating entire levels, buildings, doors, etc.

Wait, you're a procgen guy but you refuse to work in C++? OMG guys, Notch is on MTBS! I really like Minecraft a lot, sir, but your engine is terrible!

Seriously, though, I'm also fascinated by this stuff. I don't know much about procgen support in UDK, but I get the sense that's mostly because you can't really do much of it with the access UDK provides to the underlying code. Unity has some impressive procgen options, but the other limitations of the engine (not to mention the $1500 pricetag) make it unattractive to me. I really think Torque is the best bet us procgen coders have right now short of maybe cooking up our own Rift implementation in Ogre3D. I'm building an FPS game here, there are only so many wheels I want to reinvent...
.

My problems with c++ are mainly that its error messages are hopelessly cryptic, and that I hate dealing with memory management. I always end up fighting the language. I want to know what went wrong, and I don't want to worry about the details of memory usage.
I haven't run into any issues with unity so far, and $1500 is affordable for me, and well worth it to me if it will provide a smoother development experience.

Mystify wrote:My problems with c++ are mainly that its error messages are hopelessly cryptic, and that I hate dealing with memory management.

Well, just stop writing bad code and you won't have to deal with so many error messages?

I get the memory management gripe, it's the primary reason I'm in love with Python and scared about all the brain rewiring I'll need to do to tackle Torque. When you get sufficiently close to an engine, though, isn't the only sure way to optimize your game to leave almost nothing to chance and lax garbage collectors? One major concern I have about Unity is that they don't seem to be taking the VR latency issue seriously. Mr. Wyand actually agrees with the premise that Unity is really good at getting out of your way and letting you test and create things rapidly; my (entirely speculative) concern is that all the stuff Unity is doing behind the scenes to enable this is insufficiently optimized, and a whole lot of Unity devs are going to wind up frustrated when their games are making people ill with 60+ millisecond headtracking latency and Torque and UDK games are buttery smooth at 20ms.

Damn lonely in that demo! But very nice! I loved stacking turrets, then blowing them up. And firing grenade canisters high into the air, then trying to catch them on the way down. Very nice for demoing the Rift to the uninitiated. Good things shall come from this I suspect. Thx.

--p.s. the out of body experience after death was interesting too, thought I had positional tracking for a moment.

Thanks, guys!

@nateight:
The 16mspf I mention is actually the maximum rendering target we were trying to hit on slower machines. On more recent machines you should be able to hit 7-8mspf with the Rift Valley demo. But that is just the time for a single frame render. If you are looking at the overall latency from when you rotate your head until the last pixel is drawn and cleared from the display, then it will be more than that. I don't have the means here to actually measure that total latency.

And feel free to jump into our FPS Tutorial. The last remaining piece that needs to be modified is a reference to our old Toolkit in Chapter 8 and creating a package for distribution. The Toolkit was in use when Torque 3D was a commercial engine, and has since been replaced with the Project Manager. The rest of the tutorial should successfully carry you through the whole process.

- Dave

Grats Dave. I'll see you and your team in the game.

nateight wrote:Unity has some [url=http://sixtimesnothing.wordpress.com/]impressive procgen options[/url...

Hmm... That's a FOSS project it's pointing to. MIT license.

https://code.google.com/p/unityterraintoolkit/

I'm a explore this and see what a BountySource fundraiser for getting this ported to Torque would look like. Perhaps the project should be a wrapper for Unity plugins, with this one use case as the first release.

@Gnometech:

Just a quick question: what is your world editor like in comparison to Unity? May sound a bit noobish, but I've never used world editors before Unity, but I think it works awesome. Either way, I love working with FOSS low level engines, so props to you for joining the virtual game

@Kajos:
I can't really answer that as I haven't played with Unity much. I've heard other people state that Torque 3D is between UDK and Unity for ease of use. If you're curious you could check out our FPS Tutorial. Here is a direct link to the World Editor section: http://www.garagegames.com/products/tor ... orldeditor.

- Dave

This is great news, and its awesome that Rift developers have another option. Especially one that is free and open-source.

@GnomeTech:

Another question: what do you use for profiling? The standard gcc profiler?

Might be handy to have a features page for these things, I couldn't find one on your website.

@Kajos:
While you are free to use any compiler profiling on hand, Torque 3D does have some built-in profiling tools. In anything but a TORQUE_SHIPPING build you may hold down CTRL-F3 for a while and then release it. This will write a profile dump to your game executable's directory as profilerDumpToFile*.txt.

The profiling is done using matching PROFILE_START(name) and PROFILE_END() blocks, or the newer PROFILE_SCOPE(name) that doesn't require a matching end. You may search the engine for these to see how they are used (and feel free to add your own to track down an issue).

The two files you want to look at for more information are:
https://github.com/GarageGames/Torque3D ... profiler.h
https://github.com/GarageGames/Torque3D ... ofiler.cpp

I thought we had some docs on using the profiler but all I could come up with on the GarageGames' site were some old references. This definitely is a good place for us to fill in some information.

- Dave