Hi all.. i'm building a high detail 3D landscape (an entire continent + isles and seas/oceans around it) that will be the main area of *something*.. where the *Something* can be a game or simply a "big box" to travel in and where people can add their own stuff.
Just for example, beside copyright issues, you can think to a detailed JRRT Middle Earth map where people can add their Argonath Models.. or their Hobbiton/Bree town models.. or people who don't have fun with 3D modeling can simply roam around..
Well.. my ACTUAL need is to build this big landscape model in a format that can be exchanged between almost every engine that can handle it.. that's because i still don't know what will be the final use of this model, but i need to create it only 1 time I don't want to have the problem to rebuild it several times because the output file format is closed to a single engine/software.
So, I need your advice... actually, i'm building it in pure vector shape but the area is REALLY big (you can think to 8k x 6k miles width) and can't find a tool who can handle such a wide area..
Anyone have some tips for me? Such as scaling the model in the proper way or know a tool that can handle a very big model without slicing it/needing to cut it in X subzones/submodels.
It's not really practical to think of such a thing as a single model, and impose the restriction that it be handled as a single model. It's not a single model. On modern hardware, it can not be done with a single model, not even remotely. Consider that if you have an 8000x6000 mile heightmap, sampled at 1 yard resolution (which is actually relatively coarse; even better would be 1 ft resolution). That equates to a heightmap 14080000x10560000 in size. That, my friend, is a gigantic freakin' heightmap. You are talking multiple gigabytes of data, just to store the vertex buffer. The index buffer would be another huge chunk of data. Every additional vertex attribute such as normals would contribute multiple gigabytes of data. Very few computers could keep that much data in memory at once, and certainly no consumer grade video cards are available with terabytes of video RAM that could keep it as a single model. No, a world that size absolutely MUST be split up in a sensible manner.
And it's not even just the impracticality of handling that as a single model. You also have to consider the impracticality of moving that world dataset around. Any time someone connects to your world, they need the world data streamed to them. You going to stream the entire freakishly gigantic single-model world to them? How many days do you want them to wait while it downloads? No, you need to have the data partitioned so that you only move around the data that is required for a given player. Anything else would be such an irresponsible waste.
And how would you construct such a world in the first place? Here is an exercise for you. Sit down with a 3D modeler and construct a heightmap at 1 yard resolution that is 1 mile by 1 mile in size. Take a measure of how long it takes you to sculpt and texture so that it looks good. Now, multiply that effort by 48 million, and you'll have a reasonable guess at how long it'll take you to construct the larger terrain by hand.
Typically, for planet-scale terrain, you are going to have to rely on procedural generation to construct the vast majority of the data set. There simply is not enough time for you to do it any other way. And given that, you can effectively store an entire world as a single unsigned integer seed to feed to the generator. The generator can be set up to spit out chunks of the world at a time, rather than the whole shebang.
Consider a world like World of Warcraft, to give yourself a sense of scale. The game consists of 4 continents. I read somewhere that the largest, Kalimdor, was approximately 60 sq. km. in size. The world you propose is approximately 77248512 sq. km. in size. 12 million times bigger. How many people are you going to hire to populate that space?
As a final thing to think about: exactly how many players will you have, and exactly how much space will they need to occupy? Because your proposal would be sufficient to give 48 million players each a full square mile to play with. If you have fewer players, there will be vastly more space for each player. The effect of this would be a world that feels very, very empty and dead. If a player has to travel hundreds of miles to encounter another player, they might as well be playing single player. And if they all congregate in certain areas, that leaves huge swathes of the land unoccupied; essentially, those areas of land represent wasted resources that do not contribute to the final experience. So many man hours of time, so many computer hours of time, wasted on creating content that nobody will ever see.
My personal opinion is for you to aim smaller. Instead of a world 8000x6000 miles in size, shoot for one 8x6 miles. That's still a pretty freaking big place to explore, and yet is vastly more manageable to handle and build.
Hi JTippetts and thanks for your reply i definitely got the point.. in fact, my very first problem is about the effective scale of the map compared to the "real" proportion with human/plants/etc...
I had the feeling that my object was oversized but i couldn't get HOW MUCH it was o/s... you explained it and cleared the point
And the second point was "why almost all the terrain editor have map range between 2k x 2k to 4k x 4k as max size"..
Now, just to hit the spot.. I have the border of all my lands (in spline form) + a grayscale heighmap... what's the best tool i can use?
ATM I'm working with Grome, World Builder and VNS (plus the UDK module for landscaping).. i'd like to keep the landscape modelig outside UDK to have a stand alone model to import in any engine i could ever use, but i don't know if it can be easier.. i have to say that WB and VNS are GREAT tools indeed.. it's hard for me to quit using them and use a less powerful tool (but i have to say, i don't really know the UDK capabilities in landscape modeling).
by now, i will resize my model.. and hope to post some WIP soon