New Release D3D9Client Development

[jarmonik]

I am finding I can't raise the gold visor in UMMUs when running in the D3D9 client. I did a search and nothing came up, so I am wondering if this is a known and expected issue with D3D9 or I have a more unique issue with my current installation.

I also have found that the XR2s braking performance drops considerably under D3D9. I found it almost impossible to stop the thing before running of the runway. Had to go into the config file and beef up the braking power considerably in order to get the brakes to behave as I would think they would.

The visor doesn't work here either and neither does the HUD without a GDI compatibility mode. I haven't done any detailed diagnostics about the matter but a dependency walker program shows that ummu is using oapiMeshMaterial() function which doesn't work in a graphics client environment.

The braking force of a wheel-brakes has been pretty low always in the Orbiter as far as I remember.

 

[Cras]

I admit I need to do some more work on testing the brakes because I just flew the XR2 and got different braking pefromance than that which I had set up from running a saved scenario where the XR2 was on final approach into KSC. I am using specific vessel config override files, on top of the general xr2 config file, and the braking force line I hvae put into the specific file config override.

As for the visor, I have already got the client in GDI compatability mode, it was the only way to get the HUD to work for UCGO vessels, and thus the same being for UMMU is not surprising.

I wonder than if it is possible to just replace the gold visor mesh with the clear one, as I never found the gold mesh to be that useful in orbiter, I find it more of a hinderence than anything.

 

[flyer]

GT335M Not recognised

Hi there,

I have just updated my 335M graphics card to the latest nvidia driver (280.26) and now when I run orbiter_ng with the D3D9 client, my GT335M card is not listed, only the integrated intel card.

I am running the executable with the 335M but still the Intel HD integrated card is the only option I have to select.

Does anybody have any suggestions for something I can try to do to fix this?

Thanks very much,


Flyer

(Alienware M11xR2 i7)

 

[Columbia42]

Is the "always enumerate devices" box checked in the video tab of the launchpad?

 

[flyer]

I don't have that option with the orbiter_ng.exe and D3D9 client - it is with the normal orbiter.exe though


---

I'm also not having any luck running Energia with the D3D9 client. Has anybody got this to work? I tried searching but didn't come up with anything.

 

[Cras]

An update on the braking issue I had earlier, I think it has something to do with GDI compatibility mode. The braking effectiveness when GDI compatability mode is on stutters, it will kill my velocity in spurts, then be totally ineffective. I just tried a landing with GDI mode off, and the braking performance was what one would expect it to be. While the frame rate is still very high with GDI mode on, it is not as high nor as smooth as with it off, and that is to be expected. Something with the lower framerates not letting the XR2 brakes function all the time, only in spurts.

---------- Post added at 09:55 PM ---------- Previous post was at 09:54 PM ----------

I'm also not having any luck running Energia with the D3D9 client. Has anybody got this to work? I tried searching but didn't come up with anything.

Energia works fine in D3D9, except that you cannot insert it into the scenario via the scenario editor. I get CTD everytime. If I load orbiter up using the inline client, and insert Energia and set up the payloads, then save, reload the save in D3D9, it works perfectly.

 

[jarmonik]

An update on the braking issue I had earlier, I think it has something to do with GDI compatibility mode. The braking effectiveness when GDI compatability mode is on stutters, it will kill my velocity in spurts, then be totally ineffective. I just tried a landing with GDI mode off, and the braking performance was what one would expect it to be. While the frame rate is still very high with GDI mode on, it is not as high nor as smooth as with it off, and that is to be expected. Something with the lower framerates not letting the XR2 brakes function all the time, only in spurts.

I made some tests using XR2 Ready for takeoff scenario and FlightData module to track the airspeed and I coudn't detect any difference in GDI compatibility mode. It was a simple test: accelerate to 50m/s and brake. Can you reproduce the problem with a similar test ? or does it require taking off from the ground ?

 

[Cras]

The speeds I have been dealing with are indeed approach speeds, landing around 150 m/s. I have since taken very aggressive approaches in terms of killing speed.

I did an appraoch where I was able to land at something like 80 m/s and the XR2 stopped very well.

I will try to reproduce actually using the flight data module and report back.

---------- Post added at 07:05 PM ---------- Previous post was at 11:43 AM ----------

I did an approach, landed at about 120 m/s in both the inline client, and with D3D9, and I found something that might be the clue to why I have such poor braking performance.

I did both flights with the flight data recorder on showing both Altitude, and Airspeed.

When flying in the inline client, the braking performance is great, the wheels get on the ground, I hit the brakes, and the XR2 stops.

When I flew with the D3D9, as I landed and the ship slowly slowed down as I applied the brakes, the atltitude graph became volitile, showing my altitude jumping up and down up and down, and what I think is happening is that the ship is actually not staying on the ground, it is skipping of the surface, and when orbiter detects the wheels are off the ground the brakes don't work, so that is why I get the skipping in performance. I am not sure why this skipping happens in the D3D9 client, it sure does not in the in-line client, as the altitude data shows a steady line, the wheels are on the ground and the brakes are working continuously.

 

[Astronut25]

Texture Bug

Here's another interesting bug,

The central tower and the cube thing on top are low resolution, while the surrounding structures with the exact same textures are showing normally.:huh: This happens when I create a normal texture for them.


I can't get the "Instert My Photos" function to work, so I had to copy the thumbnails.
DX7 & DX9 W/O Normals


