Project D3D11Client Development
- Thread starter Glider
- Start date
Weirdo Earthtorch
Member
- Joined
- Mar 23, 2008
- Messages
- 165
- Reaction score
- 0
- Points
- 16
I've made some changes - can you please get latest version and give it a try?
Are you trying to run in fullscreen? I'm also on Win7 64 Home Premium, Intel HD graphics. I was seeing the same (and a lot of other weird shadows/colors if I changed settings) until I switched to windowed mode on the video tab. I remembered that the installation instructions said fullscreen wasn't working yet. Just a suggestion.
Ripley
Tutorial translator
- Joined
- Sep 12, 2010
- Messages
- 3,133
- Reaction score
- 407
- Points
- 123
- Location
- Rome
- Website
- www.tuttovola.org
I've just translated today the D3D11 install instructions for my website, and there was exactly written that "currently fullscreen is not supported".
Weirdo Earthtorch
Member
- Joined
- Mar 23, 2008
- Messages
- 165
- Reaction score
- 0
- Points
- 16
Unfortunately no difference in limited testing so far.
n122vu said:
Thanks for the suggestion, no it's not in fullscreen, I recalled seeing the info that fullscreen was not yet supported, and in fact the fullscreen option is greyed out and not selectable. I tried running at a lower window resolution with no change. I've tried all the visual parameters enabled/disabled, and whilst it makes some difference (weird colours on runways/water) I still get the same issue of the global texture seemingly overlaying the base texture/runways etc when the camera gets to a certain altitude.
It's really puzzling. I'll keep plugging away testing, and it's interesting to note that n122vu had similar issues with the HD3000 graphics. Incidentally I'm on the Intel 8.15.10.2656 driver which seems to be fairly stable for both D3D and OpenGl apps. Also of interest is that the D3D9 client (for 111105) seems fine using exacty the same scenarios.
For me the fullscreen option wasn't initially grayed out. In fact at first it was selected by default, and I could select resolutions on that side, but there were no labels on the left checkboxes. Once I selected Windowed Mode, the left side became grayed out and unselectable.
dumbo2007
Crazy about real time sims
Is it something to do with loading lower LOD textures after the camera is a certain distance away. Maybe the client is not finding it. Perhaps look at the texture calls for the particular camera distance.
Is there a sharp altitude at which the runway textures always disappear ?
Is there a sharp altitude at which the runway textures always disappear ?
Weirdo Earthtorch
Member
- Joined
- Mar 23, 2008
- Messages
- 165
- Reaction score
- 0
- Points
- 16
It's not an exact distance, and varies with position on the surface, and with the body itself. For Earth, it's about 190m camera altitude. It seems to switch on the reflective (specular?) water textures on Earth too.
Half an hour with the scenario editor, and I checked all default solar system bodies. It occurs on Earth, Moon, Mars, Mercury and Venus. The common denominator for me is maxpatchresolution. For all those bodies, it is 8 or greater. For all the others, it's 4-7. Mercury is particularly bad (surface not visible til c.800km alt), possibly because it is the demo terrain body. Terrain demo, when enabled, works fine, but shows similar near-surface characteristics. Maybe something to do with the terrain generation?
Last edited:
Screamer7
Member
The XR2 and Delta glider behave strange in the D3D11 client environment.
The speed tape and altitude tape fluctuated up and down as my speed increase.
The flight director also does not stay center.
It is almost if I flew in a turbulence atmosphere.
In the D3D9 client this does not happens and everything behave smoothly.
Is this a feature of the D3D11 client?
The speed tape and altitude tape fluctuated up and down as my speed increase.
The flight director also does not stay center.
It is almost if I flew in a turbulence atmosphere.
In the D3D9 client this does not happens and everything behave smoothly.
Is this a feature of the D3D11 client?
No, this is a (incomplete) "feature" of beta version called "wind". If you don't like it, go to settings and turn it off.
Screamer7
Member
I like it. It makes the flight feel more "energetic".:thumbup:
Cras
Spring of Life!
- Joined
- Apr 13, 2011
- Messages
- 2,215
- Reaction score
- 0
- Points
- 36
- Location
- Los Angeles
- Website
- www.youtube.com
2000 + 10x + y
* x > 0
** if x = 1 then y > 1
* x > 0
** if x = 1 then y > 1
Frogisis
innn spaaaaace...ace...ace...!
- Joined
- Aug 13, 2008
- Messages
- 185
- Reaction score
- 0
- Points
- 31
- Location
- Chicago
- Website
- www.frogisis.com
Other than eternal tweaking and bug hunting, what is there mainly left to do on it? Terrain and clouds seem like they're getting there, and Dansteph is working on getting the DGIV ready, but is there other graphics stuff still to be addressed, or major under-the-hood stability and performance ideas left to be implemented, or, barring feature creep, are you mainly just tying it all together?
We've gotta wait for Glider as it's mostly his show - I was just consulting and bug-fixing, as well as working towards improving general stability and compatibility.
Here is the situation as I see it:
1. New atmosphere rendering engine seems to be in good shape, but currently it's working for Earth only. Glider has mentioned that this engine can be adapted to other planets' atmospheres too, but I'm not sure about the effort needed to achieve that.
2. Terrain engine seems to be working, however there is a whole host of issues that is mostly related to the fact that Orbiter physical core does not support terrain. Among those are:
- collision detection/response. This is mostly research issue - we're trying to figure out a way calculate response force based on what vessel parameters are (lateral and angilar speed/acceleration, current orientation, wether the gears are down or not, and so on).
- dealing with bases. This is a very big issue and a main showstopper. The problem is that Orbiter assumes that the terrain is flat, and so do all of MFDs and auto-pilots. So while rendering bases on top of terrain is not that big of a problem (bases can be shifted up/down based on the underlying terrain), all navigation devices that use altitude(MFDs, HUD, auto-pilots) can not be fixed. And it's not just a matter of feeding "new" device to these devices, some of them (for example autoland autopilot, ILS/VTOL MFDs) have to take terrain curvature into account.
- Orbiter does not allow to go below "sea-level". While this isn't that big of a problem for the Earth (as far as I know there is just one place on Earth where you can actually fly below sea level, and actual local sea level there is around -200m), it is a big problem for other planets/moons. For example, the territory underneath Moon's Brighton Beach base is in negatives, which means base and vessels are up in the air. And while bases can be fixed, vessels can not go below zero altitude, so we're stuck here big time.
Let's wait for Glider to give us his outlook on a situaton, but the way I see it until we solve aforementioned issues there is no point in releasing the client...
Last edited:
Frogisis
innn spaaaaace...ace...ace...!
- Joined
- Aug 13, 2008
- Messages
- 185
- Reaction score
- 0
- Points
- 31
- Location
- Chicago
- Website
- www.frogisis.com
Cool, thanks for the update.
When I was playing around with Orulex earlier, I saw a thread where Artlav suggested the idea of reducing the radius of a planet so its "sea level" was equal to the lowest point on the terrain map, and that way there'd be no negative terrain, so bases would always be in craters instead of on weird Devil's Tower-style plateaus, and you wouldn't hit an invisible floor if you tried to land on very low terrain. I tried this on the moon, reducing its radius in the .cfg file by about 3.8km after scouting around in World Studio, but the terrain just shrank along with it to maintain the relative elevations - which is obvious in retrospect - so I gave up because it wasn't that big an issue.
But I can see conceptually how it would work, and it seems like a simple enough way to get the bases to be landable and look right. I don't know enough about how the data gets from the sim to the MFDs, but since there's collision data for the terrain, and things like Sensor MFD that can spot objects, maybe a workable solution would be a special "radar altimeter" MFD that somehow visually represents that collision data, which you'd use when landing on "natural" terrain the same way you'd use the sea level-calibrated VTOL MFD when landing at a base.
Or maybe something better than either of those ideas which you've already thought of.
When I was playing around with Orulex earlier, I saw a thread where Artlav suggested the idea of reducing the radius of a planet so its "sea level" was equal to the lowest point on the terrain map, and that way there'd be no negative terrain, so bases would always be in craters instead of on weird Devil's Tower-style plateaus, and you wouldn't hit an invisible floor if you tried to land on very low terrain. I tried this on the moon, reducing its radius in the .cfg file by about 3.8km after scouting around in World Studio, but the terrain just shrank along with it to maintain the relative elevations - which is obvious in retrospect - so I gave up because it wasn't that big an issue.
But I can see conceptually how it would work, and it seems like a simple enough way to get the bases to be landable and look right. I don't know enough about how the data gets from the sim to the MFDs, but since there's collision data for the terrain, and things like Sensor MFD that can spot objects, maybe a workable solution would be a special "radar altimeter" MFD that somehow visually represents that collision data, which you'd use when landing on "natural" terrain the same way you'd use the sea level-calibrated VTOL MFD when landing at a base.
Or maybe something better than either of those ideas which you've already thought of.
I've offered this solution to Glider, but he shot this down because this will make terrain unreal (for example Olympus mountain on Mars would be 40 km high instead of 25km, and this difference makes flying around its top unreal - while atmosphere is thin at 25 km already, it's virtually non-present at 40 km, so you can't fly at 40 km). Not to mention that bases' issue still won't be solved.
I actually think of a different way - simply "blend" terrain around bases so it would be at sea level around them allowing for all landing-related gear to still work. And create a new Surface MFD which would display current real altitude along with "sea-level" altitude. BTW this is similar to the way it's done on a real jets - there is a barometric altimeter that shows approximate altitude based on a atmospheric pressure, and "radio-altimeter" that shows real altitude.
Similar threads
