Project D3D11Client Development

[dumbo2007]

By the way, does anyone else get the colors error I was referring to earlier : http://orbiter-forum.com/showthread.php?p=351013&postcount=362

I havent tried with the latest code yet, so it may be gone.

 

[Screamer7]

i noticed a small issue with the D3D clients.
In the D3D11 client in external view when moving the object with the mouse, it sometimes moves in a erratic way.
It is much more noticeable with the D3D9 client as with the D3D11 client, but it is still there, albeit a very small amount.
In the plain Orbiter 2010 P1, it is not there, and the objects rotate very smoothly.

 

[movieman]

But come to think of it, I cannot recall any games that are 64-bit anyway. The 64-bit programs I use are applications like Photoshop, or After Effects.

APB is, because it needs more than 2GB of RAM. I think Age of Conan has a 64-bit client. Those are the only two I can think of out of the games I own.

Otherwise, pretty much every program I use is 64-bit. There's no reason to stick to 32-bit x86 code unless you're running on a crappy old CPU which doesn't support 64-bit.

 

[Face]

Just to let you all know, I've back-ported Asmi's master branch (the standard one, not the terrain branch) to O2010P1 here.

 

[asmi]

Just to let you all know, I've back-ported Asmi's master branch (the standard one, not the terrain branch) to O2010P1 here.

You're right on time I'm just about to start closed alpha testing for a new iteration of a client, and once it more or less stable - public beta testing.

Just as an update, here is what will be included in new version (these features are already implemented):
- Terrain
- New atmopshere render
- Fullscreen support
- New HDR engine powered by Pixel Shaders
- Choice of HDR engine (none, Compute Shaders, Pixel Shaders) in config window
- Numerous fixes and improvements
These are things that I'm working on/will be working on that are planned to also be included in new version:
- Reworked shadows, including vessel and terrain self-shadowing
- Per-pixel local lights
- reworked exhaust smoke trails

That's it for now, of course plans can (and likely will) change, so the list of "will be" things can change in both ways, but at least what's done is done

 

[DaveS]

asmi: Could you provide an example of the reworked exhaust smoke trails? Currently Orbiter uses textures for this. What is your approach going to be?

 

[asmi]

asmi: Could you provide an example of the reworked exhaust smoke trails? Currently Orbiter uses textures for this. What is your approach going to be?

Honestly I didn't think about it yet. I just don't like the way it currently looks. I'll give you more details when I'll actually start working on this issue.

 

[Face]

I've just pulled your tagged version, asmi. Did you intend to continue my numbering scheme or was it just coincidence?

In any case, I didn't really think much about it. Would it make sense to discuss the numbering scheme a bit?

On a side note: I tested Ascension Ultra with the D3D11Client main branch, and noticed a problem with the configuration file reader. If there are comment lines inside a block, the system hangs on startup. I'm already working on it and can link you a changeset this evening...

regards,
Face

 

[asmi]

I've just pulled your tagged version, asmi. Did you intend to continue my numbering scheme or was it just coincidence?

In any case, I didn't really think much about it. Would it make sense to discuss the numbering scheme a bit?

