Atlas Crashes consistently

#21 Welp, still having issues even with trying to change timing and setting process affinity, and verifying the geomstub was valid, to even looking at 1.7 and examining the same areas for any differences.. to no avail.

Still getting crashes with same collideLine functionality and it would seem that GG is too busy with T3D to frequent the TGEA forums much anymore...

#22 Sorry to hear it isn't working out, Jeremiah. :(

I expected this. They said they weren't prioritizing Atlas anymore and that it would not be used in T3D. So I guess people get less familiar with it and few know how it really works anymore. Add the recent inactivity of this forum subcategory, and well..

#23 I'm not too surprised myself, because its sort-of become the standard MO around here, sadly.

Its no wonder more and more people are finding other products to use with support from people other than interns and community members

If this only happened in our build, I'd think it was me, but I've merged/re-merged, checked builds, tested original SDK all with same results, yet its still having same crashes.. sort-of amazing

Of course, when I found that Ded. Server crashes with same GFX::get() issue that Atlas use to have, it made me realize that despite the product, things aren't tested in all scenarios (and they should've been)

#24 If you're using Atlas, you're best off sticking with 1.7.1. The main reason to switch to 1.8.x would be Mac support, and Atlas doesn't work on OS X anyways. Other bug fixes should probably be merged back into your existing codebase, instead of trying to merge your changes into our latest codebase.

I'm sorry I can't be of more help, but the cold harsh truth is that we simply don't have the time or resources to test and maintain Atlas, especially since the primary author (Ben Garney) is no longer at GG.

As far as forum posts go, keep in mind that if we're posting in the forums, we're not writing code. While I'm writing this post, I'm not working on TGEA 1.8.2. And yes, I'm in the office, working on a product that is not my responsibility, on a Sunday. I'm just crazy like that ;).

Edit: By the way, if you do find a fix, I will put it in TGEA. I'm watching this thread, so as long as it gets posted here...

#25 I am still confident I could fix the problem if I could replicate it.
I have 8 PCs and 1 laptop here and none are dual core.

I am pretty sure it is a thread problem.
The difference between 1.7.1 and 1.8.+ , as far as atlas is concerned, is that atlas uses a different resource manager that "could" be causing some issues with threading.

I can't say for sure.
If I had a dual core to try it on and debug it I would know for sure.

Right now all I can offer is some arm chair quarterbacking.

Try changing

if (ei[i] > bmax[i] || si[i] < bmin[i])
            return false;

To

if ( bmax[i] ==null || bmin[i] == null)
         return false;

if (ei[i] > bmax[i] || si[i] < bmin[i])
            return false;

The reason I test bmin and bmax is ei and si are evaluated and passing fine a few lines before.

Until I get a dual core that is about as far as I can speculate on a fix.

#26 @Alex: Thanks for your time, I know you don't deserve the brunt of most of the criticism that floats around here.

Unfortunately there are tons of renderer fixes and such that are needed in 1.8.1 (some issues with specular etc), that just aren't easy "back merges", so moving forward is/was our plan.

We may investigate some things with MegaTerrains, but have had excellent results with Atlas, so far (terrain/look wise and dont really want to lose most of that)

@Bill: I tried similar but not that exactly, so i'll give it a shot.

On a side note, a smaller Atlas doesn't seem to have any issues whatsoever, which definitely leads to some thread/resource potential issues.

#27 @Bill: That check pretty much killed all collision on Atlas with Projectiles lol. I find that odd though since that would mean, theyre consistently coming back null

Edit: actually, that needed to be a continue, not a return false, since some axis' could be invalid anyways.. will test and see

#28 You right it should be a continue statement.

Are you still getting the crash or any other errors?
Beside the projectile.

#29 On a side note, in AtlasInstance::renderObject:

if(mGeomTOC->castRay(focusPos, endPos, &ri, false))
         mClipMap->recenter(ri.texCoord);
      else
      {
         // Cast up...
         endPos = focusPos + Point3F(0,0,2.0*mWorldBox.len_z());
         if(mGeomTOC->castRay(focusPos, endPos, &ri, false))
            mClipMap->recenter(ri.texCoord);
      }

If the top section is commented out and the bottom one is fixed up to be called, the ClipMap on the terrains looks perfect, instead of blotched. The issue becomes when you switch to Mission Editor it all goes black, until you go under the terrain. It seems this could be tied to resource issues with it not properly recentering 100% of the time

#30 I have determined that the incorrect clipmap problems we discussed before can be forced to occur.

If the clipmap and the geometry are snapped to a specific location in one go ,like when you first load the mission, this will almost always cause the clipmap to "pick" the wrong textures to use.

When the error occurs point the camera at the area that is wrong and move away from it as soon as you cross enough LOD bounds the error corrects itself and you can go back to the spot where it looked wrong an it looks fine now.

Simply put if the camera moves faster than the atlas can load the relevant data it some times incorrectly abandons loading needed data.

#31 Well, with a continue, it works like normal, but does still crash. :/

As for clipmap, its annoying, but making it recenter based on top cast and not bottom (which does fix it), seems like it'll do for us.

But, we're lookign into just doing MegaTerrains since Atlas isn't going to be supported anymore (much) and theres obvious issues with it.

#32 Well, that sucks... I guess I wasted money buying that terrain maker so I could make Atlas terrains. :-\