Let's say I have a large terrain that's an island that I import into world editor and make it 256 X 256 tiles, and lower left corner is location -128, -128 for example; then I put another large island that is 256 X 256 in a different place -- say the lower left corner of that terrain is 400,400. And another large island of 256 X 256 tiles at 700,700 and so on.

(1) The positions of all the various items and things seem to be floats (not doubles) ?

If computed from 0.0f at some point the float error is going to become so great that items and such (and possibly even the islands themselves) won't be in the correct spots or even calculate correctly due to significant digit error. But if internal locations of things are computed from the Int location of the tile + float fractional position, then the float position maintains full accuracy no matter where in the world the tile or item is.

(2) So is the calculation for the stuff in each tile (lets say buildings or rocks or whatever) computed from the Int location of the tile with a float showing the fractional position (thus preserving the float accuracy of each tile), or is it computed from 0.0f ?

One way you are really limited on the # of tiles you can use in a world by float accuracy; the other way a single world can truly be as large as you want up to the HUGE size of Int (32 bits).

I've tested it on range -20 .. + 20km and it worked pretty stable (no issues)
40x40km area is pretty huge for a game.

So they are computed from 0.0f with floats ?

The problem is not actually the size of each piece of the terrain. The problem comes in with having several large places (terrains) in the world (like different large islands separated by ocean for example) being all in the same "world" in World Editor. This means I have to have different large places in the terrain to be different "worlds" in World Editor -- otherwise the locations lose their accuracy to the point they can't be correctly computed if they are all part of a large single world map I think.

Okay, I'm confused. I thought world size was supposed to be limited only by the size of the hard drive?

The largest land based game so far was 63,125 square miles or 163,492 square kilometers.

(11-25-2011 09:17 PM)wysardry Wrote:  Okay, I'm confused. I thought world size was supposed to be limited only by the size of the hard drive?

It depends on coordinates too. If you are placed somewhere between 1-9 "units", it is difference, then between 10-99 (you loose one decimal of accuracy, because length of that number is fixed - for example 0,001 vs 9999). If you loose more decimals (i dont know this engine, so i dont know exact number), some rendering can have artefacts, you can have problems with colliders, etc...This is common problem for all engines I know.

The world is streamed though, according to the engine features list, which means that somewhere along the line it is divided into "chunks", each of which could have its own independent coordinate system.

Unless I'm missing something, object positions could be referenced by chunk number and coordinates within that chunk, so floating point accuracy wouldn't be a problem.

(11-25-2011 09:45 PM)wysardry Wrote:  Unless I'm missing something, object positions could be referenced by chunk number and coordinates within that chunk, so floating point accuracy wouldn't be a problem.

You can keep active chunk always on 0,0,0 and shift coorditanes with change of chunk, but it means lots of practical troubles with recounting coordinates. Usually loose of few decimals is no problem, so if your terrain is reasonably sized, it shoudnt be problem.

Well, I'm looking for an engine that can handle very large terrain - around 65000 square miles or 168350 square kilometres, with a level of detail suitable for a player to walk around on in a first person perspective.

If floating point issues effect EE, then what's the go here???

http://www.esenthel.com/?id=feature/game_engine

(11-26-2011 07:55 AM)fatcoder Wrote:  If floating point issues effect EE, then what's the go here???

http://www.esenthel.com/?id=feature/game_engine

This IS confusing. I also understood worlds are basically unlimited in size and I assumed they work on the 'chunk-offset' method mentioned above (ie. each area is a chunk), but unless its mis-understood, this suggests otherwise :

(07-23-2011 01:11 PM)Esenthel Wrote:  I've tested it on range -20 .. + 20km and it worked pretty stable (no issues)
40x40km area is pretty huge for a game.

Unless you mean you tested on 20km per area / chunk (ie scaled up terrain)?

Please clarify.

there is no chunk + offset
positions are stored as single 32bit floats
40x40km was tested and stable - that size of world already consumes many GB, it is not reasonable to make bigger worlds

Quite a few commercial titles have been made with Large Video Game Worlds.

160 square km is 61.776 square miles. WoW is about 80 sq miles, Burnout Paradise around 200, Asheron's Call is 500, Lord of The Rings Online is around 30,000...

The largest land-based game was Daggerfall with an area of 62,394 square miles or around 161,600 square kilometres. It was made in 1996 and ran on a 486 with 8 Mb RAM.

Most modern engines available at an Indie-friendly price can't seem to cope with terrain anywhere near that size though (I have been looking).

(11-26-2011 10:43 PM)impi Wrote:  

(07-23-2011 01:11 PM)Esenthel Wrote:  I've tested it on range -20 .. + 20km and it worked pretty stable (no issues)
40x40km area is pretty huge for a game.

Unless you mean you tested on 20km per area / chunk (ie scaled up terrain)?

Perhaps that is what he means as note he used the word area. Esenthel can you please clarify if you meant 40x40km area or world.

(11-26-2011 10:50 PM)Esenthel Wrote:  there is no chunk + offset
positions are stored as single 32bit floats
40x40km was tested and stable - that size of world already consumes many GB, it is not reasonable to make bigger worlds

Seriously ... if the total world size for a world file is around 40x40km then you should not have a feature "Support for unlimited sized worlds".

Unlimited means just that .. unlimited. 40x40km is not unlimited. Call it "Support for LARGE sized worlds".

I completely understand and agree with you that worlds that size start to max out server resources - which is the point I've tried to make in some other posts. Specially when you have many players logged in and a lot going on.

And thats also why I made a feature request that you enhance Esenthel to have visibility into adjacent worlds (visibility only, not physics etc) ... that will allow licensees to develop games more like MMO - not just multiplayer : ie. we can have a grid of worlds (each potentially running on its own server), and the player can cross into adjacent worlds. So each server / world resources are seperate.

(11-27-2011 02:28 AM)impi Wrote:  Unlimited means just that .. unlimited. 40x40km is not unlimited. Call it "Support for LARGE sized worlds".

40x40km is enough for any MMO ever. Have you ever tried to populate lets say 30 square kilometrs with reasonable content? We did and it took 2 years of 5 people to have at least something (basics were done by generator, rest of time was hand tuning), other 7 years we were tuning it even more. Now we have realy nice world, which makes sense, it has lots of interesting places and it is not just empty like worlds made 100% by generators. So for any ground based MMO is 1600sq kilomets something, you can never seriuosly populate and there is no reason to have city, than 20km of generic generator land without any event place and than other city. Too big world is problem, you have no chance to make nice individual places.

In case of flight simulator you need bigger terrain, but requirments on streaming are 20x smaller, because you have almost no detail on the ground. What I know about EE shows, that it can be easily done.