Afx And Tgea (tse)?

#61 Hey jeff can I get your professional opinion on this click Here

#62 OK, it looks like I'm making sense out of the alpha-fading implementation. Currently I have a visibility factor that is exposed to CustomShaders. Operations like player fading and runtime model alpha settings manipulate this visibility factor and a custom pixel shader can be created to use the value to render the object with transparency. There are still some issues, such as the fact that an invisible object still casts a shadow, (I think this happens in the Hobbit, too), but some good forward progress here.

#63 Just wanted to add my 2c here and say that I am looking forward to the release of afx for TGEA. Hope you get all the issues worked out soon Jeff.

#64 So is this gonna be a huge issue to integrate sounds like you are having to make a lot of changes?

#65 I haven't had any issues with sounds. That does not seem to have changed much.

#66 Oops I meant

So is this gonna be a huge issue to integrate? It sounds like you are having to make a lot of changes?

#67 Gotcha..

What do you mean by integrate? Do you mean merging AFX into an existing game which is using TGEA as it's codebase? It shouldn't be much worse than it is in the case of TGE. There AFX requires mods to about 30 different code files of the TGE sources and all of the changes are very clearly marked. There are a couple of tricky spots, but overall it's significantly less than the number of mods that were required to integrate TLK when it was a separate product. It really depends a lot on how comfortable you are with code merges and whether you have the proper tools for it. Personally I find code merges to be quite tedious, but they're pretty much a fact-of-life given the way the Torque engines are organized and distributed, and most users seem to manage.

#68 Here's a quick update on progress...

I've got a solution for the alpha-fading that appears to be working, but only for CustomMaterials and I think only for 2.0 or greater shader hardware. To get alpha-fading, (such as a player fading with setFade()), you need to use or create a shader that makes use of a fadeAlpha value that's passed in to the pixel-shader for custom-materials. The main part of a simple shader might look something like this:

Fragout main( ConnectData IN,
              uniform float4    ambient         : register(C3),
              uniform sampler2D diffuseMap      : register(S0),
              uniform float     fadeAlpha       : register(C8)
)
{
   Fragout OUT;

   OUT.col = IN.shading + ambient;
   OUT.col *= tex2D(diffuseMap, IN.texCoord);
   OUT.col.a *= fadeAlpha;
   
   return OUT;
}

I also did some research into how to reproduce the default material using a custom-material (not as easy as it sounds) which is documented somewhat in this thread.

In order to get more control over lighting, I modified lighting so that you could specify a mask of what object types you allow the light to show on. Currently these object types consist of atlas terrain, legacy terrain, dts objects, and dif objects. Normally a light shines on all of these if it can, but you can use the mask to disable one or more object types. For example, if you're designing a spell with some nice zodiacs, you may not want your lights to cover them up with the ground lighting, so you shut it off. Or maybe you like the way a light looks on your player, but not on the ground. You can use one light on the player, and a different light on the ground, and adjust them independently. It's sort of a category based light linking scheme.

Finally, I brought the current AFX for TGEA build up to and beyond the capabilities in AFX 1.0.2. Currently, all but the most experimental parts of our TGE code trunk, are also in TGEA.

Currently I'm working on re-lighting all of the existing AFX effects to look best under TGEA lighting, but I've already run into a snag. Apparently a simple dynamic light shining on a simple default material is not being lit correctly using the stock procedural shaders. (see this thread.) Unfortunately, this slows things down a bit. The re-lighting work is done largely by eye, comparing the lighting produced by TGEA with that produced by the same lighting on TGE and making adjustments and possibly improvements. It's a lot of work, and I hesitate to proceed without doing a number of tests to determine how reliable the TGEA lighting is currently.

#69 Update?

#70 Given the number of bugs I was running into in TGEA 1.01, I slowed down this development for a bit. Now that TGEA 1.02 is available (just downloaded it), the effort should pick up again and I'm hopeful that TGEA 1.02 will provide the level of stability we need for the final push to get the AFX for TGEA product released.

#71 Any good news?

#72 _any_ news?

#73 Everything is converted over to TGEA 1.02 and so far 1.02 has been working out pretty well. The main areas that need work include:

- lighting
The existing lighting (designed on TGE) for all of the pre-made spells and effects looks extra bright on TGEA. Not sure yet if this indicates any kind of problem with TGEA lighting, it might just be brighter than TGE lighting. What it does mean is that lighting for all of the pre-made effects needs to tuned for TGEA.

- model shaders
Many of the model effects are not being rendered quite correctly. Since it is very important for model effects to fade in and out nicely, all of them require custom-shaders, and in a few cases they are not rendering right. As with the lighting, this does not necessarily indicate serious problems, and may just require adjustments to the custom-shaders. Almost all the problems have something to do with transparency and perhaps in the way different sources of transparency combine: texture alpha, animate dts visibility, alpha multipliers, alpha fading. In one case, we have a model that won't render parts of its mesh when rendered with a custom-shader w/ transparency enabled.

- atlas tuning
Things are generally running alright on atlas terrain, but with the extreme variations possible in atlas, this requires quite a bit of testing and tuning. I've been generating my own atlas terrains and developing a better feel for what to expect from different atlas variations.

- latest improvements
All zodiac rendering, (on legacy terrain, atlas, and interiors). is now shader based. This avoided a number of zodiac rendering artifacts and greatly improved the code integration. While we don't plan on having anything fancy in place for release, this also opens up the possibility of adding hooks for creating customized zodiac shaders.

#74 Sounds very interesting

#75 Thank you for the news :)

sounds good and quite interesting

#76 Your are making great progress and its looking sweet!

I will be buying it when its released :)

#77 Hows things now that 1.03 has droped?

#78 The 1.03 caught me by surprise, but the changes were fairly confined and not difficult to merge. Everything is working pretty well in 1.03. So far I've posted two TGEA bugs since the update.

One was a trivial bug where the new atlas lightmap generation was reversing green and blue for the sun color which caused some interesting results for non-white sunlight.

The other bug is in the way the standard shaders deal with fog. Scaled objects mess up the fog algorithm which adds less and less fog color as objects are scaled up. I've been trying to make most effects look good under heavy fog, and this bug gets in the way of that, but it's still a fairly minor problem. One may be able to correct the problem in custom-shaders, but as yet I haven't figured out how.

Another problem with the shader fog, is that it is incorrect for AddAlpha blended objects. The workaround for this is fairly trivial but you have to use different shaders when doing additive blends.

- latest progress

Recently I've been creating custom shaders for all the model effects. Aside from the fog issues, I've been able to get the right look in most cases choosing the right shader from a set of eight shared custom shaders. A few effects will end up with their own special shaders.

The Space Orc has been introduced into the demo, together with a complete set of alpha-fading custom materials. He works much better as a spellcaster than I thought he would. The only real problem is with the red glow on his eye-piece which cannot be converted to a custom-shader.

Work has shifted heavily from programming to content preparation which is a good sign that we're closing in on a publishable version.

Here are a couple of images:

#79 Forgive my ignorance but could you enlighten me on why the red I cannot be converted to a custom shader?

#80 There is this code excerpt from CustomMaterial:

bool CustomMaterial::setupPass( SceneGraphData &sgData )
{
   // custom materials don't glow for the moment...
   if( sgData.glowPass )
   {
      return false;
   }

I'm not exactly sure "why" they don't work, but if you try it, a CustomMaterial with glow enabled does not in fact glow. And in case you were wondering, commenting out the early return in the above code example does not make it work either.

My current compromise is to keep the eye as a standard material. It glows but it won't fade out like the other custom materials.