# New ReleaseD3D9Client Development

#### Marg

##### Member
Thanks, it is better. Where is defined the size of cloud microtextures (scale)?
But yes, I also share DaveS's thoaughts about particle illumination, but it can be diffiicult.

P.S. are ocean waves moving faster?

#### jarmonik

Beta Tester
Thanks, it is better. Where is defined the size of cloud microtextures (scale)?
But yes, I also share DaveS's thoaughts about particle illumination, but it can be diffiicult.
P.S. are ocean waves moving faster?

The scale is tied to a tile level which can be changed only from the (*.cpp) source codes. Also the scale can be only doubled or reduced in half. A Finer control is possible by altering the micro-texture size that is currently 256x256. It doesn't need to be power of two.

There are some plans to create a particle effect editor which would allow more options and capabilities for particles and emitters. This editor would be an extension to the mesh/vessel editor that's been mentioned earlier. The particle lighting issues would be addressed during the upgrade process.

Is the water too fast ? It's defined in Surface.fx line 679, current speed in 60 tiles / h

#### DaveS

Donator
Beta Tester
Thanks, it is better. Where is defined the size of cloud microtextures (scale)?
This the cloud micro textures I'm using, it's a bit on the old side but still works well: [ame="https://www.orbithangar.com/searchid.php?ID=3164"]Just a moment...[/ame]

#### kuddel

##### Donator
Donator
P.S. are ocean waves moving faster?
Yeah, they are definitely "feeling" to fast.
I would rather go for 1/3 of the speed, as it "feels" better.

Easy fix by changing Modules\D3D9Client\Surface.fx (SurfaceTechPS; Line 679):
vUVWtr.x += fTime*60.0f/3600.0f;
vUVWtr.x += fTime/180.0f;

#### Marg

##### Member
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?)

#### DaveS

Donator
Beta Tester
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.

Last edited:

#### 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?)
Code:
svn://svn.orbiter-forum.com/orbiter/

#### kuddel

##### Donator
Donator
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

##### Member
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

Beta Tester
...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

##### Donator
Donator
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.

Last edited:

#### Marg

##### Member
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?

Last edited:

#### kuddel

##### Donator
Donator
@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

Beta Tester
@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 ?

Last edited:

#### kuddel

##### Donator
Donator
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

##### Member
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

##### Donator
Donator
@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

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

#### kuddel

##### Donator
Donator
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

##### Donator
Donator
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.

#### Attachments

• 24.4 KB Views: 59
• 918.7 KB Views: 11