New Release D3D9Client Development

[jarmonik]

I just noticed a "bump" in the framerate in SSU exclusively in D3D9 and tracked it down to this:

Calling oapiEditMeshGroup convert's the mesh from static to dynamic allowing a faster read-modify-write operations with the vertices but it's likely slower to render. It's possible that 2010-P1 version doesn't do the switch to dynamic.

How much the frame rate is effected ? Does it get better or worse ?

 

[GLS]

Calling oapiEditMeshGroup convert's the mesh from static to dynamic allowing a faster read-modify-write operations with the vertices but it's likely slower to render. It's possible that 2010-P1 version doesn't do the switch to dynamic.

The mesh is animated... doesn't that already make it dynamic? I just want to hide the water bag meshes on the pad at T0.

How much the frame rate is effected ? Does it get better or worse ?

What am I supposed to do? Run a oapiEditMeshGroup at the begining of the sim to set a 0 flag just to change the mesh to dynamic, thus avoiding the change at T0?

 

[jarmonik]

The mesh is animated... doesn't that already make it dynamic? I just want to hide the water bag meshes on the pad at T0.

No, animation is done via matrices, vertex data in a vertex buffers remains unchanged. This looks like an obvious bug since a visibility flag change wouldn't need to ticker a conversion to a dynamic, since the vertex buffer isn't accessed. I'll fix that.

---------- Post added at 10:27 ---------- Previous post was at 09:20 ----------

New atmospheric configuration files for Earth and Mars has been committed to SVN. Are they OK ?

EDIT: The Earth in D3D9 is still brighter than the "true" Earth, especially the oceans. But I guess that would require a shader code change. It's not a high priority thing so it needs to wait.

 

[jarmonik]

Here's the latest atmospheric configurations for Earth and Mars. Unzip in Config/GC/

 

[jarmonik]

ATTENTION:

We would need to solve the problem of the official client distribution. How do we do it ?

Here are some points:

- Not behind one person. Meaning that any developer could create a new official distribution package if needed.
- Can host multiple versions. Because some may prefer an older one.
- It would be also good if an optional proprietary art-works could be hosted on a same site. If not then a link to an off-site location should do the trick.

I suppose we could upload the latest stable code to CodePlex and use it for distribution. (If it works)

How does the OrbitHangar handle multiple revisions ? and what about access by multiple developers ?

 

[Abloheet]

or why not use svn for d3d9client too?

 

[SolarLiner]

We would need to solve the problem of the official client distribution. How do we do it ?

Having past experience with GitHub I'd say it would be the best place to handle releases and issue tracking, and has a web api to get the latest release, a certain tag, or a specific release. The actual code in the repository could be a landing page that serves those different versions, as well as documentation, links, etc.

When the question of delivery was first asked I started making a nonfunctional (for now) but "proof of concept" webpage for the D3D9 addon delivery: https://solarliner.github.io/D3D9Website/ (github repo here)

Of course, anything and everything can be changed, from the color palette to the background images.

 

[Face]

We would need to solve the problem of the official client distribution. How do we do it ?

Here are some points:

- Not behind one person. Meaning that any developer could create a new official distribution package if needed.
- Can host multiple versions. Because some may prefer an older one.
- It would be also good if an optional proprietary art-works could be hosted on a same site. If not then a link to an off-site location should do the trick.

I suppose we could upload the latest stable code to CodePlex and use it for distribution. (If it works)

How does the OrbitHangar handle multiple revisions ? and what about access by multiple developers ?

I would suggest using social coding platforms like Github or Bitbucket. For open-source software, the hosting is free, you can put a Wiki there, get a bug-tracker and upload as many distribution versions as you want. The mentioned two allow multiple maintainers AFAIK, by means of giving accounts permissions to upload/admin certain aspects of given projects.
Many of those sides forbid license violating material, but given that D3D9Client is using LGPL, this should not be a problem.

Why not CodePlex, then? Well, I see it as mostly dead by now. Microsoft itself moved to Github, so this might be the best option.

Why not OHM? As of now, there is almost no support for multiple versions of an addon, and it is cumbersome to keep it up-to-date. I also don't think that there will be much change in the future, despite the staff's obvious efforts to keep it running. OHM's main audience is well served with the current format, but it is not suitable for open-source development IMHO. To leverage the coverage of OHM, you can always upload a dummy entry that simply points people to the real site to download distributions.

Only drawback of my suggestion: you'd have to practically give up on SVN.

just my :2cents:

 

[SolarLiner]

Only drawback of my suggestion: you'd have to practically give up on SVN.:

Why, exactly, is this a drawback? :lol:

