New Release D3D9Client Development

[kuddel]

Thanks!
A couple a things I found in file gcConst.h:
line 495: nameless structs containing variables with same name
line 578: missing return

a) That's the 'a' float used both in {R,B,G,A} and {{RGB},A} "union". they should be O.K. from a memory layout. I haven't found a good way to work around that (yet).
b) Right! Good catch. Will be fixed! :thumbup:

 

[GLS]

a) That's the 'a' float used both in {R,B,G,A} and {{RGB},A} "union". they should be O.K. from a memory layout. I haven't found a good way to work around that (yet).
b) Right! Good catch. Will be fixed! :thumbup:

and the 'w'

 

[kuddel]

Changing the FVECTOR4 from

typedef union FVECTOR4 
{
	// ...
	float data[4];
	struct {
		float x, y, z, w;
	};
	struct {
		float r, g, b, a;
	};
	struct {
		FVECTOR3 rgb;
		float a;
	};
	struct {
		FVECTOR3 xyz;
		float w;
	};
} FVECTOR4;

...to...

typedef union FVECTOR4 
{
	// ...
	float data[4];
	struct {
		float x, y, z, w;
	};
	struct {
		struct {
			float r, g, b;
		};
		struct {
			FVECTOR3 rgb;
		};
		float a;
	};
	struct {
		FVECTOR3 xyz;
		float w;
	};
} FVECTOR4;

...should do the trick.

But it greatly reduces readability

I might have to add some comments ?!

By the way here's a nicer summary of that.

---------- Post added at 00:03 ---------- Previous post was at 00:02 ----------

and the 'w'

Oh, 'w' has also to be moved. Thanks!

---------- Post added at 00:09 ---------- Previous post was at 00:03 ----------

So this should be it, right?

typedef union FVECTOR4 
{
	// ... 
	float data[4];
	struct { // {x,y,z,w} or {xyz,w}
		struct {
			float x, y, z;
		};
		struct {
			FVECTOR3 xyz;
		};
		float w;
	};
	struct { // {r,g,b,a} or {rgb,a}
		struct {
			float r, g, b;
		};
		struct {
			FVECTOR3 rgb;
		};
		float a;
	};
} FVECTOR4;

 

[GLS]

So this should be it, right?

typedef union FVECTOR4 
{
	// ... 
	float data[4];
	struct { // {x,y,z,w} or {xyz,w}
		struct {
			float x, y, z;
		};
		struct {
			FVECTOR3 xyz;
		};
		float w;
	};
	struct { // {r,g,b,a} or {rgb,a}
		struct {
			float r, g, b;
		};
		struct {
			FVECTOR3 rgb;
		};
		float a;
	};
} FVECTOR4;

It seems ok now.

 

[jarmonik]

Here you go: https://www.dropbox.com/s/p03i0psduchso3y/SSU_v5.0r3247.zip?dl=0, full package.

Ok, Thanks. I had some trouble getting it to work, it seems to crash in a cockpit view but I was able to make the necessary test.


Here's a slightly modified shader and textures. Some of the textures were pretty badly out of reasonable range. Even if we have a "roughness map" it is in-fact a smoothness map so 255 is mirror smooth and 0 is very rough. This article speaks of a "Microsurface" https://marmoset.co/posts/physically-based-rendering-and-you-can-too/


The textures should be remade the ones in the package have been modified-compressed-modified-compressed... so the quality have deteriorated.


Could you test these textures and the modified shader to see if there are any fundamental issues remaining. I wasn't able to test the local lights due to no access in cockpit.

 

[jarmonik]

But it greatly reduces readability

It's readable well enough :thumbup:

---------- Post added at 18:13 ---------- Previous post was at 18:12 ----------

Since performance will depend on unknowns (number of lights, mesh complexity and CPU power) the only answer it to let the user decide. But it should be implemented for all lights of course.
So a "Compute local light shadows ON/Off" switch would do.

Ok, Agreed.

 

[4throck]

A quick remark about transparency:
Perhaps mesh groups could be excluded from shadow computations, based on material properties. Simply exclude if opacity is different from 1.

