New Release D3D9Client Development

[DaveS]

For some reason I do not see cloud microtextures... I know this mcwgogs addon, and effect is absent. Client is installed, microtexture checkbox is checked, but Orbiter though is not r.90 but otherwise everything runs OK.

I've noticed the same, the micro-texture blending with the cloud layer texture isn't that strong and it seems to be a hit-or-miss situation on whether or not it's going to work. It's nothing like Orbiter 2006/2010.

 

[GLS]

For some reason I do not see cloud microtextures... I know this mcwgogs addon, and effect is absent. Client is installed, microtexture checkbox is checked, but Orbiter though is not r.90 but otherwise everything runs OK.

I tried to update Orbiter, but TortoiseSVN somehow fails. Is it address issue?
I see "svn://orbiter-forum.com/orbiter" but should it be like "svn://svn.orbiter-forum.com/orbiter" (with another svn in address?)

Orbiter BETA address should be:

svn://svn.orbiter-forum.com/orbiter/

 

[kuddel]

I see "svn://orbiter-forum.com/orbiter" but should it be like "svn://svn.orbiter-forum.com/orbiter" (with another svn in address?)

Assuming you use TortoiseSVN, you can easily relocate the repository URL:

1. Right-click on your working-copy (base-)folder,
2. select TortoiseSVN->Relocate...
3. and enter the new URL (svn://svn.orbiter-forum.com/orbiter)
4. and confirm with OK.

That should do it

 

[Marg]

thanks to kuddel now everything should be OK, but I noticed sometimes in a scenario I do not have shadows and selfshadows cast by vessels. But just occasionally. It was relatively "cloudy day" in that particular scenario...

 

[jarmonik]

...but I noticed sometimes in a scenario I do not have shadows and selfshadows cast by vessels. But just occasionally. It was relatively "cloudy day" in that particular scenario...

Screen shots could help to identify the problem. Also, In the configurations there are selfshadowing option like "Near by objects", "All visible objects" which might have an effect.

---------- Post added at 14:53 ---------- Previous post was at 14:52 ----------

I am currently thinking a bout a repository-relayout, but that definitely should be postponed!

What kind of layout changes ? I have no idea what you mean by that.

 

[kuddel]

What kind of layout changes ? I have no idea what you mean by that.

General structure changes, to...
- move ModHTML.exe and over.exe to a "build-tools" branch, and reference them from trunk/, and branches/ [*]
- move the sources of ModHTML.exe to the "build-tools" branch
- include the sources of over.exe to the "build-tools" branch

[*] As ModHTML.exe is identical in all branches/ and trunk/ it seemed favorable if it only needs to be committed at one place - and all branches automatically get the "newest" version on update.
The HTML templates also didn't seem to fit (spread all over the branches/ and trunk/)


...but that's not really very important, just a little "housekeeping" that I thought might be needed.

 

[Marg]

Sometimes local light sources are disabled. I enable, but after some certain scenarios, they can be disabled again...
(D3D9 22 sep on 14 sep Orbiter2016). D3D9 does not like something and it disables?

 

[kuddel]

@Marg: Is there a specific scenario that reproduces the problem most often?
From a quick code-review there is no such thing as "auto disable", but from the description it "sounds" like an uninitialized memory or (even worse) an unintentional memory write-access.
If you have a scenario that shows the effect more than others, could you please tell us that scenario?
Best would be a stock orbiter scenario, as addons can make thinks even more complicated.

 

[jarmonik]

@Marg: Is there a specific scenario that reproduces the problem most often?
From a quick code-review there is no such thing as "auto disable", but from the description it "sounds" like an uninitialized memory or (even worse) an unintentional memory write-access.
If you have a scenario that shows the effect more than others, could you please tell us that scenario?
Best would be a stock orbiter scenario, as addons can make thinks even more complicated.

I have encountered a similar issue as the one mentioned by Marg. I don't remember what it was exactly but probably a configuration changes were disregarded and reverted to default settings. I did mention about the anomaly to you (if you have seen it) but you didn't experience it. I mostly disregarded it as a temporary glitch in my computer. I don't recall seeing it anymore.


If you got time to take a closer look to the issue it's well appriciated.

EDIT: How common the problem is ? has anyone else encountered it ?

 

[kuddel]

I'll take a close look at the members in memory *before* our Scene::bLocalLight
...maybe there is some D3D9Client-internal out-of-bounds access.
I'll focus my checks on the 2016 branch, so we are all on the same page.

 

[Marg]

Strange, I cannot launch Orbiter_NG at all. I am confused, I changed nothing on my PC... yesterday it worked, but not now. Hm...
I double click, no results... of course with all "run as administrator" option ON\OFF, etc. Ordinary Orbiter.exe launch window appears, but not Orbiter_NG.

 

[kuddel]

@Marg: ...any Virus-Scanner preventing you from starting it?
As those update very regularly, the phrase "... I changed nothing on my PC..." is almost never true nowadays

---------- Post added at 23:01 ---------- Previous post was at 22:56 ----------

@jarmonik: FYI
I've looked into the Local-Lights issue, but couldn't find anything obvious...
I took the liberty to fix some warnings cppcheck was complaining about, but those changes don't change anything regarding Marg's (and your) Local-Light issue...

 

[Marg]

In D3D9client.cfg is a line "light congiguration", where is the letter g instead of the f... just to know

 

[kuddel]

Oh a typo (embarrassing), I'll take a look if that might cause a problem on write-read circle.

---------- Post added at 23:30 ---------- Previous post was at 23:27 ----------

No, it is written as "LightCongiguration" and also read as "LightCongiguration".
So apart from the typo it's O.K.
Possibly we might change (auto-port) that in the future (although it's not worth it)

 

[kuddel]

I've added a missing feature in D3D9Client (trunk) that should now enable planetary bodies that are defined as a mesh and "Size = xxx" parameter in their .cfg file.
(See attachment and the threads here and here for what I mean by that).

Until this revision (r1187) the body mesh had to be scaled (by Shipedit.exe for example) to be rendered correct (full) size with D3D9Client.
Now the mesh can be kept in usual "1.0 based" coordinates and the Scale parameter from the config is applied (as Orbiter 2016 does)!

@Jarmo: It seem that the texturing is not working 100%, though. Could you take a quick look, as it might take you only seconds while I'm a bit lost...

For the test I've added 67P/Churyumov-Gerasimenko as it is sooo non-spherical
The texture is just a dummy as the texturing is probably not right anyway.

This is not (yet) a new release, we have to sort out the texturing issue first (if it is one), before we create a new D3D9Client-forBETA and back-port it to D3D9Client-for2010 as well.

 

[GLS]

I've added a missing feature in D3D9Client (trunk) that should now enable planetary bodies that are defined as a mesh and "Size = xxx" parameter in their .cfg file.
(See attachment and the threads here and here for what I mean by that).

Until this revision (r1187) the body mesh had to be scaled (by Shipedit.exe for example) to be rendered correct (full) size with D3D9Client.
Now the mesh can be kept in usual "1.0 based" coordinates and the Scale parameter from the config is applied (as Orbiter 2016 does)!

@Jarmo: It seem that the texturing is not working 100%, though. Could you take a quick look, as it might take you only seconds while I'm a bit lost...

For the test I've added 67P/Churyumov-Gerasimenko as it is sooo non-spherical
The texture is just a dummy as the texturing is probably not right anyway.

This is not (yet) a new release, we have to sort out the texturing issue first (if it is one), before we create a new D3D9Client-forBETA and back-port it to D3D9Client-for2010 as well.

Wait a minute, that's not a real photo?! :jawdrops:

 

[Abloheet]

That solution has been a long time in the making. Much much thanks for taking out the time from your schedule to implement it. Now all the minor moons can be modeled again in Orbiter 2016 D3D9!

 

[Marg]

I noticed, that even during nighttime in orbit sun shines through transparent meshes (satellite antennas, etc.). Orbiter 2016 (not BETA), and 6.sep client.

 

[clipper]

I noticed, that even during nighttime in orbit sun shines through transparent meshes (satellite antennas, etc.). Orbiter 2016 (not BETA), and 6.sep client.

Are you using the LensFlare post processing option? If so, I can report this issue as well. It's easily observed with the XR2 3D cockpit HUD.

 

[Marg]

Yes , I use LensFlare postprocessing ON (I think it's just them I see through transparencies). If it could be on the day side, it would be nothing too serious, but on the night side it's a bit odd...