Microsoft went and transfered their code to GitHub. VS Code, their open source text editor/ lightweight IDE is on GitHub. This does seem to me as the best option too. The website would need to be placed on a branched called "gh-pages", and the code can be transfered as is. There's even AFAIK a nifty little tool to convert a SVN repo to Git(Hub), keeping branches and tags.

We also could set up a GitHub group that would be the technical ownership of the repo, and add the contributors to that group, making them in turn have write access. Lastly, I think the best feature of Git(Hub) is the ability to do pull requests, which means everyone can fork the project, add their changes, and do a pull request to merge the changes back into the repo. No need for permanent write access or ownership. People contribute as a one time thing without entering 100% into the project (paging Google Play Music Desktop Player as an example of a relatively large project that uses a lot of this feature to ensure one-time contributions).

The GPMDP project also uses continuous integration through AppVeyor for Windows, which allows for nightly builds, adds webhooks to build on code push, can manage releases, etc.

And one last thing: GitHub has an integrated extension in VS2015 that integrate GitHub projects into Visual Studio.

 

[jarmonik]

We just got a while back fast and well working SVN on orbiter-radio and we are making progress. And now we should abandon that and move to Git because it's a modern trend ?

I am unfamiliar with Git and I wouldn't want another headache from that. I don't know Git and how much better it could be but I wouldn't expect too much.

The Orbiter-Forum is the heart of operations here and the bug tracker would serve us better right here. The Orbiter already has one, so, I guess that D3D9 could have it's own too.

I have a web page from my ISP but it's for private use. I can't give additional access rights there. So, I guess, just having a webpage for the project would be sufficient enough. My knowledge doesn't go beyond HTML there.

 

[Face]

Why, exactly, is this a drawback? :lol:

Well, you and me know that there is only a win in using DVCS instead of centralized version control like SVN.
But we have to accept that especially git is very complicated to use for people used to things like SVN. It is a different way to think about version control.

That's why I wrote about it being a drawback: Jarmonik might be comfortable with SVN, and the DVCS mind-set might not ring with him (yet). Switching the versioning system just to use a different platform can very well be seen as a drawback there, especially if you are the pragmatic type who sees tools as... well... tools.

Ups. :ninja:'ed by Jarmo

 

[SolarLiner]

Switching the versioning system just to use a different platform can very well be seen as a drawback there, especially if you are the pragmatic type who sees tools as... well... tools.

I know, that's why I meant it as a joke. I'm personally more or less comfortable with both of them, since I learned both at roughly the same time. But I can see why someone used to SVN could have a hard time switching to Git, even when the grass is way greener on the other side

I have a web page from my ISP but it's for private use. I can't give additional access rights there. So, I guess, just having a webpage for the project would be sufficient enough. My knowledge doesn't go beyond HTML there.

I could handle the webpage here, since I have a working prototype (I need feedback on it still, by the way!). No server hosting required as it doesn't need any server-side code, only JavaScript to retrieve release information, if we were to use GitHub for release management. Even with not actual code, it would just need to have a GitHub account and repo ownership to push a new release. Choosing this solution would mean and always-updated website without need to change the code everytime.

 

[SolarLiner]

On un unrelated post, I'm proposing my own changes on top of Jarmo's for thee Earth atmosphere.
Test by unzipping to /Config/GC.

 

[jarmonik]

I need feedback on it still, by the way!

It looks good and it's fine by me, although I cannot comment the code. I would probably remove the third "atmospheric" background image since it serves no purpose there.

 

[jarmonik]

D3D9Client-RC1 for Orbiter 2016

Here's the latest "stable" revision of the client with the newest atmospheric configurations and micro textures for the Moon and Mars.

If "Antialiased" is selected from the Sketchpad settings then that should fix at-least some font rendering issues.

Microtextures are here (Download)

Is everything OK there ?

 

[DaveS]

Documentation related issue: It seems that the D3D9Client document isn't updated to explain how the new PBR affects the advanced texture maps. Also a couple of the new advanced texture maps are missing:

• Rougness map
• Fresnel

 

[Weirdo Earthtorch]

Resolution Bias?

This effect on Earth terrain, in the latest RC4 Orbiter, D3D9 RC1. Low to high Resolution Bias mimics the effect of going from cubic to linear interpolation in the inline client. Occurs with archive and cache formats, both base and full tile sets.

Does not occur in Orbiter 160412 - D3D9 23.11 Jun 17 2016, which is the only other test version I have. (I think this version is pre-archive tile format?)

Does not appear to happen on Moon/Mars.

Apologies for the brief post, I've been trying unsuccessfully to pinpoint what causes the change and when.

Set video-advanced-mesh resolution to 64
Launch scenario
Open D3D9 debug window (CTRL+F4) >>> set resolution bias higher incrementally

