Well everything starts up fine now, but I seem to be encountering memory issues.
Program keeps throwing that error during the tile rendering process.
I have downloaded JRE 7 update 2, set java to be able to use 2gigs of ram... I'm running 64bit Win7 still, with 8gigs of ddr3 (so physical ram is plenty high enough). And watching the program itself, I see it never exceeds allocating itself more than 256(?)MB of ram.
Is that the problem, or is there something else I'm missing that I can fix?
Wow thats a big map! Minetographer has a built in limit of 256MB which I've tested to work up to 36000 tiles. This is good for most users. At this point, if you want to change this you must use the Linux version, as the Windows version is permanently set by my compiler.
Run the linux version using the following command:
java -Xmx1024m -jar Minetographer -run
Change the value within -Xmx ... m to the amount of MB you want to allocate. If you want the most memory possible, it is a good idea to only allocate HALF of your total system memory. You don't want one program to have all the memory, because your system will start paging memory to the disk... You said you have 2GB of RAM; You should then use -Xmx1024m or -Xmx1g.
In the future I want to create a launcher that will allow users to define how much memory to use at startup.
As always your support is both timely and on-the-ball.
I'll give this a rumble and update with status :smile.gif:
Update:
Hehehehehehe! Rendering Tiles at 1600MB and counting! <mad cackle> It lives.... IT LIVES!
Thanks again for all the help!
Edit: 2900 MB o.0
Well thank you! :biggrin.gif:
HAHA. I haven't taken the time to properly tune the garbage collector, so it won't release memory until it runs out or when the render completes. In the mean-time it holds on to all the memory in case it needs to use some (so it doesn't have to re-allocate).
So it's not actively using all that memory, it's just not letting the inactive memory go.
Im not sure if this is possible, but could the software calculate roughly how large the map will be once its rendered? I was doing a test render today, was almost finished with what I thought was a decent compressed settings but it was close to 20 gigs worth of map and a lot more than I wanted to deal with.
Otherwise some decent settings to get a render around 2-3 gigs where the original map is about a gig of data.
Im not sure if this is possible, but could the software calculate roughly how large the map will be once its rendered? I was doing a test render today, was almost finished with what I thought was a decent compressed settings but it was close to 20 gigs worth of map and a lot more than I wanted to deal with.
Otherwise some decent settings to get a render around 2-3 gigs where the original map is about a gig of data.
I am running some tests to find the best weight/quality ratio, and trying to find some kind of formula to calculate the final size.
The results of my tests are starting to be interesting.
First it looks like color depth is totally useless (no difference whatever setting i put)
Also it looks like the JPG compression only accepts values of 1.0, 0.5 or 0.0. All intermediate values i tried used the previous setting.
Here is a comparison of the weight of the different files.
This weight is for a small map (2700 chunks) and with only one zoom level, with camera height set to 12. (these are the parameters that i found influencing the weight of the map).
For a big map. the size would be different, but the order would stay the same.
I'm now personally going to use GIF, because it looks as good a JPG 100, but is lighter.
For very big maps i would recommend JPG 0.5, it gets a little bit of compression but is acceptable.
Then i discovered that the number of zoom levels changes slightly the weight of the file.
A zoom level set to one will only render the most zoomed up view (biggest files), a level 2 will render the most zoomed up, and one zoomed down a little bit (biggest + 1 a little big smaller), a level 3 wil render the close-up + 2 zoomed down level, and so on.
This value can be set pretty high without changing the final weight too much.
The most interesting part is the one about camera height, but the renders take forever, so i still don't have all the results concerning this one, i will add my final data here as soon as i get them.
jakester2, i don't know if you are aware, but it seems like i have to restart minetographer between each render.
Here is the interesting part: The camera height property.
Take a look at this graph:
As you can see, the lower the value, the bigger the files. A camera height of 2 will generate a map 45 times bigger than a camera height of 24 (4.4GB VS 99 MB for GIF for exemple).
And the only thing a camera height of 2 will allow you is to zoom really close to the map, but even a height of 24 will still allow you to see clearly the mushrooms on your map. The default value is 12, you can get 3.5 times smaller than default by going 24, and the map will not be that different.
My advice would be to go for GIF with a camera height of 20 and 6 levels of zoom for regular maps.
Big maps should go JPG 0.5 with cam height of 24 and 8 levels of zoom (or even bigger if 8 doesn't allow to zoom out all the way).
The results of my tests are starting to be interesting.
First it looks like color depth is totally useless (no difference whatever setting i put)
Also it looks like the JPG compression only accepts values of 1.0, 0.5 or 0.0. All intermediate values i tried used the previous setting.
Here is a comparison of the weight of the different files.
This weight is for a small map (2700 chunks) and with only one zoom level, with camera height set to 12. (these are the parameters that i found influencing the weight of the map).
For a big map. the size would be different, but the order would stay the same.
I'm now personally going to use GIF, because it looks as good a JPG 100, but is lighter.
For very big maps i would recommend JPG 0.5, it gets a little bit of compression but is acceptable.
Then i discovered that the number of zoom levels changes slightly the weight of the file.
A zoom level set to one will only render the most zoomed up view (biggest files), a level 2 will render the most zoomed up, and one zoomed down a little bit (biggest + 1 a little big smaller), a level 3 wil render the close-up + 2 zoomed down level, and so on.
This value can be set pretty high without changing the final weight too much.
The most interesting part is the one about camera height, but the renders take forever, so i still don't have all the results concerning this one, i will add my final data here as soon as i get them.
jakester2, i don't know if you are aware, but it seems like i have to restart minetographer between each render.
This is some great data! I have been doing some regression analysis lately to try and accurately calculate the output sizes. But without the source code for Tectonicus, this is difficult.
Just to make a correction, the alpha bits setting does in fact do something. It determines the complexity of the alpha color rendered by your graphics card. It, however has no effect on render size. Also, the jpg compression range supports all floating point values between 1.0 and 0.01. If you don't notice a change, there may be a problem with your graphics driver.
Generally the best way to quickly lower the file size is to set the camera height to 18+. For servers with very large maps, I recommend 20+. This value decreases the file size exponentially.
About the restart bug; Yes I am aware of this and I'm going to have a solution as soon as I can.
As you can see, the lower the value, the bigger the files. A camera height of 2 will generate a map 45 times bigger than a camera height of 24 (4.4GB VS 99 MB for GIF for exemple).
And the only thing a camera height of 2 will allow you is to zoom really close to the map, but even a height of 24 will still allow you to see clearly the mushrooms on your map. The default value is 12, you can get 3.5 times smaller than default by going 24, and the map will not be that different.
My advice would be to go for GIF with a camera height of 20 and 6 levels of zoom for regular maps.
Big maps should go JPG 0.5 with cam height of 24 and 8 levels of zoom (or even bigger if 8 doesn't allow to zoom out all the way).
Cheers
Wow this is really great! Thanks for your hard work. I think I will modify the available settings to take this data into account.
And I have to agree. I just ran a render with GIF, CH20, ZL6 and it turned out great.
Putting aside file size, I would still go with JPG 0.80 as far as quality vs. file size. Although GIF looks good with the default texture pack, when using others I have gotten poor color quality in the past. It really depends on preference though.
I am very tired now, but i will definitely try again other JPG compression settings tomorrow if i have time...
I tried 0.8, 0.7 and 0.25 and all the time the outpout folder was 111MB (wich was my size for 0.5) and when i was restarting minetographer, the value was back to 0.5.
I am very tired now, but i will definitely try again other JPG compression settings tomorrow if i have time...
I tried 0.8, 0.7 and 0.25 and all the time the outpout folder was 111MB (wich was my size for 0.5) and when i was restarting minetographer, the value was back to 0.5.
It looks like your setting isn't applying. When you change the value of a text field you have to press Enter to apply the change.
yes i know that..
I was even pressing save settings even if it's not supposed to be necessary..
I'll let you know when i've done my tests.
Any plans for rendering the nether in the next version? :smile.gif:
That is very strange. I have 5 different machines that I test every release on and this has not been an issue. Go to your Minetographer app data folder and try deleting any .mdat files you see. One of them may be corrupted. Minetographer will rebuild them at next launch.
And the nether has worked since 0.7.5. Just change the dimension drop down box from Terra to Nether.
Heres a map I made last night using 0.7.6: (and no its not buggy, thats actually how my nether map looks. lol)
So yes it's rendering my nether, but it's rendering all the top layer of bedrock (that should be present in all legit nether world) so we can't see anything..
It's been doing that since the 1st version i tried, that's why i keep asking what you're going to do about the nether :tongue.gif:
I have tried using minetographer
Tho i find it hard for my very large map.
My map is 2.2gb large, so it is very big.
It had around 600k chunks according to minetographer
tho when it started to render it stoped half way...
it took over 48 hours to get to half way...
so i was quite sad to see it stop
Make sure you guys set the camera height to 24, that's the only way to make your render lighter.
Maybe you will also need to increase the ram allowed to the software, jakester explains how to do it somewhere in this thread.
But big maps are time and ressource consuming, and if your computer doesn't follow, you might never be able to render the map.
Wow thats a big map! Minetographer has a built in limit of 256MB which I've tested to work up to 36000 tiles. This is good for most users. At this point, if you want to change this you must use the Linux version, as the Windows version is permanently set by my compiler.
Run the linux version using the following command:
Change the value within -Xmx ... m to the amount of MB you want to allocate. If you want the most memory possible, it is a good idea to only allocate HALF of your total system memory. You don't want one program to have all the memory, because your system will start paging memory to the disk... You said you have 2GB of RAM; You should then use -Xmx1024m or -Xmx1g.
In the future I want to create a launcher that will allow users to define how much memory to use at startup.
I'll give this a rumble and update with status :smile.gif:
Update:
Hehehehehehe! Rendering Tiles at 1600MB and counting! <mad cackle> It lives.... IT LIVES!
Thanks again for all the help!
Edit: 2900 MB o.0
Well thank you! :biggrin.gif:
HAHA. I haven't taken the time to properly tune the garbage collector, so it won't release memory until it runs out or when the render completes. In the mean-time it holds on to all the memory in case it needs to use some (so it doesn't have to re-allocate).
So it's not actively using all that memory, it's just not letting the inactive memory go.
Uploading my Mk2 map to my website now, woot!
Mk1 was a .png at 9+gigs, so I decided to go with the tried and true .90 compression .jpg lol.
1 gig is a little easier to upload. Even if it is 91,500 files.
I love these maps :smile.gif:
Yeah, for a web server jpg is defiantly the way to go! Can you post a link to the map?
I would like to see that huge map too!
Otherwise some decent settings to get a render around 2-3 gigs where the original map is about a gig of data.
I am running some tests to find the best weight/quality ratio, and trying to find some kind of formula to calculate the final size.
Downloading
First it looks like color depth is totally useless (no difference whatever setting i put)
Also it looks like the JPG compression only accepts values of 1.0, 0.5 or 0.0. All intermediate values i tried used the previous setting.
Here is a comparison of the weight of the different files.
This weight is for a small map (2700 chunks) and with only one zoom level, with camera height set to 12. (these are the parameters that i found influencing the weight of the map).
For a big map. the size would be different, but the order would stay the same.
I'm now personally going to use GIF, because it looks as good a JPG 100, but is lighter.
For very big maps i would recommend JPG 0.5, it gets a little bit of compression but is acceptable.
Then i discovered that the number of zoom levels changes slightly the weight of the file.
A zoom level set to one will only render the most zoomed up view (biggest files), a level 2 will render the most zoomed up, and one zoomed down a little bit (biggest + 1 a little big smaller), a level 3 wil render the close-up + 2 zoomed down level, and so on.
This value can be set pretty high without changing the final weight too much.
The most interesting part is the one about camera height, but the renders take forever, so i still don't have all the results concerning this one, i will add my final data here as soon as i get them.
jakester2, i don't know if you are aware, but it seems like i have to restart minetographer between each render.
Take a look at this graph:
As you can see, the lower the value, the bigger the files. A camera height of 2 will generate a map 45 times bigger than a camera height of 24 (4.4GB VS 99 MB for GIF for exemple).
And the only thing a camera height of 2 will allow you is to zoom really close to the map, but even a height of 24 will still allow you to see clearly the mushrooms on your map. The default value is 12, you can get 3.5 times smaller than default by going 24, and the map will not be that different.
My advice would be to go for GIF with a camera height of 20 and 6 levels of zoom for regular maps.
Big maps should go JPG 0.5 with cam height of 24 and 8 levels of zoom (or even bigger if 8 doesn't allow to zoom out all the way).
Cheers
This is some great data! I have been doing some regression analysis lately to try and accurately calculate the output sizes. But without the source code for Tectonicus, this is difficult.
Just to make a correction, the alpha bits setting does in fact do something. It determines the complexity of the alpha color rendered by your graphics card. It, however has no effect on render size. Also, the jpg compression range supports all floating point values between 1.0 and 0.01. If you don't notice a change, there may be a problem with your graphics driver.
Generally the best way to quickly lower the file size is to set the camera height to 18+. For servers with very large maps, I recommend 20+. This value decreases the file size exponentially.
About the restart bug; Yes I am aware of this and I'm going to have a solution as soon as I can.
Wow this is really great! Thanks for your hard work. I think I will modify the available settings to take this data into account.
And I have to agree. I just ran a render with GIF, CH20, ZL6 and it turned out great.
Putting aside file size, I would still go with JPG 0.80 as far as quality vs. file size. Although GIF looks good with the default texture pack, when using others I have gotten poor color quality in the past. It really depends on preference though.
I am currently re-rendering to get below 1000MB filesize. (My Free Website only holds that, and the site comes with my minecraft server)
So once I have gotten the size below that I'll throw a link on here.
I do have to say though, the map doesn't seem that large to me personally. I'm certain that servers with like 100-150 people have much larger ones...
I think the file size might be misleading. But regardless, I'll throw the link on here :wink.gif:
I tried 0.8, 0.7 and 0.25 and all the time the outpout folder was 111MB (wich was my size for 0.5) and when i was restarting minetographer, the value was back to 0.5.
It looks like your setting isn't applying. When you change the value of a text field you have to press Enter to apply the change.
I was even pressing save settings even if it's not supposed to be necessary..
I'll let you know when i've done my tests.
Any plans for rendering the nether in the next version? :smile.gif:
That is very strange. I have 5 different machines that I test every release on and this has not been an issue. Go to your Minetographer app data folder and try deleting any .mdat files you see. One of them may be corrupted. Minetographer will rebuild them at next launch.
And the nether has worked since 0.7.5. Just change the dimension drop down box from Terra to Nether.
Heres a map I made last night using 0.7.6: (and no its not buggy, thats actually how my nether map looks. lol)
So yes it's rendering my nether, but it's rendering all the top layer of bedrock (that should be present in all legit nether world) so we can't see anything..
It's been doing that since the 1st version i tried, that's why i keep asking what you're going to do about the nether :tongue.gif:
Make sure you guys set the camera height to 24, that's the only way to make your render lighter.
Maybe you will also need to increase the ram allowed to the software, jakester explains how to do it somewhere in this thread.
But big maps are time and ressource consuming, and if your computer doesn't follow, you might never be able to render the map.