Tree render.

[tahoward]

Ok, dynmap pulls off a full render on a pre-generated world like Skylands, however, it seems to not like trees all that much:

http://img.photobucket.com/albums/v380/drkomiter/dynmap_skylands_trees.jpg

This also occurs on the edge of normal maps as well, except just the tops of the tree leaves go missing:

http://map.madminer.com

The difference being with Skylands is most of the map has not been traveled by players.

My template for Skylands:

version: 0.20 templates:

Template for normal world (HDMap hires)

custom-normal-skylowres: enabled: true

Number of extra zoom-out levels for world (each level is twice as big as the previous one)

extrazoomout: 2
center:
  x: 0
  y: 64
  z: 0
maps:
  - class: org.dynmap.hdmap.HDMap
    name: skylands
    title: "SkyLands"
    prefix: dntsky
    perspective: iso_SE_60_medres
    shader: jolitexture
    lighting: nightandday
    icon: images/block_skyland_custom.png

[rodeyseijkens]

Same issue here too.

[FrozenCow]

Can you try using the official Dynmap v0.20?

[tahoward]

The madminer address is now updated to the recommended version of Dynmap v0.20. Removed the tile directory for a fresh render. I re-ran the render for Skylands on my local machine as well with identical results as preciously posted.

Edit: preciously lol...

[rodeyseijkens]

I also run on the Recommended v0.20 version.

[FrozenCow]

I've found the issue and fixed it in 0.21. I'll create a 0.20.1 version later when some more of the fixes are in. The issue was that for some reason Skylands uses data-value 8 for parts of their leaves. The minecraftwiki isn't yet up to date on these values, since they only describe values 0, 1 and 2: http://www.minecraftwiki.net/images/8/8c/DataValuesBeta.png You can get 0.21 here: http://webbukkit.org/jenkins/public/dynmap/

[mikeprimm]

@FrozenCow - I found that the non 0,1,2 values are present in general (not skylands specific): looks like the values can have either 4 or 8 added on, and it appears to have to do with the leaves being marked for "fade processing" (the possibility that they may fade). I suspect that the chunk generator creates some of these pre-marked, and if the chunk isn't loaded long enough, it never gers processed (hence why it has been reported primarily on remote corners of folks maps).

[FrozenCow]

Hmm interesting. I would guess this feature is only in the newest versions of Minecraft. I added some debugging to test the data values of a few trees, apparently those didn't contain data-values with 4. Where exactly did you get this information?

[mikeprimm]

I added debug for any blockdata above 2 for leaves, and did a run on a non-trivial normal-environment world. I saw values for all 3 leaf types (0,1,2), plus all of them +4 (4, 5, 6), plus all of them +8 (8, 9, 10). The minecraft wiki text for the Block IDs page describing the mapping makes reference to 'bit 0x4' being associated with leaf fade processing (see http://www.minecraftwiki.net/wiki/Data_values#Leaves) - I suspect that both 4 and 8 are associated with this processing, particularly since I found the coordinates of the +4 and +8 valued leaves correlated with chunks that were likely only active briefly after they were first generated (the most remote corners and edges of my map). I'm going to take a peek at the Bukkit/MC server chunk generation code and tree population code to confirm the domain of bits, but my test run with the equivalent texture mappings for N, N+4, and N+8 yielded 100% correction on all trees of all types on my test map.

[mikeprimm]

The values are what I found by adding debug on any tree data value above 2, and running on my nontrivial normal world map. I observed all combinations of the 3 base ids and both +4 and +8 (but not +12). There is a reference to 'bit 0x4' in the text of the block data text in the MC wiki.

FrozenCow reply@reply.github.com wrote:

Hmm interesting. I would guess this feature is only in the newest versions of Minecraft. I added some debugging to test the data values of a few trees, apparently those didn't contain data-values with 4. Where exactly did you get this information?

Reply to this email directly or view it on GitHub: https://github.com/webbukkit/dynmap/issues/376#issuecomment-1748873

[tahoward]

Map.madminer.com has been updated with v0.21. Topless trees are still popping up towards the edges. I ran the render on my local machine for Skylands with no change as well.

[mikeprimm]

What time was the build you used? I've tested the latest with a map that showed the problem and everything worked.

[tahoward]

About 20 minutes ago. I just re-downloaded v0.21 to be absolutely sure and have set up bindings so map2.madminer.com resolves to my local test machine which has skylands loaded on a fresh, mostly unmodified, dynmap plugin. Using the default "skylands-hires" template with flat map commented out.

server.madminer.com:25566 should get you on the minecraft server for this map.

It will take a while to fully render, but you should be able to see what I am looking at.

[mikeprimm]

Try latest build when you get a chance

[tahoward]

I see trees now; with leafs! Awesome work. I'll let this sit and render to see if I can catch anything else.

map2.madminer.com

[tahoward]

Closed by accident. My bad.

We got leafs now; however there are still a few oddities if you start looking closely at the trees. I'll log in to the server to see if there is a common type for the missing leaf blocks tomorrow evening.

[mikeprimm]

OK - added the id=3 leaves, which appear (though not documented anyplace I can find) to come from migration of alpha maps. Give latest 0.21 a spin.

[tahoward]

Ok, I'll be able to in about 3 and a half hours from now.

Edit: Running now. Initial results are looking better than I last remember; will let this complete.

BTW 32 bit is awesome with duko pack. map.madminer.com; putting my vm to good use. : )

[tahoward]

Go ahead and call this one fixed.

[mikeprimm]

Cool - thanks for the help getting this fixed

[tahoward]

My pleasure, dynmap is an amazing piece of work. Glad to help. : -)