New Release D3D9Client Development

[jedidia]

No such branch as Beta3 should exists. Latest stable code in located in trunk

Huh... there's a beta3 branch right here. Though judging by the url you posted, that's completely the wrong repo... :shifty:

So, low experience doesn't really mean anything.

Technically not, But if you just spent the last month at work trying to get to grips with Gradle, Ansible, Maven and Vagrant all at once, you get a bit tired of sticking your nose into a new tool for a while... :lol:

 

[jarmonik]

Huh... there's a beta3 branch right here. Though judging by the url you posted, that's completely the wrong repo... :shifty:

Yes, it's a wrong repo, the CodePlex is history.

---------- Post added at 03:13 ---------- Previous post was at 00:41 ----------

Got it. I'm on it. Thanks for the explanation.

Also one idea that crossed my mind is to use a different micro texture for flat terrain and slopes. By comparing vertex normal to planet's mean normal a slopes could be detected. Also, terrain altitude could effect in micro textures.

Normal mapping wouldn't work for slopes unless tangent and bi-tangent information is stored in a vertex data.

 

[Face]

Huh... there's a beta3 branch right here. Though judging by the url you posted, that's completely the wrong repo..

My mirror is pulling from here: svn://mirror.orbiter-radio.co.uk/D3D9client

Branches in there:

• Experiments
• trunk
• VertexComp
• 2010-P1
• Reflect

 

[Marg]

If you go to Video->Advanced and then click "Create Symbolic Links" does the problem go away ?

I already tried (link exists), but problem remains.

 

[SolarLiner]

Here's a quick shot at normal maps for the Moon micro-textures. They are in an uncompressed RGB8 format since I didn't know how you'd have wanted to compress them.

 

[jarmonik]

Here's a quick shot at normal maps for the Moon micro-textures. They are in an uncompressed RGB8 format since I didn't know how you'd have wanted to compress them.

Thanks for creating the normal maps. I'll include them in the client.

---------- Post added at 19:48 ---------- Previous post was at 19:43 ----------

I already tried (link exists), but problem remains.

When I try Galaxy C5, I see a plane on a runway ready for take off. When I apply thrust, it will pitch up immediately ending upside down. That certainly is a bug but it isn't in the client. What am I supposed to see here ?

 

[SolarLiner]

Thanks for creating the normal maps. I'll include them in the client.

Contributing how I can

I might change them as I see how they behave in D3D9 though. This is definitely not final.

 

[Marg]

When I try Galaxy C5, I see a plane on a runway ready for take off. When I apply thrust, it will pitch up immediately ending upside down. That certainly is a bug but it isn't in the client. What am I supposed to see here ?[/QUOTE]

Oops, There is an issue with landing points in Config\Spacecraft folder -
file Galaxy-C5.ini three landing point rows must be changed to this

LAND_PT1=(0,-8.105,24.95)
LAND_PT2=(-5.45,-8.285,-5.87)
LAND_PT3=(5.45,-8.285,-5.87)

because they were too close together. But pulling them more apart solves stability problem.
But yes, that is not d3d9.dll issue. But problem I was writing is that I somehow do not see plane at all... camera points to vessel's position but there is emptiness.
So you can see in newest d3d9.dll version? Strange... I even updated Nvidia drivers, tried different parameters.

Additionally - 1) when camera is in Ground Earth mode, I can normally move camera around invisible plane.
but when it is in 2) Absolute Direction mode I can't move or rotate camera at all.
Tried inline client - no problems.

 

[jarmonik]

Additionally - 1) when camera is in Ground Earth mode, I can normally move camera around invisible plane.
but when it is in 2) Absolute Direction mode I can't move or rotate camera at all.
Tried inline client - no problems.

That's exactly what happened to me too. There was a black hole in a ground, camera was jammed couldn't move it much, no plane anywhere. But after creating the symbolic links all those problems went away and I was able to see the plane like in the inline engine.

Nothing's been changed from the D3D9 that could cause problems like that.

 

[Marg]

That's exactly what happened to me too. There was a black hole in a ground, camera was jammed couldn't move it much, no plane anywhere. But after creating the symbolic links all those problems went away and I was able to see the plane like in the inline engine.

