g3d.dll......help ..!

[Kosta 122]

Also something else interesting:As I mentioned earlier, I am in a process of reinstalling FSX for testing, and I noticed following, which goes line in line with VAS usage.I have no errors without scenery.I don't see those GUID errors really impacting g3d.dll crashes. I started by removing parts of the scenery from the folder, and I would get a g3d.dll, but not the missing GUID.And by lowering the VAS by whatever, I can prevent crashes. - Note here: VAS does not have to be near 4GB (=exhausted) for g3d.dll error to appear. With some sceneries, I can go way higher, and with some, I can only put usage up to 3GB. Example: EBBR, EDDF, allow max. VAS ~3.2GB, otherwise error. Not possible to workaround by MLA. Flytampa LOWW: can go as high as 3.8GB and still land.That goes line in line with almost any post out here.As JB said, FSX is dead down the road. Developers are trying too much, and overloading.Right now I am installing a very slim version of FSX, only needed stuff, like, per flight basis. Only two airports, only base scenery, see how far that brings me.You must realize that if you are flying, and you have 1-2 airports installed on the way, they also fully load with all their glory, causing VAS to jump.

I also think that FSX is becoming heavier and heavier with huge addons and whatnot and it simply isn't build for that... Nor is it build for all that shiny new hardware. The funny things is that even that shiny new hardware won't let me run FSX smoothly with an fps if 60 all the time. If I don't use the bufferpools tweak, fps is below 20 in way too many places. Guess I (we?) will have to get used to saving the gameevery few minutes and simply reload it after yet another appcrash.

Quite agree on that. Though not all aircraft are gonna permit a successfull reload.

[Guest jahman]

Jahman, seriously, after all this time? Since when does Task Manager report correct VAS?

Blimey! More of a reason then to concentrate on Corrected VAS. I bet many simmers out there are looking at the wrong, lower, number and thinking it can't be VAS because it's nowhere near the limit.

...Guess I (we?) will have to get used to saving the gameevery few minutes and simply reload it after yet another appcrash.

What? you don't have AutoSave enabled in FSUIPC?Cheers,- jahman.

[Kosta 122]

Autosave is not really useful to me, since I fly for BAV, and that would mean I would have to stare at the screen all the time, even on longest of flights.

Blimey! More of a reason then to concentrate on Corrected VAS. I bet many simmers out there are looking at the wrong, lower, number and thinking it can't be VAS because it's nowhere near the limit.

Most ARE looking at the wrong number, I see it all the time!

[Guest]

What? you don't have AutoSave enabled in FSUIPC?

I don't own FSUIPC. I really see no use for it. Did you think everyone owns FSUIPC...?BTW I am going to give my final solution a try this evening: the magic bullet, the answer to all problems... the free one month version of Prepar3D! :) Could well be that one may solve all my appcrash problems. ;) I'll let you know how it goes. (If I can figure out how to get the Katana working in it, that is, because default aircraft usually give no appcrashes.)

[Kosta 122]

I don't own FSUIPC. I really see no use for it. Did you think everyone owns FSUIPC...?

I do, yes... FSUIPC is a swiss knife for FSX.

[CFIJose 5,485]

This is just a quick request. For those having g3d.dll crashes in specific areas, LOWER both AI to 25%.Please let me know your results.Jose

[Guest]

I do, yes... FSUIPC is a swiss knife for FSX.

Ah, ok, well, I don't have it and never had it in all my years of simming (since the early nineties). ;) Of course I know about it, but I could never find a reason to buy it. That autosave function might be a good reason though, haha! But there are cheaper options for that.

[Kosta 122]

This is just a quick request. For those having g3d.dll crashes in specific areas, LOWER both AI to 25%.Please let me know your results.Jose

No AI at all, LOL.

[Guest]

This is just a quick request. For those having g3d.dll crashes in specific areas, LOWER both AI to 25%.Please let me know your results.Jose

I already always have AI at 25% and get appcrashes.

[Kosta 122]

