TGEA RC1 Bug : ProjectileData LightRadius

#1 I haven't seen this one added to at all, but there seems to be a general lighting issue in RC1. I'm still compiling all the different areas it fails, but I just wanted to throw this out there in the meanwhile:

* projectile lights illuminate the entire chunk that it is passing over
* dynamic lights placed inside interiors w/ passthrough are lighting up the entire terrain chunk
* mission lighting fails when lighting interiors that are OK in MS4.1

There may be a few more issues, but after banging into those three I just packed it up. I'm going to do a fresh debug compile once I get to my desk and post a little bit more than "it's broke, damnit!"

#2 Check - same here. Already reported into Ben some time ago, but never fixed apparently. RC1 still has the problem (checked yesterday)

Initially I though it might have something to do with the number of guns on the ships - adding multiple light sources.

Video showing problem in Air Ace in a bit more detail.

airaceonline.arcadersplanet.com/for_ben/TerrainLightProblem2.wmv

Most interesting part is 2/3'rds into the movie - enabling chunk boundaries in debug build. Shows clearly that its lighting up the entire chunk

#3 Hi Bryce,

We're looking into the first two (which are the same issue, right? - atlas dynamic lighting not rendering correctly).

Can you elaborate on the mission lighting issue? Also make sure you're using the latest map2dif or map2dif+.

#4 Same here but we use Legacy. A big chunk is lit up and it does not look very smooth.

#5 @John: Yes, but I wanted to be specific as to not relate potentially unrelated issues.

I compiled a new map2dif_plus and re-exported from 3DWS.

This occurs when the interior is about to enter the camera in DEBUG, on release the map will not relight when loading.

I'm getting the following assert:
Fatal: (c:\tgea.rc1\engine\interior\interiorlmmanager.cpp @ 477) InteriorLMManager::getHandle: invalid base texture handle

AssertFatal(interior->getLMHandle() < mInteriors.size(), "InteriorLMManager::loadBaseLightmaps: invalid interior");

      InteriorLMInfo * interiorInfo = mInteriors[interior->getLMHandle()];
      InstanceLMInfo * baseInstanceInfo = interiorInfo->mInstances[0];  // <- asserts here

      for(U32 j = 0; j < interiorInfo->mNumLightmaps; j++)
      {
         AssertFatal(pBitmaps[i][j], "InteriorLMManager::loadBaseLightmaps: invalid bitmap");

From console.log:

Fatal: (c:\tgea.rc1\engine\interior\interiorlmmanager.cpp @ 477) InteriorLMManager::getHandle: invalid base texture handle
keyboard0 input device unacquired.
mouse0 input device unacquired.
DirectInput deactivated.
Error, a DecalManager (193b7d8) isn't properly out of the bins!
Error, a InteriorInstance (4c106c0) isn't properly out of the bins!
Error, a InteriorInstance (4c106c0) isn't properly out of the bins!
Error, a InteriorInstance (4c106c0) isn't properly out of the bins!
Error, a InteriorInstance (4c106c0) isn't properly out of the bins!
Error, a AtlasInstance2 (57b31ac) isn't properly out of the bins!
Error, a Sky (58a1bfc) isn't properly out of the bins!
Error, a Player (58a95fc) isn't properly out of the bins!
Error, a Camera (5a9c0e8) isn't properly out of the bins!
Error, a Sky (35978b8) isn't properly out of the bins!
Error, a AtlasInstance2 (3551c50) isn't properly out of the bins!
Error, a InteriorInstance (4ad8940) isn't properly out of the bins!
Error, a InteriorInstance (4ad8940) isn't properly out of the bins!
Error, a InteriorInstance (4ad8940) isn't properly out of the bins!
Error, a InteriorInstance (4ad8940) isn't properly out of the bins!
Error, a Camera (57b89e0) isn't properly out of the bins!
Error, a Camera (57b89e0) isn't properly out of the bins!
Error, a Camera (57b89e0) isn't properly out of the bins!
Error, a Camera (57b89e0) isn't properly out of the bins!
Error, a Player (58a5460) isn't properly out of the bins!

The other errors seem to be fruit of the poisonous tree, as when I remove the interior the mission loads and operates successfully.

I'm totally open to the fact that my conversion from MS4.1 to RC1 missed something, but exporting the same structure with the MS4.1 map2dif showed no such lighting issues in my MS4.1 build.

If you need more info let me know.

#6 Thomas and Stefan - can you guys double check your projects' atlas and terrain material definitions to make sure they match up with the RC1 definitions (also that they're only defined once).

I ran into similar problems yesterday when testing (with both atlas and the terrain) - the lighting was either oddly scaled or completely missing. It turns out the material definitions I pulled from 'terrain_water_demo\data\terrains\materials.cs' were overridden by or overriding the definitions in 'demo\data\materials.cs' (my test was based on the demo mod).

Specifically the atlas and terrain materials were not pre-loading and the terrain materials were using the pre-detail mapping definition - this caused all sorts of graphical problems.

The correct atlas definitions are in the 'terrain_water_demo' mod and the correct terrain definitions are in the 'demo' mod. Don't worry, I just synced these up in head, so 1.0 should have the correct and up-to-date definitions in both. :)


Bryce, sounds good - thanks for posting more info. Does the dif work correctly in a clean copy of RC1, and if not can you send it over to me?


Thanks guys!

#7 Your last post pointed me in the right direction.

My terrain lighting issue was absolutely the shaders.

But I also moved my interior into terrain_water_demo and loaded it... and it light mapped just fine.

The problem is in my initialization of ... something... in my scripting. I'm going to have to compare it to the terrain_water_demo to find the solution, but consider this a non-issue.

Thanks for the help. :)