Dunno, but aren't you guys missing this post here?sebik wrote:A good compromise could be 40x40 grid. It extends building field by 8 blocks in every direction. Calculate:
Right now the plan is to make a 32x32 grid = 100%
With 40x40 it would be ca. 156%. It takes additional 50%, but I hope it is still not that much.
With 45x45 (TMUF environments) field is widen nearly twice (198%). It might be too much.
With 64x64 it is 400% of original field. It is way too much as Nadeo said.
There is either 32x32 or 64x64 and nothing in between, because you save the date in binary code and from a programmers point of view it would be a loss of memory if you don't use the 64x64 but a grid >32x32, because you don't fully exhaust your reserved memory place.Hylis wrote:The 32x32 is better for the 'octree' than using inbetween power of two size, so we optimise also like this (instead of selection another dimension between 32 and 64) and if we move from 32x32 to 64x64, it makes 4 times more blocs on the ground (1024 to 4096) Then if you want to fill 3000 additionnal spaces to have your scenery 'not flat', the bloc costs too much for this on Canyon. It may create trouble in memory as well for the 2 Go 32 bits limit, or a least make it too difficult for small configurations.
We have then decided to go with 32x32, like the first TM and stadium. We feel it safer to start with even if I recognize that having bigger construction field is cool. We even developped a special technology to optimise it for 64x64, but I still feel it too risky to do it.
And to be honest, i never had a problem where i had to stop my building process because of there wasn't enough place but because of starting on the wrong place of the map. Therefore i think the new copy/paste will solve everything.