Tiling strangeness

Bug Reports
#1

Hi,…I’m trying to incorporate tiles into a larger tile set. This is proving extremely vexing…there’s some wierdness going on with the tiled output

The process:
I output 4 contiguous tiles 10K from Global Mapper.

I take the bottom right tile “A” Process it and output as 4 10K tiles, covering exact same area but double the res.

Take the tile set from Global Mapper (call it “B”) and output it as 16 10K tiles, again doubling the res.

I alter the tile names of “A” so that they will be loaded as part of the tile set “B”, covering the same area- …but trying to merge A into B, produces inexlicable disparities
of alignment and features.
In both A and B, I turned off Edge Blending in any file import devices.

Taking the tile 2_1 for eg…

1st tiling results for B
http://www.skindustry.net/medem/files/Temp/bug/Tile_set_1st_attempt.png

2nd tiling results for B
http://www.skindustry.net/medem/files/Temp/bug/Tile_set_2nd_attempt.png

subset A result
http://www.skindustry.net/medem/files/Temp/bug/subset_A.png

I’ve been at this for a week now, and I’m at a loss to work out what’s going on.

monks

#2

Actually the process I described above it not what I did.

I didn’t take tiles from Global Mapper in the end- I just outputted a single 10K file from there. Then I processed that 10K file and upscaled and tiled in WM. Both A and B
came from that first single tile from Global Mapper.

monks

#3

Ok, here’s a clearer illustration of the problem:
the process I’m following in a nutshell…I’ve included a shot of the same area of the terrain at each stage.

Take a 10K tile from Global Mapper. Edit out any out of range data at the edge.

We now have the 10K parent tile.
http://www.skindustry.net/medem/files/Temp/bug/again/parent.png

WM- upscale to 20K- call this A (can’t work with 20 K single tiles in WM-
hence only upscaling to 20K at first)- A = now 4 10K tiles.
http://www.skindustry.net/medem/files/Temp/bug/again/fromthe20k.png

Take the lower right tile (call it B) process and tile and output as 4 10Ks…no erosion or processing here
anywhere near the edges so no reason for anything to change at the edges.
Any processing is occuring within a masked out interior section.
http://www.skindustry.net/medem/files/Temp/bug/again/fromthemordor.png

Take A and upscale again to 40K. Now these are at the same scale as B.
rename the tiles B (well no need to even do that as you can set WM to do it)
drop subset tiles B tiles into A folder
http://www.skindustry.net/medem/files/Temp/bug/again/2_1fromthe40k.png

Siurely these should be exact matches? There’s distortion and shifting around of terrain features.

*The differences in the colours in the pngs above are due to the fact that
Wilbur’s shader is set to relative altitudes not absolute. It changes
depending on what terrain range you have in the tile.

*All tiles are strictly speaking 10004, set up in the Custom.

There’s a setting called edge blending in file import devices in WM. I’ve
made sure that’s been set to 0 in every case. Not sure if this will help,
but it’s the only thing I could think of changing.

I’m not doing ANY processing at all on the complete tile set A, and the processing on B is limited to the interior by a mask.
Both A and B share a common parent.

monks

#4

Stephen, it seems to be the resampling and tiling.
Here’s another test of a tmd consisting of two devices. File import and height output.
I turned off Edge Blending in the file import.

The terrain before
http://www.skindustry.net/medem/files/Temp/bug/original.png
and after
http://www.skindustry.net/medem/files/Temp/bug/after_20k.png

It only seems to have errors along the n-s axis. e-w looks fine to me.
Maybe it’s the Edge blending, or bt format or the 10K size??

monks

#5

Hi monks,

I’m trying to understand exactly what is happening here… I’m getting a bit confused by all the image scales in play here which is making it hard to understand where you’re seeing an issue. In the sequence parent->fromthe20->fromthemordor->fromthe40, there is a zooming in occurring that is making it hard for me to match up features and see what you’re talking about. Is that an artifact of something or part of the effect you’re talking about?

#6

perfect, I was just going to ask about reducing to the basics.

If those two images are the simple result of an input->output node setup, then there is definitely something going horribly wrong, somewhere.

Can you send me the height file going to the file input node at support@world-machine.com?

#7

:shock:…me too! My brain been hurting…but yep that last test was a much needed sanity check, I’ll get the tmd to you. I saved out a build report too on that last run.

monks

#8

I just did a test that took 4 10K tiles, added some layout shapes over the n-s axis, and outputted as exactly the same tile set.
Similar errors were there again, so it looks like it’s the tiling rather than the resampling as such.

//stephen, is there any chance of a link to an older build that doesn’t have the bug?? I’m kinda in the middle of a large Make run on our project terrain for the renderer
and WM is crucial to it!

monks

#9

Is there a chance of mailing me a link to an earlier build that works? I don’t have any other versions here…

monks

#10

TURNS OUT THIS WAS NOT A BUG AFTER ALL. garrrrrrrr!!!

SOLVED.

monks

#11

Any chance you could explain more? :stuck_out_tongue:

I am working through my bug list and was about to start diving back into this one.

#12

:D…nah not a bug. Two source terrains that should have shared the same parent, didn’t. But Tthey still should have been identical since I always work with the same tile set configuration, but somehow one got altered. So, I had to go back to the parent tiles set and start the whole workflow again.

Btw, Stephen, I couldn’t find any info in the pdf help file on positioning a file manually in the world. There’s the options Bring into view and Set in Layout in the file input device. Did you include that? It’d be great to have a manual option in Layout mode where you could just move and position the file with a hand tool - like Photoshop. Just an idea. :wink:

monks

#13