Project Orbiter texture tree tools (OT3)

[fort]

Thanks for posting this fort.

I thought I was losing my mind when the documentation and treeman were giving two different latitude index results for the converted file, old surface tile to new.

Hello,

I think that those formulas are right but I was hoping that Face will confirm it by regards to it's own formulas for treeman but... All experiences i made seems to confirm that i'm right but sometimes...

I was hoping also that Martin will take à look someday to this topic and says something about that difference between it's pdf and what one experiment here but...

good day NukeET and thank you for your addons.
:tiphat:

 

[Face]

Thanks for posting this fort.

I thought I was losing my mind when the documentation and treeman were giving two different latitude index results for the converted file, old surface tile to new.

Hello,

I think that those formulas are right but I was hoping that Face will confirm it by regards to it's own formulas for treeman but... All experiences i made seems to confirm that i'm right but sometimes...

I was hoping also that Martin will take à look someday to this topic and says something about that difference between it's pdf and what one experiment here but...

good day NukeET and thank you for your addons.
:tiphat:

I must admit that I simply did not understand fort's text. What is wrong now? treeman's output, or martins formula?

If the former: I've tried it with several bases, and the results were right IMHO. If the later: I started with martins formula, but of course I never expected my code to work perfectly at first, so I've tweaked it until it worked correctly (in my eyes) for the bases I've tried.

If you folks think that there is something wrong with martins documentation, please report it to him. If you think treeman is producing wrong output, please give me an example where it does so, and what the correct result should be, so I can look into where it goes wrong.

Here is the code I use to convert old-style tiles to new-style tiles NOW:

float bands=pow((float)2,level+7);
level+=12;
lat=(int)bands-1-lat;
lon=(int)bands*2+lon;

This is what I started with (in my naive 1:1 conversion to code from documentation), but what is apparently wrong:

float bands=pow((float)2,level+7);
level+=12;
lat=(int)bands-(lat<0?0:1)-lat;
lon=(int)bands*2+(lon<0?0:1)+lon;

Fort, did you talk to martins about that already?

 

[fort]

...so I've tweaked it until it worked correctly (in my eyes) for the bases I've tried

For my part I have not tweaked my trys. I tried to understand at new ( a made it a lot of time in the past ), from the Pablo Luna exe, how the tile structure works compared to the 2016 one but, short on my english, it will be really difficult for me to give a comprehensive explanation here.

I think that the formulas i posted are right but i was hoping that someone, maybe you, could confirm it, or not, without, for me, to make others experiments that takes always a lot of time.

I remember some test i made with the last release for treeman and it seems to me that everything was right compared to my research.

I don't know, who, will have, and where, and how - and, as you see, i'm not the champion of the english language here - to contact Dr Schweiger about that, and i'm not sure that he have time for.

I've done what i was maybe able to do. After that...

good day Face.

 

[Face]

I think that the formulas i posted are right but i was hoping that someone, maybe you, could confirm it, or not, without, for me, to make others experiments that takes always a lot of time.

I remember some test made with the last release for treeman and it seems to me that everything was right compared to my modest research.

I don't know, who, will have, and where, and how - and, as you see, i'm not the champion of the english language here - to contact Dr Schweiger about that, and i'm not sure that he have time for that.

I've done what i was able to do. After that...

good day.

So if I get that right you want me to tell martins that there might be something wrong with his documentation? Well, I can do that, but I can't really explain it. I can just show him my code and ask him to rethink the documentation based on it.

However, I can't explain it based on your post, because I don't understand it myself. NukeET, you apparently understand it, could you do that, please?

Perhaps I don't see the difference, because I work on the configuration file entries and not on the file names? :shrug:

---------- Post added at 22:13 ---------- Previous post was at 21:58 ----------

For my part I have not tweaked my trys. I tried to understand at new ( a made it a lot of time in the past ), from the Pablo Luna exe, how the tile structure works compared to the 2016 one but, short on my english, it will be really difficult for me to give a comprehensive explanation here.

Well, coding is different from just doing it by hand. I often had situations where readily available formulas were hard to translate to code, so I am not that surprised if my first approaches are wrong. In addition, the formula in martins documentation talks about file-names (E/W and N/S prefixes), not the entries in the configuration file (simple integer values). Perhaps that's different, too?

However, if treeman presents correct results, but your manual procedures following martins formula is off-by-one, there might be at least some misunderstanding of the documentation.

 

[fort]

misunderstanding

...misunderstanding or errors, i don't know.

So if I get that right you want me to tell martins that there might be something wrong with his documentation ?

Is it necessary ? : treeman works and my approach works in concert with your program. Not sure that there will be a lot of people to try by themselves the little equation of the pdf. But treeman certainly more often.

