New Release D3D9Client Development

[jarmonik]

I can reproduce this one. Looks like after separation the animation transformations are applied into a wrong mesh somehow. Animations seems to be reset to the correct one after restarting the scenario. Also, there seems to be some serious issues with near clipping plane.

---------- Post added 24-04-11 at 00:17 ---------- Previous post was 23-04-11 at 23:40 ----------

(225: 32.3s 0.0us)(0xA08) clbkVisEvent called hObj=0xDD3D928, vis=0x149DC1C8, msg=1 context=0xFFFFFFFF
(226: 32.3s 18.7us)(0xA08) EVENT_VESSEL_DELMESH
(227: 32.3s 34.4us)(0xA08) clbkVisEvent RETURN
(228: 32.5s 1.1us)(0xA08) clbkVisEvent called hObj=0xDD3D928, vis=0x149DC1C8, msg=0 context=0x0
(229: 32.5s 62.2us)(0xA08) EVENT_VESSEL_INSMESH
(230: 32.5s 62106.5us)(0xA08) vVessel(0x149DC1C8)::InsertMesh(0) hMesh=0x11D76128 offset=(0, 0, 0)
(231: 32.5s 62172.4us)(0xA08) clbkVisEvent RETURN

Looks like the SoyuzTMA is trying to delete a mesh from an index of 0xFFFFFFFF. The call is ignored as being out of range. What short of action should be taken here
​

---------- Post added at 00:23 ---------- Previous post was at 00:17 ----------

Yes, it does.

Yes, with the internal DX7 engine but not with external D3D7Client.

---------- Post added at 14:46 ---------- Previous post was at 00:23 ----------

[COLOR=Gray](222: 42.0s 2116.8us)(0x7E8)[/COLOR][COLOR=Olive] Vessel(0xDE748EC) ISSR\TMA_BO has 1 meshes[/COLOR]
[COLOR=Gray](223: 42.1s 2.6us)(0x7E8)[/COLOR][COLOR=Olive] Mesh(0x118C68A8) Offset = (0, 0, 0)[/COLOR]
[COLOR=Gray](224: 42.1s 72.4us)(0x7E8)[/COLOR][COLOR=Olive] RegisteringVisual (SoyuzTMA-10-BO) hVessel=0xDE748EC, hObj=0xDBDF720, Vis=0x1479DBD0, Rec=0x43D3128, Type=10[/COLOR]
[COLOR=Gray](225: 42.1s 0.0us)(0x7E8)[/COLOR][COLOR=Blue] clbkVisEvent called hObj=0xDB1AB30, vis=0x1479D420, msg=1 context=0xFFFFFFFF[/COLOR]
[COLOR=Gray](226: 42.1s 20.1us)(0x7E8)[/COLOR][COLOR=Blue] EVENT_VESSEL_DELMESH[/COLOR]
[COLOR=Gray](227: 42.1s 2449.3us)(0x7E8)[/COLOR][COLOR=Blue] clbkVisEvent RETURN[/COLOR]
[COLOR=Gray](228: 42.2s 1.1us)(0x7E8)[/COLOR][COLOR=Blue] clbkVisEvent called hObj=0xDB1AB30, vis=0x1479D420, msg=0 context=0x0[/COLOR]
[COLOR=Gray](229: 42.2s 64.4us)(0x7E8)[/COLOR][COLOR=Blue] EVENT_VESSEL_INSMESH[/COLOR]
[COLOR=Gray](230: 42.3s 58227.2us)(0x7E8)[/COLOR][COLOR=Olive] vVessel(0x1479D420)::InsertMesh(0) hMesh=0x118C68A8 offset=(0, 0, 0)[/COLOR]
[COLOR=Gray](231: 42.3s 58292.0us)(0x7E8)[/COLOR][COLOR=Blue] clbkVisEvent RETURN[/COLOR]
[COLOR=Gray](232: 42.3s 0.0us)(0x7E8)[/COLOR][COLOR=Blue] clbkVisEvent called hObj=0xDB1AB30, vis=0x1479D420, msg=2 context=0x0[/COLOR]
[COLOR=Gray](233: 42.3s 17.2us)(0x7E8)[/COLOR][COLOR=Blue] EVENT_VESSEL_MESHVISMODE[/COLOR]
[COLOR=Gray](234: 42.3s 32.9us)(0x7E8)[/COLOR][COLOR=Olive] VisMode set to 3[/COLOR]
[COLOR=Gray](235: 42.3s 48.6us)(0x7E8)[/COLOR][COLOR=Blue] clbkVisEvent RETURN[/COLOR]

