Project D3D11Client Development

[Felipi1205]

:compbash:

 

[Face]

Oh, and Face - please merge in back to your branch.

I'll do so, but I want to stay with the 2010P1 version, so it might take a while until I push the merge...

 

[asmi]

Good news - I've finally got to the bottom of this issue with displaying/not displaying Sun - invalid RS state was set up for star rendering. It's now fixed and committed to my SC. I've also updated binary.

---------- Post added at 12:19 ---------- Previous post was at 12:14 ----------

I'll do so, but I want to stay with the 2010P1 version, so it might take a while until I push the merge...

Ok, whatever you prefer. Since there are just a few changes, if you want you can take my code and adapt it in so it would work and compile with 2010 P1 - it should be fairly simple. For convenience you can create a conditional compilation so it will be possible to build it against both beta and release versions.

 

[Veterok]

I put together a level_7 normal map for the moon a while back. (image source: LOLA Science Team)

I thought it might be of some use to Glider if he's working on planetary normal map support.

Assuming D3D11 will use the .tex format for planet normals.

 

[Glider]

I put together a level_7 normal map for the moon a while back. (image source: LOLA Science Team)

I thought it might be of some use to Glider if he's working on planetary normal map support.

Assuming D3D11 will use the .tex format for planet normals.

Thanks. I was about to start writing a converter for Celestia normal maps in order to test normal map support that I've already implemented.

BTW, I've already created new terrain code (for vegetation too, but that thing isn't debugged so far and will require a lot of work on textures and meshes) with support of normal, height and LCC maps. Currently it is able to work with up to L18 tile mesh resolution and performance similar to old tilemanager (it can render L19 and L20 as well, but float precision is too low for them to be rendered properly.) Though, L18 seems to be enough for detailed terrain.

D3D11 will use _norm.bin for L9-LMAX texture offset data, _norm.tex for L1-L8, and _tile_norm.tex for L9-LMAX.

 

[Veterok]

Thanks. I was about to start writing a converter for Celestia normal maps in order to test normal map support that I've already implemented.

Hey, that's a programming task I might actually be able to handle. I'll give it a shot.( I speak c++ at a 4th grade level)

Currently it is able to work with up to L18 tile mesh resolution and performance similar to old tilemanager (it can render L19 and L20 as well, but float precision is too low for them to be rendered properly.) Though, L18 seems to be enough for detailed terrain.

Oh, I'll make a global lvl 18 texture, lets see the raw .bmp file will be... 131 Terabytes. Maybe in a couple decades

 

[asmi]

Thanks. I was about to start writing a converter for Celestia normal maps in order to test normal map support that I've already implemented.

BTW, I've already created new terrain code (for vegetation too, but that thing isn't debugged so far and will require a lot of work on textures and meshes) with support of normal, height and LCC maps. Currently it is able to work with up to L18 tile mesh resolution and performance similar to old tilemanager (it can render L19 and L20 as well, but float precision is too low for them to be rendered properly.) Though, L18 seems to be enough for detailed terrain.

Wow that's great news! I can't wait to see it in action!

D3D11 will use _norm.bin for L9-LMAX texture offset data, _norm.tex for L1-L8, and _tile_norm.tex for L9-LMAX.

Hmm, if I remember correctly, you said that you won't be using normals for L9+, but instead you will be using heightmaps + GS to generate terrain. In that case you won't need normal maps because you will caclulate normals inside GS...

BTW, send me please your email in PM - I will send you invitation to bitbucket.org and will give write access to my repository so we can collaborate more efficiently.

---------- Post added at 16:47 ---------- Previous post was at 16:46 ----------

Hey, that's a programming task I might actually be able to handle. I'll give it a shot.( I speak c++ at a 4th grade level)

I used to be a good C++ developer, until I moved to .NET C# around 10 years ago But I still remember how to write and use templates - that's a good sign!

 

[Glider]

Hmm, if I remember correctly, you said that you won't be using normals for L9+, but instead you will be using heightmaps + GS to generate terrain. In that case you won't need normal maps because you will caclulate normals inside GS...