Well, the way I'm planning to assign versions is as following:
0.minor.buildtype.buildnumber
minor - I increment minor version every time there are major changes.
buildtype - it's "a" for alpha builds, "b" for beta builds, "rc" for release candidate builds, "r" for release builds
buildnumber - it's just a sequential number since label has been applied
Once we're happy with the client (which I think is never gonna happen ) we'll assign a major version 1, and will move on.
Buildnumber is set during the build, all the rest is a tag in source control.
So current alpha builds have versions 0.4.a.XX, once we'll start public beta testing, it will be 0.4.b.XX, once client is more or less stable and most of major bugs are fixed we'll move on to 0.4.rc.XX, and eventually to 0.4.r.XX (if by that time the won't be another batch of major changes, otherwise the cycle will start all over with 0.5 version family).

UPDATE:
On a second thought, maybe we should just ditch a major version alltogether and use version like 4.a.XX... Hmmm... What do you think of that?

On a side note: I tested Ascension Ultra with the D3D11Client main branch, and noticed a problem with the configuration file reader. If there are comment lines inside a block, the system hangs on startup. I'm already working on it and can link you a changeset this evening...

regards,
Face

OK, great. I appreciate any contributions, since there are so many things to be done, and too few resources to do all that...

 

[Face]

Well, the way I'm planning to assign versions is as following:
0.minor.buildtype.buildnumber
minor - I increment minor version every time there are major changes.
buildtype - it's "a" for alpha builds, "b" for beta builds, "rc" for release candidate builds, "r" for release builds
buildnumber - it's just a sequential number since label has been applied
Once we're happy with the client (which I think is never gonna happen ) we'll assign a major version 1, and will move on.
Buildnumber is set during the build, all the rest is a tag in source control.
So current alpha builds have versions 0.4.a.XX, once we'll start public beta testing, it will be 0.4.b.XX, once client is more or less stable and most of major bugs are fixed we'll move on to 0.4.rc.XX, and eventually to 0.4.r.XX (if by that time the won't be another batch of major changes, otherwise the cycle will start all over with 0.5 version family).

UPDATE:
On a second thought, maybe we should just ditch a major version alltogether and use version like 4.a.XX... Hmmm... What do you think of that?

Hm. Elaborate dot-something version numbers is something I don't sympathize with, as they apply a sophisticated metric where there really is none IMHO. The best metric is the hashcode and the DAG, but I can of course see the need for a strictly increasing numbering scheme for the quick "oh, it is newer!" glance. I just think that this scheme should be simple, as any information beyond that can be provided by the exact hash/branch the version comes from.

That is why my try was to have the usual major.minor scheme with the meaning that major increases with every milestone reached, and minor increases with every release point. It is also reflected in the labeling of the client window/splash screen like so (see code):

• "Releases" only display as "<named branch> - version <tag>, built <date>"
• Development snapshots display as "<named branch> - version <tag>+<distance of current changeset to tag> (<revision number>:<hash code>), built <date>"

That said, a simple increasing number is already sufficient for me, but it looks odd to the regular user of our current dot-number culture (you wouldn't believe what kind of discussions I had at work about this ).

OK, great. I appreciate any contributions, since there are so many things to be done, and too few resources to do all that...

Here you are.
Face

 

[asmi]

<skipped>

OK then, to circumvent this discussion now - I'll leave things as they are for now, we'll see later how it goes.

Here you are.
Face

Thank you very much!
Can you pls commit changes to my fork? If you can, please do it for both "D3D11Client" and "D3D11Client - Terrain" branches.

 

[dumbo2007]

ok here goes my attempt to derail the thread again...

so asmi, you were talking about collisions of vessels with terrain earlier. For this when a vessel touches the terrain it would still be far from the spherical surface of the planet which its on. Thus Orbiter would try to pull the vessel down towards the surface.

Then to keep the vessel on the terrain you would need to somehow override the behavior of Orbiter, specifically take control of the vessel's state.

Can this be done in the client i.e. totally ignoring the state received from Orbiter core and setting one's own position ?

 

[asmi]

ok here goes my attempt to derail the thread again...

You'd better stop doing so - moderators generally don't like that

so asmi, you were talking about collisions of vessels with terrain earlier. For this when a vessel touches the terrain it would still be far from the spherical surface of the planet which its on. Thus Orbiter would try to pull the vessel down towards the surface.

Then to keep the vessel on the terrain you would need to somehow override the behavior of Orbiter, specifically take control of the vessel's state.

Can this be done in the client i.e. totally ignoring the state received from Orbiter core and setting one's own position ?

You can't directly set vessel's coordinates, but you can affect vessel's state by applying force to the vessel to compensate for the gravitational force. BUT since Martin has said that he is going to add terrain support into Orbiter, I've decided to not implement it at all in the client. So right now you can go through terrain like nothing have happened

 

[dumbo2007]

hmm, ok. I thought that you receive the co-ordinates of the vessel in a callback function. Then draw it in a d3d11 window. So if you choose to ignore the position and draw the vessel at say (0,10,0) instead of (0,0,0), the user will see the vessel rendered higher and not at the surface.

(Just an example, I am assuming 0,0,0 to be at the surface).

Anyway since you are not implementing collision its not relevant. I was exploring the possibility of overriding orbiter's data in the client to add extra features if needed.

 

[asmi]

hmm, ok. I thought that you receive the co-ordinates of the vessel in a callback function. Then draw it in a d3d11 window. So if you choose to ignore the position and draw the vessel at say (0,10,0) instead of (0,0,0), the user will see the vessel rendered higher and not at the surface.

(Just an example, I am assuming 0,0,0 to be at the surface).

Anyway since you are not implementing collision its not relevant. I was exploring the possibility of overriding orbiter's data in the client to add extra features if needed.

There is no callback for rendering vessels (or anything else for that matter), but we do have a way to get vessel coordinates. The problem is not where to render vessel, but do force Orbiter (and all relevant MFDs) to believe that the vessel IS actually where it has to be. There are 1.000.000 reasons why it should be that way, and I'm not gonna go into details on that one, since this would be complete offtopic here....

As for the physical simulation - as I said - apply force to a vessel, and Orbiter's core will take care of the rest. It's actually much easier than to calculate coordinates yourself, and this way you don't actually need a way to set these coordinates - to do that you need nothing more than VESSEL::AddForce() and Newton laws of motion.

 

[Face]

OK then, to circumvent this discussion now - I'll leave things as they are for now, we'll see later how it goes.

Alright, nothing set in stone anyway.

Thank you very much!
Can you pls commit changes to my fork? If you can, please do it for both "D3D11Client" and "D3D11Client - Terrain" branches.

You mean push to your fork on BB? Will try, I didn't know I have push access there...

It already is on the D3D11Client branch. As for the Terrain branch, do you mean just duplicating (cherry-picking) the changesets or merging in the changes?

 

[asmi]

It already is on the D3D11Client branch. As for the Terrain branch, do you mean just duplicating (cherry-picking) the changesets or merging in the changes?

I mean just to apply these your changes to terrain branch as well - it also needs to be fixed

 

[Face]

I mean just to apply these your changes to terrain branch as well - it also needs to be fixed

I guess this means transplanting/cherry-picking/grafting over the changesets to the Terrain branch. I've done that now and pushed all to your fork at BB. Please have a look, hope this is what you had in mind.

 

[asmi]

I guess this means transplanting/cherry-picking/grafting over the changesets to the Terrain branch. I've done that now and pushed all to your fork at BB. Please have a look, hope this is what you had in mind.

Good stuff! Thanks a lot once again!

 

[ggrof]

To get all features of D3D11 (terrain, atmosphere, etc.), i have to download only the latest file (in the ltest link) or I have to get some basic files?