EDIT: disregard all the above, user error. :facepalm:

Scenario:

BEGIN_DESC
Current scenario state


Contains the latest simulation state.
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 51982.4940796594
  Help CurrentState_img
END_ENVIRONMENT

BEGIN_FOCUS
  Ship DG-01
END_FOCUS

BEGIN_CAMERA
  TARGET DG-01
  MODE Extern
  POS 206.277893 -96.869133 -30.080284
  TRACKMODE TargetRelative
  FOV 50.00
END_CAMERA

BEGIN_HUD
  TYPE Orbit
  REF AUTO
END_HUD

BEGIN_MFD Left
  TYPE Docking
  NAV 0
END_MFD

BEGIN_MFD Right
  TYPE Orbit
  PROJ Ship
  FRAME Ecliptic
  REF Earth
  TARGET ISS
END_MFD

BEGIN_VC
END_VC

BEGIN_SHIPS
ISS:ProjectAlpha_ISS
  STATUS Orbiting Earth
  RPOS 5243839.293 -4221042.683 175247.384
  RVEL -4611.1607 -5637.8022 2484.6605
  AROT -110.000 -15.000 -84.000
  AFCMODE 7
  IDS 0:1 100 1:2 100 2:3 100 3:4 100 4:5 100
  NAVFREQ 0 0
  XPDR 466
END
DG-01:DeltaGlider
  STATUS Landed Earth
  POS -4.0763000 53.0684000
  HEADING 134.97
  ALT 1.134
  AROT -31.046 -39.199 46.226
  AFCMODE 7
  PRPLEVEL 0:0.998000 1:0.978000
  NAVFREQ 2 466 0 0
  XPDR 0
  HOVERHOLD 0 1 0.0000e+000 0.0000e+000
  GEAR 1.0000 0.0000
  AAP 0:0 0:0 0:0
END
END_SHIPS

BEGIN_ExtMFD
END

 

[jarmonik]

This effect on Earth terrain, in the latest RC4 Orbiter, D3D9 RC1. Low to high Resolution Bias mimics the effect of going from cubic to linear interpolation in the inline client. Occurs with archive and cache formats, both base and full tile sets.

I see that with linear interpolation but I am unable to reproduce the effect with cubic interpolation regardless of what ever is the resolution bias.

The small circular/gradient looking artifacts is a known problem. We might be able to reduce them by making the sun light less (light/normal) angle dependent but I don't know what other side effects it might have.

 

[Weirdo Earthtorch]

OK you can disregard the above. I'm not able to confirm right now, but I don't think I checked the linear/cubic setting when running d3d9 client, sorry. :facepalm:

 

[kuddel]

We just got a while back fast and well working SVN on orbiter-radio and we are making progress. And now we should abandon that and move to Git because it's a modern trend ?

I agree. git is a real pain in the *** for beginners. I have to use it once in a while and it's always waaaay to complicated.

I am unfamiliar with Git and I wouldn't want another headache from that. I don't know Git and how much better it could be but I wouldn't expect too much.

Git would make it easier for others to fork (github term, not git terminology, though). Which in my opinion only creates even more different forks that no one can handle...
For providing patches the Orbiter-Forum is good enough and those patches -once commited- are immediately a benefit to everyone.
I've seen many git-based projects where several forks did have a patch, but the procedure of "pull-request", "push", "pull", "accept PR" etc. prevented that patch from being incorporated into the main branch (master)...

For someone who wants to contribute even more than a patch, inviting him/her to get write-access to the svn repository is the way to go. In need of major changes that should not interfere the main development (trunk), a feature-branch is easily created.

The Orbiter-Forum is the heart of operations here and the bug tracker would serve us better right here. The Orbiter already has one, so, I guess that D3D9 could have it's own too.

100% agree. This forum is the place where people look for errors/fixes, so it should be the place to report them.

I have a web page from my ISP but it's for private use. I can't give additional access rights there. So, I guess, just having a webpage for the project would be sufficient enough. My knowledge doesn't go beyond HTML there.

The only thing needed is some procedure "how to upload a release".

I like the page SolarLiner presented some posts before.

The build-process is very easy once the preparations are done (Compiler and DirectX SDK Libraries set-up).
It creates two packages (ZIPs), one including the source code (~5.6MB) and project files, one without (~1.6MB).

So a kind of "upload page" to upload the two files and a short description of the changes would be enough.
Some "magic" automatic system (like Jenkins) could be established to even more automate this. Although this would require a more strict procedure on "tagging"/"branching".
I have running a Jenkins CI Server locally, so every time someone commits some changes a full build & cppcheck run is done.

:2cents:
Kuddel