Atlas Crashes consistently

#1 I have never seen any error related to atlas's castray before.
If I had to guess I would say that the atlas file has corrupt geometry data.

I know you said you recompiled for 1.8.1 but did you make sure that the atlas file completed correctly?

There is a bug in a stock TGEA 1.8.+ build that make generating atlas files impossible.
TGEA 1.8.0 BUG Atlas Terrain failed wrtiting bitmap

Did you check the console.log to ensure that the atlas didn't report any errors?


Try recompiling your atlas file at a deeper tree depth.
If that doesn't work try increasing you maxerror at the original treedepth and if that doesn't work keep lowering your treedepth and increasing your maxerror.

Also you should be able to safely build the atlas files with TGEA 1.7.0-1 and it will work fine in 1.8.+.
The atlas code was not significantly changed between the versions.
The only changes made appear to be on rendering and not generation.

#2 The fix for that issue is already in, and they export just fine from our build, so nothing related to that.

We were hoping they would work as-is, also, but since we've been having issues with the castray stuff, i was expecting to be some issue with needing to recompile them, but apparently not

@Bill: Are you using Blended or Unique terrains? We're using explicitly Blended ones

Will keep looking

#3 After reverting some of our changes to Atlas format, I'm back to the original implementation and we've recompiled one of our blended terrains to test.

We're seeing some odd clipmap bugs which seems to be because of it not using proper LODs and such, but still getting the crash :/

It seems from the variables in debugger that the min and max extents for the piece of geometry are coming back invalid so when the if statement is executed, it crashes.

#4 I have used both Blended and Unique.
As far as the castray is concerned it wouldn't make a difference between the two.

If I read you right you can get the atlas to load and render correctly but when you get to a certain area and performs a castray it crashes the engine.

Here is a trick to try.
Load the atlas then do a scene relight so that you generate a new lightmap for the atlas. Try and avoid the area the crash is happening in and get as high above the terrain to see if you can see the whole terrain.
If you see large blocks of either completely black or completely unshaded areas then I think you definitely have a geometry problem.

I will have to do some digging to find the thread that talked about this problem.
It also had something to do with the geometry not being completely in the atlas file and the player could just fall thru the areas that had none.
I think the solution had something to do with the treedepth.

#5 Well, I brought the terrain back to stock 1.8.1 (AtlasDemo) and it exhibits some clipmap issues, which we've seen our build too. I thought it was fine, but then after just flying around awhile (as camera), it finally crashed in AtlasDemo.



Its odd though cause we weren't seeing anything like this in 1.7.1, unless its because geomorphing is gone which could've made it act differently in certain areas.

For the heightmap, the designer is using:

size - 4096
squaresize - 2.0
vertScale - 2.0/256.0
error - 3
treeDepth - 4

For the lightmap/opacity, he is using leafCount of 16 which makes it use a treeDepth of 5 for those. The heightmap is using treedepth of 4

#6 Did some more testing and I decided to give GG the benefit of a doubt, that I had somehow done something to break it.

I grabbed clean 1.8.1 SDK, and used AtlasDemo to check the terrains (still shows the above issue) and still crashed.

I grabbed the source files and recompiled the terrain using AtlasDemo (other than the textures that had to be done in fixed exe for the bug that exists).. Same results, still crashing and still having weird clipmap/lod issues.

So, im not sure where to go from here, since we're running fine on 1.7.1, but it'd be nice to move to 1.8.1 for the rendering changes and such

#7 All I can offer at this point is if you can let me test the atlas file you created my self.
If I could repeat your problem I am sure I can at least point to the exact problem and offer a fix if I can figure one out.

As for the rendering errors. This seems to be a problem with 1.8.+ and atlas.
I bet if in the above screen shot if you hit F11 to bring up the editor the atlas file will start to render correctly again.
I have run into this problem before with 1.8.+ and haven't quite figured it out yet.
I do know if you load the atlas with the camera close to the surface this rendering error pops up a lot.
If you load it with the camera outside the atlas's bounding box it nearly never happens.

#8 Yeah, I noticed being able to bring up the Mission Editor and it fix the clipmap/lod.. but thats not a feasible option for a released product lol.


Would be awesome if there were some updates from GG

I'm working on uploading a version of the terrain for you, but no textures for it, but itll crash even if its black

#9 www.gocliche.info/FrostBite.zip

that is just the atlas, I figured you'd be able to throw it into a mission to let it load

#10 I can't replicate your error.
I just spent 10 minutes flying around and no crash.
Used stock TGEA 1.8.1 Atlas demo.
Is there a specific area that causes the crash?


Nice terrain.

#11 No specific places unfortunately. Its so far just been random and sporadic, but consistent. It wouldn't crash for awhile, then bam, crash.. then it'd be fine for a bit and crash again.

The AtlasDemo took a little longer oddly, but it still exhibited same issue.

Did you see the clipmap/lod bug on loading the map?

Whats your system specs?

#12 Well, did some more experimenting... The mission that terrain goes with had precipitation which could cause it to crash fast, so removed it and didn't see a crash for a bit.

But another mission we have that has no precipitation was exhibiting crashes too.

Im curious if collision information (bounds, etc) is constant or if its streamed in with textures, etc..

#13 Yes I seen the clipmap problem.

I tried it on 2 of my dev PC's 1 has a Radeon X1300/X1550 and the other was a Mobile Intel 915GM/GMS,910GML Express Chipset Family.

Can't repeat the error on either.

Collision is set and loaded all at one time and remains available till the atlasinstance is unloaded.

#14 Whats your CPU on those systems?

#15 Intel Celeron 1.5 GHz 2 Gigs ram on one and the other is Intel P4 2 GHz 1 Gig ram.

#16 Okay.. So far that is only correlation between myself and the designer working on the map, we both have AMD Quad Cores...

I'm wondering if something in the Atlas threading is going awry due to that fact.

#17 Another piece of the puzzle.

I do recall some problems with Quad cores.
I don't think I can help any further if it turns out to be a quad core problem.
Not my area of expertise.

The closes thing I could find to help was here.

#18 Yeah... We're testing now with setting processor affinity to 1, and designer is testing on his dual core (without affinity setting).

I'm just not sure how GG hasn't noted this or fixed it, including the clipmap issues, I guess they have T3D to focus on now

#19 Well, so far so good!

I disabled usage of the high resolution timers, in favor of a little slower, but more reliable timer. There are issues with using high performance timers, if the system doesn't properly compensate or address issues that can range from being "behind" to being a bit ahead.

This seems to have resolved our crashes and no other issues showing up so far

#20 Well.. after some more experimenting and running into this issue in other scenarios, it would seem that this code, in atlasInstanceGeomToc.cpp is the "issue"

// Push the root stub into the stack.
   stack[stackDepth++] = getStub(0, Point2I(0,0));

   while(stackDepth)
   {
      // Pop top item from the stack.
      StubType *s = stack[--stackDepth];

      // If we don't overlap, skip it. NOTE: collideLine seems to not want to detect
      // fully contained lines.
      if(!s->mBounds.collideLine(start, end))
         continue;

I did some debugging and it really seems that what is popping off of the stack is returning a bad GeomStub for Atlas. I am going to try and check it and if its invalid, then move to the next, but not sure what effect that will have on certain things.