[Thee_oddball]

Originally Posted by mazex

It sure can be, but there are tons of other games that use Speedtree out there with very good performance, like Battlefield 3 that hardly can be accused of stuttering But then of course, I hardly think there is another game that use so many trees on the same frame

Anyway - as the main logic in the game is written in .NET and the Speedtree dll:s are written in C++ there will be interop problems in this critical part that for sure will not help! Of course they can maybe do optimization so that they load stuff and don't do the marshalling every frame, but I really don't know how the Speedtree libraries work in runtime... As Speedtree does culling, lods etc I don't see how you could get around a lot of marshalling to get the C++ trees "into" your C# landscape manager? Just guessing here...

Another thing is that they seem to be using Speedtree 5.2 which is not the latest release so let's hope they work with Speedtree support to fix this and are not stuck on a license for 5.x only.

+1 , beyond that is the limits of 32bit... which is not bad but it is definitely not future proofing a 10 year game engine.

I have recently been doing extensive profiling around memory limits in .NET on a 32bit process. We all get bombarded by the idea that we can allocate up to 2.4GB (2^31) in a .NET application but unfortuneately this is not true . The application process has that much space to use and the operating system does a great job managing it for us, however, .NET itself seems to have its own overhead which accounts for aproximately 600-800MB for typical real world applications that push the memory limit. This means that as soon as you allocate an array of integers that takes about 1.4GB, you should expect to see an OutOfMemoryException().

Obviously in 64bit, this limit occurs way later (let's chat in 5 years ), but the general size of everything in memory also grows (I am finding it's ~1.7 to ~2 times) because of the increased word size.

What I know for sure is that the Virtual Memory idea from the operating system definitely does NOT give you virtually endless allocation space within one process. It is only there so that the full 2.4GB is addressable to all the (many) applications running at one time.

http://stackoverflow.com/questions/2...le-net-process