Archived

This topic is now archived and is closed to further replies.

Eziocin

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

Recommended Posts

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

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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...
You need to create Dummy's MDL with the same Guid as every single object on those library, then you need to compile with BGLCOMP(SDK) an XML with every GUID.I have already a list of them, I will try it but I need some timehttp://forum.aerosof...post__p__336125

Share this post


Link to post
Share on other sites

Here an example of XML with GUID that should be compiled and create a BGL.<?xml version="1.0" encoding="ISO-8859-1"?><FSData version="9.0" xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:noNamespaceSchemaLocation="bglcomp.xsd"><ModelData sourceFile="plane.MDL" fileOffset="0"/><!-- GUID {756b3233-6220-6c69-1020-e1b201414447} --><!-- palne --></FSData>But IMHO we should ask for every developer ti fix all this missing library.

Share this post


Link to post
Share on other sites
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
I had an interresting test today, i'm using ORBX scenery in PNW land, all of them out now, NGX, ASE, Shade and Dxtory as fps limiter.Testflight PAKT-KSEA with 737-800 in NAX (Norwegian) colour!!!, not usually a normal view up there. I have tried many flight's from PANC with same aircraft, all of them ended after YYJ, over Orcas area, every flight get a G3D.dll crash.But the clue i did today, i reduced all fuselage, tail and wing textures (down to 1024 on all of them) in that NAX paint, with some reduse on detail's of course, but still good enough in my eyes, and did a crash free flight from PAKT to KSEA. Even with autogen set to Very Dense and Mesh to 5m i had no problem, lod radius 4.5.You can see some pictures over at Flightsim.no http://www.flightsim...6970#Post626970 (norwegian language)So i think it's not only scenery's developers to blame, maybe developers all over must recognize that the limit is reached in terms of resolution on textures.

Share this post


Link to post
Share on other sites
I had an interresting test today, i'm using ORBX scenery in PNW land, all of them out now, NGX, ASE, Shade and Dxtory as fps limiter.Testflight PAKT-KSEA with 737-800 in NAX (Norwegian) colour!!!, not usually a normal view up there. I have tried many flight's from PANC with same aircraft, all of them ended after YYJ, over Orcas area, every flight get a G3D.dll crash.But the clue i did today, i reduced all fuselage, tail and wing textures (down to 1024 on all of them) in that NAX paint, with some reduse on detail's of course, but still good enough in my eyes, and did a crash free flight from PAKT to KSEA. Even with autogen set to Very Dense and Mesh to 5m i had no problem, lod radius 4.5.You can see some pictures over at Flightsim.no http://www.flightsim...6970#Post626970 (norwegian language)So i think it's not only scenery's developers to blame, maybe developers all over must recognize that the limit is reached in terms of resolution on textures.
Keep testing and find the threshold where you will cross the line on stability and instability. Find out if you can recreate the test in slew mode which will reduce the tme needed to test. Testing in slew will also take alot of other things out of the equation related to soundfiles, aircraft systems, flight modeling etc. Good deal.JB

Share this post


Link to post
Share on other sites

I menage to create a BGL for EGCC there was only one Guid missing and it works, with the MissingLibraryAlert=1 didn't ask for it.so we can test it the only problem is to record all guid that come on the windows.I have a list for EDDF EBBR ENGM

Share this post


Link to post
Share on other sites
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.
Nono, I didn't want to throw it away completely. I only brought up that it's not up to the BGL sizes or scenery size. I believe firmly it's the way the scenery is being loaded.As I mentioned earlier, I had LOWW scenery partly visible from far far away, no only a green area where the scenery is supposed to appear. Ground was basically visible.And EBBR, you must be almost above the scenery to load runways only, and that's basically what crashes the sim. And then if you manage past that point, you get the whole scenery, in that case no crash.It must be the way when scenery loads what, is how it responds to VAS.What tool would be that!?

Share this post


Link to post
Share on other sites

Word Not Allowed, I forget the name of the tool as it's been a few years, but if you open up the sdk docs then it will mention it. You can also find info on scenery dev forums. I would check for you, but I'm not by my comp.Once you load the tool, you need to load the scenery folders to see the file associations and where they are georeferenced. JB

Share this post


Link to post
Share on other sites
I had an interresting test today, i'm using ORBX scenery in PNW land, all of them out now, NGX, ASE, Shade and Dxtory as fps limiter.Testflight PAKT-KSEA with 737-800 in NAX (Norwegian) colour!!!, not usually a normal view up there. I have tried many flight's from PANC with same aircraft, all of them ended after YYJ, over Orcas area, every flight get a G3D.dll crash.But the clue i did today, i reduced all fuselage, tail and wing textures (down to 1024 on all of them) in that NAX paint, with some reduse on detail's of course, but still good enough in my eyes, and did a crash free flight from PAKT to KSEA. Even with autogen set to Very Dense and Mesh to 5m i had no problem, lod radius 4.5.You can see some pictures over at Flightsim.no http://www.flightsim...6970#Post626970 (norwegian language)So i think it's not only scenery's developers to blame, maybe developers all over must recognize that the limit is reached in terms of resolution on textures.
Guys, please, you MUST UNDERSTAND, it's not about reducing here or there. It does not matter where you reduce, as long as you manage to bring your VAS down, it will not crash. That is on reason.2nd reason as it's showing slowly is, how addon sceneries are programed, but I'm not sure on this one.I already did tests with highres, low LOD = no crash. Lowres, high LOD = no crash etc... as long as I can keep the VAS down, it won't crash. But still, some sceneries are going to cause g3d.dlls, apparently for how they are programed. See my other posts on this.I am yet to crash my sim within an area of LOWW for instance, an airport which is properly coded as it seems. I can run LOD as high as 10.5 and still pass with VAS of 3.9GB.
Keep testing and find the threshold where you will cross the line on stability and instability. Find out if you can recreate the test in slew mode which will reduce the tme needed to test. Testing in slew will also take alot of other things out of the equation related to soundfiles, aircraft systems, flight modeling etc.Good deal.JB
The line for crash is 4GB VAS. I don't know how often I must repeat all that, it's like fighting a twister... You must start troubleshooting which scenery is the one that is causing that, and WHY. FSX itself won't crash.NGX also doesn't cause g3d.dll errors, but it will load the VAS immensely.
I menage to create a BGL for EGCC there was only one Guid missing and it works, with the MissingLibraryAlert=1 didn't ask for it.so we can test it the only problem is to record all guid that come on the windows.I have a list for EDDF EBBR ENGM
What did you do, can you put a short step by step here please?I'll do my best then to test whatever I can in various scenarios... it's what I'm good at wink.png

Share this post


Link to post
Share on other sites
What did you do, can you put a short step by step here please?
You need to have SDK installed that came with FSX pro edition but it's more for developer, some tools to learn.I already explain on some post above.Lets say that FSX tell's you that miss ID {00000009-5F09-4611-A956-C169AABOA4F0}You create an XML with a Dummy MDL file and compile with a Tool, you get a BGL that you place in (ADDON SCENERY) it works.But don't mix on istalling the object library that can be found on a website of some post above, otherwise you get conflict.In my opinion we should ask to all developer so anyone have to go through this.Let's try an airport, give me all the GUID that are missing on print screen and paste on Jpeg or write it down, post or send me by PM i will compile and send you back if you want.

Share this post


Link to post
Share on other sites
You need to have SDK installed that came with FSX pro edition but it's more for developer, some tools to learn.I already explain on some post above.Lets say that FSX tell's you that miss ID {00000009-5F09-4611-A956-C169AABOA4F0}You create an XML with a Dummy MDL file and compile with a Tool, you get a BGL that you place in (ADDON SCENERY) it works.But don't mix on istalling the object library that can be found on a website of some post above, otherwise you get conflict.In my opinion we should ask to all developer so anyone have to go through this.Let's try an airport, give me all the GUID that are missing on print screen and paste on Jpeg or write it down, post or send me by PM i will compile and send you back if you want.
I'll test EBBR in a sec, just busy testing crashing situation at EGCC (I saw your Aerosoft post).Let's start like this:I saw the post about XML, so I made a text document on desktop and pasted that info into the document, and renamed it from .txt to .xml.I don't think that's right...How do I create an XML with a Dummy MDL file? I already have SDK installed, but don't really get those command prompt exes...

Share this post


Link to post
Share on other sites

I just realized that you already have the GUIDs for EBBR - that is what I would like to test out.So I tested EGCC, while I do get the missing GUID popup when I load the scenery, but I don't get it overflying EGCC at 35,000ft. I guess it's an object which has to be viewed from closer perspective. High VAS usage in EGCC is possible, unlike EBBR.No g3d.dll error with insanely high LOD_RADIUS here.

Share this post


Link to post
Share on other sites
You need to have SDK installed that came with FSX pro edition but it's more for developer, some tools to learn.I already explain on some post above.Lets say that FSX tell's you that miss ID {00000009-5F09-4611-A956-C169AABOA4F0}You create an XML with a Dummy MDL file and compile with a Tool, you get a BGL that you place in (ADDON SCENERY) it works.But don't mix on istalling the object library that can be found on a website of some post above, otherwise you get conflict.In my opinion we should ask to all developer so anyone have to go through this.Let's try an airport, give me all the GUID that are missing on print screen and paste on Jpeg or write it down, post or send me by PM i will compile and send you back if you want.
If you look at this thread:http://forum.avsim.net/topic/352086-scenery-library-object-missing/page__fromsearch__1Jim from Orbx created a 'dummy ' object for the missing GUID, that way you can see where the missing objects are

Share this post


Link to post
Share on other sites
If you look at this thread:http://forum.avsim.n...__fromsearch__1Jim from Orbx created a 'dummy ' object for the missing GUID, that way you can see where the missing objects are
That file is not available any more, I know that thread. They removed all the links as ORBX is doing "repairs" only for ORBX. I kinda understand that...Guys, right now I think we are pursuing the wrong thing. While creating dummy objects for GUIDs might be nice to get rid of errors, I don't think it's gonna fix g3d.dlls. Maybe milder them...

Share this post


Link to post
Share on other sites

Simbio,I have 3 GUID's missing, which I think are up new Stewart(CZST), so if I give you the GUID numbers could you create the .bgl file?Many Thanks

That file is not available any more, I know that thread. They removed all the links as ORBX is doing "repairs" only for ORBX. I kinda understand that...
Correct, but could Simbio, do the same kind of thing? Just a thought

Share this post


Link to post
Share on other sites
Correct, but could Simbio, do the same kind of thing? Just a thought
Yes he can, but that's not the point. I would rather have him write a small tutorial and then anyone can do it for his own purpose. As I understand it, all we need is a dummy object, whatever it is, doesn't have to be a huge crate, and then step by step how to convert that into bgl with a guid.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.