Latest News Article

[Donkey Kong]

I'm looking to modify the formula for how much a block's color is dimmed and how that dimming is calculated based on its height in the chunk. Could you point me to where in the code this is?

I'm looking in draw.cpp but I can't seem to find where the height factors in.

[Zahl]

That would be in main.cpp around line 270.

float col = float(y) * .78f - 91;

Could rename the vars there a bit I guess. It is followed by some calculations for skylight/night, if you want to change that too.

On another note, I can't really work on mcmap currently, my server's got some issues and I'm going to be busy reinstalling and setting everything up again this weekend. :-( This really is no fun.
That actually reminds me that I have to move the downloads temporarily...

EDIT: Forgot to ask: How much mem would you assign to mcmap for incremental rendering? (Other people can report too :-))
Just so I can adjust my coding and testing to how people would use that feature.

[Donkey Kong]

Hey, thanks. I'll see if I can make it look a little prettier.

I'd give it about a gigabyte. I don't mind if it takes longer, I just want it to be able to run side by side minecraft and other services in on a busy server with 4GB of ram.

[Donkey Kong]

Alright, so I've done a little poking around. I'm not completely familiar with the code but I found a way to calculate 'col' that makes a bit more sense. Right now it's linear:

float col = float(y) * .78f - 91;

But what if it were logarithmic, so typical formations stood out more?

float col = (100.0f/(1.0f+exp(-(1.3f * float(y) / 16.0f)+6.0f))) - 91;

The change is subtle side-by-side but if you flip them, you can see that the log method pops a lot more and makes the maps more legible. It should be obvious which is which.



More details:


Linear height -> brightness (the way it is now)


Logarithmic height -> brightness

[Najca]

Thx!
This program ownz!!!

[DopeGhoti]

Quote

New version released
- You can select which direction will point to the top left corner of the image using -north -east -south or -west. East would be default for the sake of backward compatibility
- Included quick fix for bad chunks that are far off the map

I'm not sure why, but the new version segfaults when doing -cave mode renderings, at least for me.

minecraft$ ~/bin/mcmap -cave -noise 10  ~/path/to/world/
Scanning world...
[0.00%]
[100.00%]
Min: (-28|-10) Max: (36|46)
Bitmap dimensions are 3850x2186, 24bpp, 24.08MiB
Terrain takes up 112.00MiB, lightmap 56.00MiB
Loading all chunks..
[0.00%]
[21.43%]
[41.30%]
[57.62%]
[81.99%]
[100.00%]
Exploring underground...
[0.00%]
Segmentation fault

[Zahl]

Donkey Kong said:

Alright, so I've done a little poking around. I'm not completely familiar with the code but I found a way to calculate 'col' that makes a bit more sense. Right now it's linear:

float col = float(y) * .78f - 91;

But what if it were logarithmic, so typical formations stood out more?

float col = (100.0f/(1.0f+exp(-(1.3f * float(y) / 16.0f)+6.0f))) - 91;

The change is subtle side-by-side but if you flip them, you can see that the log method pops a lot more and makes the maps more legible. It should be obvious which is which.

Nice! I never really gave that formula a second thought, but yeah, using that curve makes plateaus and high buildings stand out in a nice way. I'll check that out myself with a few maps and then put that in the official builds I think.

Najca said:

Thx!
This program ownz!!!

Good to hear :-)

DopeGhoti said:

I'm not sure why, but the new version segfaults when doing -cave mode renderings, at least for me.

Hmm, you either downloaded the src within about 10 minutes after I posted that, or there is still something else wrong (probably 64bit related). I fixed that bug pretty much right after releasing that version, and updated the files, hoping nobody downloaded yet ;-)

In main.cpp line 336, in undergroundMode(), the inner most loop should read as follows:

