Overlapping atlas terrain?
by addiktive · in Torque Game Engine Advanced · 02/06/2007 (2:03 pm) · 4 replies
Is it safe to overlap atlas terrains?
As an experiment, I split an island into two parts, a low quality seabed, and the island. This gives us a net smaller atlas files.
The island then is sunk into the seabed.
But I find that the FPS is dropping drastically, so I assume that there is something else happening which is giving the engine an headache.
As an experiment, I split an island into two parts, a low quality seabed, and the island. This gives us a net smaller atlas files.
The island then is sunk into the seabed.
But I find that the FPS is dropping drastically, so I assume that there is something else happening which is giving the engine an headache.
About the author
#2
It's a great way of ensuring quality of landscape is actually on the land, and not hidden for most of the game underwater.
Just a shame it overloads atlas.
Currently our project is in early stages, we have some landscape, and a few static models, nothing yet to tax either CPU or GPU.
02/08/2007 (11:42 am)
And there was me that your post was an answer!It's a great way of ensuring quality of landscape is actually on the land, and not hidden for most of the game underwater.
Just a shame it overloads atlas.
Currently our project is in early stages, we have some landscape, and a few static models, nothing yet to tax either CPU or GPU.
#3
In our game we were looking at building our terrain in "blocks" and them adding them on a piece at a time with separate Atlas Instances. I was having some trouble getting the height ranges of the different maps to match up properly and so I asked Ben G about it. He mentioned that whenever possible, we should be using 1 larger Atlas Instance rather than 2 smaller ones. Apparently the Atlas code does all the optimizing, paging, and LOD stuff that should be needed for large terrains.
We are currently using a terrain that is 32,768x32,768 game units, from an 8192x8192 heightmap (square size 4). Although the file is 118MB, we are quite happy with the performance.
(We'd really like that terrain editor to be finished though!)
02/08/2007 (12:36 pm)
I know this is only slightly related, but I'll provide it anyway.In our game we were looking at building our terrain in "blocks" and them adding them on a piece at a time with separate Atlas Instances. I was having some trouble getting the height ranges of the different maps to match up properly and so I asked Ben G about it. He mentioned that whenever possible, we should be using 1 larger Atlas Instance rather than 2 smaller ones. Apparently the Atlas code does all the optimizing, paging, and LOD stuff that should be needed for large terrains.
We are currently using a terrain that is 32,768x32,768 game units, from an 8192x8192 heightmap (square size 4). Although the file is 118MB, we are quite happy with the performance.
(We'd really like that terrain editor to be finished though!)
#4
Without being to edit the landscape in the editor, smaller chunks are easier and quicker to regenerate then the whole world every time.
02/09/2007 (11:06 am)
That must be quite a low res texture. We have 6 atlas files currently making up a bit of landscape that's about 30 square km. Totals 270meg so far.Without being to edit the landscape in the editor, smaller chunks are easier and quicker to regenerate then the whole world every time.
Torque Owner Thomas \"Man of Ice\" Lund
We do the same - and are seeing the same effect. Just haven gotten as far as to figure out why (enough other tasks at hand).
We have a large 20x20 km low poly "sea bed" - almost black textured flat sea floor. And then a higher poly island that is placed onto the sea bed.
When we have 3-4 AI controlled ships (eating a fair amount of CPU and GPU power) and look at the island, then the framerates drop noticeably.
There might be an issue here then - or just overloading the Atlas system