Blog for Brian Ramage at GarageGames.com

TGEA Milestone 4.2 release

Brian Ramage — 2007-01-24T00:12:13+00:00

I wish I could say there's a ton of grand new things in the release, but really it's just been hundreds of hours of bug fixing, plugging memory leaks, etc. It's not super exciting, but it's the kind of polish and grunt work that we do so that you guys can be sure you're building on solid code and focusing on your gameplay rather than engine building.

We're close enough to release to call this a beta. There are still some issues present in this release, but they aren't major and we are fixing them at a rapid pace. We're asking licensee's to report issues they are seeing with 4.2 (that we don't report as already known) so that we can pick up anything we missed and make sure it's as tight as possible for 1.0 release.

There is a post in the private forums detailing what's in 4.2, what we're fixing, and a bunch of other things, so check that out if you are a licensee.

Since we've had it in QA for a while now, we've already fixed many of the issues that are in that release and we aren't seeing major bugs, so we're hoping to have RC1 out in a week or two if we don't get slammed with forum bugs.

TGEA Milestone 4 Demo

Brian Ramage — 2006-10-30T20:41:28+00:00

The TGEA Milestone 4 demo is finally ready for your viewing pleasure. You can grab it from Downloads/Devlopment Demos/Torque Shader Engine EA. Yeah, we've got a lot of renaming to do.

What is TGEA? After getting lots of feedback on the TSE name change to Torque Advanced
Technologies, we've decided to change it once more. TSE is now Torque Game Engine
Advanced or TGEA. We feel this accomplishes our goals of establishing that TGEA
has more to offer than shader support, that it fits in with our current branding
strategy, and that its acronym is not slang for "crap" to people with funny
accents.

This demo features the Orc once more, but he's not dancing this time thank goodness.
It's mostly just showing off the new MS4 lighting and self-shadowing that John Kabus
added to TGEA. The editor is functional, so you can play around with the lights
and add your own and such.

TGEA is coming along well, and we're feature complete at this point. From now on
its a cycle of bug fixing, testing and feedback until we're done. There are plenty
of docs to be added and refined as well, particularly in the areas of compiling on
VS2005 and using Materials. Some of the code also needs better documentation
such as the new RenderInstance rendering structure.

For those of you wondering where TGEA fits into the Torque product line, it is
our high end engine, aimed at serious 3D developers. A version of it runs on the
XBOX 360, so it's got console port potential. The core of TGEA is the same as
the Torque engine with the same object model, scripting, networking, and
editing tools. For the most part the core is exactly the same we as regularly
merge the code between the two. TGEA is a bit more complex to use than TGE, but
it offers higher performance and better visuals if you know what you're doing.

Pretty much all of the rendering code in TGE has been gutted in TGEA. Among
many improvements, it has:

- A full blown material system that can procedually generate shaders
based on artist preferences. It also can be used for storage of per-surface
data such as sound, physics info, and shader parameters.

- An integrated dynamic lighting and shadowing system that works alongside
the material system to take full advantage of shader surfaces.

- A prototype super large (Atlas) terrain system that can effeciently render
very large view distances, take up only a bit of video memory and yet deliver
unique non repeating terrain over several square kilometers.

- Fully transformable water with realtime reflections and underwater rendering

- A new batched rendering system to render objects like characters much more
effeciently than in TGE.

- Support for full screen effects such as glow, bloom, refraction, DRL, and HDR.

- An abstracted rendering layer to support multiple rendering APIs.

This engine has been in use internally for some time and was used for our hit
XBox Live Arcade title "Marble Blast Ultra". It's been pretty well battle tested
and is ready to be used to make your game or Serious application.

I personally can't wait to finish cleaning up the remaining bugs and get it out
the door, it's been a long time ;)

TSE Milestone 4

Brian Ramage — 2006-08-17T19:55:43+00:00

There are a lot of questions being asked about TSE with the announcement of Torque X and MS4 coming up fast. I thought I'd answer some of them here to clear things up a bit and also show some pretty orc pictures ;)

Thanks to John Kabus for all the lighting work he did to make this possible. Also thanks to Joe Maruschak and Mark McCoy for all painstaking tweaking to the Orc's textures and animations for this demo. Tim Aste has done some pretty cool work with his characters, check up with him for some more screenshots and video of his work. Pat Wilson and Ben Garney also jumped in for some last minute code tweaks on the Orc demo. Hope to get it to y'all soon.

On to the Q/A:

- When is MS4 release?
Sometime soon, not this week though.

- What's going on with TSE after MS4?
Like other launches, we will go through a period of bug fixes based on community feedback and push out some release candidates until we feel it's ready for a full 1.0 release.

- September release?
We're hoping that we'll be ready for a 1.0 release in September. It depends on how solid it's looking. We're not going to release in September unless it's really ready to go.

- Is the TLK included with TSE?
Yes, the TLK is fully integrated with TSE and has some new features like hardware shadowing (including self-shadowing), dynamic lighting with specular and normal mapping support, and HDR/DRL solutions. John can fill you in on the complete rundown of all the cool new features.

- What's going on with OpenGL and fixed function support?
OpenGL will not be supported in the 1.0 release, but we will have OpenGL and fixed function support further down the road.

- What's the status on Atlas?
Atlas is near to becoming "runtime feature complete" that means you'll have everything you need to run Atlas and import terrain from tools like l3dt. Full editor support will not be in for Atlas however in the 1.0 release. Please note that legacy (TGE) terrain runs just fine in TSE, incuding all the editing options. I believe it outperforms TGE's terrain as well, but I haven't actually done metrics to prove it.

- What's the deal with TSE/Torque X?
They are completely separate products with different feature sets. We'll be announcing more information about Torque X when it's closer to release. Torque X is completely C# managed code however, so if you are looking for a C++ solution with shaders, TSE is the only way to go. And of course, you can still go to the 360 with the TSE path with TSE 360.

- Will TSE be standalone when final?
Yes, TSE will be its own product, you won't need to purchase TGE in order to buy TSE. Yes, the price will go up.

- If I buy Early Adopter, will I have to pay extra for updates?
If you buy the Early Adopter version of TSE now, you will not have to pay anything for the full 1.0 update or bugs fixes from then on.

- Are we going to see some new demos we can download?
Yes, although when is a bit uncertain. We should be showing some of the new stuff at PAX coming up next weekend though, so stop on by to check them out.

- Will TSE ship with the Legions demo?
Probably not anytime soon no.

- What's going on with that forest picture on the DSOTD?
We might have an exciting announcement regarding that in the near future ;)