(For texture alpha, there's no solution, the mesh must be updated)

 

[jarmonik]

I agree with this option as it is an option seeing in many modern AAA games. Another shadow related bug is that what shadows are seen depends on what vessel is in focus. This is an old bug that I have reported earlier: https://www.orbiter-forum.com/showthread.php?p=579460&postcount=4566

I made some testing and I saw that shadow quality can wary depending on vessel in focus like in this screen shot (SRB on shuttle wing) but they shouldn't completely disappear. It shouldn't be difficult to apply better shadows on all small vessels like the shuttle.

 

[DaveS]

Ok, Thanks. I had some trouble getting it to work, it seems to crash in a cockpit view but I was able to make the necessary test.


Here's a slightly modified shader and textures. Some of the textures were pretty badly out of reasonable range. Even if we have a "roughness map" it is in-fact a smoothness map so 255 is mirror smooth and 0 is very rough. This article speaks of a "Microsurface" https://marmoset.co/posts/physically-based-rendering-and-you-can-too/


The textures should be remade the ones in the package have been modified-compressed-modified-compressed... so the quality have deteriorated.


Could you test these textures and the modified shader to see if there are any fundamental issues remaining. I wasn't able to test the local lights due to no access in cockpit.

I did forget to mention that the modules were built for the latest Orbiter 2016 beta revision (90). Things do look better now though, thanks. Final confirmation will have to come once proper reflections have been implemented.

 

[kuddel]

Side note for developers compiling D3D9Client from source:
- 'trunk' is currently not the main development branch of Jarmo. He currently mainly develops on branch '2016'.
- I'll merge all the changes back to 'trunk' when it makes sense (@Jarmo: drop me a note when you think it's worth it :thumbup

 

[Trekkie]

Question, For the Standard Orbiter Game Engine are Meshes as Planets supported, but strangely in the D3D9 engine when i load up my Planetary System that uses the Meshes the meshes are not present like in the Regular engine.. somebody knows a fix for this?

 

[Abloheet]

Question, For the Standard Orbiter Game Engine are Meshes as Planets supported, but strangely in the D3D9 engine when i load up my Planetary System that uses the Meshes the meshes are not present like in the Regular engine.. somebody knows a fix for this?

Umm, as far as I know, and have tested and used, latest version of d3d9 client for latest version of Orbiter, i.e. 2016 Beta rev90, fixed the invisible planet meshes in external graphics client bug. Not sure about d3d9 client version for Orbiter 2016 release. That one maybe doesn't have the fix implemented yet.. haven't tested.

 

[Trekkie]

Umm, as far as I know, and have tested and used, latest version of d3d9 client for latest version of Orbiter, i.e. 2016 Beta rev90, fixed the invisible planet meshes in external graphics client bug. Not sure about d3d9 client version for Orbiter 2016 release. That one maybe doesn't have the fix implemented yet.. haven't tested.

they seem to appear now but there is still one problem they dissapear when zooming out.. For instance im trying to recreate another sun, so its a big sun and when i zoom out beyond 1.7G it dissapears

 

[jarmonik]

Side note for developers compiling D3D9Client from source:
- 'trunk' is currently not the main development branch of Jarmo. He currently mainly develops on branch '2016'.
- I'll merge all the changes back to 'trunk' when it makes sense (@Jarmo: drop me a note when you think it's worth it :thumbup

My current working copy of 2016 branch was a lot of modifications since I am still working on "mesh to terrain" converter and other elevation tools. I don't know when I got the time to finish it. However, I don't see any issues with merging current 2016 modifications into the trunk.

 

[Marg]

How is was about local light shadows? any chance?...

 

[kuddel]

Phew! I managed to merged the changes from branch/2016/ to trunk/, but that was a big mess!
The trunk/ HEAD compiles, links & runs :thumbup:,
but the planetary elevation is not working correct :thumbsdown:

• Bases are floating above (or below) the surface
• It looks like the elevation is scaled wrong (but that might be an optical illusion due to the point above )

So, Jarmo (or anyone else) whoever finds and fixes the issue first gets 1e3 extra karma points :lol:

---------- Post added 10-04-20 at 01:14 ---------- Previous post was 09-04-20 at 23:20 ----------

Side note:
I will probably exchange all the "for each (... in ...)" code by range-based for statements, as the former is not C++ standard (as the documentation notes).
Not that we like D3DClient to be cross-compile-able, but still...:thumbup:

 

[DaveS]

How is was about local light shadows? any chance?...

And of course multiple environment cameras so that we finally can have realistic reflections (instead of one camera being responsible for all the reflections on multiple elements which is very unrealistic).

 

[GLS]

Side note:
I will probably exchange all the "for each (... in ...)" code by range-based for statements, as the former is not C++ standard (as the documentation notes).
Not that we like D3DClient to be cross-compile-able, but still...:thumbup:

Those "auto loops" are a very good feature, as it decreases the number of times coders look like fools... :lol: :shifty:

 

[llarian]

Hmm, off hand, did you try to incorporate surface flattening in the area of the bases that are floating?

Phew! I managed to merged the changes from branch/2016/ to trunk/, but that was a big mess!
The trunk/ HEAD compiles, links & runs :thumbup:,
but the planetary elevation is not working correct :thumbsdown:

• Bases are floating above (or below) the surface
• It looks like the elevation is scaled wrong (but that might be an optical illusion due to the point above )

So, Jarmo (or anyone else) whoever finds and fixes the issue first gets 1e3 extra karma points :lol:

---------- Post added 10-04-20 at 01:14 ---------- Previous post was 09-04-20 at 23:20 ----------

Side note:
I will probably exchange all the "for each (... in ...)" code by range-based for statements, as the former is not C++ standard (as the documentation notes).
Not that we like D3DClient to be cross-compile-able, but still...:thumbup:

 

[DaveS]

Trying the build the last D3D9Client sources I get this when the script gets to the GenericCamera MFD, this is with the latest trunk revision (r. 1273):

c:\d3d9client\orbitersdk\samples\genericcamera\mfd.cpp(389): error C3861: '_FVECTOR4': identifier not found [C:\D3D9Client\Orbitersdk\samples\GenericCamera\GenericCamera.vcxproj]
c:\d3d9client\orbitersdk\samples\genericcamera\mfd.cpp(390): error C3861: '_FVECTOR4': identifier not found [C:\D3D9Client\Orbitersdk\samples\GenericCamera\GenericCamera.vcxproj]
c:\d3d9client\orbitersdk\samples\genericcamera\mfd.cpp(391): error C3861: '_FVECTOR4': identifier not found [C:\D3D9Client\Orbitersdk\samples\GenericCamera\GenericCamera.vcxproj]