oblique works for me in both 0.1b1 and 0.1b2. we installed python 2.6 in parallel with 2.4 as to not break stuff that relies on 2.4, and i'm pretty pleased with 0.1b2 so far!
edit: i guess i haven't tried oblique_angled, mine looks exactly like yours, gloryfish.
No, I was working on it before I switched to the multi-core stuff but didn't get it finished. It probably won't be in the first stable release but probably soon after that.
Is there a particular approach you were planning to take? I'd love to help out and I have a vacation coming up. Seems like it would be fun to work on.
Not exactly sure what you mean by this but the half-finished angled_oblique mode should give you an idea of how I was going to go about it, it'll basically be the same thing, but instead of rendering the whole map at once, it'll work on individual chunks.
Quote from Crashed »
When the maps get rotated (hopefully optional), could you put up a compass like these:
This way we know where we're going regardless of orientation.
Yep, that's the plan. Since it's using numpy now it should be pretty easy to adjust the orientation of the map, I'm just not sure when I'll get to it.
Quote from FrostyWolf »
"pynemap.py --rotate 90" for "earth-sun" orientation :smile.gif:
Corax's code allows it to be a toggle.
The problem with Corax's code is that it only works for straight-down views (like overhead), (angled) oblique would look odd.
Is there a particular approach you were planning to take? I'd love to help out and I have a vacation coming up. Seems like it would be fun to work on.
Not exactly sure what you mean by this but the half-finished angled_oblique mode should give you an idea of how I was going to go about it, it'll basically be the same thing, but instead of rendering the whole map at once, it'll work on individual chunks.
Quote from Crashed »
When the maps get rotated (hopefully optional), could you put up a compass like these:
This way we know where we're going regardless of orientation.
Yep, that's the plan. Since it's using numpy now it should be pretty easy to adjust the orientation of the map, I'm just not sure when I'll get to it.
Quote from FrostyWolf »
"pynemap.py --rotate 90" for "earth-sun" orientation :smile.gif:
Corax's code allows it to be a toggle.
The problem with Corax's code is that it only works for straight-down views (like overhead), (angled) oblique would look odd.
O, well that sucks. I mean, you can already rotate any topdown view with pretty much any image editor known to man. Oblique is where the issue is IMO.
I got this working in CentOS 5, and I just wanted to share my method with anyone else on the same platform. You can install python 2.6, and it can live happily with 2.4. It installs the binary as python2.6
1. Get EPEL repo http://fedoraproject.org/wiki/EPEL it contains python 2.6 packages
2. yum install python2.6-devel
3. Install Imaging Library and progress bar from source (see first post for that info), but make sure you do it by "python2.6 setup.py install" so it knows to install it for python 2.6.
4. Edit the pynemap.py and change #!/usr/bin/python to #!/usr/bin/python2.6
Oh and yes please have some rotating options so oblique works right. No option of cartographer will do this right, no combo of flip or rotate, so here's something this program can have over cartographer.
Other notes:
You can cron up cartographer just fine, but that shouldn't be the only reason to use this program.
And if you use convert, add "-quality 100" to maximize the compression.
Bit of an issue with a large map (780 megs) - here's the error I get. I think someone managed to get map chunks generated a thousand kilometers out.
rbos@rollup:~/minecraft-smp/pynemap$ ./pynemap.py ../world/level.dat -v
[INFO] Rendering overhead map of ../world as map.png...
[INFO] Loading chunks
[INFO] Loaded 97223 chunks
[INFO] Finding map size...
[INFO] Map size: {'x_min': -625185, 'z_min': -304, 'z_max': 625049, 'x_max': 312}
[INFO] Map image size: (10007952, 10005648)
Traceback (most recent call last):
File "./pynemap.py", line 438, in <module>
main()
File "./pynemap.py", line 405, in main
mapper.render(options['render-mode'], options['output-file'], render_options)
File "./pynemap.py", line 172, in render
self.render_modes[mode](output_file, options)
File "./pynemap.py", line 306, in _render_overhead
map_image = Image.new('RGB', map_image_size, (255,255,255))
File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 1763, in new
return Image()._new(core.fill(mode, size, color))
MemoryError
It's trying to create a huge (larger than your available memory) image because it thinks you have a chunk way off in the corner somewhere but it's probably just an oddly named .dat file. If this is release-0.1b2 then you can try changing line 150 from "self._chunk_files = glob.glob(os.path.join(self._level_dir, '*', '*', '*.dat'))" to "self._chunk_files = glob.glob(os.path.join(self._level_dir, '*', '*', 'c.*.*.dat'))" and see if that fixes it.
Bit of an issue with a large map (780 megs) - here's the error I get. I think someone managed to get map chunks generated a thousand kilometers out.
rbos@rollup:~/minecraft-smp/pynemap$ ./pynemap.py ../world/level.dat -v
[INFO] Rendering overhead map of ../world as map.png...
[INFO] Loading chunks
[INFO] Loaded 97223 chunks
[INFO] Finding map size...
[INFO] Map size: {'x_min': -625185, 'z_min': -304, 'z_max': 625049, 'x_max': 312}
[INFO] Map image size: (10007952, 10005648)
Traceback (most recent call last):
File "./pynemap.py", line 438, in <module>
main()
File "./pynemap.py", line 405, in main
mapper.render(options['render-mode'], options['output-file'], render_options)
File "./pynemap.py", line 172, in render
self.render_modes[mode](output_file, options)
File "./pynemap.py", line 306, in _render_overhead
map_image = Image.new('RGB', map_image_size, (255,255,255))
File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 1763, in new
return Image()._new(core.fill(mode, size, color))
MemoryError
It's trying to create a huge (larger than your available memory) image because it thinks you have a chunk way off in the corner somewhere but it's probably just an oddly named .dat file. If this is release-0.1b2 then you can try changing line 150 from "self._chunk_files = glob.glob(os.path.join(self._level_dir, '*', '*', '*.dat'))" to "self._chunk_files = glob.glob(os.path.join(self._level_dir, '*', '*', 'c.*.*.dat'))" and see if that fixes it.
How are things coming along for the stable release?
Bit of an issue with a large map (780 megs) - here's the error I get. I think someone managed to get map chunks generated a thousand kilometers out.
rbos@rollup:~/minecraft-smp/pynemap$ ./pynemap.py ../world/level.dat -v
[INFO] Rendering overhead map of ../world as map.png...
[INFO] Loading chunks
[INFO] Loaded 97223 chunks
[INFO] Finding map size...
[INFO] Map size: {'x_min': -625185, 'z_min': -304, 'z_max': 625049, 'x_max': 312}
[INFO] Map image size: (10007952, 10005648)
Traceback (most recent call last):
File "./pynemap.py", line 438, in <module>
main()
File "./pynemap.py", line 405, in main
mapper.render(options['render-mode'], options['output-file'], render_options)
File "./pynemap.py", line 172, in render
self.render_modes[mode](output_file, options)
File "./pynemap.py", line 306, in _render_overhead
map_image = Image.new('RGB', map_image_size, (255,255,255))
File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 1763, in new
return Image()._new(core.fill(mode, size, color))
MemoryError
It's trying to create a huge (larger than your available memory) image because it thinks you have a chunk way off in the corner somewhere but it's probably just an oddly named .dat file. If this is release-0.1b2 then you can try changing line 150 from "self._chunk_files = glob.glob(os.path.join(self._level_dir, '*', '*', '*.dat'))" to "self._chunk_files = glob.glob(os.path.join(self._level_dir, '*', '*', 'c.*.*.dat'))" and see if that fixes it.
How are things coming along for the stable release?
Slow, apparently there's no easy way to overlay images in Python so I had to write it myself which has taken a while (actually only finished it today). Problem now is that oblique mode isn't rendering right and rendering in general is really slow due to the overlaying thing. Not sure what I'm going to do about that yet.
If the rendering (drawing pixels to your image buffer) is taking the longest now, it might be time to use OpenGL. I've had a few crazy ideas about loading the entire chunk into a GL_TEXTURE_3D as an indexed color array, then drawing quads for each slice through the chunk, varying all 3 texture coordinates.
If the rendering (drawing pixels to your image buffer) is taking the longest now, it might be time to use OpenGL. I've had a few crazy ideas about loading the entire chunk into a GL_TEXTURE_3D as an indexed color array, then drawing quads for each slice through the chunk, varying all 3 texture coordinates.
I haven't done any profiling but I'm pretty sure the actual slowdown is doing the overlay stuff, although I wonder if OpenGL could help with that as well... I'll have to look into that.
keep getting this, and i got pretty much all packages there is for python(including the ones you stated ofc), running python 2.5, debian lenny
Traceback (most recent call last):
File "./pynemap.py", line 5, in <module>
import numpy, shmem
File "/home/mine/bin/pynemap/shmem.py", line 37, in <module>
from multiprocessing import sharedctypes
ImportError: No module named multiprocessing
keep getting this, and i got pretty much all packages there is for python(including the ones you stated ofc), running python 2.5, debian lenny
Traceback (most recent call last):
File "./pynemap.py", line 5, in <module>
import numpy, shmem
File "/home/mine/bin/pynemap/shmem.py", line 37, in <module>
from multiprocessing import sharedctypes
ImportError: No module named multiprocessing
Looks like the multiprocessing module was introduced in version 2.6, you'll either need to upgrade or you can try this out: http://pypi.python.org/pypi/multiprocessing/
I haven't tested it so I dunno if it will work.
keep getting this, and i got pretty much all packages there is for python(including the ones you stated ofc), running python 2.5, debian lenny
Traceback (most recent call last):
File "./pynemap.py", line 5, in <module>
import numpy, shmem
File "/home/mine/bin/pynemap/shmem.py", line 37, in <module>
from multiprocessing import sharedctypes
ImportError: No module named multiprocessing
Looks like the multiprocessing module was introduced in version 2.6, you'll either need to upgrade or you can try this out: http://pypi.python.org/pypi/multiprocessing/
I haven't tested it so I dunno if it will work.
thanks got it sorted out eventually when i installed python2.6(and a few libs)
but it really seems to take its time processing.. and i dont seem to be able to pick oblique, just the default overhead, either way great work! cant wait to use this instead of bugged cartographer
I've kind of lost interest in both the game and this project and starting working on other things, :sad.gif: Hopefully when Notch fixes some of the server-side **** like inventory I'll want to play and work on this again.
I've kind of lost interest in both the game and this project and starting working on other things, :sad.gif: Hopefully when Notch fixes some of the server-side **** like inventory I'll want to play and work on this again.
edit: i guess i haven't tried oblique_angled, mine looks exactly like yours, gloryfish.
No, I was working on it before I switched to the multi-core stuff but didn't get it finished. It probably won't be in the first stable release but probably soon after that.
This way we know where we're going regardless of orientation.
Corax's code allows it to be a toggle.
Not exactly sure what you mean by this but the half-finished angled_oblique mode should give you an idea of how I was going to go about it, it'll basically be the same thing, but instead of rendering the whole map at once, it'll work on individual chunks.
Yep, that's the plan. Since it's using numpy now it should be pretty easy to adjust the orientation of the map, I'm just not sure when I'll get to it.
The problem with Corax's code is that it only works for straight-down views (like overhead), (angled) oblique would look odd.
O, well that sucks. I mean, you can already rotate any topdown view with pretty much any image editor known to man. Oblique is where the issue is IMO.
1. Get EPEL repo http://fedoraproject.org/wiki/EPEL it contains python 2.6 packages
2. yum install python2.6-devel
3. Install Imaging Library and progress bar from source (see first post for that info), but make sure you do it by "python2.6 setup.py install" so it knows to install it for python 2.6.
4. Edit the pynemap.py and change #!/usr/bin/python to #!/usr/bin/python2.6
Oh and yes please have some rotating options so oblique works right. No option of cartographer will do this right, no combo of flip or rotate, so here's something this program can have over cartographer.
Other notes:
You can cron up cartographer just fine, but that shouldn't be the only reason to use this program.
And if you use convert, add "-quality 100" to maximize the compression.
forum: http://minecraft.novylen.net
We have cookies.
It's trying to create a huge (larger than your available memory) image because it thinks you have a chunk way off in the corner somewhere but it's probably just an oddly named .dat file. If this is release-0.1b2 then you can try changing line 150 from "self._chunk_files = glob.glob(os.path.join(self._level_dir, '*', '*', '*.dat'))" to "self._chunk_files = glob.glob(os.path.join(self._level_dir, '*', '*', 'c.*.*.dat'))" and see if that fixes it.
How are things coming along for the stable release?
Slow, apparently there's no easy way to overlay images in Python so I had to write it myself which has taken a while (actually only finished it today). Problem now is that oblique mode isn't rendering right and rendering in general is really slow due to the overlaying thing. Not sure what I'm going to do about that yet.
"We will absolutely not keep in mind what external mapeditors will have to do to read data from the disk, that makes no sense whatsoever." - Grum
I haven't done any profiling but I'm pretty sure the actual slowdown is doing the overlay stuff, although I wonder if OpenGL could help with that as well... I'll have to look into that.
Looks like the multiprocessing module was introduced in version 2.6, you'll either need to upgrade or you can try this out:
http://pypi.python.org/pypi/multiprocessing/
I haven't tested it so I dunno if it will work.
thanks got it sorted out eventually when i installed python2.6(and a few libs)
but it really seems to take its time processing.. and i dont seem to be able to pick oblique, just the default overhead, either way great work! cant wait to use this instead of bugged cartographer
Now with even more burst dragons and autokickbans plugin rpg!
I've kind of lost interest in both the game and this project and starting working on other things, :sad.gif: Hopefully when Notch fixes some of the server-side **** like inventory I'll want to play and work on this again.
how about now? server-side inventory is fixed =)