Project Tile Maker Development Thread - Orbiter 2014 stuff

[SolarLiner]

TileMaker is an external tool which helps you to import surface tiles into Orbiter.

Project is here: https://tilemaker.codeplex.com/

No downloads for now, because the project is in "even the code is in alpha state" ! :lol:

If people wants to help me, I'll be glad to share them the project!


PS to Moderators: If this thread is subject to crosspost with my other thread, please keep the dev one and remove the other. Thanks

---------- Post added at 21:00 ---------- Previous post was at 00:01 ----------

Question Spam(tm) :
Does Orbiter assume completely spherical planets or takes account of oblateness?
How to get the surf tile level based on the Vertical Span of the tile? The resolution of it? Other?

Thanks for answering

 

[paddy2]

Given that Planet / Moon size does not alter, tile size is fixed.

For lat is > x < y and tile is > a< b tile size equals z

x y a b could be hard coded per plant, they are a given.

My 2 penny worth

 

[SolarLiner]

So if I understand correctly, all the tile from the same level shares the same span?
So I need then to get the references to return the level from there.

 

[paddy2]

The hight is fixed but the width changes as you move away from the equator. Square at the equator and a triangle at the poles!

 

[SolarLiner]

Yeah, that's what I thought. But I still need a way to get the levels' heights from the planet the user is currently working on (because I try to make the tool as universal as possible, letting the user work on any planet they want).

 

[paddy2]

Given that there is there is only 9 planets ( He wer a planet when I ws a boy, happen he's a planet now..)

its a finite amount of coding. Choose a planet = read a dataset. Possibly have a file (.cfg) the user can alter to suit as a choice on the menu?

 

[SolarLiner]

Reading some sort of database is my plan because of the universality (who knows, maybe one day someone will want to make an island in a customized solar system).
But i still don't fully understand how to get the level of a tile ...


In other news: My threaded tile splitter works fully fine, after an almost full coffee night of crazy reading and thinking !

Basically, I give the initial image, a 512*512 rectangle corresponding to the cropped area, and the result filename, before throwing everything in a Thread Pool (these are amazing) with the cropping fuction (using the native GDI+ Bitmap class). I just have to wait for the images !
Surprisingly this was a whole lot easier than I thought, I just had to rework the initial cropping function to adapt it on a multithreaded environment.

The test used ~55% of my CPU power, and last 6 seconds. I'm so happy to got it working! It just misses the GUI feedback, the user have nothing currently to know if it has finished or not.

---------- Post added at 21:29 ---------- Previous post was at 16:44 ----------

Owait, testing on other pictures made me think that this is not good at all.
Take this (undersized for you) image of Hannah, a character from EA's Battlefield 4 (because that's the first pic I found) :

Original image is 4096x4096, so 64 tiles. Well, look at this:

While there's indeed 64 tiles, it seems like a resizing transformation was done before doing the transformation. She's normally in the center of the image, but there she seems way over the right.

So I checked my stuff. One time. Two times. Blamed the "Image.Clone()" function, tested it, but everything seems fine. I even explained my code to an imaginary alien to see if everything's good; the answer is yes. Nothing wrong. Everything is correct.

So I think that multithreading thing does not perform as wanted ... It's a shame to have to cancel that awesome Thread Pool made overnight to a long, boring 1 thread job ...

Here's everything about the stuff, fo anyone wanting the link: https://tilemaker.codeplex.com/SourceControl/latest#Threaded.cs

---------- Post added 03-10-14 at 14:17 ---------- Previous post was 03-09-14 at 21:29 ----------

WINNING !!! :woohoo:
In fact, Bitmap take DPI into account. When initializing a new Bitmap, DPI is set to default (96.0). But, some pictures had another set of DPI resolution (72 most of the time), and during cropping, when copying one Bitmap into another, DPI was respected, and the image resized. But not anymore! I now copy the Bitmap parameters into the new Bitmap variable, so DPI and all the other stuff is preserved.
Gosh that was hard to find! I'm now happy.

 

[SolarLiner]

Hi,
Improvement has been made, and progress too. I am now able to grid the planet at the best level possible for the picture, taking into account the size of the image and the size "on the planet". So I can get coordinates for all tiles, and that's good. The problem is now snapping the picture to the grid, so it can split into 512 tiles properly, with the picture staying in the right place all the time.
More precisely, it is the coordinates to pixel conversion that I need to do to get the rectangle, which will be taken into account for the splitting later. Let me explain with this image:

The snapped rectangle is in green, the actual image in red, and the grid in black.

This is what I am trying to achieve. But I just can't seem to translate from GPS coordinates to pixels in the image (I have all the references I need because I have resolution in px/cm and even in px/° ...)

Can someone help me here? It would be awesome. Thanks!

 

[SolarLiner]

I have some proof of concept regarding surface tiles for Orbiter 2014.
I don't know why, but the first 3 levels only contain one tile of the entire surface, so calculation and split is easy for these ones

I figured out that for level 4, there are 2x1 tiles total, level 5 is 4x2, lvl6 8x4, etc.
Which was easily fit in a function:
[math]2^{level-4}[/math]

Gives us the total tiles on the longitude for a given level (assuming level>3). So getting the tile in which the coordinate is in can be done easily, with only one thing to note:
[math] Tile_{lat} = 2^{level-4}*((Latitude+90) / 90)[/math]
[math]Tile_{long} = 2^{level-3}*((Longitude+180)/180)[/math]
The thing to notice is that you have to add 90/180 to the coordinates because the new system uses unsigned numbers, whereas the coordinate system is a signed one.

After that, the file path is simple: [Level:00]\[Latitude:000000]\[Longitude:000000].dds
The zeroes are the numbers of numbers* that needs to be put. (.NET format style)

Translated to TileMaker, it gives this:

Now I need to figure out the "great-grandparent" link to the elevation tiles, and what are the links to the night/specular mask tiles are as well.

My problem on snapping the image to tiles still remains, I haven't found a solution to it, so if one can help me, it would be great.

 

[Loru]

Keep in mind that surface texture & heightmap folders in Orbiter2014 will probably be compressed. AFAIK code has already been shipped to Martins for integration.

I'd hold a bit with it

 

[SolarLiner]

Won't be hard to change after all, it's only a relatively small code change. And I think I'll be able to follow along. Depends on what's coming in the next beta ...