-
Posts
591 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Everything posted by mhe
-
I think once the Rift consumer version is out, we will see drastic decreases of Eyefinity and Surround setups in the wild. The Steam hardware survey would be very interesting to monitor for these stats.
-
Of course venture capital is a nice thing to have when doing R&D, but if there would be no feature complete dev kit, how is a developer supposed to ensure his game is working perfectly with the consumer version of the Rift? If the devs would pay for them like they did with the previous kit, money wouldn't be an object.
-
And rightly so. I'm very much looking forward to the announcement of the second developer kit version (which I assume must come as the current DK is not feature-complete).
-
I very much believe VorpX will enable us to fly with the Rift without too much hassle with screen configs and the like...
-
I think I cracked the problem. The multiple force vectors can be viewed as accelerations instead of speeds. If the acceleration is zero, the applied force is zero too. Therefore angles are not relevant as long as all velocities of both wind and aircraft remain the same. So my mental model only applies if the equilibrium is disturbed, but not if everything remains as it is. Thanks, HugePanic! Harzach: That book has been on my reading list for quite some time now, you just reminded me of that and made me order it. OzStriker: Sorry buddy, you were right after all. All I needed was an explanation. :)
-
I may be wrong, but as stated before, I'd love to know the reasons for it being so. I have my problem with the ship analogy, as water is uncompressible and therefore hardly comparable to air. And yes, the ship will be drifting. Chances are, it will also rotate a bit while drifting. And it is this rotation/yaw that causes all the other things I stated in an aircraft. All these theoretical sidedrifts without rotation stem from a simple vector model where one assumes that all the forces act on one point (which is very convenient mathematically), but once you look into forces acting on different points with different grades of "efficiency" (because wind and water can simply put more force on an object the more friction/drag there is), things get a lot more complicated. As said, I have no problem with being proven wrong, I love standing corrected. But I refuse to accept that something is wrong just because one guy says so without giving any reason whatsoever. Let's just say I have an academic interest in the topic. ;)
-
Ok, so your argument is "I am so great and knowledgeable and you are wrong". If I am so wrong, please correct me. Communities are there to share the knowledge you know. ;) I love constructive criticism as it enables one to learn. If you want me to shut up, prove me wrong with substance instead of just claiming the high ground by default. You have yet to come up with anything of substance to do so. The drag of an aircraft's side profile is not the same over the area, thus a crosswind force will be more absorbed on one point than the other. If the tail is pushed harder sideways due to it having more drag seen from the side, it will result in the aircraft slightly yawing, the banking will be the result of previously stated effects. And while we are at it - applying aileron trim to a unbalanced aircraft will result in unbalanced lift to counter the unbalanced masses. This is great, but asymmetric lift also creates asymmetric drag, which will in turn have to be countered by rudder/rudder trim.
-
So you cannot make sense of what I'm saying but yet you claim that everything I say is wrong? :huh: I smell trolling... ;)
-
Care to explain your "argument"? A perfectly trimmed aircraft will not weathercock, that's right. But that is only true for perfectly static wind conditions where you counter cross wind drift with the perfect amount of wind correction angle. And these theoretical conditions rarely occur in reality, bar from perhaps a simulated environment. But go ahead and do the test I suggested. ;) An aircraft not experiencing any attitude change from crosswind would mean it would have to follow any fluctuation in windspeed perfectly, meaning it would have to have no inertia whatsoever.
-
Actually it is not only windshear, it is wind itself. An aircraft in a crosswind has the tendency to yaw its nose into the wind. This comes from the cross-section profile of the aircraft with the tail being very large and being pushed harder from the side than the rest of the aircraft. If you have a yaw-moment into the direction the wind is coming from, the outer wing will have a slightly higher airspeed than the inner wing, resulting in the outer wing producing slightly more lift - therefore the aircraft slightly banks to the inside of the turn. You have the same effect of aileron and rudder being "linked" aerodynamically - step on the rudder only and the aircraft will bank as well. Try it out - fly an empty aircraft straight and level in a crosswind, trim it out perfectly. Then reverse your heading 180 degrees, wings level and let everything go. If your assumption of wind direction being of no significance would be right, the plane would fly perfectly straight. But in fact it isn't. Try it at about 20 knots crosswind enroute for example, you will notice the difference. But yes, an asymmetrically loaded plane will either counter this effect or make it much more pronounced, depending if the asymmetry makes the plane roll into the direction the wind is coming from or not.
-
You could also use a RamCache instead of a pure ramdisk. Doesn't catch the first disk access, but will store the accessed blocks in memory until the allocated memory is full. So you can rest assured that nothing is cached that is not used, but it doesn't load as fast as a real ramdisk the first time of course. I use FancyCache (and an SSD) and have not have any troubles with stutters or anything like that. The sim just performs flawlessly (until somebody drops multple CBUs that is, but that's another story). RamCaches are simply almost as good but are much less trouble in terms of tweaking.
-
Nope. No 3D, this doesn't work properly. As said, you need both viewpoints to be slightly off-center, like the human eyes. Diverging the view angles is not the way to go. You want it to be like this: What you've basically linked in the vids instead are 2 eyes merged into one, emulating squinting to the outside. Not very good in the Rift. We need ED to let us configure the viewports per eye independently, that would solve all problems as we could even configure things like IPD ourselves. Then they would only need so allow us to use the barrel distortion shader on a per-viewport basis and we're good.
-
Oculus just announced that they got 16 million US$ investor money (besides other money I'm sure they got from the guys endorsing them in their previous Kickstarter video) which will allow them great purchasing power for future endeavours. The future of gaming sure looks exciting. Since this thread has become on of the top 5 in terms of posts in this subforum, it might be good to see some ED folks having a more or less official word about it. The low res problem has been somewhat fixed and quality will increase even more over time, visibility of the keyboard is possible via the lower air vents etc. So basically every possible problem for this device to be very very viable for flight simulation is fixed within very overseeable timeframes. And if integrating their SDK is as easy as they claim, it might be a must-have for DCS. Perhaps when EDGE comes out... If you do a new rendering engine, you might put in stereoscopic support as well. Even if you make me pay me extra for it (EDGE 3D or something), but damn I want it...
-
For those who didn't watch the video, here is a still showing the difference concerning the screen door effect between the current developer version and the HD prototype:
-
There is support hacked together with Vireio and FaceTrackNoIR for FSX, War Thunder supports it, also there is already a beta of a user-made plugin for X-Plane. And perhaps VorpX will work fine with DCS (if the HUD is made to work correctly with stereoscopy, if not, there is always the inferior but more compatible Z-Buffer approach). Got my shipping e-Mail last night, UPS says I'm going to receive my Rift on monday! :D Getting native support for DCS is a must have. There are plenty of things where the keyboard doesn't matter as much. Imagine being the door gunner on the Huey in MP while wearing the rift. Hell yeah...
-
There ya go, closeups of the current and the HD display next to each other. :thumbup: (At 2:45)
-
Um das Update Problem in den Griff zu bekommen kann ich nur empfehlen die Monitor LUAs und die Init Luas der exportierten Instrumente in JSGME Mod Packages zu packen. Wenn also ein Update kommt, dann drückt man zuerst auf Cancel, geht in JSGME, deaktiviert alle Mods. Dann updaten, mittels JSGME mal drüberschauen welche Files das Update geändert hat (Snapshot sollte man immer aktuell haben!) und dann weiß man eh was Sache ist. Danach die ganzen Mods wieder aktivieren. Zeitaufwand keine 10 Minuten (exklusive Downloadzeit, die je nach Serverlast beträchtlich sein kann). Das Problem mit der woanders liegenden Export.lua ist mit dem letzten Helios Build auch gefixt, beim schwarzen Bildschirm muss ich noch testen.
-
Sign me up for the Rift formation flight! Mine is in processing state, will get it when the next batch ships.
-
Can someone tell me if Visib range is the main FPS killer?
mhe replied to Dudester22's topic in DCS World 1.x (read only)
It will only show an increase in quality when you zoom in to the MFCDs so that they will half the screen. Every frame will sync the update rate of the MFCDs to the framerate of the sim, so it will result in additional load for the engine and hence lower FPS. I achieve great results with 512 and every frame off. -
Can someone tell me if Visib range is the main FPS killer?
mhe replied to Dudester22's topic in DCS World 1.x (read only)
Yes, increasing the resolution will make things more crisp, the difference can be seen if you zoom in to the displays or use exports. -
Will that be a library I can use directly in the Arduino IDE with a simple include-statement? Because that would be awesome! It would make it very simple to make standardized code for Arduinos that could be configured by setup variables to acommodate every setup out there. But given the fact that an A-10C has lots of dial gauges, there will be a fair amount of stepper motors (and shields to drive them) required.
-
Well if looking down is desperately needed, I'm sure it can be made possible by modding the hardware a bit if it doesn't give you that capability right out of the box. :)
-
QNH is the calculated pressure at sea level with the base of the calculation being a measurement at the airfield giving you the QNH. So if you enter the QNH correctly, your altimeter will display the elevation of the airfield above sea level. The 29.92 you enter into the A-10C's altimeter is a setting in inches of mercury (29.92"Hg is equal to 1013.25 hPa or millibars). This value can be either QNH or QFE. So when an airfield measures let's say 1000hPa locally and it knows it is 1000ft above sea level, it then calculates the QNH by using it's known elevation as steps for hPas. In lower altitudes you can assume 27-30ft altitude per hPa (it depends on many factors like temperature as well). Let's take 30ft per hPa. So if you are at 1000ft from sea level, your pressure should drop 1000/30 hPa -> 33.33hPa. So if you add this to your local measurement, you end up with 1033hPA as your QNH. If a pilot enters this into his altimeter, it will read the field elevation. 1000is your QFE, meaning that when the pilot enters QFE into his altimeter, the altimeter will read zero when on the ground. Don't know why there is only 720 from 790 as choosable value, I assume that depends on the airfield elevation you work with. I don't play around much with the mission editor, so can you assign QNHs to each airfield or is it a global setting? Also, the values would suggest to me that these are rather QFE than QNH values for higher airfields, as QNHs are typically values from approx. 980 to about 1030. At least that's how it is in civilian aviation in the real world.
-
I have 3 Leap Motions on pre-order. Once they arrive, I will give them a thorough workout in DCS and report my findings. :)
-
The keyboard issue seems somewhat overblown - the GameStar hands on review from 2 days ago mentions that you are able to peek down past your nose to look at the keyboard (but that might depend on the form of your nose). :) As for 3x27" vs Rift: You can't compare fov in sheer numbers because the FOV generated by a triple screen setup varies with viewing distance and the angle the outer screens are positioned at. You also cannot compare DPI of the display panels as that again produces different results with different viewing distances. So it all comes down to pixels per angular minute or second when comparing displays. You can calculate these with a tangent function and you will come up with the result that the picture in a 3x27" FullHD setup will be much more crisp because there are vastly more pixels drawn over a much smaller area in your personal field of view. But since immersion is much harder to quantify (and does NOT represent graphic quality), it is rather pointless. Since immersion is a very individual thing and people respond very differently to different forms of stimulus, it all boils down to what works for who. Some people's brains respond very positive to convincing aircraft sounds, others need high end graphics, even others need that every switch must do what the original aircraft's documentation says it does. Before we discuss what is more immersive and why, we would have to come up with a quantifiable score for immersion and since that is down to the individual, the only way to keep that score is by reviews of users having tried the thing. And the response is very positive, even from people who own triple screen setups. Of course everyone acknowledges the downside of the low resolution of the technology in its current form, but that problem will go away with time. Once the resolution problem is solved and you have perhaps a bit more resolution than needed, you have some leeway for playing with the optics, stretching the FOV even farther. And FOV not only means horizontal or diagonal, it means vertical FOV as well (although the vertical FOV on the current Rift is slightly higher than the horizontal per eye). In DCS usage, the Rift might be fun for simple flying around or doing air races in a Mustang, for combat you currently have the issue of resolution (and that holds true even for FullHD screens). Many people have the zoom mapped to the spare axis on the Warthog Throttle, including me, and it requires a fair amount of zoom to line up small targets for the GAU-8 at larger distances. But in the Rift, zooming in that way might give many people serious headaches, the only way around that would be a massive increase in resolution so you can see these targets at a distance - you cannot aim at subpixels.