Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Beta
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Orbiter Beta Topics related to Beta releases of Orbiter and Orbiter development.

Closed Thread
 
Thread Tools
Old 08-01-2016, 04:12 PM   #31
DaveS
Addon Developer
 
DaveS's Avatar


Default

Quote:
Originally Posted by martins View Post
 Since this question has come up a few times, I'll add a tutorial to the Orbiter documents on base design in Orbiter 2016.

In short:
  • Convert the base tiles to standard planet texture tiles (512 x 512, DXT1) and add them to the planet's texture tree (Textures\<planet name>\Surf\...)
  • Optionally, do the same for the night light textures and water masks (Textures\<planet name>\Mask)
I'm a little stuck on these two steps as I have no idea on how to convert surface tiles to planet tiles. It would be nice if a graphically comprehensive guide could be made. A good example could be this one:
VandenbergAFB - 2006
DaveS is offline  
Thanked by:
Old 08-01-2016, 04:38 PM   #32
AssemblyLanguage
Donator
Default

Quote:
Originally Posted by martins View Post
 Has this been resolved? Error code 126 means "The specified module could not be found." If the D3D9 client has indeed been installed correctly, this error might point to an unresolved dependency. (maybe the MSVC runtimes?) You could try checking with the Dependency Walker to see if you find any problems.

Anybody else with this problem?
I have MSVC Redist x86 2015, 2013, 2010, 2008 and 2005 installed. Interestingly, I have two versions of 2008: 9.0.30729.17 and 9.0.30729.6161. MSVCP.71.dll and MSVCR71.dll are in the Orbiter2016 folder.

Orbiter2016/Modules/Plugin folder has D3D9Client.dll dated 7/24/16 7:48 am.

How do I get and run the Dependency Walker?

Thanks.
AssemblyLanguage is offline  
Old 08-01-2016, 04:41 PM   #33
DaveS
Addon Developer
 
DaveS's Avatar


Default

Get these runtimes: https://www.microsoft.com/en-us/down...s.aspx?id=9033
DaveS is offline  
Thanked by:
Old 08-01-2016, 04:45 PM   #34
martins
Orbiter Founder
Default

Quote:
Originally Posted by AssemblyLanguage View Post
 I have MSVC Redist x86 2015, 2013, 2010, 2008 and 2005 installed. Interestingly, I have two versions of 2008: 9.0.30729.17 and 9.0.30729.6161. MSVCP.71.dll and MSVCR71.dll are in the Orbiter2016 folder.

Orbiter2016/Modules/Plugin folder has D3D9Client.dll dated 7/24/16 7:48 am.

How do I get and run the Dependency Walker?

Thanks.
It used to be bundled with visual studio, but probably no more. You can get a standalone version here: http://www.dependencywalker.com/. After installing, just open the 32-bit version, and drag-and-drop the D3D9 dll onto it.

There are probably more modern tools around these days, but it is still fairly useful in tracking down dependencies, missing symbols, etc.
martins is offline  
Thanked by:
Old 08-01-2016, 05:08 PM   #35
AssemblyLanguage
Donator
Default

Quote:
Originally Posted by DaveS View Post
The directx_feb2010_redist.exe is asking where to put it.

I have x86_microsoft-windows-directx_31bf*.manifest in C:/Windows/WinSxS/Manifests.
AssemblyLanguage is offline  
Old 08-01-2016, 05:10 PM   #36
DaveS
Addon Developer
 
DaveS's Avatar


Default

Quote:
Originally Posted by AssemblyLanguage View Post
 The directx_feb2010_redist.exe is asking where to put it.

I have x86_microsoft-windows-directx_31bf*.manifest in C:/Windows/WinSxS/Manifests.
The exe is just a regular stand-alone setup file. You can put it anywhere. When it has been downloaded, you just need to run it and it will install the runtimes.
DaveS is offline  
Thanked by:
Old 08-01-2016, 05:33 PM   #37
AssemblyLanguage
Donator
Default Solved

Quote:
Originally Posted by AssemblyLanguage View Post
 The directx_feb2010_redist.exe is asking where to put it.