Nothing's been changed from the D3D9 that could cause problems like that.

Solved! I must announce you are right. It was really this thing. Everything is OK. I must be ashamed taking your time...
Maybe reason was that I copied previous Orbiter r44 to a duplicate folder, and somehow something was messed up. I deleted subfolders Modules/Server folder and recreated symbolic links.

 

[jedidia]

Maybe reason was that I copied previous Orbiter r44 to a duplicate folder, and somehow something was messed up.

Well, then the symbolic link would still have pointed to the folders of the previous orbiter installation

 

[Marg]

But I still notice lunar crater wall flickering, when in lunar orbit (any vessel, default ones too). It is not observable in internal\cockpit view, but when in outside view, flickering stops when distance from vessel is a few hundred meters or more.

 

[jedidia]

Hmph... I'm getting a build error:

error C2084: function 'float exp2(float) throw()' already has a body c:\orbiter 2015\orbitersdk\d3d9client\VectorHelpers.h

If I comment it out the project builds, but I assume it's there to mitigate rounding errors, so... any advice?

At least I can confirm that the crash happens in D3D9 client, though in a place where the call stack is being terribly unhelpful. I'll take a closer look at it over the weekend.

 

[jarmonik]

Hmph... I'm getting a build error:

error C2084: function 'float exp2(float) throw()' already has a body c:\orbiter 2015\orbitersdk\d3d9client\VectorHelpers.h

If I comment it out the project builds, but I assume it's there to mitigate rounding errors, so... any advice?

That's odd. I haven't seen that. It's possible that VS2010 and VS2012 project files are out of date. I am still running VS2008.

At least I can confirm that the crash happens in D3D9 client, though in a place where the call stack is being terribly unhelpful. I'll take a closer look at it over the weekend.

If the call stack is unhelpful then a trace log is a way forward. Switch to a debug level 4 and try to reproduce the CTD as quickly as possible. The trace log should help to narrow down the region.

 

[jedidia]

Ok, got it! Well, most of it, anyways.
The problem is not with dynamically deleting animations per se... the problem is when deleting several animations in the same frame.

clbkVisEvent will receive the current indices of animations deleted in the frame. The list doesn't get updated until next frame, so the indices received are all valid in the current list, from 0 to n. But vves:elAnimation() updates its own list immediately when called. In other words, the animstate list gets shorter with each deleted animation, while the indices keep coming from the old list, usually in ascending order. Eventually the received index will be n/2 + 1, while animstate only has a length of n/2.

Jarmonic, since I assume you know the structure best, what would you think would be the cleanest solution to remove invalid elements from animstate after the entire frame has been processed?

