New Release D3D9Client Development

[jarmonik]

A note on the sunset/sunrise effects in the beta version of D3D9Client. There's still too much yellow. This is screenshot from D3D9Client Beta 11:

It shouldn't be yellow like that. Re-install the client and make sure that every file is replaced. The yellow is likely a result from some old files not being replaced.

---------- Post added at 04:54 ---------- Previous post was at 04:08 ----------

For some reason, using a normal map on a surface will slightly corrupt the specular reflection. This fix re-calculates the z-axis based on the x and y axes, which are unaffected.

The same problem is present on vessels, too.

Yes, there is something going on with a normal maps. It would seems that a vector obtained from a normal map isn't a unit vector. I suppose, it might be practical to create an algorithm to pre-compute the blue channel when a normal map is loaded.

---------- Post added at 06:53 ---------- Previous post was at 04:54 ----------

Seem to have found something with the latest version of the client for 2010p1, I am not at all sure what the cause of it can be, haven't really done a lot of process of elimination yet, but what I am seeing is:

I load up a scenario with Shuttle Fleet in LEO, about 430km, not sure that matters. I have a few MFDs open in the VC, Orbit MFD, Pursuit MFD, GPC MFD, Sync Orbit, and Burn Time Calc.

I set the shuttle to be in an intertial attitude hold, NOT an LVLH hold. Then I set the time acceleration to 100x. When the sim is loaded I am at something like 500 fps. And as the sim goes, and the shuttle keeps flying around the earth, I see the frame rate drop at a pretty fast rate then as time goes, a bit slower, and it then bottoms out at about 70fps or so....so there seems to be something going on that is kill the frame rates...this I dont think is linked to Ext MFD or anything...maybe it has something to do with the VC MFDs I am not sure, but I found it odd how the frame rate degrades over time, and not in just a single burst that can be linked to when a certain mfd is turned on like before.

Does the same occur with stock Delta Glider with default MFDs ?

You can also view some statistics by pressing [Ctrl+Shift+C]. All values except "Tile Count" should be pretty stable (i.e. not increasing). Also, it's a good idea to check the D3D9ClientLog and see if there are any un-released sketchpad objects reported in the end of the log.

We would need a better diagnostics display to track a resource usage and loading. As well as execution times of some code sections. Some of that should be implemented on Orbiter's side to measure an amount of time spend in MFDs, HUDs, etc...

 

[Cras]

So I was messing about with this problem again, I looked at the statistics on CTRL SHIFT C, and the values all were pretty stable (except for Tile count as expected)

But here is what I found. The frame rate in the sim is stable...UNTIL I alt+tab out of it. When I alt + tab in it will most likely cause the cascade FSP drop. I say most likely because I tried it a few times and the first couple attempts all caused it right when I tabbed back into orbiter. The last time I did it the first attempted seemed to have no effect, as the frame rate was still up in the mid 400s as expected....but the second time I saw the frame rate cascade. This is with the full screen window mode, which is what I have used for many versions of D3D9 client. I am gonna try a default DG scenario and see if the alt+tab causes the same thing to occur.

---------- Post added at 12:49 AM ---------- Previous post was at 12:39 AM ----------

Couldn't get it to occur with the stock DG. I edited my Shuttle Fleet scenario so to not have any MFDs on, and it still occurs, and it doesnt seem attached to time accelerations, under normal 1x speed the frame rate cascade still occurred after 2 alt+tabs.

---------- Post added at 05:01 AM ---------- Previous post was at 12:49 AM ----------

Still not sure what causes it. I had the sim run for a while without any alt-tab and the frames eventually dropped, then I restart the computer and had the sim run, and the frame rate drop never occured. There have been issues in the latest version of the sim not closing fully, sometimes it hangs and I have to go into Task Manager to kill the process, maybe that has something to do with it, so far I haven't been able to link any action inside the sim to causing the frame rate drop.

 

[kuddel]

Please Help! Orbiter NG no graphics
Running in server mode (no graphics client attached)
I don't have any ideas why this is happening: am I missing a flash player, is my graphics card the problem, did I install it wrong?
I need to fix this problem to do a project for science fair and its due in less than a week, we were supposed to get to Mars but this happened.
Please help, thanks!

Hello xN0xM3RCYx310,