Nevertheless, in spite of my problem with english language i'll try to show here the demonstration - not sure that someone will be interested but...- point by point, starting from the 2010 arborescence to the 2016 one, to explain how i finished with my own formulas and how they match - and i think quite correctly in terms of coordinates - the result given by the last release of treeman, and Orbiter references themselves.

In the meantime - because it can takes time for that: pictures, right translations from french to english, and i don't use a translator... - if, in the meantime, luck could bring Dr Schweiger around...

I will start from the Pablo Luna exe - and it's imperfections -and from a basic grid, with eight, ten, twelve...some tiles, paired number. But back to work tomorrow...so maybe tuesday and most certainly wenesday or later or never.

My mind is far from all the reflexion i've made to obtain the resulting formulas - and it was not a pleasure party - but it should be ok nevertheless. At the end all the "logical" of that is clear.

 

[NukeET]

I think fort is right.

The following is empirically determined:

If I convert old surface tile, Moon_3_e1674_s0397.dds:

using Martin's documentation, I get >>surf\15\001421\003723.dds

using treeman, I get >>surf\15\001420\003723.dds

using fort's rules, I get >>surf\15\001420\003722.dds

What actually works in my case is fort's version.

EDIT

I tried a newer(?) version of treeman, found here: http://www.orbiter-forum.com/showthread.php?p=543594&postcount=33

What I then got as output was >>surf\15\001420\003722. i.e., what works in my case.

 

[fort]

I think fort is right.

The following is empirically determined:

If I convert old surface tile, Moon_3_e1674_s0397.dds:

using Martin's documentation, I get >>surf\15\001421\003723.dds

using treeman, I get >>surf\15\001420\003723.dds

using fort's rules, I get >>surf\15\001420\003722.dds

What actually works in my case is fort's version.

I dont remember exactly but i think that the problem come from the version you use. I remember obtaining a good result with a treeman version ( maybe the one made in october: OT3's one, page 3 or 4 of that topic ), when the one posted in the entry of the topic could be obsolete.

http://orbiter-forum.com/showthread.php?p=543594&postcount=33

 

[NukeET]

I dont remember exactly but be carefull with the version you use. I remember obtaining a good result with a treeman version ( maybe the one made in october: OT3's one, page 3 or 4 of that topic ).

http://orbiter-forum.com/showthread.php?p=543594&postcount=33

See the edit on my last post here:

http://www.orbiter-forum.com/showthread.php?p=545671&postcount=66

 

[Face]

Is it necessary ? : treeman works and my approach works in concert with your program. Not sure that there will be a lot of people to try by themselves the little equation of the pdf. But treeman certainly more often.

That's the question right there. If treeman works properly according to your understanding (and examples), I can show (and explain) the code to martins. But I don't know whether or not it matches his equations.

In the meantime - because it can takes time for that: pictures, right translations from french to english, and i don't use a translator... - if, in the meantime, luck could bring Dr Schweiger around...

I guess Martin is not visiting this thread frequently, so chances are he never noticed this uncertainty. I'll send him a PM.

 

[fort]

Hello,

I spent a lot of time to experiment about these "shift by one".

I have no base to convert or create. But grounds in Orbiter interested me for a long time and, in fact, OT3 was, is, another tool than I wanted to know.

If one accept to spend - not you, you have enough to do with treeman - half an hour can be one hour, surftilecalculator paper and pencil in hand, old tilemanager eventually to be complete, starting from previous experiments - the ones I filled pages 2 and 3 of this topic - to try to understand how all this works and inform anomalies identified (starting from the information of the pdf, in confrontation with our own testing), if the equations at the end prove to be simple enough ... they do not match with those of Dr. Schweiger.

I can always be wrong but I think I did all this with rigor, own material, protocols, and NukeET but only NukeET, alas, seems to say that my results could be correct. Many were interested in your device - treeman, OT3 now - there is a month or two, but I no longer see them ...

And when NukeET confronts, our findings, handmade, with those of OT3, latest version, they are identical. Meaning that OT3 does the job as it could be done by hand with our own formulas.

There must be something, somewhere... or we deceive, are wrong, all three. It 's possible.

Is all that important at the point that we should call Dr. Schweiger for that ? I have no idea.

 

[Face]

Many were interested in your device - treeman, OT3 now - there is a month or two, but I no longer see them ...

Yeah, that's not the first time this happens. No problem with me, if nobody is interested anymore, I'll just stop working on it. :shrug:
At the moment, though, it is too early to do this judgement, because of course people are busy exploring and playing the new version. Give them some time.

And when NukeEt confronts, our findings, handmade, with those of OT3, latest version, they are identical. Meaning that OT3 does the job as it could be done by hand with our own formulas.

There must be something, somewhere... or we deceive, are wrong, all three. It 's possible.

Is all that important at the point that we should call Dr. Schweiger for that ? I have no idea.

Well, as I see it there is AT LEAST a misunderstanding - if not even an error - of martins equations, if all of us three needed to adjust their procedures to get proper results. So for this alone it can't hurt to contact him IMHO. This is why I've already sent him a PM with a short description of the matter at hand, some comments on what I think is the problem, and an invitation to join the discussion here. We'll see what happens...

 

[fort]

At the moment, though, it is too early to do this judgement,

It's also how i see that.

So for this alone it can't hurt to contact him IMHO.

I would have hesitated to take this initiative. I'm only a light butterfly in Orbiter.

 

[Face]

I would have hesitated to take this initiative. I'm a only a light butterfly in Orbiter.

Hey, the good doctor is no crocodile :lol: . No need to be shy.

 

[4throck]

At the moment, though, it is too early to do this judgement, because of course people are busy exploring and playing the new version. Give them some time.

Of course I'm interested!
But as Face mentioned these things take time.
I also prefer to start working with something that has matured.
So to be honest I'm waiting on a post reading "here's the link to the final version" :lol:

In orbiter development nothing is fast or easy.

A personal example:
1) I started modeling an upgraded Gemini VC
2) I need to merge my mesh with the existing one
3) I need to write a program to merge meshes
4) I can do it in Python but it would be nicer for others if its in Javascript (browser based)
5) I must learn more Javascript
6) No new mesh and no converter program :facepalm:

 