I did some tests on VAS, to give you an idea what are we dealing with here:Basic FSX, only module addons, no scenery or aircraft: VAS 1,5GBBasic + FSGlobal: VAS 1,55GBBasic + FSG + UTX: VAS 2,4GBBasic + FSG + UTX + NGX: VAS 3GBBasic + FSG + UTX + NGX + Aerosoft EBBR: crash, VAS 3GBBasic + FSG + NGX + EBBR: pass, VAS 2,5GB, after EBBR VAS 2,3GBWeird thing was, MLA was turned on, in the pass where it crashed, VAS was NOT exhausted (3GB), but MLA didn't report any missing libraries.But in the next pass, where it passed, MLA reported errors, about 10 of them.Then I reloaded the flight, same settings, but this time without MLA:Pass, same VAS usage before and after, 2,1GB...2,3GB.This shows me that MLA doesn't really impact if the scenery is going to crash or not.All tests were done with LOD_RADIUS=7.5, texture 4096 and high settings.As far as I can see, this is fault of addon scenery, not FSX. Because if I unload EBBR, I can drive the VAS to 4GB without the problem.Only thing worth noticing is the very high VAS usage both addons cause. They are both using more thna 600MB of VAS, no wonder we are having problems! (yes, I know my LOD is high, this is for testing only!)Next test is going to be near FT LOWW, also trying to exhaust VAS and crash it. I also wonder if there are going to missing libraries present. Stay tuned.

[Buzz313th 0]

I personally don't think it's a direct issue with VAS being exausted as it is with amount of data being moved for a given amount of time to and from the vid card from system ram. My issues were solved with a combination of ram timing changes, vid drivers and a few changes of some fsx cfg tweaks. All of which have a direct influence on how FSX manages memory into and out of the dynamic buffer/vid card. Remember, the dynamic buffer (BufferPool) does not use vid memory, it uses system ram and that dynamic command buffer queue is managed by cpu clock cycles. So again, as our systems get faster and our overclocks get higher and the scenery developers release larger and larger single bgl files that need to be loaded in one chunk, the software memory management defined in FSX is being overwhelmed. FSX unfortunately uses system ram and the cpu to command all functions of the vid card and all thats left for the vid card to do is just draw what the cpu instructs it to do by the cpu per frame. Our modern vid cards are capable of managing and processing most of the command calls themselves including the dynamic vertex buffer and furthermore the most recent drivers for them are written to expect them to do so. So, in a nutshell, the faster and more recent our systems get, the harder we are making it for FSX to do what it was originally written to do.The g3d.dll error is caused by scenery bgl's being too large. But it is not the developers fault. I think they need to be aware of this issue and try to split the size and content of the scenery bgl's into smaller chunks. Like instead of having one very large bgl for the area of olympia, they make two bgl's half the size. I believe this would make it easier for memory management in FSX to load the required scenery data over time, instead of having to deal with one very large bgl that chokes the system.JB

[Kosta 122]

Then explain to me, why can I push FT LOWW up to 4GB VAS, and AS EBBR won't even load if I put high LOD. FT has no missing GUIDs, no erros, everything is peachy. I think it *is* developers fault, or better said, poor SDK and support from MS, leaving developers guessing what is right.There is a thing I noticed though: AS EBBR, same as EDDF for instance, loads it's scenery all in one. Already when you are close to the airport it attempts to load a large portion. LOWW I can see from very far, much further than EBBR/EDDF - I believe this is the reason my airports crash. This is definitely one of the reasons for g3d.dll errors.

[Buzz313th 0]

Then explain to me, why can I push FT LOWW up to 4GB VAS, and AS EBBR won't even load if I put high LOD. FT has no missing GUIDs, no erros, everything is peachy. I think it *is* developers fault, or better said, poor SDK and support from MS, leaving developers guessing what is right.There is a thing I noticed though: AS EBBR, same as EDDF for instance, loads it's scenery all in one. Already when you are close to the airport it attempts to load a large portion. LOWW I can see from very far, much further than EBBR/EDDF - I believe this is the reason my airports crash. This is definitely one of the reasons for g3d.dll errors.

Maybe because LOWW has more bgl files (smaller chunks to load) to allow the memory management to slowly load to the sum of 4gb, where EBBR has most of it's data in one or a few bgl requiring FSX to pass a basketball through a garden hose.Where I used to get my g3d.dll crash over the OLM vor in PNW. I watched the scenery load, the error would pop up right before the vid card would draw a huge chunk of autogen all at once. I know this, since when I got rid of the errors, I did the test directly over the same position and at the moment where the crash should have happened, I observed about 300 autogen object pop up at once, it accessed the hard drive and gave the system a small stutter but didn't crash. I believe that PNW has alot of anotated autogen, meaning that the developers have associated certain autogen objects to ground coordinates, thus forcing these objects to be drawn everytime. With regular non anotated autogen, I believe (but I might be wrong) that FSX will generalise autogen per the type of ground tile giving FSX more leeway (but less accurate geographically wise) in placing the objects. I think that the later option may be easier on the system as FSX is not forced to draw the objects if under high load. So, maybe taking the OLM bgl's and splitting them up would allow FSX to move the same amount of info over a longer period of time.JB

[Kosta 122]

Maybe because LOWW has more bgl files (smaller chunks to load) to allow the memory management to slowly load to the sum of 4gb, where EBBR has most of it's data in one or a few bgl requiring FSX to pass a basketball through a garden hose.Where I used to get my g3d.dll crash over the OLM vor in PNW. I watched the scenery load, the error would pop up right before the vid card would draw a huge chunk of autogen all at once. I know this, since when I got rid of the errors, I did the test directly over the same position and at the moment where the crash should have happened, I observed about 300 autogen object pop up at once, it accessed the hard drive and gave the system a small stutter but didn't crash. I believe that PNW has alot of anotated autogen, meaning that the developers have associated certain autogen objects to ground coordinates, thus forcing these objects to be drawn everytime. With regular non anotated autogen, I believe (but I might be wrong) that FSX will generalise autogen per the type of ground tile giving FSX more leeway in placing the objects. I think that the later option may be easier on the system as FSX is not forced to draw the objects if under high load. So, maybe taking the OLM bgl's and splitting them up would allow FSX to move the same amount of info over a longer period of time.JB

Alright, I compared:Scenery folder:FlyTampa has 75 files, 73mbAerosoft has 183 files, 13mbTexture folder:FlyTampa: 322 files, 191mbAerosoft: 929 files, 110mbI think we can throw away the theory about size of the BGL files. Or even textures.But, what do you change in your BIOS to slow down the RAM as you call it? Which settings exactly? I wouldn't know where to start fiddling with RAM timings - last time I did, I made such a lockdown I needed to reset the BIOS with a jumper... CLR_RTC... grr...Is there some tutorial how to make those missing objects by myself? I am total noob, but would like to try this out, I don't believe it's that complicated! Only to test how things perform...

[Buzz313th 0]

Alright, I compared:Scenery folder:FlyTampa has 75 files, 73mbAerosoft has 183 files, 13mbTexture folder:FlyTampa: 322 files, 191mbAerosoft: 929 files, 110mbI think we can throw away the theory about size of the BGL files. Or even textures.But, what do you change in your BIOS to slow down the RAM as you call it? Which settings exactly? I wouldn't know where to start fiddling with RAM timings - last time I did, I made such a lockdown I needed to reset the BIOS with a jumper... CLR_RTC... grr...

Don't throw the theory away too quickly. More files, less data in the scenery folder is just a generalisation. See if you can find the files that are loaded at the position you get your crash. Also, depending on your FSX.cfg, disbale preload or not and your LOD setting, will determine when and where the files are being loaded and when and where the info is being sent to the card to draw. Then compare. Some of those files are libraries, some are scenery tiles etc. A while ago, I dabbled in scenery development and there is a tool in the FSX SDK that allows you to bring up a world map and mouse over certain areas to see which bgl files are active thus would load for that given location.If I'm wrong, then I'm ok with that. I'm just trying to throw out my personal opinions based on my experience and trying to help.In regards to the memory timings... I loosened up memory timing and NB timing and saw an improvement in other sorta random g3d.dll errors and crashes, as well as an increase in smoothness, less fluctuations in the frame counter, but a small loss in overall peak framerate, but, it still did not get rid of that one crash in PNW over OLM. I'm not gonna make any suggestions as each system is different, but for me I maintained a manual setting of my memory ratio and then let my bios auto detect what would be failsafe in regards to timing. Then after a reboot, the bios would spit out the timings greyed out that it was using for auto. Then I started working from there and manually set them till I found what impacted my system the most. On my system it was tRD(Static tRead Value) that needed to be loosened to 10 and tRFC that needed to be loosened. Although, and not to confuse you anymore, I was able to tighten tRFC back up beyond what it was prior after getting rid of my entire "poolsize=x" entry in the fsx.cfg, which allowed for a few more frames in performance.PS. Now in the Orbx forum there is a gentlman who tried playing with memory timing and it didn't help. So again, why does it work for me and not him? Systems are different and require a different solution is my guess.JB