Hi.
Sbuilder is great but I have an annoying problem:
I want to append vtp-coastlines files (bgl's) covering lod5 area.
If those vtp-files are larger than 2-2.5 MB, sbuilder would not append them. Sbuilder gives no error message, it just work and work with the task. CPU usage goes up to 100%, and it work forever but nothing happends. I think it's a bug with appending large size vtp-coastline bgl's in sbuilder. I discovered this when I was trying to append a vtp-coastline bgl from norway scenic (it's over5 MB in size - yes it's a complete lod5 area with lot's of coastlines, thousands of lakes and rivers, we have alot of fjords,lakes and rivers in that part of norway.)
Is this a known limitation to Sbuilder?
greetings from Norway
Jan Roar Roed
Appending Large size vtp-files- big problem
Hi,
SB does not check the system memory before opening, importing or appending files.
It just reads the files and admits there is system RAM available. A BGL File of 5MB is an enormeous file !!! The BGL itself is very compact. But SBuilder translates the appended files to a large ammount of data. One VTP point in a BGL file occupies 2 Bytes. When SB reads the point, it translates the point into:
- a double precision latitude > 8 bytes
- a double precision longitude > 8 bytes
- a single precision altitude > 4 bytes
- a long integer for the index of point > 4 bytes
Total > 24 bytes! and I am not considering everything!
So a 2 byte piece of data is transformed into 24 bytes!
I think that if you add more memory to the PC, there is a possibility that you can append the file. The following is from the Help files!
Regards, Luis
SBuilder hardware requirements depend on the complexity of your project. The main requirement will be memory to handle large bitmaps as backgrounds and speed if you are working with large quantity of data. As an example, the processor used in the developing of SBuilder was a 2.8GHz PIV with 512MB of RAM. We tested SBuilder with files with about 20 thousands polygons and big bitmaps. In order to get a good display refreshing we needed to partition bitmaps backgrounds and work with smaller projects. In the quoted system, bitmaps of 2000 x 2000 presented no speed problem.
SB does not check the system memory before opening, importing or appending files.
It just reads the files and admits there is system RAM available. A BGL File of 5MB is an enormeous file !!! The BGL itself is very compact. But SBuilder translates the appended files to a large ammount of data. One VTP point in a BGL file occupies 2 Bytes. When SB reads the point, it translates the point into:
- a double precision latitude > 8 bytes
- a double precision longitude > 8 bytes
- a single precision altitude > 4 bytes
- a long integer for the index of point > 4 bytes
Total > 24 bytes! and I am not considering everything!
So a 2 byte piece of data is transformed into 24 bytes!
I think that if you add more memory to the PC, there is a possibility that you can append the file. The following is from the Help files!
Regards, Luis
SBuilder hardware requirements depend on the complexity of your project. The main requirement will be memory to handle large bitmaps as backgrounds and speed if you are working with large quantity of data. As an example, the processor used in the developing of SBuilder was a 2.8GHz PIV with 512MB of RAM. We tested SBuilder with files with about 20 thousands polygons and big bitmaps. In order to get a good display refreshing we needed to partition bitmaps backgrounds and work with smaller projects. In the quoted system, bitmaps of 2000 x 2000 presented no speed problem.
the computer has 3.2 Ghz pent IV with HT and 1024 MB DDR RAM. when trying to append the file I get a RAM usage of 256MB and pagefile usage of 181MB. Sbuilder is not using more than 1/4 of my total RAM ammount.
the computer does not hang or crash, it's just Sbuilder working and working, and the sbuilder windowstext says (Sbuilder (then the project name) not responding). it does not slow down the computer. as I try to append the file, I can use the computer as normal for other things. It's just that sbuilder works forever with the append task.
Jan Roar Roed
the computer does not hang or crash, it's just Sbuilder working and working, and the sbuilder windowstext says (Sbuilder (then the project name) not responding). it does not slow down the computer. as I try to append the file, I can use the computer as normal for other things. It's just that sbuilder works forever with the append task.
Jan Roar Roed
-
Jan Nielsen
- Posts: 22
- Joined: Sun May 16, 2004 7:18 pm
- Location: Norway
Hi,[:)]
An obvious solution to this is to decompile the vtp file with James Keirs LWMViever. You can decompile parts of the file so that it can be recompiled with BGLC_9 and Rhumbafluppys macros, supported with LWMViever, into several smaller files.
When decompiling you are prompted for upper left LOD8 cell and lower right LOD8 Cell. You can try to append all of these smaller recompiled files and then compiling with SBuilder, or you can make your changes in SBuilder to the smaller files, compiling the smaller files, and decompiling the smaller files with LWMViewer and then merging them together with a text editor back into the original sized BGLC source file. Then compiling this merged file into the resulting edited origal sized VTP-bgl file.
Complicated? Not really!
If your intention was only to change the texture type used, for example from beach with surf to a beach without surf, then that change would have been done faster with a LWMViewer decompiled source file using the text editors search and replace function.
[8D]
God helg!
An obvious solution to this is to decompile the vtp file with James Keirs LWMViever. You can decompile parts of the file so that it can be recompiled with BGLC_9 and Rhumbafluppys macros, supported with LWMViever, into several smaller files.
When decompiling you are prompted for upper left LOD8 cell and lower right LOD8 Cell. You can try to append all of these smaller recompiled files and then compiling with SBuilder, or you can make your changes in SBuilder to the smaller files, compiling the smaller files, and decompiling the smaller files with LWMViewer and then merging them together with a text editor back into the original sized BGLC source file. Then compiling this merged file into the resulting edited origal sized VTP-bgl file.
Complicated? Not really!
If your intention was only to change the texture type used, for example from beach with surf to a beach without surf, then that change would have been done faster with a LWMViewer decompiled source file using the text editors search and replace function.
[8D]
God helg!
I have come to a conclusion that Sbuilder might manage to append the file, it may take som time (hours). So I have started the append process and will let it run for some hours (getting out, having pizza, shopping etc) 
Since the program do not crash, the computer does not hang, and the sbuilder seems to be doing something, I will think it may take 2-3 hours to append a vtp-bgl file of this size. I will let you know if this work out well
the project I'm doing is adapting Norway Airports into Norway quality mesh and norway Scenic. the coastlines at some of the airports need major editing, and it's usualy much faster to append scenic's files and move som linepoint/polygonpoints and recompile a new file.
Jan Roar Roed
Since the program do not crash, the computer does not hang, and the sbuilder seems to be doing something, I will think it may take 2-3 hours to append a vtp-bgl file of this size. I will let you know if this work out well
the project I'm doing is adapting Norway Airports into Norway quality mesh and norway Scenic. the coastlines at some of the airports need major editing, and it's usualy much faster to append scenic's files and move som linepoint/polygonpoints and recompile a new file.
Jan Roar Roed
-
rhumbaflappy
- Posts: 420
- Joined: Sat Oct 16, 2004 10:11 pm