[Face]

So to be honest I'm waiting on a post reading "here's the link to the final version" :lol:

There won't be a final version, just as TeX version numbers approach [math]\pi[/math], but will never reach it. So I'm afraid you will never use it, then.

 

[4throck]

No need to be so precise ;-)

Anyway, right now I'm following the "Bulgarian base conversion manual" and downloaded treeman so I'll settle for the current < 3.14 version ...

---------- Post added at 22:00 ---------- Previous post was at 21:20 ----------

OK, it works as intended, using an old school .bat file to simplify things.

Decided to convert all my bases. Had a lot of them, so made this Python script that prints the necessary .bat commands.

import os

string1 = "treeman D:\jogos\Orbiter2016_base\Textures\Earth Surf -b D:\jogos\Orbiter2016_base\Config\Earth\Base"+"\\"
string2 = " D:\jogos\Orbiter2016_base\Textures2 -y > surf.txt"

for file in os.listdir("D:\jogos\Orbiter2016_base\Config\Earth\Base"):
    if file.endswith(".cfg"):
        print(string1 + file + string2)

Copy and paste the output into a .BAT file next to treeman and just sit back

 

[NukeET]

Yeah, that's not the first time this happens. No problem with me, if nobody is interested anymore, I'll just stop working on it. :shrug:
At the moment, though, it is too early to do this judgement, because of course people are busy exploring and playing the new version. Give them some time.



Well, as I see it there is AT LEAST a misunderstanding - if not even an error - of martins equations, if all of us three needed to adjust their procedures to get proper results. So for this alone it can't hurt to contact him IMHO. This is why I've already sent him a PM with a short description of the matter at hand, some comments on what I think is the problem, and an invitation to join the discussion here. We'll see what happens...

I found the issue because the Excel spreadsheet i had developed (straight from the equations Martin published) showed a different answer than what treeman generated. Of course, I went straight to my spreadsheet first - thinking I had set up the algorithm wrong.

I would have hesitated to take this initiative. I'm only a light butterfly in Orbiter.

After seeing your add-ons...you are anything BUT a light butterfly.

 

[4throck]

My conversion efforts went well but there are issues with transparency.

I'm using the same source .dds as in Orbiter 2010 but I get:

That darker area is where .dds transparency != 0.

I think this is related to texconverter's default settings.

 

[Face]

My conversion efforts went well but there are issues with transparency.

I'm using the same source .dds as in Orbiter 2010 but I get:

That darker area is where .dds transparency != 0.

I think this is related to texconverter's default settings.

Is the transparency bit set in the old config file for that tile? Because if so, treeman would alpha-blend it into the underlying stock texture, otherwise not.

 

[4throck]

No, the bit was 1 since it worked fine in 2010.
Tried changing to 3 but the results are the same!

Orbiter 2010 (with bit set to 1) / 2016 (converted with bit set to 3)

I'll try some other .dds formats.

Anyway, why convert the tiles at all? They are already DDS. Woudnl't move and rename be enough?
Sorry if the question is dumb ;-)


But the most important is that it's looking good.
For a single base OT3 is more than useful with minimal manual work. Great job!