1. Welcome to the forum.
2. If you are in such a hurry (...less than a week...) why don't you first start with the "inline" graphics client? That is by running "orbiter.exe", not "orbiter_ng.exe"
3. You should *read* the documentation(s)! If you like to run Orbiter with an external graphics client (e.g. D3D9Client) you have to do some more 'setup'.
   a) download a graphic-client
   b) 'install' that graphic-client
   c) run "orbiter_ng.exe" and select the graphic-client under the "Modules" tab.
   d) possibly you like to tweak some settings of that graphic-client as well
4. I recommend to KISS[1] and try "orbiter.exe" (with the inline graphic-client)

Nevertheless, good luck with your project


[1] [ame="http://en.wikipedia.org/wiki/KISS_principle"]K.I.S.S.[/ame] (Note, that the last 'S' of KISS is not something I would call you )

 

[Felix24]

Yes, there is something going on with a normal maps. It would seems that a vector obtained from a normal map isn't a unit vector. I suppose, it might be practical to create an algorithm to pre-compute the blue channel when a normal map is loaded.

At present, the fix (hack) re-computes the blue channel on the fly, but I agree that doing it all at once when the map is loaded would be more efficient.

Could it be the program I'm using to generate the normal map is not doing it correctly, i.e. making it such that the vector isn't a unit vector? I'm using the Normalmap plugin (v. 1.2.3) for GIMP. https://code.google.com/p/gimp-normalmap/

 

[jarmonik]

One thing that will give a slightly better results is:

cNrm.xy = cNrm.xy*2.0 - 1.0;

Leaving the z channel (blue) unbiased since it can be only a positive in a tangent space normal maps. But the specular reflection still remains a little dim but it's brighter that with all channels biased.

Maybe the blue channel is not supposed to be biased or what do you think ?

---------- Post added at 07:04 ---------- Previous post was at 06:55 ----------

[/COLOR]Still not sure what causes it. I had the sim run for a while without any alt-tab and the frames eventually dropped, then I restart the computer and had the sim run, and the frame rate drop never occured. There have been issues in the latest version of the sim not closing fully, sometimes it hangs and I have to go into Task Manager to kill the process, maybe that has something to do with it, so far I haven't been able to link any action inside the sim to causing the frame rate drop.

How long you need to be in orbit until the frame rate starts to drop ?

Currently there seems to be an error in unloading of surface tiles so, a frame rate drop may occur after running out of on-board video memory. But that's unlikely the source of the problem in this case.

How much memory is spend for surface tiles and how much free memory there is ?

---------- Post added at 07:08 ---------- Previous post was at 07:04 ----------

Could it be the program I'm using to generate the normal map is not doing it correctly, i.e. making it such that the vector isn't a unit vector? I'm using the Normalmap plugin (v. 1.2.3) for GIMP. https://code.google.com/p/gimp-normalmap/

I wouldn't blame it. Adobe Photoshop with nvidia plugins is creating similar results.

 

[Cras]

2.5 GB of free video memory give or take a bit.

I was messing about again to try and find a correlation, and I might have found one....

I unchecked the 'enable geometry instancing', and the frame rate cascade didnt occur.

However, when I alt tabbed out and back in, there was a frame rate hit, but the frame rate would remain pretty constant, so like, it would be running at 300 or so...steady. Alt tab, and now it is down to low 200s, alt tab, down to 120 or so, alt tab, down to 90.

It seems that once running the sim for the first time on a computer boot, I can be in orbit for quite some time before I see the cascade. As I shut orbiter down and reload it, the cascade will happen sooner and sooner, so it did suggest to me maybe to be a memory thing, something leaking somewhere, but the free video memory remains awfully high. Lemme run the sim again and see what is going on with memory for surface tiles.

---------- Post added at 01:27 AM ---------- Previous post was at 01:19 AM ----------

took a screenshot of the data after the frames dropped down to under 100....

it is hard to judge a time when it happens, but alt-tab does seem to be a reliable means to cause it to happen, even though it will happen without it given the time to run. As you can see, this is only 15k or so timesteps, most at 10x time acceleration so wasnt running for very long.

 

[jarmonik]

Does the geometry instancing have any effect to the frame rate when it is running properly ?

The screen shot reads that a texture allocation is 888MB and that's a pretty lot. Any ideas what causing it ? I suppose a high resolution surface base tiles could contribute a lot into the value. Total amount of video memory used is above 1GB. The "Available video memory" also includes a system memory that is shared with a display card which is likely much slower than on-board video memory. So, how much memory there is on the display card ?

 

[Cras]

With geometry off the frame rate was around the same, if anything spiked about 10 frames higher than before.