There's also a problem that clbkVisEvent doesn't receive all deletion events. But this problem is either on my end (I know that the deletion for all my animations is called, but maybe they're not successful?) or on Martins.

 

[jarmonik]

Jarmonic, since I assume you know the structure best, what would you think would be the cleanest solution to remove invalid elements from animstate after the entire frame has been processed?

I haven't written the code, so, I'm not an expert on that matter. It's up to you to decide how to fix the problem.

I see potential error between DelAnimation() and GrowAnimstateBuffer(). nanim is decremented in DelAnimation() and it no longer describe the current size of the animstate buffer.

So, VESSEL::GetAnimPtr() returns the highest animation ID used by a vessel not the number of animations. Is that right ?

So, a fix would be doing nothing in DelAnimation() ?

Isn't invalid animation elements already filtered out by this line ?

if (!anim[i].ncomp) continue;

in

for (UINT i = 0; i < nanim; i++) {
		if (!anim[i].ncomp) continue;
		if (animstate[i] != (newstate = anim[i].state)) {
			Animate(i, newstate, mshidx);
			animstate[i] = newstate;
		}
	}

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

There's also a problem that clbkVisEvent doesn't receive all deletion events. But this problem is either on my end (I know that the deletion for all my animations is called, but maybe they're not successful?) or on Martins.

It would be good idea to check the return value of VESSEL:elAnimation(). If there's no failure or no reason for failure then it would be good idea to ask about it form Martin.

 

[jedidia]

So, VESSEL::GetAnimPtr() returns the highest animation ID used by a vessel not the number of animations. Is that right ?

Don't have the code here right now, but from what I saw yesterday, I think it does return the number of animations. Everything works pretty much as intended, except that the list inside Orbiter doesn't get updated until after the frame, so all deletion events received in the same frame come with the indices in the list as it was at the beginning of the frame, while DelAnimation() shrinks its list on a per-deletion basis, not on a per-frame basis.

Isn't invalid animation elements already filtered out by this line ?

Yes, but then nothing is done at all, which leads to an incorrect size of the animstate list. Imagine you have 10 animations, and in one frame the last 2 (indices 8 and 9, in this order) get deleted. the first call works as intended, but afterwards the size of animstate is only 9. So nothing happens at the second call, although the animation doesn't exist anymore.
The problem comes when the animations are checked for change the next time, then D3D9 client will attempt to querry an animation that doesn't exist anymore.

So, a fix would be doing nothing in DelAnimation() ?

Basically yes, but the animstate list still needs to be updated after a frame if deletions have happened. Not difficult, just thinking about how to do it with a minimum of overhead.

It would be good idea to check the return value of VESSEL:elAnimation(). If there's no failure or no reason for failure then it would be good idea to ask about it form Martin.

Yeah, I figured that much...

 

[gosavich]

-Apologies if this is a known issue. I tried searching for a similarly reported problem but didn't exactly find a post that points to a solution. Does anyone else have a problem with the VC MFDs being completely invisible when using the default Atlantis in the latest Beta (v47) and associated D3D9 client build? I don't know if it was present on prior builds.

 

[jarmonik]

Basically yes, but the animstate list still needs to be updated after a frame if deletions have happened. Not difficult, just thinking about how to do it with a minimum of overhead.

Ok, copy that. If a valid animstate varies between [0 to 1] then it should be possible to flag animstate for deletion by setting it's value to -1 for an example. Also a new additions could be identified with -2 for an example.

Then the actual deletion and initialization could be executed in UpdateAnimations() when a new frame begins.

It would be logical to presume that new additions would be placed on a top of the list, but I don't really know if that's the case.

---------- Post added at 02:26 ---------- Previous post was at 02:23 ----------

Yeah, I figured that much...

Would be a good idea to post a link into the beta thread. Martin could miss that post as easily as I did.

---------- Post added at 02:27 ---------- Previous post was at 02:26 ----------

-Apologies if this is a known issue. I tried searching for a similarly reported problem but didn't exactly find a post that points to a solution. Does anyone else have a problem with the VC MFDs being completely invisible when using the default Atlantis in the latest Beta (v47) and associated D3D9 client build? I don't know if it was present on prior builds.

It's a known issues and hopefully fixed in the next beta.

 

[jedidia]

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.

---------- Post added at 09:44 PM ---------- Previous post was at 02:03 PM ----------

Ran upon another (unrelated) problem for which I could use some advice.

When calling VESSEL::GetDevMesh() in the very first clbkVisualCreated of the session, I only get NULLs (only in D3D9, works without trouble in inline). Could you tell me a bit about the processing order here? Is it possible that D3D9client doesn't have the meshes ready at that time?

---------- Post added at 11:51 PM ---------- Previous post was at 09:44 PM ----------

Huh, this is weird... In the inline client, clbkVisualCreated is called after clbkPostCreation, in D3D9client it's called before. In IMS2 meshes are added in clbkPostCreation, so that's why I'm getting NULLs. But I have no idea what action in D3D9client causes Orbiter to trigger clbkVisualCreated on the vessel. Any ideas?

EDIT: nevermind, got it after hunting through the orbiter sdk docs and comparing sources with D3D7 client.

In Scene::Initialise(), D3D9client calls CheckVisual(), which calls AddVisualRec, which calls RegisterVisObject, which will trigger clbkVisualCreated on the relevant vessel. Evidently, the postCreation on the client is called before it is on the vessels, which makes sense.

Fact is that clbkPostCreation in D3D7client does not call CheckVisual. It only calls it in Scene::NewVessel() and Scene::Update(), both places at which D3D9client also makes the call. So calling it already in clbkPostCreation results in divergent behavior of the two clients.

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?