I have x86_microsoft-windows-directx_31bf*.manifest in C:/Windows/WinSxS/Manifests.
Installing directx redist fixed the D3D9Client.dll code 126 problem and I have a working RC.2

Thanks to DaveS and Martins.

BTW, I ran the dependency Walker before I installed Directx redist and got a lot of errors from NTDLL.DLL. Thanks for pointing to the tool.
AssemblyLanguage is offline  
Old 08-01-2016, 05:43 PM   #38
SolarLiner
It's necessary, TARS.
 
SolarLiner's Avatar
Default

Quote:
Originally Posted by jarmonik View Post
 It is possible but as far as I can tell no tools exists for that yet. I have some base/terrain editing tool placed on my work schedule and some parts are already implemented. I should be able to continue the work on that sector pretty soon since the priority is high and the D3D9Client is in reasonable stable state. (There are just a few knows issues to fix).
I had a project originally for Orbiter 2010 that would take a high res satellite or aerial image, indicate the bound coordinates and output the correct tiles in DDS format ready to be put into Orbiter. I had stopped getting a Orbiter 2010 version to work and started shifting towards getting a Orbiter 2016 version to work - however I couldn't get an algorithm to work properly.

I was thinking of making two projects: a cross-OS command line program that would take a config file as input to process the imagery (having a linux build could be beneficial for those having servers idling and want to offload some work to them); and a GUI program that would create that configuration file.
SolarLiner is offline  
Old 08-02-2016, 02:20 AM   #39
martins
Orbiter Founder
Default

Quote:
Originally Posted by DaveS View Post
 I'm a little stuck on these two steps as I have no idea on how to convert surface tiles to planet tiles. It would be nice if a graphically comprehensive guide could be made. A good example could be this one: VandenbergAFB - 2006
I have now drafted a document describing the new texture format, including a section on converting base tiles. It probably needs a bit more work, but let me know if this is useful, or if anything is unclear or missing.

One problem I realised is that the tileedit utility doesn't (yet) work on the compressed tile archives, only on the expanded tile cache directory tree. So it's not very useful if you only have the archive files.
I might need to do something about this; either allow tileedit to read the archive files, or provide texpack with the ability to extract the cache from an archive.
Attached Thumbnails
PlanetTextures.pdf  
martins is offline  
Old 08-02-2016, 05:51 PM   #40
DaveS
Addon Developer
 
DaveS's Avatar


Default

Quote:
Originally Posted by martins View Post
 I have now drafted a document describing the new texture format, including a section on converting base tiles. It probably needs a bit more work, but let me know if this is useful, or if anything is unclear or missing.
That is beyond me. I guess I'll to have to wait for a utility.
DaveS is offline  
Old 08-02-2016, 08:52 PM   #41
SolarLiner
It's necessary, TARS.
 
SolarLiner's Avatar
Default

I can understand it more or less, so I guess it's very dumbed down

One thing I didn't understand though, with plsplit64. It is restricted to splitting an entire planet at once or can it split local imagery as well?

Also a more theoretical question about the first 3 levels: are they all covering entire planets regardless of their radius? Why 3 levels at different texture sizes?
SolarLiner is offline  
Old 08-02-2016, 09:06 PM   #42
martins
Orbiter Founder
Default

Quote:
Originally Posted by SolarLiner View Post
 One thing I didn't understand though, with plsplit64. It is restricted to splitting an entire planet at once or can it split local imagery as well?
No, you can split smaller areas as well. During operation, plsplit64 asks for the latitude and longitude bounds of the bitmap you provide. Even so, the source bitmap has to be at the correct resolution for the desired level. plsplit64 only splits the bitmap, but doesn't do any interpolation. For example, for generating level-4 tiles, the source bitmap must be at resolution 360/1024 degrees per pixel.

Quote:
Also a more theoretical question about the first 3 levels: are they all covering entire planets regardless of their radius? Why 3 levels at different texture sizes?
A matter of resource management. At very small apparent radius in the render window, it is unnecessary to cover the planet with a 512 x 512 bitmap and a high-resolution mesh. It's essentially just a continuation of the quad-tree LOD theme.
martins is offline  
Thanked by:
Old 08-04-2016, 10:33 AM   #43
Enjo
Mostly harmless
 