I am wondering if it is just this scenario, it has Shuttle Fleet with which I have added reflective surfaces to the radiators and windows, added a bump map, the space station is also quite large with various docked vessels and 5 solar panels from MBR ITS which contain an enourmous amount of verticies for the unfolding animation.

The total Vidmemory on this GPU is 4 GB, I am using the high res Earth that martin put out, along with his Hi-res KSC package he put out a few years ago.

I didnt see this in a scenario with just the stock DG in it, but there seems to be something with having a lot of stuff in the scenario that causes some sort of memory leak, something I dunno. It is just this is a rolling scenario situation, and I have been flying the Shuttle to this particular space station for a while now and hadnt experienced this kind of frame rate cascade before. I am gonna try to roll back the client to an earlier version later today and see if it happens again. Try to determine if it is a client issue, or maybe there was something done in this scenario, added a vessel or something, that causes this effect.

I might seem to be pulling at strings but I am having a very hard time trying to find a pattern here as to this sideffect.

---------- Post added at 08:50 PM ---------- Previous post was at 02:59 PM ----------

Well, it is not the geometry instancing, as I just saw it occur with that box unchecked. I then thought it might be the day/night transition, but that was not the case. Then I thought it might be something with the VC, since I noticed when I changed from the aft workstation location, back to the left seat, the MFDs that were open 'flickered', and the frame rate dropped, but when I tried to recreate it, I did recreate the flicker, but not the frame rate drop, so that isnt the issue either.

 

[jarmonik]

Sounds like the geometry instancing was a big failure, so, it will be removed. A Literature of a modern GPU computing often states that a frame rate is more depended on draw call count rather than number of vertices processed. That doesn't seem to be entirely accurate.

1.) Could you confirm that the frame rate drop doesn't occur with the inline engine.

2.) Could you pay some attention to scene rendering time that reads about 6000us in the screen shot. What does it read when the frame rate is good ?
1/6000us = 166FPS

3.) Could you turn off reflections and custom cameras.

 

[Cras]

Cant confirm it in the inline engine as my frame rate performance is so bad I never really see a drop, it is around 20 and it just bounces up and down from there.

I did roll back to R12, which was always rock solid stable for me over a many many hours of Orbiter flight, and I was able to get the frame rate to cascade via several alt-tabbing as well, so it is not a geometry instancing issue at all. Turning off reflections and custom cameras has no change as well, other than just a higher starting frame rate.

I am starting to rip various vessels I have in the scenario out and see if it is something going on with an add-on and this is not a D3D9 client issue at all.

---------- Post added at 11:22 PM ---------- Previous post was at 05:36 AM ----------

Ok, I think I finally figured it out. It is this add on:

[ame="http://orbithangar.com/searchid.php?ID=4682"]Antares Manned Spacecraft 2.51[/ame]

I have an Antares RV docked to the space station, which is a relatively new addition to the scenario. I have ran it a couple times now, and when the frame rates cascade, I delete this vessel from the scenario and it immediately reverts the frame rate back to where it should be. I am gonna try a few more things to see if I can confirm this a bit more, but I feel this is the culprit.

I noticed that in the new version something was added to the D3D9 client that all of a sudden made some of the gauges in the Antares VC to come alive, gauges that had long remained blank in the D3D9 client, but now they work, maybe the way they are being allowed to function is causing this cascade effect.

 

[Felix24]

One thing that will give a slightly better results is:

cNrm.xy = cNrm.xy*2.0 - 1.0;

Leaving the z channel (blue) unbiased since it can be only a positive in a tangent space normal maps. But the specular reflection still remains a little dim but it's brighter that with all channels biased.

Maybe the blue channel is not supposed to be biased or what do you think ?

I think all channels should be biased. Biasing only the x and y causes the light and dark spots to reappear. Even though the z-channel would (almost) always be positive, it should still be scaled correctly because the transformation matrix is expecting a unit vector.

