decal poly stuff up!

[Guest christian]

I just left the save harbour of New Zealand and let my decompiler loose onto african decal poly bgls and it bails out badly.One problem, I solved. I stuffed up the texture information in the data section. This was easy to solve and means that I know now how textures work with decal polys. I don't have much time, so I will report results later...The other stuff up is data related and I don't have a clue how to solve it. I just copy paste some hexdata:a1 86 04 01 ; data header (4 = POLYGON, 1 texture group follows )00 01 ; texture 0 and 1 poly to follow04 ; 4 data points74 29 44 30 ; points5c 29 3b 30 49 29 44 30 74 29 44 30 ; new LOD8 quada1 8e 04 01 ; same as above00 02 ; texture 0, 2 polys to follow1f 02 00 ; this is my problem. This is usually only one byte! ; 1Fh = 31, but 33 points follow! ; Obviously 31 + 2 = 33, but what does that mean???56 29 66 12 ; points85 29 5c 12d7 29 40 12cd 29 20 12cb 29 f6 11d4 29 de 11ef 29 ae 1105 2a 80 1108 2a 60 11fc 29 48 11ec 29 41 11ca 29 40 11bf 29 35 11bb 29 1e 11b8 29 b6 10b3 29 9b 10a9 29 86 109c 29 78 1077 29 65 105c 29 5b 1047 29 65 103c 29 7d 102c 29 ba 101f 29 d0 100b 29 d6 10dc 28 cc 10cf 28 d0 10ce 28 df 10e3 28 50 11 e3 28 5f 11 d3 28 80 11 c5 28 8c 1156 29 66 12 0e ; this is ok, 0eh points followc5 28 8c 11 9c 28 a2 11 93 28 ae 11 8c 28 d4 11 8e 28 df 11 a3 28 f5 11 b9 28 f8 11 e2 28 f3 11 f7 28 fb 11 07 29 0c 12 37 29 59 12 47 29 66 12 56 29 66 12 c5 28 8c 11the bgl file is nph492008.bgl in easthem/africachelp me!!! :)Cheers, Christian

[rhumbaflappy 113]

Hi Christian.Well, Africa is a dark and mysterious continent.:-lol It is 31 + 2...how strange, and how would the terrain engine know to add 2 points? Perhaps this has something to do with Lee's discovery that points range from 1-255... with 0 not being a valid point? So when it reads the next word with a 0, it knows to add the LSB ( 2 ) points to the list? Weird.In truth, I found the NPH files a little strange. What are they? Swamp?My head's still spinning from finding a possible landclass/waterclass switch for water flattens.I've only got 1 section of my tutorial done, and I already need to rewrite it! :-eek

[Guest christian]

I had a thought overnight...Maybe the count byte only goes up to 31. This means the first 3 bits of that byte are reserved for something else! And then we have 2 bytes as addon-count if the point count is bigger than 31.This could explain the weird 4080 offset. If a point < 4080 than it's not a coordinate but an additional count value. This way we can have more than 31 points in a poly.This makes sense but I doubt that's the 100% solution. 4080 is too strange a number and I have seen smaller numbers than 4080, eg 4060. What's really strange is that 4060 doesn't get displayed, so I suspect a bug in M$ tools there. Also, I got a weird 'bug' with a convex poly, it did the convex bits right, but after about 20 points, it wouldn't draw the points anymore, but just close the polygon (there were 5 more points to go). All very weird...Cheers, Christian

[Guest]

I think I have the reason for the 4080 offset!!As Christian has stated, why 4080? Granted it's 255 * 16 so that got me thinking. I've seen numbers in the BGL below 4080 (sometimes way below) and also numbers greater then 12240 (255 * 48 -or- 255 * (16 + 32). Why a 50% overlap in both directions? And that statement made me think about how would you get a clean line between two nieghboring LOD 8 blocks. Heck, I'd have an overlap!So I did some modifications in a BGL file to extend lines that reached the LOD 8 border by extending the coordinates out farther. In other words (this is hard to explain in words), I took a line with a vertices points in a LOD-8 block to the west, determined how to extend it to a zero X point, computed the Y based on the angle of the line and it's Delta-X that I created and replaced the original X,Y values with these values. I expected that if I moved to the LOD-8 block on the west side, I'd see my line (a road) extended. But I didn't. It didn't change at all. So I moved the Y coordinate up 500 points to the north and the line moved farther north to match, but stopped on the LOD-8 boundry. And the original line was also there, but only from the boundry to a short distance into my original LOD-8 block. My hypothesis...To get smooth transitions for lines from one LOD-8 boundry to another, you can plot the lines outside of your current block to adjacent blocks!! And the beauty is that flight simulator somehow doesn't care and will neatly cut the line at the boundry. So in theory, if you had two identical vertices points for a line in both LOD-8 defintions, you should get a smooth transition from one LOD-8 block to another. I'm figuring you can plot lines from 0 to 16320. That's 16 LOD-13 blocks on either side of the LOD-8 boundry or a 50% overlap. This would really work well if the width of the lines changed at these overlapping points. By having the overlap, you should still see a smooth transition.Lee.

[rhumbaflappy 113]

Hi Lee.You'e right in that you can plot beyond the LOD8 border, and the terrain engine stops plotting at the borders edge. That would make for smooth transitions of lines and decals. The real breakthrough for understanding the number ( 4080 ) was your discovery that the number basis was 255, not 256.The flatten and water polys are evolutions of the older CFS2-style water, and don't have this inherent smoothness. And that may be a change we can anticipate for FS2004... that the older polys may be updated to an LOD8 reference, rather than an LOD13 reference.I do wish more people would look at the TMFs with hex editors to help sort out the few remaining mysteries of these files. You and Christian have helped me greatly with my understanding.Dick

[Guest christian]

Oh my, this was too complicated for Monday morning *:-* I got it though after reading it a second time. It does make some sort of sense, eg if you are too lazy to compute the exact borders (or widths). The remaining question is, does it make a difference. Ie, should we bother to compute the correct vertices with a LOD13 quad (to save framerates), or doesn't FS2002 care?What I suspect is that FS2002 internally draws the polygon. Than (if M$ is clever), the polygon gets written into the stencil buffer. Then the polygon gets cropped in the stencil buffer to the size of the LOD13 polygon. At last the polygon gets written onto the ground texture using the stencil buffer as a mask. If this is how things work, we really don't have to bother to calculate exact LOD8 polygons, but can use the 50% overlap.Very interesting finding!!! I think that solves the last decal poly mystery I had. I wanted to send you my newest TMFmacro last Friday but ran out of time... Expect it any time soon...Oh wait, I still have one little mystery, that's what values get written into the LOD10 / LOD13 values, because only LOD8 matters for the decals? I suspect it simply is (LOD13 % 32), etc... Cheers, Christian