Enjo's Avatar


Thumbs up Wine compatible

RC 2 works flawlessly on my Debian Stable with DX9 for RC2. DX7 client exposes some MFD drawing problems, but I think it should be every Linux guy's standard attitude to complain only when every other solution has failed.
The only thing that bothers me is that my own addons don't work (sic!) due to unsatisfied dependencies, but I can resolve this later.
Enjo is offline  
Old 08-04-2016, 10:48 AM   #44
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by martins View Post
 I have now drafted a document describing the new texture format, including a section on converting base tiles. It probably needs a bit more work, but let me know if this is useful, or if anything is unclear or missing.
I miss the details of the archive format. How is the TOC composed, what compression format is used, etc.

EDIT: From a quick glance that seems to be ZLIB default compression, because the magic header 78 9C is present. Is that correct?

EDITEDIT:

Looks like it works like this:
Byte-OffsetBit-LengthTypeDescription
016String"TX"
216ushortVersion? 0x1const
432uintNode list start address 48const
832uintAnother Version? 0x1const
1232uintArchive start address
1664ulongArchive length
2432uintNode count
2832uintNode index for level 1 (or 0xFFFF if gap)
3232uintNode index for level 2 (or 0xFFFF if gap)
3632uintNode index for level 3 (or 0xFFFF if gap)
4032uintNode index for level 4 first root (or 0xFFFF if gap)
4432uintNode index for level 4 second root (or 0xFFFF if gap)
4832*8blockStart of node list (k=index*32+48)
k+064ulongStart of node archive (address=archive_start+value)
k+832uintUncompressed length
k+1232uintNext node index quad tree quadrant 1
k+1632uintNext node index quad tree quadrant 2
k+2032uintNext node index quad tree quadrant 3
k+2432uintNext node index quad tree quadrant 4
k+2832uintreserved space filled with garbage?

P.S.: It seems like due to the nature of the quadtree, dummy nodes are produced if there is a gap between the various layers (e.g. base tiles). These nodes point to the same archive entry as the higher resolution tile that caused them, but with zero uncompressed length.

Last edited by Face; 08-04-2016 at 01:50 PM.
Face is offline  
Old 08-04-2016, 09:08 PM   #45
martins
Orbiter Founder
Default

Quote:
Originally Posted by Face View Post
 I miss the details of the archive format. How is the TOC composed, what compression format is used, etc.

EDIT: From a quick glance that seems to be ZLIB default compression, because the magic header 78 9C is present. Is that correct?

EDITEDIT:

Looks like it works like this:
Byte-OffsetBit-LengthTypeDescription
016String"TX"
216ushortVersion? 0x1const
432uintNode list start address 48const
832uintAnother Version? 0x1const
1232uintArchive start address
1664ulongArchive length
2432uintNode count
2832uintNode index for level 1 (or 0xFFFF if gap)
3232uintNode index for level 2 (or 0xFFFF if gap)
3632uintNode index for level 3 (or 0xFFFF if gap)
4032uintNode index for level 4 first root (or 0xFFFF if gap)
4432uintNode index for level 4 second root (or 0xFFFF if gap)
4832*8blockStart of node list (k=index*32+48)
k+064ulongStart of node archive (address=archive_start+value)
k+832uintUncompressed length
k+1232uintNext node index quad tree quadrant 1
k+1632uintNext node index quad tree quadrant 2
k+2032uintNext node index quad tree quadrant 3
k+2432uintNext node index quad tree quadrant 4
k+2832uintreserved space filled with garbage?

P.S.: It seems like due to the nature of the quadtree, dummy nodes are produced if there is a gap between the various layers (e.g. base tiles). These nodes point to the same archive entry as the higher resolution tile that caused them, but with zero uncompressed length.
Nice reverse engineering I think you are pretty much correct on all points (except byte offs 8, which is a 4-byte bit flag mostly reserved for future use. At the moment, only bit 0 is used which signifies that the contents are compressed). In any case, I'll put more details on the archive format into the next revision of the paper.
martins is offline  
Thanked by:
Closed Thread

  Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Beta


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 07:44 PM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.