I say "almost" because even though a positive z-channel is most common, applying a normal map with an inverted z-channel to a surface makes sense if the surface is illuminated from the back. Combined with texture maps, this can be used to simulate the sun shining through translucent material like the ISS solar panels. I made a proof of concept about a year ago (http://www.orbiter-forum.com/showthread.php?p=452811&postcount=2673) which used this technique, and I think it's worth developing further. A side benefit would be that when dynamic shadows are implemented, the translucent textures should already play nice with the shadows. Shadows cast on the sunlit side of the translucent surface would be visible on the opposite side.

 

[fort]

Two others d3d9ocean.dds in a "crossingwaves style" ? a liittle bit smoothed comparing to the previous one ( your's jarmonik and the one made, i think, by Felix24 ).I wanted to see ,with the d3d9ocean2.dds included in the zip, if it was possible to have another color ( with some green ) for the water but it seems ( i tried to find a cfg for that... ) that not.

 

[Spacethingy]

Using client Beta 11 with Orbiter beta 28th Feb release: terrain seems to cover landing pads, which is doesn't in the stock client:

I don't understand the FPS boost that the client gives me. The stock client pulls about 15 FPS with the scene, the DXD9 client gives me about 80-100! :thumbup:

 

[jarmonik]

I think all channels should be biased. Biasing only the x and y causes the light and dark spots to reappear. Even though the z-channel would (almost) always be positive, it should still be scaled correctly because the transformation matrix is expecting a unit vector.

That's fine by me. Although, normal map export utilities seems to assume unbiased z-axis. So, normal maps would need to be pre-processed during loading to fix that.

I say "almost" because even though a positive z-channel is most common, applying a normal map with an inverted z-channel to a surface makes sense if the surface is illuminated from the back. Combined with texture maps, this can be used to simulate the sun shining through translucent material like the ISS solar panels. I made a proof of concept about a year ago (http://www.orbiter-forum.com/showthread.php?p=452811&postcount=2673) which used this technique, and I think it's worth developing further. A side benefit would be that when dynamic shadows are implemented, the translucent textures should already play nice with the shadows. Shadows cast on the sunlit side of the translucent surface would be visible on the opposite side.

The translucency effect sounds great. But I don't quite understand the need of a negative z-axis in a normal map. Or, are you thinking about having two different normal maps for a surface ? (i.e. an other map for a translucency.)

---------- Post added at 18:42 ---------- Previous post was at 18:40 ----------

Using client Beta 11 with Orbiter beta 28th Feb release: terrain seems to cover landing pads, which is doesn't in the stock client:

I suppose we could wipe the z-buffer clean after rendering the terrain. That should prevent issues like that.

 

[Felix24]

The translucency effect sounds great. But I don't quite understand the need of a negative z-axis in a normal map. Or, are you thinking about having two different normal maps for a surface ? (i.e. an other map for a translucency.)

Yes, I think there would end up being two normal maps for a surface, one for direct lighting and one for translucent lighting. I originally only used one which would switch depending on which way the sun was shining, but two would be more accurate.

They wouldn't need to be loaded as two separate maps, though; the normal map could be loaded twice, once normally and once inverted.

 

[JMW]

https://www.dropbox.com/s/2qzomam120fv1cx/Screenshot 2015-03-04 20.10.24.png?dl=0

Yeah, I think this is taking Total Immersion too far !! :rofl:

Keep up the great work fellers.

 

[Felix24]

Puzzling issue:

I start Orbiter_ng with D3D9, and run the Atlantis cockpit scenario in the Space Shuttle Atlantis folder, and press F1 to view outside. I move my joystick around, the RCS fires as it should, but the payload bay doors become animated like ailerons. Full right closes both doors quickly, neutral opens the starboard door and leaves the port door closed, full left opens both doors.

Does this happen to anyone else? It only happens to me if it's the first scenario I run. It also does it on the Atlantis MMU Satellite Repair scenario.

 

[GLS]

Puzzling issue:

I start Orbiter_ng with D3D9, and run the Atlantis cockpit scenario in the Space Shuttle Atlantis folder, and press F1 to view outside. I move my joystick around, the RCS fires as it should, but the payload bay doors become animated like ailerons. Full right closes both doors quickly, neutral opens the starboard door and leaves the port door closed, full left opens both doors.

Does this happen to anyone else? It only happens to me if it's the first scenario I run. It also does it on the Atlantis MMU Satellite Repair scenario.

I recall I had a similar issue some time ago... the thing is I don't remember with what and where :facepalm:. It might have been the Orbiter beta, not sure... but it was definitely with the stock shuttle. Also, no joystick here, that happened with the keyboard RCS buttons.

 

[Felix24]

I recall I had a similar issue some time ago... the thing is I don't remember with what and where :facepalm:. It might have been the Orbiter beta, not sure... but it was definitely with the stock shuttle. Also, no joystick here, that happened with the keyboard RCS buttons.

This is with Orbiter Beta, and I found it also does it when I control the RCS with the keyboard.

 

[Abloheet]

Yup, happens with rcs as well as aerodynamic control surfaces