DShiznit wrote:
That is awesome. So to make this work, you need to replace the minecraft executable?
Thanks! Yes, but I'm working on making my changes backwards-compatible, so that you can still use "normal" 256-block-tall maps in singleplayer and can still connect to regular 256-block-tall SMP servers. After I get that working, the next step will be to make this whatever sort of patch Minecraft mods use so that they can be combined with other mods, because I also want to be able to use one of the long-render-distance mods like Optifine to be able to see more of the generated skyline at once.

Edit: Thanks to tonight's coding work, my custom client can work with servers that are running both tall maps and normal maps, which means I (or you!) can play on regular servers with the modified client. The thing that doesn't yet exist is a server version that can understand tall maps and handle them properly; I'm not going to worry about that for now. I'll stick with loading my fledgling NYC chunks locally, then see if something like Bukkit or Spigot supports mods that go as deeply into the game core as my modifications do.
doenst the server.properties file have a world height parameter??
legodude wrote:
doenst the server.properties file have a world height parameter??
Yes, it does, but it doesn't actually affect anything useful. The Mojang code does very much not do anything to support tall maps, to the extent that some of the packet types even use bytes (ie, 0-255) to hold y-coordinates.
i believe there is a bukkit plugin wich fixes those cases.. maybe even bukkit itself has fixed some of them..
legodude wrote:
i believe there is a bukkit plugin wich fixes those cases.. maybe even bukkit itself has fixed some of them..
Are you sure? The vanilla client can't even be made aware of worlds taller than 256 blocks without Java modifications, so I seriously doubt bukkit can do anything purely server-side.

To keep you all updated, Mathuin has been very helpful in guiding me towards creating an expansion to TopoMC that grabs orthoimagery and layers it into the Minecraft terrain. I've had to pull in a lot of new (and old!) code to do the trick, but I've finally started getting realistically-colored terrains based on satellite imagery. I'm still working on adjusting the coloring and terrain type generation.

Edit: Here's an area of New York near my university (Astor Place, specifically) at 1:1 scaling. I suspect my green color is still not right, and I still have a lot to do with things like incorporating IR information, but I think it's looking good.

IR? Does that mean something other than infrared?
IR can also mean a bitcode intermediate representation of code, such as LLVM IR, but I doubt that KermM will be displaying bitcode in MC Razz

KermM: Looks great! Is this taking data from google maps?

Oh wait, didn't you say the images are from elsewhere?
The images are from the USGS API; the ones I'm working with are 4-band NAIP orthoimages, which include R, G, B plus infrared information (for surveying agriculture). The IR band is useful for me because it helps me differentiate green things that are not trees and grass from green things that are. Even dust and dirt (like baseball diamonds) reflect more IR, to my surprise. Anyway, I made a few more passes over my conversion code, and here's what I have now for a sample including Central Park and part of the Upper East Side and Upper West Side. I have included details of the terrain to show that elevation data is being pulled in.

*bump* Current status: Attacking a few different problems with the program at once to try to make headway on them all:
1. In trying to convert all of Manhattan's terrain at 1:1 scale, I rediscovered that my machine has far too little memory for the task. Since my field is distributed systems, it seems logical for me to distribute the Prep and Build phases (phases 2 and 3 of 3), so I'm currently working on making the Prep phase parallelizable.
2. I wrote code on Sunday to be able to plop Collada models converted to voxels down on the terrain. The results showed a mismatch in orientation between the terrain and the models. The model in the image below is correctly rotated, while the terrain is wrong.
What does that look like from a not-birds-eye view? My eyeballs are slightly weirded out by that image.
elfprince13 wrote:
What does that look like from a not-birds-eye view? My eyeballs are slightly weirded out by that image.
I Took a bird's-eye-view of Fifth Avenue at the Guggenheim Museum (as orthoimagery painted onto the terrain), and pasted a chunk of the actual Guggenheim model from another part of the map on top. That's why it looks so odd. Smile

Edit: The TopoMC creator confirmed that my reported bug exists. He tested for Washington, DC and found a skew of 11 degrees (instead of the 15 degrees I'm seeing for New York City).
*bump* Finished my first pass over preparing terrain information in a tiled, parallelizable manner. Once I have the single-threaded, tiled implementation complete, I can use Python's multiprocessing (Pool) module to actually parallelize it. The other goal of this process was to avoid running out of memory trying to manipulate giant sets of data in memory all at once. Anyway, status is that elevation and orthoimagery data look good, but the landcover layer appears scaled and offset (or perhaps just offset, the more that I stare at it):

*bump* Although the alignment of buildings onto the terrain is still an unsolved problem, here's what Washington, DC's Union Station looks like on top of the terrain in the city (I just generated a small area around the station):

And here's the proper way to convert the terrain of all of the island of Manhattan into a Minecraft map without expanding to multiple computers:
Very cool! What in particular are the problems associated with aligning the buildings? Is it still an issue of angular deviations in the source data?
No, it's an issue (I think) with the projections used for the terrain data. The terrain was being converted from UTM to AEA, and I think that is/was rotating the terrain relative to the buildings. I'm experimenting now with keeping it in UTM, and seeing if that will do the trick.

Edit: It looks good. Now that I spent 17 hours generating Manhattan with the old, incorrectly-rotated data, I'm generating a dynmap for it while I also restart the Manhattan terrain generation with UTM coordinates. I'm hoping it comes out nicely (and that I don't use up all of my hard drive's inodes trying to render this...).
Just saw your link on Facebook! Still waiting to see the 3d pictures Smile
elfprince13 wrote:
Just saw your link on Facebook! Still waiting to see the 3d pictures Smile
I'll do my best to take some of those this evening. Smile I'm afraid I won't be able to render an isometric view online, I don't think, though I may eventually try just to see how much I can strain my desktop. Razz
Looking good!

KermMartian wrote:
*bump* Current status: .... 1. In trying to convert all of Manhattan's terrain at 1:1 scale, I rediscovered that my machine has far too little memory for the task.

If your script is cross platform compatible (and simple enough for someone like I to start), I wouldn't mine loaning my computer out. Not sure of the RAM on your desktop (likely the same or higher as me), but I run 16GB at 1600Mhz, which is unfortunately the highest I can go Sad
Actually, I solved that problem with a combination of two approaches:
- Tiled and parallelized the conversion into separate threads, meaning that the amount of memory can be trivially controlled. It's a simple time-memory tradeoff now.
- Moved to one of our (idle) 32-core servers that can crunch through the conversion very fast.

Edit: Here's the most zoomed-out view I can get of the current map. It looks amazing from the map; on the ground, it's a little less coherent. I'm looking forward to the addition of the buildings, as I think that will make it feel a lot more like a real world. This map is 16,000 x 24,000 voxels (384 million square voxels = 384 million square meters), 1.5 million 16x16x256-meter Minecraft chunks, and 6.58GB of packed data.

If you could get roads overlaid, I am sure that the view from the ground could make more sense. Other than that, nice job!
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10  Next
» View previous topic :: View next topic  
Page 7 of 10
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum