Jump to content

Graeme_77

Members
  • Content count

    19
  • Joined

  • Last visited

Community Reputation

6 Neutral

About Graeme_77

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Graeme_77

    [SOLVED] Frame Rates / Objects size

    @Goran_M i5-2500k clocked to 4.2GHz, 8GB 1600Mhz DDR3, 1GB Radeon HD 6850. P8Z68-V LE. (It was a good spec in 2012!) Test 1 :- All four sliders on the graphics settings to minimal, 1x AA. Loaded to an airfield outside the available scenery (runway and water everywhere) TBM Cockpit view 14.3fps, External view 23fps IXEG Cockpit view 30fps, External view 40fps Test 2 :- Visual Effects: High(HDR), Texture Quality: Medium, Number of World Objects: Low, Reflection Detail: Minimal, AA: None EGPH Runway 24, default X-Plane scenery TBM Cockpit view 10.5fps, External view: 14.2fps IXEG Cockpit view 27fps, External view: 29fps Default C172 G1000 Cockpit view 33fps, External view 30fps You've built a really, really beautiful model - but at the moment it's very heavy on system requirements.
  2. Graeme_77

    [SOLVED] Frame Rates / Objects size

    Thanks @skiselkov - I know your priority is making the model run well on new hardware and these older machines are a fringe case for you. Regardless a low poly model would be much appreciated. What I’ve seen of the model is really fantastic and hopefully in 6 weeks or so I’ll have a new machine to run it on.
  3. Graeme_77

    [SOLVED] Frame Rates / Objects size

    Skyguider your GPU is miles better than mine, but your CPU is of a similar age (I've got an i5-2500k 3.3 with a slight overclock). I've tried all the same things you did and can't get a significant improvement. I don't think it's textures as although they are 4K the total texture size is only around 200MB, My suspicion is it's the size of the obj files that is the issue, and perhaps that's loading the CPU rather than the GPU causing the whole sim to slow down. The obj files are enormous. 6 times larger than the IXEG, 5 times larger than Felis 154, 3 times larger than the FF A320 and finally only slightly smaller than the Rotate MD-80 which is virtually unusable on XP11 for me - although it ran OK on XP10 - again suggesting perhaps that the CPU load is the problem rather than the GPU. Here's a extract from an IXEG object:- POINT_COUNTS 7222 0 0 28056 VT -0.7237 0.3741 2.0096 -0.165 -0.439 0.883 0.6316 0.874 and from the TBM:- POINT_COUNTS 470814 0 0 470814 VT 0.00841901 0.09876074 0.00741016 -0.99862665 0.05215613 -0 0.894862 0.79924899 I don't know how the X-Plane engine works, but the sim appears to be being asked to draw a massive amount of polygons apparently to a higher precision with the TBM model. I'd be keen to see how your system performs if you swap the forward view to the X-Plane HUD view? For me this instantly doubles the FPS. No textures are unloaded, but the sim simply performs better without the cockpit view hence my suspicion it's the objects themselves. I've also tried pulling the CBs for all the G1000 screens but that has no improvement. As a last resort, I made a copy of the .acf then removed references to glareshield.obj, seats.obj, cargo.obj and cabin_rear.obj - this improved my FPS from 15 to 18 - a 20% improvement.
  4. Graeme_77

    Show LOC1 and LOC2 at same time?

    Hello Javier, The normal way to do this on a single PFD+MFD G1000 is to use the Bearing pointers for the VOR. Click the "PFD" softkey and click the BRG1 and BRG2 keys to cycle through pointer options until you have pointers for NAV1 and NAV2 displayed at the same time. It's easy enough to fly a VOR "on the needles" rather than with the CDI presentation. Hope this helps!
  5. Graeme_77

    [SOLVED] Frame Rates / Objects size

    I've got lot less VRAM than that, but even with textures set to low and most of the internal and external textures resized down to 2048 there was no framerate improvement. I think It's all in the 3D model itself. If I go to external view and zoom far away or view forward with no panel the frame rates are fine and the pages like engine parameters are fine. From the TBM glareshield.obj POINT_COUNTS 470814 From the IXEG fuselage.obj POINT_COUNTS 81633 In the objects folder the IXEG has 137MB of textures vs 149M in the TBM - I don't think that's a huge difference for the GPU, but as I noted initially the TBM OBJ files are 6 times larger than the IXEG. (I completely understand my system is well below spec, and what I've seen of the system sim is really very good!)
  6. Graeme_77

    [SOLVED] Frame Rates / Objects size

    I’ve got a relatively old PC, I5-2500 and a 1GB HD6850 Graphics Card - and I know it’s probably well below what the developers had in mind when they developed the TBM so this isn’t a criticism of the product. However, I’m getting frame rates of less than 12 with the TBM, compared with 35 on the IXEG 737 with otherwise identical settings. I had a look in the objects folder and the objects are huge, the largest obj is 45MB for a glareshield. In total the IXEG objects are 56.5MB, with the TBM at 327MB - so I’m guessing this is where the frame rate hit is coming from. Changing the forward view to the X-Plane default HUD view restores the frame rates to 35-40. Before I commit $2500 to a new PC can I ask is any optimisation of the model planned? Thanks, Graeme
  7. Graeme_77

    Altimeter Counters

    I bought the MU2 in the recent sale, and it's certainly a tricky beast to master. The torque reaction seems a bit severe but I understand this is an MU2 trait and with practice not a issue. However one of those "little things" that looks a bit odd is how the digits move on the altimeter drum counter. Most commonly the digits are arranged on the drum so that as the altitude increases the digits move down in the drum counter window, just as they would move down the screen in a PFD display. However on the MU2 this is reversed so when climbing the numbers rotate up. Although there are undoubtedly examples where this is the case, in my experience the vast majority of drum altimeters work in the first sense. (For example the IXEG 737). My question is: is this an intentional feature based on the real aircraft modellled? If so, then that's great. If not, are there any minor updates planned where this could be changed? Thanks, Graeme.
  8. Graeme_77

    Magnetic Variation

    Jan, I've had a look in my earth_nav.dat file, and I have two lines for the ROVANI VOR. Line 9997 in the file, with a value of 6.0 before the ROI identifier, and another line 25306 with a value 0.0. At a guess I'd say one was the VOR, and the other the DME? I've checked my charts as well, and the inbound course is the reciprocal of the radial, so as far as the charts go the VOR should be correctly aligned with Mag North. Do you have an example of an instrument approach where the VOR is not aligned to mag north so I can have a look at how it's represented - I'm ashamed to admit I'd not considered that possibility!
  9. Graeme_77

    Magnetic Variation

    As far as I'm aware I'm using default data supplied with the Steam version of X-Plane. I've got the HD Mesh v3 and also the EFRO Scenery Gateway airport. I'll have a look at the dat files.
  10. Graeme_77

    Suggestions for IXEG video content

    Hi Kneighbour, Thanks for your suggestions. Flying a circuit in a 737 is not unknown, it's how pilots new to a jet transport learn how to land the aircraft before being released to fare paying passengers. That said, it's a very specialist kind of operation so I'll have a look and see if I can find any information on how it's done on the 737. It's a great idea though, should hopefully make for an interesting video. i've never seen the glideslope fail to capture, the only thing I can think of is it won't capture the GS until after the VOR/LOC has engaged. Also, I have a vague recollection that intercepting the ILS whilst in LNAV is not a good idea on the Classic, so make sure you pick up the localiser in HDG mode, at least until you're sure you can capture it every time that way. Would you be able to show me a screenshot of the flight deck when it's failed to capture? I'll need to see the EADI, EHSI and MCP in the pic. Thanks, Graeme
  11. Graeme_77

    Magnetic Variation

    Jan, Thanks for all your input on this matter. I've been doing a bit more investigation and based on the attached composite screenshot the VOR North value is exactly the problem. I don't see any problem at all with your Mag Vars and understand they're based on a 2020 epoch. Pictured is the default 172 tracking towards ROI VOR on Radial 180, so inbound 360. Nill wind and aircraft stabilised on track for a few miles. Note the Mag Compass value shown in the data output and directional gyro is 354.2, Almost exactly what the VOR North value for ROI is. Now what this means is the VOR "calibration" for want of a better description, is based on difference from Magnetic North, not True North. To fly inbound on Radial 180 I'm using a course from 354 degrees, rather than 360 as one would on a perfectly calibrated VOR. Now, to the root of the matter perhaps. I understand you very kindly updated the X-Plane Mag Var system (as well as all those lovely gateway airports!). As the VOR's are apparently referenced to Mag North, perhaps the values for the VORs were not changed when the MagVar table was updated? It's almost like the VOR North value was being used as a fudge to make the procedures work with the previous incorrect MagVar? If the VORs were referenced to True (i.e. had a VOR MagVar stored in the database) then perhaps this would not have been an issue. If I reset VOR North to 0 then everything works exactly as expected as if the VOR was perfectly calibrated. Thanks, Graeme
  12. Graeme_77

    Magnetic Variation

    Sorry Jan, just to add I tried resetting the VOR North value of the offending VOR to 0 and it seemed to be a much closer match. Is the VOR North value the MagVar? ROI has 10.8E published but the VOR North is around 354. Do you know what the VOR North value is designed to reflect? - the notes I found say it lists the *Magnetic* Heading of the 360 Radial, if this is the case the VOR North value would not represent MagVar but rather the "shift" in real MagVar since the VOR MagVar was last reset? Thanks, Graeme
  13. Graeme_77

    Magnetic Variation

    Thanks Jan, I'm aware of the real life limitations for the VOR system, however for a published VOR approach the stated radials should work correctly. Basically, I followed an overlay procedure cross checking with the radio aids on the published charts, and the raw data was off by 4-5 degrees.
  14. Graeme_77

    Magnetic Variation

    Hi All, I've just spent a frustrating couple of hours typifying to set the sim up for a video on VOR/DME approaches. I'm looking at the VOR 03 approach at EFRO Rovaniemi. To keep it simple I'm looking at a final inbound leg of 23 degrees, nil wind. FMC overlay procedure followed in LNav the aircraft tracks correctly, and with the map navaids selected the ROI VOR is shown exactly on the heading line on the nav display. This is exactly what I expect, the aircraft is tracking directly towards the beacon on a course of 23 degrees. Perfect! Except both the VOR display and RMI show a course of approx 27 degrees to the VOR. I'm guessing this is a MagVar issue. Can somebody explain the relationship between the X-Plane database MagVar and how it interacts with the IXEG database? Can I change the X plane MagVar table? TVM, Graeme
  15. Graeme_77

    Suggestions for IXEG video content

    Thanks for all the feedback, I'm really glad you're finding the videos enjoyable and useful. The next video should be out in a few days or so. I'm looking at covering non precision VOR and NDB approaches next, before moving on to visual circling. As always if you have any suggestions for procedures or other aspects of the sim I'd be happy to hear them.
×