[Project] D3D11Client Development

[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]

Quote:

Originally Posted by 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?

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]

Quote:

Originally Posted by 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?

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?

Quote:

Originally Posted by Face

 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]

Quote:

Originally Posted by asmi

 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 ).

Quote:

Originally Posted by asmi

 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]

Quote:

Originally Posted by Face

 <skipped>

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

Quote:

Originally Posted by Face

 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]

Quote:

Originally Posted by dumbo2007

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

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

Quote:

Originally Posted by dumbo2007

 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]

Quote:

Originally Posted by 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.

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]

Quote:

Originally Posted by asmi

 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.

Quote:

Originally Posted by asmi

 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]

Quote:

Originally Posted by Face

 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]

Quote:

Originally Posted by asmi

 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]

Quote:

Originally Posted by Face

 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?