TSE optimizations

Brian Ramage — 2006-06-07T00:43:46+00:00

Hey everyone, just wanted to give a little bit of an update on the optimizations I've been working on for TSE. The batching system is working out very well as you can see in the fps of the screenshots I've posted. That's 10 space orcs in one shot running around 140 fps on a 3.4ghz P4 with an x800.

The batching essentially will group up draw calls into one manager, stuffing them into bins like mesh, interior, translucent, glow, etc. Each bin is then sorted by Material, and then at draw time, it will loop through each Material and send the appropriate draw and shader data to the card. It greatly reduces the number of render calls to the GPU and speeds things up quite a bit.

Since you can control the order that the bins are drawn and you can add your own fairly easily, a lot of the sorting issues in TSE should be eliminated, and also customized to the needs of your game.

While working on the new batching system I also found and resolved more issues related to the skinning system in TSE. Dynamic vertex buffers have now been fully implemented (as opposed to the existing 'volatile' vertex buffers), so transferring vertex data up has been further optimized.

In this lower shot, you can see the new "Warning" material that I've created to let the user know that there is an unmapped material in the scene. This should make it easier to detect than the previous "drop to fixed function with no lighting" system. It works for most of the major geometry - interiors and meshes.

This update should go live pretty soon, I'm just cleaning up some minor remaining issues and waiting for some Atlas changes to be complete before it's released. I'm also hoping to kill some bugs over the next few days that the community has brought to my attention.