for (size_t y = MAPSIZE_Y-1; y < MAPSIZE_Y; --y) {

If the line does not look like that, you should also fetch the worldloader.cpp again from the zip, there was another glitch in there.


If the line is already like the one above, a workaround should be

for (int y = MAPSIZE_Y-1; y >= 0; --y) {

Hope that helps.

[DopeGhoti]

Zahl said:

Hope that helps.

It surely did. (I just did a fresh git pull and it's working again now after recompiling)

I should have thought of doing a git pull before coming asking for help

(Also, I'm new to git; is 'git pull' analagous to 'cvs update'?)

[optimus]

Hi,

Great program! Thanks for your efforts.

Seeing how development seems to be occurring pretty rapidly atm, I've registered here to lodge a feature request with you.

Would it be possible to add the ability to generate a CSV representation of the map in your program?

Doing so would mean that the generated CSV file could be imported in to real mine engineering software, allowing for crazy amounts of planning and accuracy within Minecraft.

This has come up a couple of time in requests on this forum but I havent' seen any solutions yet.


For example:

X, Y, Z - block location with reference to level origin (ie. 5,150,5) would denote a block is 5 blocks from the model origin in Easting, 150 in Northing and 5 from base of model and field denoting type of block (ie. coal, stone, water etc).


Thanks!

[NotTarts]

This is great, thanks. Much faster (and nicer looking) than other mappers on the same settings

I've also created my own colours, based off JohnSmith Textures Pack:

#ID	R	G	B	A	Noise
1	93	90	82	255	16
2	42	79	12	255	14
3	72	58	36	255	22
4	82	78	67	255	26
5	76	56	42	255	11
6	120	120	120	0	0
7	55	55	57	255	0
8	69	124	186	41	0
9	69	124	186	41	0
10	229	148	37	255	0
11	229	148	37	255	0
12	134	124	77	255	14
13	84	73	55	255	24
14	227	162	34	255	0
15	161	121	79	255	0
#ID	R	G	B	A	Noise
16	39	42	49	255	0
17	83	68	52	255	0
18	19	48	26	180	12
19	0	0	0	0	0
20	124	151	155	90	0
21	0	0	0	0	0
22	0	0	0	0	0
23	0	0	0	0	0
24	0	0	0	0	0
25	0	0	0	0	0
26	0	0	0	0	0
27	0	0	0	0	0
28	0	0	0	0	0
29	0	0	0	0	0
30	0	0	0	0	0
#ID	R	G	B	A	Noise
31	0	0	0	0	0
32	0	0	0	0	0
33	0	0	0	0	0
34	0	0	0	0	0
35	204	210	197	255	10
36	0	0	0	254	0
37	51	75	42	254	0
38	59	97	130	254	0
39	128	100	0	254	0
40	140	12	12	254	0
41	204	210	197	255	0
42	173	173	173	255	0
43	85	78	69	255	0
44	85	78	69	254	0
45	160	72	51	255	0
#ID	R	G	B	A	Noise
46	193	60	23	255	0
47	0	0	0	0	0
48	67	75	49	255	0
49	58	47	58	255	0
50	254	203	58	200	0
51	255	170	30	200	0
52	245	220	50	255	0
53	101	76	56	255	11
54	115	92	70	255	0
55	81	15	15	255	0
56	88	175	194	255	0
57	114	151	165	255	0
58	119	96	69	255	0
59	95	106	15	255	0
60	86	57	36	255	0
#ID	R	G	B	A	Noise
61	110	89	51	255	0
62	110	89	51	255	0
63	42	78	12	255	0
64	90	68	48	255	11
65	100	89	69	32	0
66	79	76	71	180	0
67	80	75	65	255	26
68	0	0	0	0	0
69	0	0	0	0	0
70	0	0	0	0	0
71	191	191	191	255	0
72	0	0	0	0	0
73	121	75	75	255	0
74	121	75	75	255	0
75	181	100	44	254	0
#ID	R	G	B	A	Noise
76	255	0	0	254	0
77	0	0	0	0	0
78	220	230	236	254	0
79	144	192	220	55	0
80	220	230	236	255	0
81	81	116	56	255	0
82	180	185	196	255	0
83	95	116	52	255	0
84	81	68	56	255	0
85	80	69	44	255	11

There's also a spreadsheet version for easier editing

[Donkey Kong]

I like the colors NotTarts posted the best so far, so I did a rendering of most of my map with the log brightness function. I think it looks better than cartographer now, honestly.

Clicking gets you the whole 20MB thing.

[Zahl]

optimus said:

Would it be possible to add the ability to generate a CSV representation of the map in your program?

Doing so would mean that the generated CSV file could be imported in to real mine engineering software, allowing for crazy amounts of planning and accuracy within Minecraft.

This has come up a couple of time in requests on this forum but I havent' seen any solutions yet.


For example:

X, Y, Z - block location with reference to level origin (ie. 5,150,5) would denote a block is 5 blocks from the model origin in Easting, 150 in Northing and 5 from base of model and field denoting type of block (ie. coal, stone, water etc).


Thanks!

So, as far as I understand, you just want a converter that will turn the map into a human readable text file; just all the blocks which aren't air should be dumped with a relative origin. Anything else? Do they have to be ordered in some way?
Anyways, if this is what you want, that should really take no longer than maybe half an hour of work. I would merely write a new program for that, based on mcmap, since that has nothing to do with rendering anymore.


About the colors by NotTarts, that indeed looks really great and way more realistic.


A quick status update from my side: I'm quite sick currently, staying in bed most of the time. :-(
Still made some progress on mcmap, cause it gets quite boring doing nothing all day.

[dorino1]

Quote

Colors should now be customizable.

And this is now my main renderer. :3

Ah, and an issue. With the skylight on, there's some black artifacting around some halfsteps in my map and some fences if I use a darker color. Hm?

[GoingIncognito]

If this works on my Mac it'll be my new mapping program for most mapping tasks. Certainly looks nice and works better for me than other programs, even if it doesn't have quite all the other features yet. Hasn't given me a single error yet (unlike almost every other program). I'm using the colors posted by NotTart right now, but I think overall they're just a shade too dark for me. Meh, I'll quit being lazy eventually and fix it.

Here's my newest world, I call it "Terra Incognita" (literally Unknown Land, plus I thought it fitting given my name):
http://bit.ly/9vdUh0
(I'd post it directly in the thread but it's coming out way too huge and I'm too lazy to figure out why right now)

Edit: Runs fine on my Mac using command line. I'd prefer a GUI, but I'm no programmer . If someone makes a GUI I'll volunteer to test it .

[hakre1]

Just wanted to say I'm LOVING this Program!
It works so flawlessly.
Here is a little building animation of my Colosseum.
http://www.pasteall....how.php?id=6178

[irowboat]

I'm having trouble compiling it, here's my specs:
Linux 2.6.32-24-server #43-Ubuntu SMP Thu Sep 16 16:05:42 UTC 2010 x86_64 GNU/Linux
g++ 4:4.4.3-1ubuntu1
g++-4.4 4.4.3-4ubuntu5
zlib1g-dev 1:1.2.3.3.dfsg-15ubuntu1
build-essential 11.4build1 11.4build1

Errors here: http://pastebin.com/UaMGmMLU

Any tips?

[edit] still fails using the github master, pastebin updated [/edit]

[Veefy]

Zahl said:

optimus said:

Would it be possible to add the ability to generate a CSV representation of the map in your program?

Doing so would mean that the generated CSV file could be imported in to real mine engineering software, allowing for crazy amounts of planning and accuracy within Minecraft.

This has come up a couple of time in requests on this forum but I havent' seen any solutions yet.


For example:

X, Y, Z - block location with reference to level origin (ie. 5,150,5) would denote a block is 5 blocks from the model origin in Easting, 150 in Northing and 5 from base of model and field denoting type of block (ie. coal, stone, water etc).


Thanks!

So, as far as I understand, you just want a converter that will turn the map into a human readable text file; just all the blocks which aren't air should be dumped with a relative origin. Anything else? Do they have to be ordered in some way?
Anyways, if this is what you want, that should really take no longer than maybe half an hour of work. I would merely write a new program for that, based on mcmap, since that has nothing to do with rendering anymore.


About the colors by NotTarts, that indeed looks really great and way more realistic.


A quick status update from my side: I'm quite sick currently, staying in bed most of the time. :-(
Still made some progress on mcmap, cause it gets quite boring doing nothing all day.

Hi, I'm a friend of optimus (the guy who made the original request). I'm a mining engineer in real life so I have access to a huge amount of real world existing mine infrastructure layouts and real world orebody models. Most models in their simplest form just have a X,y,Z co-ordinate to say where the block is sitting in space relative to an origin and then attributes for that block (ie. grade, rocktype etc).

There would be no specific requirement in the output file for anything other than the block having a value for x,y and z. ie. say the model was a perfect cube 100 blocks every side then the bottom block in the left hand corner would be (1,1,1) and top right hand corner would be (100,100,100) and for a number telling me what sort of block it is (ie. 0 = air, diamond = 3, coal = 4 etc) or something equally logical.

That would be great.

Also, assuming that you could write a program that dumps out that info in a comma separated value file, do you think it would be possible to reverse that process (ie. take a .csv file with just x,y,z and an attribute for block type and then use that to generate a minecraft level from it. Probably that would be really difficult but I'd be keen to know. I gather the model format has a bunch of other block attributes which would need to be generated.

[Zahl]

Thanks for all your positive feedback again guys! :-)

dorino1 said:

Ah, and an issue. With the skylight on, there's some black artifacting around some halfsteps in my map and some fences if I use a darker color. Hm?

Think I know where that is coming from. Included a cheap fix in the github master, so if you know how to compile this yourself you can give it a try. It unfortunately does ugly things to the edges of the map. Next official release would hopefully be tomorrow, and contain a proper fix to this.

irowboat said:

I'm having trouble compiling it, here's my specs:
Linux 2.6.32-24-server #43-Ubuntu SMP Thu Sep 16 16:05:42 UTC 2010 x86_64 GNU/Linux
g++ 4:4.4.3-1ubuntu1
g++-4.4 4.4.3-4ubuntu5
zlib1g-dev 1:1.2.3.3.dfsg-15ubuntu1
build-essential 11.4build1 11.4build1

Errors here: http://pastebin.com/UaMGmMLU

Any tips?

[edit] still fails using the github master, pastebin updated [/edit]

I'm not quite sure, but it looks like some problem with gcc. Some googling revealed that it might help to reinstall the package libc6-dev since it complains about sys/cdefs.h missing. Hope that works.

Veefy said:

Hi, I'm a friend of optimus (the guy who made the original request). I'm a mining engineer in real life so I have access to a huge amount of real world existing mine infrastructure layouts and real world orebody models. Most models in their simplest form just have a X,y,Z co-ordinate to say where the block is sitting in space relative to an origin and then attributes for that block (ie. grade, rocktype etc).

There would be no specific requirement in the output file for anything other than the block having a value for x,y and z. ie. say the model was a perfect cube 100 blocks every side then the bottom block in the left hand corner would be (1,1,1) and top right hand corner would be (100,100,100) and for a number telling me what sort of block it is (ie. 0 = air, diamond = 3, coal = 4 etc) or something equally logical.

That would be great.

Also, assuming that you could write a program that dumps out that info in a comma separated value file, do you think it would be possible to reverse that process (ie. take a .csv file with just x,y,z and an attribute for block type and then use that to generate a minecraft level from it. Probably that would be really difficult but I'd be keen to know. I gather the model format has a bunch of other block attributes which would need to be generated.

Converting to CSV should be quite trivial, however, converting back to minecraft's format would indeed be more complicated, as there is information like amout of light hitting a block and data about monsters or other entities etc. stored inside the map files. If you get some of these wrong, the whole chunk might be regarded invalid by minecraft and will be discarded, or the game might just crash. So I'll not even try to get this done. I think that would be more of a job for those who are working on external map editors for Minecraft, as they already tackled these issues.
But if you are still interested in the Minecraft to CSV converter I could do that after finishing incremental rendering, which is hopefully by tomorrow.


Finally,
about the incremental rendering: I got it to work to a limited extend right now, that means only if you use the -north switch, and it still has issues with edge detection and light where it pieces together two parts.
If you can't wait to try it out, just pull the github master, and report any additional issues you encounter. If you give it enough mem to render everything at one there should be no problems at all and it should work just like the current official release.
The way the incremental rendering currently works is:
If you give mcmap enough memory to hold the bitmap and the whole world in memory, it will do just that and use no incremental rendering at all.
If you give it more than twice the amount of memory the final bitmap will consume, mcmap will generate the whole bitmap in memory and just split up the world loading, which should still be a little faster than using disk caching, but save some memory.
Else, it will also split up the output file and render parts of the world to disk. This is the slowest approach and will take the longest time.

Rotation is as usual a little brain twister, especially as the approach I've taken for that is a little lazy...
Edge detection and light shouldn't be too hard to fix.
All that's left then is code cleanup... To many new vars, main() getting too long.

[irowboat]

Wacky fun - that did it. Thanks.

[DopeGhoti]

Looking forward to incremental rendering, as people are suddenly scattering to the four winds on my server

Also, related to the .CSV export request, the one reason I still have a copy of Cartograph is the .TXT file it dumps with a raw count of how many of each type of block are on the map.

Any chance we could get either an option to do that with mcmap or, better, a separate tool that just chews on the map data and spits out a .TXT or .CSV for our mining engineer friends?