I think I should add normal map support for all L that was found in files (so, users that don't want to enable terrain by some reason will still be able to use L10 or L12 normal maps), and use altitude (or other parameter. I still need to test it.) to switch between normal and heightmap (gradually) if user enabled terrain. So, while at 500 km orbit (it means that L8, L9 and L10 tiles will be used) you will see only normal mapped L9-L10 Earth textures on flat tiles, and when you are at 80km you will see real terrain. Also, I think that I will use VS to generate heightmapped tiles for FL10, and tesselate meshes in FL11 only, because FL11 hardware tesselation is much better than anything that can be done in GS.

 

[asmi]

I think I should add normal map support for all L that was found in files (so, users that don't want to enable terrain by some reason will still be able to use L10 or L12 normal maps), and use altitude (or other parameter. I still need to test it.) to switch between normal and heightmap (gradually) if user enabled terrain. So, while at 500 km orbit (it means that L8, L9 and L10 tiles will be used) you will see only normal mapped L9-L10 Earth textures on flat tiles, and when you are at 80km you will see real terrain.

Well that might actually be a problem. Imagine you're descending somewhere around Everest mountain. As we all know, it's almost 9 km high, so when this transition occur I doubt you won't notice surface jumping to 9 km, unless it's REALLY far away. It's even worse in case of Mars - as there are [ame="http://en.wikipedia.org/wiki/Olympus_Mons"]mountains[/ame] as high as 21 km. So this consideration effectively demands heightmaps usage for L8 and higher levels, so no normals will be needed - even if you won't be using GS for tesselation, you can use it to dynamically caclulate normals since all primitive's vertices are available in GS.

Also, I think that I will use VS to generate heightmapped tiles for FL10, and tesselate meshes in FL11 only, because FL11 hardware tesselation is much better than anything that can be done in GS.

Indeed it is - that's why originally I was going to create FL11-only engine - since there are just too many things in FL11 that are well worth using But since are trying to create FL10-compatible engine, I thing we still shall use GS for some tesselation - even in gs_4_0 you should be able to subdivide single triange into ~20-30 new ones, which would provide much better quality. And if you'll add GS instancing (multiple invocation of GS shader for the same input primitive) on top of that, you should be able to come adequatly close to HW tesselation, unless latter is used with 64x64x64x64 factors

 

[NOMAD]

I just do as asmi said,but when I open orbiter.exe or orbiter_ng.exe,it crash to desktop.
My computer specs:win7sp1 and video card is nVidia 9800GT.
How can I do?

 

[dumbo2007]

If you are planning to add terrains would it be possible to make the height value available at each point on the surface so I can try to use it to collide vessels ?

 

[asmi]

I just do as asmi said,but when I open orbiter.exe or orbiter_ng.exe,it crash to desktop.
My computer specs:win7sp1 and video card is nVidia 9800GT.
How can I do?

According to NVIDIA website your video card is DirectX 10-compliant, so it does meet minimun requirements to run the client.
You've said that built-in client (orbiter.exe) also crashes, which makes me think that there is a problem with installation itself, not with a client. Before you'll go into running a client, you need to ensure that built-in client works. I assume you did update in to 111105 beta build. If so - check your orbiter.log file to see if there are any warnings, errors and stuff like that. Also - if you have any third-patry modules turned on - try turning them all off and see if you can run the client.

If you are planning to add terrains would it be possible to make the height value available at each point on the surface so I can try to use it to collide vessels ?

As far as I understand Glider is going to implement collisions with ground as part of this whole terrain thing. Otherwise it would look a bit stupid...

 

[Glider]

If you are planning to add terrains would it be possible to make the height value available at each point on the surface so I can try to use it to collide vessels ?

Of course. All tiles have system memory copy of their heightmap, so it is possible to quickly find height and surface normal for any latitude and longtitude. Planets without heightmaps will have generated heightmaps for all L8 tiles + L9 and higher heightmaps will be created dynamically in the same way default Orbiter client loads tiles from _tile.tex files. (level that should be generated for whole planet and maximum dynamically generated level will be included in cofig files, so it will be possible to generate heightmaps for all L9 or L10 tiles too and not only L8)

 

[dumbo2007]

Awesome. I have been stuck with using Orulex for testing terrain collisions and low fps(9-10 fps) with the default gfx. So it will be great to upgrade to a new terrain system. By the way I have been thinking about decoding the LOLA data present in the MIT servers (http://imbrium.mit.edu/DATA/LOLA_GDR/POLAR/IMG/) and use that for terrain generation. Probably the same way Artlav does it by doing the LOD calculations and other compute intensive stuff in a separate thread and stream it to the Orbiter rendering thread. It would give probably the most accurate picture possible :

http://www.hrpictures.com/fulldome/LOLA/

But for the initial stages its best to keep it simple.

 

[asmi]

Here is another update - I don't know about you guys, but I got sick trying to guess where the hell the runway is during night landings, so I've implemented runway lights. Here is what it looks like now (click to enlarge):

This is the same part of runway, just looked at from different directions - according to this some lights are supposed to have different colors when seen from different directions. For example in the beginning of rwy all lights have to be white if one looks "towards" center of rwy, and yellow-read when one looks away from the center of rwy. As most of you know, information about rwy lights config is in base config files, but Orbiter doesn't provide API to access it, so I has forced to develop my own config file parser to load this info, and so I did
VASI and PAPI are not implemented yet, but I'm working on it and will get it done soon.

Enjoy!

 

[Cras]

Runway lights in a graphics client? asmi, you da man.

 

[asmi]

Runway lights in a graphics client? asmi, you da man.

As I said - when I need something - I just go and take it, not wait until it will be given to me It took me about a day to implement and debug config file parser, but this is a worthwhile investment, as there are some objects (like runway lights, beaconlights, solar arrays) that have to be read directly from bases' configs in order to be displayed...
Besides, this is my end target when it comes to rwy lighting:

So I've still got work to do :tiphat:

 

[DaveS]

As I said - when I need something - I just go and take it, not wait until it will be given to me It took me about a day to implement and debug config file parser, but this is a worthwhile investment, as there are some objects (like runway lights, beaconlights, solar arrays) that have to be read directly from bases' configs in order to be displayed...
Besides, this is my end target when it comes to rwy lighting:

So I've still got work to do :tiphat:

Thanks for taking up the challenge of implementing runway lights in a graphics client! BTW, will sunrise/sunset effects like this one be implemented:

 

[Veterok]

I started a new thread for putting together a package of planetary textures, normal maps, height maps, vegetation models, etc... for use in the D3D11 client.

http://orbiter-forum.com/showthread.php?t=26097

 

[asmi]

Thanks for taking up the challenge of implementing runway lights in a graphics client!

Well someone has to be first to do that I sincerely don't understand how you all guys (I mean those who use graphic clients) are landing without lighting... Or do you time your reentries so it will be day landing?
I had to do a couple of hacks (for example I cut off light display 50 km away from camera, and light size increases with distance to defeat "z-fighting" issue) - but those are just little technicalities...

BTW, will sunrise/sunset effects like this one be implemented:

I was thinking about implmenting it when I was working on post-processing effect, but I couldn't find any whitepaper more or less completely covering physical principals of lens glare's appearance so I could code it appropriately - remember this is a simulator, so effects have to be real too Currently all PP effects work only for FL11 (so only DirectX 11-compatible hardware, effects are automatically turned off if hardware is not DirectX 11-compatible), so I will get back to them after I'll be done with lighting, so yes - eventually this will be done one way or another.

---------- Post added at 20:38 ---------- Previous post was at 20:31 ----------

I started a new thread for putting together a package of planetary textures, normal maps, height maps, vegetation models, etc... for use in the D3D11 client.

http://orbiter-forum.com/showthread.php?t=26097

This is Glider's show