@Piboso: Here is a quote from your track creation rules Wiki page - "Every texture must have power of 2 (eg: 256, 512, 1024, 2048) dimensions".
Now I understand keeping texture dimensions to a power of 2, but what I'm not clear about is whether there is a maximum dimensional limit to a texture size and/or a maximum limit to a texture file size(as in Megabytes) before it would create a problem with the converter/exporters?
Hawk.
Okay... Let me put this in another way in case there is a misunderstanding:
I have a .dds(DXT1 format) terrain texture that is 8192 X 8192 (Power of 2, so should be okay). I exported just the terrain data defined as TRKGRAS as an FBX(binary format with embedded media(FBX 2010 version)) as part of my investigation as to what is crashing the FBX Converter.
Now when I try to convert that FBX Terrain file as a collision(.trp) file with the FBX2EDF converter the converter crashes when trying to load in that data, so I'm presuming there is a bug/issue with large texture files even though it is correctly sized in power of 2?
So my question is: Is there a bug/issue with the FBX converter in this situation, and if so, will it be fixed in good time? :)
I really need to know the answer to this question to possibly save myself a lot of wasted time trying to fix this when it could just simply be a bug/issue with the converter/exporters. ;)
Hawk.
PS: Does exactly the same thing when trying to use the 3dsMax 2010 EDF exporter too.
Textures of size 8192x8192 shouldn't be a problem.
Quote from: PiBoSo on February 21, 2017, 10:50:34 AM
Textures of size 8192x8192 shouldn't be a problem.
I've just done another investigation test, and it does actually seem there is a problem with the texture size of 8192x8192:
I reduced the texture size of the terrain texture to 2048 X 2048 and it is now going through the exporter okay when exporting a [collision].trp file.
I'm just going to make sure everything else in the scene will export okay on an individual basis before I will test the terrain textures again by trying a 4096x4096 texture size.... I will report back when I have done this.
Thank you Piboso, appreciated. ;)
Hawk.
Hi Piboso.
After many hours spent trying to find a solution, and then asking Manu for advice and help(Manu was able to export the file for me with no issues at all), I have come to a theoretical conclusion for the problem I was having with not only the FBX2EDF converter but also the very same problem with the EDF-exporter for 3dsmax crashing all the time too for me on this track project:
Would I be correct in assuming that if the file I'm asking the exporter/converter to process needs more physical system RAM than I have available to complete it's task then there is no provision for the exporter/converter to use a buffer/page file or virtually created RAM on HDD or SSD to compensate for that lack of physical RAM to complete it's task without a fatal crash in the exporter or converter?
I also think there is the same issue with TrackED? Because the large track .map and .trp files I got back from Manu's export wouldn't load into TrackED for me neither(TrackED just crashed every time for me), but PeterV could load the .trp file into TrackED with no problems at all. Both have 16GB RAM, I only have 7GB RAM.
I've noticed in the past too that when we create a very large track surface and try and load it into TrackED, then Tracked becomes very sluggish and staggering in it's operation for me as though it's struggling for memory too? Also the TrackED screen doesn't zoom out far enough to be able to see all the large track surface as a whole.
This as I say is only my theory of what is happening when I try to export the files of my track project I'm working on; because Manu and PeterV could process the file without any problem and yet the only difference seems to be system specs, in that I only have only 7GB of RAM and they both have 16GB of RAM.
If this theory is correct, would it be possible to update the exporter/converter apps to be able to use a HDD/SSD buffer file/virtual RAM to allow it to process the data without crashing if a user hasn't enough physical RAM available to complete the task?
I'm totally not sure my conclusion is anywhere near to correct at all, but I do hope this report helps. ;)
Hawk.
Imho this tool has some issues:
(https://s7.postimg.org/d7ci83e6f/cpu.png) (https://postimg.org/image/d7ci83e6f/)
In the shot the cpu at 30% but the tool is just open ???
I am not sure it is as simple as system total memory - a 32 bit app on a 64 bit system runs via WOW64 and this controls memory allocation
http://stackoverflow.com/questions/490520/virtual-address-space-in-64-bit-systems-running-in-compatibility-mode (http://stackoverflow.com/questions/490520/virtual-address-space-in-64-bit-systems-running-in-compatibility-mode)
Is everyone running the same OS?
Just ran an app that reports that by default fbx2edf is not largeaddressaware so you will have 32 bit memory limitations
Quote from: h106frp on February 22, 2017, 11:29:07 PM
I am not sure it is as simple as system total memory - a 32 bit app on a 64 bit system runs via WOW64 and this controls memory allocation
http://stackoverflow.com/questions/490520/virtual-address-space-in-64-bit-systems-running-in-compatibility-mode (http://stackoverflow.com/questions/490520/virtual-address-space-in-64-bit-systems-running-in-compatibility-mode)
Is everyone running the same OS?
Just ran an app that reports that by default fbx2edf is not largeaddressaware so you will have 32 bit memory limitations
Following up on h106frp investigations into this issue:I made all the GPB MOD-Tools "
Large Address Aware" and now I can use the FBX2EDF Exporter on the .trp conversion on my large file track project without it crashing(not tried the .map conversion yet, I'll try that later today).
I can also now use TrackED without it crashing with this track project too.
I've also now made GPBikes "core.exe" LAA too, so I'll be interested to see if it affects and/or improves the stability of GPBikes too like it certainly has done for the MOD-Tools.
A switch over to true 64 bit addressing seems to be the way to go Piboso? Or at least providing true 64 bit versions as well as the current 32 bit versions? Tracks/Bikes and projects are only set to get bigger and better, you know. ;)
Massive thanks and appreciation to
h106frp for investigating this issue and finding the solution to the problems I was having here. Fantastic! ;D
Hawk.
Quote from: Hawk on February 23, 2017, 11:51:53 AM
I've also now made GPBikes "core.exe" LAA too, so I'll be interested to see if it affects and/or improves the stability of GPBikes too like it certainly has done for the MOD-Tools.
Hmm, wouldn't this prevent you from going online ?
I'll give it a try with my issue on Fuji.
But notice that using LAA does not seem to be totally risk-free: http://stackoverflow.com/questions/2288728/drawbacks-of-using-largeaddressaware-for-32-bit-windows-executables (http://stackoverflow.com/questions/2288728/drawbacks-of-using-largeaddressaware-for-32-bit-windows-executables)
Quote from: HornetMaX on February 23, 2017, 01:50:01 PM
Quote from: Hawk on February 23, 2017, 11:51:53 AM
I've also now made GPBikes "core.exe" LAA too, so I'll be interested to see if it affects and/or improves the stability of GPBikes too like it certainly has done for the MOD-Tools.
Hmm, wouldn't this prevent you from going online ?
I'll give it a try with my issue on Fuji.
But notice that using LAA does not seem to be totally risk-free: http://stackoverflow.com/questions/2288728/drawbacks-of-using-largeaddressaware-for-32-bit-windows-executables (http://stackoverflow.com/questions/2288728/drawbacks-of-using-largeaddressaware-for-32-bit-windows-executables)
If it solves the problems I was having so I can get on with my MOD work while Piboso fixes the issues then I'm willing to take the risk..... I mean what's the worst that can happen? Maybe have to do a system re-install if things go tits-up? Not a problem compared to not being able to do anything because the tools keep crashing(for me personally) all the time on this large track file project I'm working on. ;) 8)
But certainly if anyone tries this, then do so at your own risk guys. ;)
Hawk.
PS: Not tried getting online as yet, but that's an interesting point Max which I will soon find out no doubt. ;)
For mod tools I'm absolutely OK with the LAA stuff.
But activating LAA on GPB is another thing. The risk is only to have "crashes" due to this. The LAA change is reversible (and anyway you could just reinstall GPB).
There should not be any risk of system reinstall: the change is made in the .exe file (unless I'm missing something).
Quote from: HornetMaX on February 23, 2017, 02:22:19 PM
For mod tools I'm absolutely OK with the LAA stuff.
But activating LAA on GPB is another thing. The risk is only to have "crashes" due to this. The LAA change is reversible (and anyway you could just reinstall GPB).
There should not be any risk of system reinstall: the change is made in the .exe file (unless I'm missing something).
Well, it seems it(LAA) worked in getting TrackED working and the FBX2EDF converter to give me a .trp file from this project, but it's still crashing when trying to convert to a .map file. So I don't know what's happening there.... Maybe it is just a lack of RAM I have for this large file? :-\
Hawk.
Well, that would depend by how exactly each tool manages memory allocation. But anyway, if you're RAM limited, the best you can hope is to start swapping to disk, which would make any processing hopelessly slow. Until Intel's Octane at least :)
When trying to compile Nicks map file the fbx2edf application fails when task manager memory (system total) allocation hits
2.6GB for a non modified fbx2edf
4.7GB for a modified (LAA) fbx2edf
failures are repeatable.
If i try and clear backgound tasks to free memory the same occurs but offset down by the ammount cleared.
win7 64bit 8GB ram
Hmm. Just tried to view the source fbx and hit 8GB. Think their might be issues.
Converted to something i could view but still crashes at the same incremental memory usage points - pointer issue?