DX9 W/ Normals


Also, has anyone noticed that the monorails don't work?
I also noticed that my surface base structures have shadows.

 

[orb]

I can't get the "Instert My Photos" function to work, so I had to copy the thumbnails.

Fixed links, as clicking on images transfered me to my albums.

Also, has anyone noticed that the monorails don't work?

Yes, they don't work in Orbiter_ng, like other dynamic base structures (e.g. solar plants, runway lights). It isn't a bug of D3D9Client, they weren't just implemented yet in non-graphics Orbiter.

 

[orb]

DX7 & DX9 W/O Normals


DX9 W/ Normals

After a closer look at these screenshots I have a question. The top one (with brighter landing pads) looks like you were using bloom effect. Do you use ENBSeries or any other way to add post processing effects to Orbiter? Is your problem reproducible without this additional post processing?

 

[Astronut25]

...looks like you were using bloom effect. Do you use ENBSeries ...?

I have ENBSeries.

Is your problem reproducible without this additional post processing?

No difference without ENB.

After a closer look at these screenshots I have a question. The top one (with brighter landing pads)...

That's another bug I've noticed similar to this one, where some normals cause that on a couple things (the Landing Pads & Space Station Building Block Tanks). I don't understand why it does that with just those two things.

 

[orb]

That's another bug I've noticed similar to this one, where some normals cause that on a couple things (the Landing Pads & Space Station Building Block Tanks). I don't understand why it does that with just those two things.

The brighter pads and overlaid blur (visible as slightly brighter blurred area around pads and darker area around structures) are caused by ENBSeries bloom effect. On the 2nd screenshot there is no ENBSeries, as it's most likely a shot from in-line client (there is monorail).

Can you post a screenshot from D3D9Client without ENBSeries at all?

 

[jarmonik]

When I flew with the D3D9, as I landed and the ship slowly slowed down as I applied the brakes, the atltitude graph became volitile, showing my altitude jumping up and down up and down, and what I think is happening is that the ship is actually not staying on the ground, it is skipping of the surface, and when orbiter detects the wheels are off the ground the brakes don't work, so that is why I get the skipping in performance. I am not sure why this skipping happens in the D3D9 client, it sure does not in the in-line client, as the altitude data shows a steady line, the wheels are on the ground and the brakes are working continuously.

I made a several test flights with XR2 from runway-15 to runway-13 and I couldn't detect any problems in altitude or braking performance. The altitude graph was steady after touchdown. I have no idea what is cousing the problem. The D3D9Client doesn't interface with the physics in anyway.

Is this a XR2 specific problem or does it occur with other vessels like stock delta-glider ?

If it does occur with other vessels then it might be good idea to file an official Orbiter2010-P1 bug report about it with some data like a screen shot from the unstable altitude graph.

Is anyone else having the same problem ?

 

[Astronut25]

The brighter pads and overlaid blur (visible as slightly brighter blurred area around pads and darker area around structures) are caused by ENBSeries bloom effect. On the 2nd screenshot there is no ENBSeries, as it's most likely a shot from in-line client (there is monorail).

Can you post a screenshot from D3D9Client without ENBSeries at all?

Here's an ENB free install screenshot.


in an earlier post I was actually referring to the strange glow on the pads that are easier to see in this screenshot. (it disappears when I remove the normal for that texture)


Here's another bug, where the shadow from Brighton Beach is visible elsewhere (that's not Brighton in the screenshot, its a copy). This also happens with other bases. This happens when I use F1 to change the view.


Note: I am still not able to use the "insert my photos" function (it doesnt do anything). these are just copies of the thumbnails.

 

[jarmonik]

in an earlier post I was actually referring to the strange glow on the pads that are easier to see in this screenshot. (it disappears when I remove the normal for that texture)

There is a similar glow in the ailerons of stock delta-glider. As far as I can tell, it's caused by a mesh problem. The Orbiter is using indexed meshes where one vertex can be shared between multible faces. Even if two vertices has an equal position, normal vector and UV coordinates they may have different tangent space.

The D3D9Client could easily reconstruct the mesh however after that every attempt to edit the mesh with oapiEditMeshGroup() would fail. But, of course, the surface base meshes are unlikely edited via oapiEditMeshGroup().

The most reasonable work-a-round is to replace it with normal mapping compatible mesh by spliting the vertex that's causing the glow.

 

[n122vu]

I'm still getting sent to my own albums when clicking on the images above.

 

[orb]

I'm still getting sent to my own albums when clicking on the images above.

The links in the latest Astronut25's post here have been fixed now.

 

[Veterok]

Will you be adding normal map support for planets and moons soon?
I spent a few hours figuring out how to convert planet textures from celestia (up to lvl 8 anyway)

We are go for depth!
http://imgur.com/6OFkP

 

[Veterok]

I poked around in the source on bitbucket, and I can see why normal mapping is coming to planets last, There's a lot going on with the LOD system for planets.

My thoughts on it were to store normal maps in the same .tex format as planet textures, so you would have a moon_tile_norm.tex. Then you can reuse* most of the TileMgr code. While making it manage two tilesets, you might as well make it 'n' tile sets, to support specular and night light maps at the same level.

And displacement maps if you're moving development to the new fork. What's the plan there?

*Please be advised that nothing found here has necessarily been reviewed by people with the expertise required to provide you with complete, accurate or reliable information.