Almost forgot to mention - the batching has been tested on Geforce cards and seems to have substantially increased performance. This scene runs about 120fps on Matt Fairfax's laptop with a Geforce 6800 in it. I put a 6600 in my machine and it runs about 40ps - not spectacular, but I'm not sure even one Orc ran at that speed previously.

I also want to mention the great work Joe Maruschak did on optimizing the space orc and his gun to use just two materials. This reduced the number of separate meshes in the orc from 27 down to 16 and almost doubled the performance when combined with the batching. Thanks Joe!

Tuesday Jul 26 22:00

Brian Ramage — 2005-07-26T22:00:26+00:00

Using quasi-procedural noise to break up texture tiling

Alex came to me the other day wondering if pixel shaders could be used to break up textures that are tiled a lot over large surfaces. After he explained exactly what he was looking for, I was pretty sure it could be done. Turns out, it was a piece of cake. I was able to whip up the shader in about 10 minutes yesterday on my first try (not even a compile error!).

The shader just uses the texture coordinates of the vertices to index into a simple noisy texture I made in photoshop. Here are the before and after pics:

And a blown up sample of the noise texture (the real one is 64x64 with each pixel being a different shade).

Here's what the shader looks like (shader model 2.0):

VERTEX:

//-----------------------------------------------------------------------------
// Structures                                                                  
//-----------------------------------------------------------------------------
struct VertData
{
   float2 texCoord        : TEXCOORD0;
   float2 lmCoord         : TEXCOORD1;
   float3 T               : TEXCOORD2;
   float3 B               : TEXCOORD3;
   float3 N               : TEXCOORD4;
   float3 normal          : NORMAL;
   float4 position        : POSITION;
};


struct ConnectData
{
   float4 hpos            : POSITION;
   float2 outTexCoord     : TEXCOORD0;
   float3 pos             : TEXCOORD2;
   float3 outEyePos       : TEXCOORD3;
   float4 outLightVec     : TEXCOORD4;
};


//-----------------------------------------------------------------------------
// Main                                                                        
//-----------------------------------------------------------------------------
ConnectData main( VertData IN,
                  uniform float4x4 modelview       : register(C0),
                  uniform float3   inLightVec      : register(C24),
                  uniform float3   eyePos          : register(C20),
                  uniform float3   fogData         : register(C22),
                  uniform float4x4 objTrans        : register(C12)
)
{
   ConnectData OUT;

   OUT.hpos = mul(modelview, IN.position);
   OUT.outTexCoord = IN.texCoord;

   float3x3 objToTangentSpace;
   objToTangentSpace[0] = IN.T;
   objToTangentSpace[1] = IN.B;
   objToTangentSpace[2] = IN.N;

   OUT.outLightVec.xyz = -inLightVec;
   OUT.outLightVec.xyz = mul(objToTangentSpace, OUT.outLightVec);
   OUT.pos = mul(objToTangentSpace, IN.position.xyz / 100.0);;
   OUT.outEyePos.xyz = mul(objToTangentSpace, eyePos.xyz / 100.0);;
   OUT.outLightVec.w = step( 0.0, dot( -inLightVec, IN.normal ) );

   return OUT;
}

PIXEL:

//-----------------------------------------------------------------------------
// Structures                                                                  
//-----------------------------------------------------------------------------
struct ConnectData
{
   float2 texCoord        : TEXCOORD0;
   float3 normal          : TEXCOORD1;
   float3 pixPos          : TEXCOORD2;
   float3 eyePos          : TEXCOORD3;
   float4 lightVec        : TEXCOORD4;
};


struct Fragout
{
   float4 col : COLOR0;
};