Looks like the animation parts will start to work properly after calling ClearAnimations() or InitAnimations() when a mesh group is deleted with 0xFFFFFFFF.

But there is still something odd going on. After separation, a new vessel is created (TMA_BO) on a line 222 and it has a one mesh 0x118C68A8 in index 0. After that, a mesh is deleted from a SoyuzTMA-10 (index 0xFFFFFFFF which most likely means index 0 with some additional operations) and it makes a perfect sence, but then.

On a line 230 a mesh is added in the index 0 of SoyuzTMA-10 and the mesh is the one created at the line 223 which is the TMA_BO. So, why is the TMA_BO inserted in the SoyuzTMA after separation. Also the visibility mode is set to 3 (Always Visible). As an result an other TMA_BO is still attached in the SoyuzTMA after separation of the first one (the Vessel from the line 222).:hmm:

---------- Post added at 15:24 ---------- Previous post was at 14:46 ----------

Looks like the SoyuzTMA is trying to delete a mesh from an index of 0xFFFFFFFF. The call is ignored as being out of range. What short of action should be taken here

Ok, I found the answer. It meens to delete all meshes.

 

[jarmonik]

Here what's happen when I jettison the BO, seems that the meshgroups are messed in some way :

The LES abort animations are messy too, the meshes that move aren't the right ones.

The first issue should be fixed now. Could you check the LES aborts.

 

[N_Molson]

Confirmed, the jettison issue is fixed. :thumbup:

But there still are issues with the LES, especially the grid stabilizers that rotate in the wrong direction :

For reference, they are supposed to deploy like that (the four black squares) :

And BTW, we see only 2 of the 4 panels on the screenshot...

 

[jarmonik]

But there still are issues with the LES, especially the grid stabilizers that rotate in the wrong direction :

And BTW, we see only 2 of the 4 panels on the screenshot...

Please no, this is probably the worst kind of bug to have.:facepalm:It was too much hoped for that the first issue whould have fixed remaining issues with the LES. Every animation has been working perfectly fine sofar, why now ? That is supposed to be a simple animation. But it do play fine with the inline engine so something is wrong. There must be something special on how it's done, so I need to know more about it and seeing the code wouldn't hurt. And I may need to rely on Martin's help with this one.

2 panels are behind the shield in the screen shot and the panels aren't black in that vessel model and I can't change that.

 

[N_Molson]

No, the panels are white anyways, that's "only" an animation problem.

But huh... I didn't wanted to say it before... :shifty: But there are texture issues too...

The SoyuzTMA Service Module (the capsule itself) has several textures to simulate the burns caused by reentry. And with the DX9 client, they don't update the right way, I fear... (for exemple, when you use the LES, the capsule is heated to red, which doesn't happen with the DX7 inline engine). :idk:

Thornton would probably be the one to contact, but I know he is currently very busy with RL work those months...

 

[jarmonik]

The SoyuzTMA Service Module (the capsule itself) has several textures to simulate the burns caused by reentry. And with the DX9 client, they don't update the right way, I fear... (for exemple, when you use the LES, the capsule is heated to red, which doesn't happen with the DX7 inline engine). :idk:

When a texture is changed with oapiSetTexture (MESHHANDLE hMesh, DWORD texidx, SURFHANDLE tex) it seems that the Orbiter doesn't reroute the replacement texture to the graphics client for some reason.

Using the oapiSetTexture (DEVMESHHANDLE hMesh, DWORD texidx, SURFHANDLE tex) function instead might help.

 

[Disconnect]

i have a problem since the last release

http://dl.dropbox.com/u/5862163/orbiterd9.mkv

 

[jarmonik]

i have a problem since the last release

http://dl.dropbox.com/u/5862163/orbiterd9.mkv

That looks horrible. I have never seen anything like that before. Could you try it in a clean installation of Orbiter. Also, does the D3D9ClientLog.html show any errors ? (It's located in /Modules/D3D9Client/) What kind of graphics hardware you have ?

EDIT: Looks like you already answered that qustion. Radeo HD3870 and it's DirectX 10.1 hardware so it's not caused by it.
EDIT2: BTW, is anyone else having the same problem ? kevin580 you ?

 

[80mileshigh]

BTW, is anyone else having the same problem ?

Hi Jarmonik, I had this issue after first installing RC11. I found I had 'D3D9ClientSL' as the only graphics module activated. I switched this to 'D3D9Client' and the problem went away. Hope this is some help.

 

[Disconnect]

Yes i've switched from SL too, and the most of the problems are disappeared, also the distant dots revealed.

But i still have those dark spots that i reported before on outer planets, on every tiles.
http://dl.dropbox.com/u/5862163/orbiter_dx9.png

-the distant dots are bright even on the body's dark side.

-Will be possible to bodies to make shadows on each other? (planet on moons and moons on planet)

 

[jarmonik]

But i still have those dark spots that i reported before on outer planets, on every tiles.

Does any of the following visual options have any effect into the dark dots. (Cloud shadows, Planet night lights, Cloud layers) ?

 

[jarmonik]

D3D9Client RC12

Before installing RC12 remove all existing D3D9Client dlls from the /Modules/Plugin/ folder.

- Near clipping plane issues should be fixed.
- The bug causing a solar panels and some other meshes to disappear should be be fixed.
- "Dot" lighting issue is fixed.
- SoyuzTMA animation/meshgroup bug is fixed.
- Shadow disappear bug is fixed.

I'll make more official release if everything is working fine. I made a small code modification to attempt to cure the "dark dot" issue from the outer planets. The LES animation bug still exists.

 

[Hayab]

Thank you for your Work Jarmonik, Dx9 Client is a true Enrichment for the Orbiter.:thumbup:

 

[Disconnect]

Does any of the following visual options have any effect into the dark dots. (Cloud shadows, Planet night lights, Cloud layers) ?

Yes, if i disable cloud shadows, the issue disappears.

 

[N_Molson]

Great work ! The BO / SA separation works well with RC12 !

The Soyuz TMA LES bug is still there, but you probably know it, just to be sure.

Notice that despite of the grid stabilizers bug, it looks very good, however. :thumbup:

 

[edsupagood]

I have a CTD with Firefly 2011. Does anyone else have this? I have tried on a clean installation of Orbiter.

 

[jarmonik]

I have a CTD with Firefly 2011. Does anyone else have this? I have tried on a clean installation of Orbiter.

If it's using spacecraft2.dll, spacecraft3.dll or multistage2.dll it won't work. However, if it's not using any of those dlls, I need a link into a download.

 

[Izack]

If it's using spacecraft2.dll, spacecraft3.dll or multistage2.dll it won't work. However, if it's not using any of those dlls, I need a link into a download.

http://yankeeclippersmobile.com/forum/index.php/board,61.0.html
They're attached to the posts in the second, third, fourth and fifth threads.

 

[jarmonik]

D3D9ClientRC13

RC13 is here.

- Slow startup & shutdown issues fixed.
- Simulation freezing in a separation fixed.
- Framerate increased.
- One modification made to attempt to fix "dark dot" issue.

http://yankeeclippersmobile.com/forum/index.php/board,61.0.html
They're attached to the posts in the second, third, fourth and fifth threads.

I can reproduce that one and it looks pretty much like the DeltaGliderIV CTD. The D3D9Clinet is calling Orbiter's RegisterVisObject() function which will never return. The Orbiter will call Vessel's clbkVisualCreated() callback function form RegisterVisObject(). The CTD will occur in somewhere in the Vessel-Orbiter interaction. The Client isn't the one to blame.

 

[jarmonik]

The Soyuz TMA LES bug is still there, but you probably know it, just to be sure.

I took a good look into it and I don't know what's causing it. The initial positions of the grid stabilizers are correct. The reference point of the rotation and the rotation axis are incorrect. The axies, probably, need to be transformed somehow.