Page 1 of 1

A huge hole in the mesh?

Posted: Sat Feb 26, 2005 9:56 pm
by Andrew
I am working on a custom roads scenery. After compiling it to a bgl, I found a huge hole in the mesh, going almost down to sea level. I noticed a little road piece going into that hole, and removed it with SBuilder and recompiled. That fixed it.

What could be the cause of this?

Posted: Sat Feb 26, 2005 11:58 pm
by Luis Sa
Hello,

In order to get an explanation you would need to decompile the mesh to see if the "void" (the hole) is present or not. What I am saying here is a pure guess. May be the hole exists in the mesh. May be it is a single point that FS filters. But when the road is placed the "filtering" action is disabled. In fact roads flatten the terrain along their path. When a road passes on a particular point or location X, near points get the altitude of X.

So I suggest that using a top down view with your aircraft in the center of the hole, press "Show Aircraft". A cross will sit on the road. Move the point of the road instead of eliminating the road. Compile again and report here your conclusions.

Regards, Luis

Posted: Sun Feb 27, 2005 12:15 am
by Andrew
Hi Luis,

Thx for the suggestion. I am not able to check the mesh in any way, but will try moving road points.

I still have the other problem I described in the "Runtime error 9" thread. Could you be so kind to recommend which version of SBuilder I should start with when reinstalling? I started with the full 2.02 package and then upgraded SB.exe and objects.txt to 2.04.

Check your mail soon as well, I am sending you a roads file which ver 2.04 won`t open...it just freezes.

Regards,
Andrew

Posted: Sun Feb 27, 2005 1:32 am
by Luis Sa
I,

I received your VTP BGL file. I took it the computer (laptop) where I develop SBuilder to append it. If I had a crash I could see exactely at what stage it was and could correct the code if it is wrong.

So I did it. Wait some 4 minutes and then I killed SBuilder as it looked like frozen. Then I tried to append in a compiled version of SBUILDER.EXE like yours. I left it trying and switch to this computer to read the forum. While I was reading I heard a noise on the laptop. The fans stopped and your roads are on the screen. 22,140 lines and 229,749 points. It took about 5 minutes on my 2.4GH pentium 4 with 512MB ram. I saved as a SBP so I can send you if needed.

I selected them all and make a Snap to Lod grid. 13 points were eliminated.

Regarding install - the last complete pack was SB202. Then I change SBUILDER.EXE and it can be found on the sbxxx.zip! When a file needs to be changed I include it together with the EXE. That is the case with objects.txt! So I have no tip regardinf your problem.

Regards, Luis

Posted: Sun Feb 27, 2005 6:10 am
by Andrew
[8D]

As I see it everything is solved! How could I guess that my P4 2.8GHz and 1GB RAM would use that long time to open the file? Waited for about 3 minutes and the VTP bgl opens fine now with SB 2.04.

Just a last question: Why did you use the "snap to grid" ?

Regards,
Andrew

Posted: Sun Feb 27, 2005 6:25 am
by Luis Sa
Hi,

[:)]

As in LWM/VTP scenery points go to a grid of 4.8 meters (LOD21) I use to force the points to the grid so that I see what I will get. Furthermore, it deletes points that are very near and can cause problems to SB when it slices the polygons prior to compilation.

Luis

Posted: Mon Feb 28, 2005 1:57 am
by Andrew
Ahh that explains it well - I will give it a try.

Obrigado!

Andrew

Posted: Mon Feb 28, 2005 2:46 am
by Horst
Hallo,
I will make an addition:
SB can read huge line and polygon files, and Scasm can compile it. It takes time(not freezing), and give the program the time.
But on the other hand, we have to take care, if the FS can handle the data (the created bgl data)?
To load a huge bgl inside the area is not a big problem, it takes some additional time. But when you fly in the area (when the file loaded), the frames will drop.
I also saw a different between FS9.0 and FS9.1. With 9.0 I got a CTD, 9.1 could handle my data.
This was not tested very intensive, because it is dependent on the area (the other data) you are working in. So I do not know exactly the limitation.
Only a hint.

Regards
Horst

Posted: Wed Mar 02, 2005 1:35 am
by Andrew
Luis,

Reporting back: I moved the little road piece just a fraction to the West, and that solved it, no more crater. [:)]

I also tried "snap to grid", and got exactly the same result as you did, but only after changing "Remove Hooks=TRUE" in the SBuilder ini file, which the help file recommends. I also noticed in the project properties box that "Coexist/Replace" was enabled, should it be so?

Anyway I see the files are a little bit bigger after recompiling them, but I gues that is because "snap to grid" also add points on the borders in order to fit the grid?

Horst, thx for the tip!

Regards,
Andrew

Posted: Wed Mar 02, 2005 6:00 am
by Luis Sa
Hi,

About the road - there is still the doubt if the problem is in the mesh or in the road or in X ? But I hope it was the mesh [:)]

Regarding hooks see this:

http://forums.avsim.net/dcboard.php?az= ... 5779&page=

There is no need to go to the INI file as there is a check box in the Preferences. I suggest that you make the foloowing exercise:

1. Start a New project. Press F8 to see the Cell grid (LOD8).

2. Make a Line going from left to right with 6 points crossing one grid. Define it as VTP (road, river, or else). Points 1 2 & 3 are on Cell 1 (the left one) and points 4 5 and 6 are on Cell 2 (the right one

3. Compile. Move the line a bit to the top so that you can append it and see both.

4. Before appending you should know that it is necessary to divide the line in 2. MS suggests in the SDK to make ONE line with points 1 2 3 and 4 - Cell 1 entering one point on Cell2 and ANOTHER line with points 3 4 5 and 6. SBuilder does that.

4. Decompile (append VTP). In the Preferences there is a switch called Join Multi-Cell Lines. I forced it to be allways ON (you can turn it OFF but SBuilder internally make it ON). What does that mean?

answer: join lines 1 2 3 4 with 3 4 5 6 so that you end up with a single line with points 1 2 3 4 5 6!

So you will see the line exactly as you created! So if you create a VTP line crossing a Cell with SBuilder, you get it back! If you recompile you get the same size.

Now suppose that lines were created by another programme (say default lines) and that the crossing is handled diferently (for example another way to implement hooks). Then when you append VTP the "joining lines that cross cell borders" function fails. You would get 2 separate lines with commom ends!
<font face="Courier New">

......|......
.1.2.3|4.....
.....3|4.5.6.
......|......
</font id="Courier New">

(in fact if the lines have the same type (you do not want to join a river with a road!) and points 3 and 4 coincide in the shown figure, Sbuilder makes a single line as I explained above)

When you compile these 2 lines you get 4 lines! The first line generates line 1 2 3 4 and 3 4. The second line generates 3 4 and 3 4 5 6! The recompiled file is larger!

Do you think I should allow Join Multi-Cell Lines to be OFF and ON instead of being allways ON?

Regards, Luis


PS: Coexist/replace depends on what you want! If set it to coexist, the existing lines will appear as well as yours!

Posted: Sat Mar 05, 2005 1:50 am
by Andrew
Luis,

Thx for your excellent explanation. I understand (almost) all now. I am sort of overloaded right now, fitting my bridges to roads and roads to bridges. [:o)]

I printed your example from Avsim. I`ll try your little example later on. Sbuilder is working like a charm, I only move roads now, and the file size after compiling is the same as before. Nice.

Leave "Join multi cell lines to "ON" by default. No problem, I got a pen and paper here, and take a lot of notes, so next time my computer breaks down I still got all the tips. [:D]

Cheers,
Andrew