//-----------------------------------------------------------------------------
// Main                                                                        
//-----------------------------------------------------------------------------
Fragout main( ConnectData IN,
              uniform float4    ambient         : register(C2),
              uniform sampler2D diffuseMap      : register(S0),
              uniform sampler2D bumpMap         : register(S1),
              uniform sampler2D noiseMap        : register(S2),
              uniform float4    specularColor   : register(C0),
              uniform float     specularPower   : register(C1)
)
{
   Fragout OUT;

   float4 bumpNormal = tex2D(bumpMap, IN.texCoord);
   float4 bumpDot = saturate( dot(bumpNormal.xyz * 2.0 - 1.0, IN.lightVec.xyz) );

   float4 diffuse = tex2D(diffuseMap, IN.texCoord);

   float2 noiseIndex;
   noiseIndex.x = floor( IN.texCoord.x ) / 63.0 + 0.5/64.0;  // uses 64x64 noise texture
   noiseIndex.y = floor( IN.texCoord.y ) / 63.0 + 0.5/64.0;
   float4 noiseColor = tex2D( noiseMap, noiseIndex ) * 1.0 - 0.5;   
   
   OUT.col = diffuse + noiseColor * diffuse.a;
   OUT.col *= bumpDot + ambient;

   float3 eyeVec = normalize(IN.eyePos - IN.pixPos);
   float3 halfAng = normalize(eyeVec + IN.lightVec.xyz);
   float specular = saturate( dot(bumpNormal.xyz * 2.0 - 1.0, halfAng) ) * IN.lightVec.w;
   specular = pow(specular, specularPower);
   OUT.col += specularColor * specular * diffuse.a;
   return OUT;
}

This technique could be used in many places where you want to break up tiling like on brick walls, floors, etc. The artist has full control over how subtle the effect is by controlling the noise texture. If you really want to get funky, you could draw a picture in the noise texture and it would show up as a mosiac pattern rather than noise. Thanks to Alex for thinking this stuff up!

I may well make this a feature in TSE's procedural shaders.

Friday Jun 24 1:22

Brian Ramage — 2005-06-24T01:22:57+00:00

TSE Milestone 3

TSE milestone 2 is complete, and milestone 3 is well underway, so I thought
it would be a good time to share my thoughts on where we're going with it.
The main goal of MS3 is to tighten up the engine for more general consumption.
We want to fix some of the more annoying bugs and streamline some areas so
working with the materials is easier. We'd also like to increase performance,
particularly on nVIDIA FX cards.

Here are some of the major improvements planned:
- Get FSAA fully working
- .DDS support and more DXT compression options
- Fix skinning code with interpolated tangent space vectors
- Get an Atlas terrain editor working
- Add a texture / material flush so artists don't need to reload TSE to tweak materials
- Pre-load materials/shaders/other resources on level load
- Better .dif warnings if they are incorrect version
- Material enhancements
- Alpha test
- Parallax mapping
- More blend operations for cubemaps
- More procedural shader options
- Better control over specular colors
- ... much more

In addition, I've got an update of Materials coming up next week that has:
- client side Materials / ShaderData / CubemapData
- auto loading of materials.cs from subdirectories - so they can live with the data
- got rid of addMaterialMapping() calls - the mapping is done in the Material itself now
- full path names of textures are no longer needed

I'll explain these improvements in greater detail when the updates go live.

Figuring a timeline for MS3 is tough at this point as we have a LOT going on behind the
scenes right now. Josh should be releasing a "bounty" list for MS3 tasks that we'd pay
to get done, so we're hoping that can speed the development a bit. We've also got the
possibility of GG co-founder Tim Gift making a guest star appearance for MS3. He might
break out some goodies (OpenGL anyone?).

Friday Feb 25 3:09

Brian Ramage — 2005-02-25T03:09:20+00:00

Water almost ready for MS 2

Been a while since I updated the old .plan. The water is coming along pretty well. I'm working on optimizing the speed and cleaning up the code and interface before release. We should have a good demo for GDC with Ben's new terrain. Here's a screenshot of a test scene with some afwul programmer art: