New Release D3D9Client Development

[jarmonik]

New information. Based on the replies I got from martin in the other thread, and a few experiments, it turns out that the size of the animation list in orbiter indeed never shrinks. When an animation is deleted, it is kept in the list, but identified by having zero components.

So we literally have to do nothing to fix the issue in D3D9 client. Marking the animstates of deleted animations with -1 as suggested is still a good idea, and I'll see if there are any queries to that where a validation check is in order, but just removing the resizing of animstate in DelAnimation already seems to be producing stable results.

That's a good news, we don't have to speculate any longer. So, let's remove the code from DelAnimation and add some comments.

Commenting out the call to CheckVisual() in Scene::Initialise() fixes my issue, but I don't know why the call is in there in the first place. Might be that by taking it out we're creating other issues, though judging by the comments the only reason for the call is to create the visuals... which is exactly what shouldn't happen yet. Oppinions?

Yes, it should be safe to remove the code. The reason why the code is placed there is to load and construct visuals before letting Orbiter to start the clock. It was a sort of "pre-load vessel visuals" hack. When the D3D9 project was started there was a problem with too early simulation start. Several seconds of simulation were passed before the first frames were rendered.

It's also good to check the "Start Paused" launch pad option. At least in 2010-P1 it causes some callbacks being called in a different order.

Other problem causing issues are likely fixed from the Beta and some checks are probably no-longer needed.

if (!parser) {
		clbkPostCreation();
		LogErr("clbkUpdate() called before clbkPostCreation()");
	}

if (nanim>0 && animstate==NULL) {
		LogErr("[ANOMALY] UpdateAnimations() called before the animations are initialized. Calling InitAnimations()...");
		InitAnimations();
	}

if (hSun==NULL) {
		LogErr("Scene::Update() Scene not yet initialized");
		//Initialise();
		return;
	}

 

[jarmonik]

There appears to be new animation problem with RMS of Stock Atlantis. Which seems to be depended on this code section in Scene::Initialize()

// Browse through all objects and create visuals if in visual range
//
DWORD nobj = oapiGetObjectCount();
	for (DWORD i=0;i<nobj;i++) {
		OBJHANDLE hObj = oapiGetObjectByIndex(iVCheck++);
		CheckVisual(hObj);
	}

So, does the stock Atlantis actually depend on changed call order of clbkPostCreation and clbkVisualCreated ? :lol:


The satellite should appear attached to the RMS arm when the scenario loads. If not then it will jump to a right place when the arm is moved. (Press Ctrl+Space to open the control dialog.)

 

[jedidia]

Yeah, that's the kind of stuff I was afraid of happening... Does the scenario work in inline client? If yes, there must be another solution.

 

[jarmonik]

Yeah, that's the kind of stuff I was afraid of happening... Does the scenario work in inline client? If yes, there must be another solution.

Yes, it works in inline. But does it work in D3D7Client ? That would be an interesting question.

 

[jedidia]

Well, I guess I'll have to try it out one of these days...

 

[jarmonik]

Well, I guess I'll have to try it out one of these days...

Unfortunately, there are no pre-build binaries and the DX7 SDK is no longer available. Haven't tried my luck with third party downloads yet.

I found this code from the Atlantis.cpp and after enabling the code, the stock Atlantis works with D3D9 better than ever, without the problematic code in Scene::Initialize(). Obviously, something does change when a graphics client is attached to Orbiter.

#ifdef UNDEF
	// note: orbiter re-applies the animations to the mesh before calling
	// clbkVisualCreated, so updating the mesh here is not necessary

	// reset grappling point
	arm_tip[0] = _V(-2.26,1.71,-6.5);
	arm_tip[1] = _V(-2.26,1.71,-7.5);
	arm_tip[2] = _V(-2.26,2.71,-6.5);

	UpdateMesh ();
#endif

This is interesting:

// note: orbiter re-applies the animations to the mesh before calling
// clbkVisualCreated, so updating the mesh here is not necessary

Maybe the re-apply doesn't take place if a client is attached.

 

[jarmonik]

D3D9ClientBeta 17f - forRev47

- Reported font rendering issue is fixed

- Animation code is cleaned up. (further testing required)

- Normal maps for surface micro textures are now supported and micro textures can be created for any planet or moon. Normal mapped water and micro textures don't work together. That's merely a performance issue.

Anisotropy setting seems to impact in performance with the surface micro textures. We are going to need a separate settings or we could hard code the setting in Surface.fx

Texture names:
D3D9[body name]_A.dds
D3D9[body name]_B.dds

Both textures are required which are mixed with D3D9MicroBlend.dds

Texture channels:
.r = normal map .r
.g = normal map .g
.b = surface albedo luminosity centered at 0.5f

Simply replace the blue channel of a typical normal map with a surface luminosity.

 

[jarmonik]

Looks like the Atlantis RMS grapple issue was a sensitive timing issue. If clbkPreStep is called only once before the visual is created it works. If it's called twice it won't work any longer.

 

[jedidia]

So... the calling order is now the same as inline client and atlantis still works?

// note: orbiter re-applies the animations to the mesh before calling
// clbkVisualCreated, so updating the mesh here is not necessary

I noticed that while working on IMS. In D3D9client it doesn't really matter that much, since visuals never seem to get destroyed when zooming out.

 

[jarmonik]

So... the calling order is now the same as inline client and atlantis still works?

Yes.

 

[jedidia]

Great! :thumbup:

There's a last divergence I noticed: When creating a surface with oapiCreateTextureSurface, a color fill succeeds in the inline client, but fails on D3D9client.

I've also used the opportunity to confirm that this problem applies to both inline and D3D9 client. Time to go file a bug report about that...

 

[jarmonik]

There's a last divergence I noticed: When creating a surface with oapiCreateTextureSurface, a color fill succeeds in the inline client, but fails on D3D9client.

Oh really ? It's actually disable on purpose. There was some trouble with an add-on that used oapiLoadTexture() first and then the surface was cleared by oapiClearSurface() which resulted a black VC in D3D9 but worked in inline. So, we actually blocked color fills on a plain textures to gain an equal response. Not sure if that was right thing to do. :lol:

But, of course, oapiLoadTexture isn't oapiCreateTextureSurface

I suppose it would be good to get a confirmation about that.

I've also used the opportunity to confirm that this problem applies to both inline and D3D9 client. Time to go file a bug report about that...

There has been a few problem with oapiCreateSurfaceEx. At least some time ago oapiCreateSurfaceEx replaced user input flags with hard coded flags. TEXTURE | RENDERTARGET was changed to a non texture surface RENDERTARGET | GDI or something like that.

---------- Post added 10-02-16 at 07:51 ---------- Previous post was 09-02-16 at 12:24 ----------

Currently it looks like in the inline engine surface created with oapiLoadTexture() cannot be color filled regardless whether the surface is compressed or not. However, a surface created with oapiCreateTextureSurface can be color filled. I'll fix that from the D3D9...

 

[Marg]

With this new F version, I have crashes with scenarios on Earth if there are reflective vessels, on launch pads (landed status), if reflection is enabled... I could not figure out what is wrong for a long time, until disabled "reflection mode"...
On the moon, or even in low Earth orbit, everything is OK with reflection mode ON.
To find out what is wrong, I added vehicles to Saturn-V stack one by one, until CM was added (its cone has environmental reflection), and LM descent stage as well and CTD happened...

 

[Abloheet]

Moon looks even better now! But where did the microtextures and normal maps for Mars go? Mars is back to being dull.

 

[SolarLiner]

Moon looks even better now! But where did the microtextures and normal maps for Mars go? Mars is back to being dull.

I have yet to make the normal maps for the Mars microtextures. I want to have finished the Moon ones so I have a good idea of the correct workflow before attempting the red planet.

 

[jedidia]

Hmmm... I'm not getting any microtextures at all anymore with a current checkout. Is it supposed to be that way right now?

 

[Abloheet]

Yeah, normal maps for mars are wip.

But what about the microtextures? They were there in d3d9 17e

 

[Marg]

Yeah, normal maps for mars are wip.

But what about the microtextures? They were there in d3d9 17e

I think D3D9Mars_A.dds and D3D9Mars_B.dds are necessary (new format)?
And you could try reflective surface on any vessel when landed on Earth... I think it makes a CTD...

 

[jarmonik]

I think D3D9Mars_A.dds and D3D9Mars_B.dds are necessary (new format)?

That is correct.

I also made some tests and we may need to change the rendering technique once more. I think it would be good to have a different close-up texture that would be visible when the camera altitude is less than 60m and an other distant texture that would be visible below 6km.

*_A.dds could be the close up texture showing rocks and sand (powder, dust or what ever is there).

*_B.dds would be more distant surface. (Could be something pretty close to the current ones)

Unfortunately, the distant texture _B does leave noticeable repetitive pattern on ground. With a good design it could be made less noticeable or it could be mixed with (not yet existing) *_C texture, but doing that would reduce performance.

Here's a new shader code that allows to experiment with close-up textures.

 

[Marg]

I really hope Earth landed CTD with reflections ON, can be solved.
But whatever visual problems with microtextures are, it is 100 times better thm without them. A different world...