Automatic ASM creation

[Guest]

AreaFill? Absolutely son!! :-hah I picked that up write away. The decompiler already recognizes them. Before the SDK came out, I was getting zero length polys in the BGL. I figured it was some sort of fill record. The SDK nailed it for me. I'll be incorporating 1x1 all the way up to the 16x16 area fills.Lee.

[rhumbaflappy 113]

Hi Lee.Cell Filling is also possible. The new 'LWM Tutorial' will deal with that first, as it's the simplest structure... no Area data at all!Fills all 1024 Areas in a Cell with a few lines of code, in case anyone wants to create new oceans or inland seas. :)I uploaded the 'LWM Tutorial' to AVSIM, Flightsim and Simviation today, so hopefully they'll appear tomorrow. I hope they are of some use to you. Some changes in terminology, no more sub-rows, and a sneaky way to avoid 'tmf2bgl' by using intergers for the header bounds... just drag'n'drop the TXT file onto the BGLC icon to compile.I also included a devious way of re-meshing old coastal flattened areas, and a few other tricks revealed.I've taken a one hour break, and now I'm writing text and code for 'VTP Method1 Tutorial'. :-abductDick

[Guest cwright]

>>You'll probably adjust your program to take advantage of the >LWMDataAreaFill?x? commands. This is new for us, as it was >revealed in the Terrain SDK. It allows blockfilling of Areas >( LOD13 ) within Cells ( LOD8 ). Dick, that'll be useful. Yesterday I wrote the code to fill in all the internal LOD13 squares and that works fine, so I can create filled circular lakes with impunity! However, multiple LOD8 squares still seem problematic. I'll leave that until a bit later. I now want to check the program on more complex and convoluted shapes. I couldn't get a mathematical formula to create complex shapes - my maths must be getting rusty! - so today I'm going to write a routine to read in hand drawn .raw bitmaps. Looking forward to reading the new tutorial. Many thanks. Best regards, Chris

[Guest]

I've looked over your tutorial. That's good stuff you wrote there. I'll be incorporating your TMF macros into my decompiler / compiler (why use BGLC if you can have a GUI interface too). It may be a while before it's completed but I am making good progress on it. I'm finishing up polygon creation from LAT / LON pairs now. I've written it so polys can span LOD 13 and LOD 8 blocks. I'm trying to break it now by giving it some pretty awkward polygons but the algorithms I used seem to be working well and it's handled everything I've thrown at it. As long as the poly is closed and doesn't cross (figure eight) it works real well. Then I start working on getting the shoreline together. Yours and Christain's work has really helped a lot.Lee.

[Guest Pittsburgh]

>And your solution works nicely with my problem stated >above!!! Thanks buddy! As far as determining direction, I'm >looking at a clockwise rotation through the line segments. >Looking for an algorithm for this. Haven't found much on >this (graphics programming is not my strength) so I think I >may have come up with something on my own... Excuse me for jumping in here in the middle of the conversation, but somewhere in my memory I recall that determining the clockwise or counter-clockwise direction of the sequence of vertices is simply done by taking the cross-product (or dot-product, right now I cant remember. Learned this in the first year of my engineering training :-)) If the resultant vector is heading away from you, the direction of the sequence defines a clockwise sequence, otherwise a counter-clockwise definition.Hope this helps :-waveLev

[Guest christian]

Is that the cross product of the vectors?3 vertices a, b, c(a-:( x (b-c) x (c-a)???Has to be cross product to be a vector again. I think you may be right, but can't get my head around it now. It's definitely true for 2 vectors, but more than 2 ???Thanks...Cheers, Christian

[Guest Pittsburgh]

Hi Christian, I think what you outlined is something like the dot-product (although I am not sure you hit the right definition :-)). The dot product is a scalar, i.e. a regular number, real or integer. If I remember correctly, from the dot product, you can determine the angle between the two vectors. The definition of dot product is:A dot B = Length(A) * Length(:( * cos(T)where A and B are vectors, Length(X) magnitude (physical length) of vector X and T is the angle between the two vectors. From this it follows that if A dot B is zero, the vectors are perpendicular to each other.The cross product is another vector. It is defined as the vector, that is normal, i.e. perpendicular, to the plane defined by the two vectors you are taking the cross product of. In this case as all vectors are in the same plane. Imagine you have two vertices (1, 0, 0) and (0, 1, 0), it is simple to see that: 1) The vertices are along the x- and y-axis, respectively.2) The angle between them should be 90 degreesTo determine the cw or ccw orientation of the vertices, you can use the right hand rule: Extend the fingers of your right hand from the origin of your system in the direction of the first vertex. Curl your fingers such that the finger tips point towards the second vertex. If your thumb points towards yourself, the sequence is counter-clockwise, otherwise it is clockwise. This is of course pretty impossible to program (I am thinking in terms of defining a thumb in VB or C++ :-)). Programatically, you have to take the cross product and see if it points towards you or away from you. If I understand your problem correctly, you are lucky that your problem is a little limited in the fact that all points are in the same plane (if I understand you correctly you are trying to generate vertices on the ground). Because of this, there are only two possibilities of the cross product: Either it is pointing directly towards you or it is pointing directly away from you.Hope this helps -- if not, do not hesitate to ask me. I am reviving what I learned many years ago :-waveLev >Is that the cross product of the vectors? >>3 vertices a, b, c >>(a-:( x (b-c) x (c-a) >>??? >>Has to be cross product to be a vector again. I think you >may be right, but can't get my head around it now. It's >definitely true for 2 vectors, but more than 2 ??? >>Thanks... >>Cheers, Christian

[Guest christian]

I must written my post pretty crap...Yes, I'm with you, and I was also saying it has to be the cross product, not dot (I studied physics quite a few years back, so I'm trying to remember all that stuff now too. I also went back to using my hands :-lol ).What I meant was, I only have vertices, so to get the vectors, you'd have to get the vectors from the vertices, but I think this is what you meant, and it's easy to do...What I don't understand yet: it's a clear case for 2 vectors indeed. But the polygon consists of many vectors. If I now take the crossproduct of each of the vectors, one by one, the resulting vector would point god knows where (I think). Say, take to vectors, the resulting vector would point in z direction as you said. But then I go to the next vector in the polygon, so the resulting vector will point somewhere in the xy plane again. Next vector and it will point into z direction again. I doesn't seem to work like that...If I take just 2 vectors out of the set I think that won't work. The polygon doesn't have to be of circle shape but can always come back (think of a C shape maybe). The crossproduct would depend on which vectors you chose. I may be wrong, I'm also trying to remember all this old maths. Maybe I'm wrong here, and you can indeed just take any two vectors next to each other...I think your theory is probably right, but I think something is still missing...Cheers, Christian

[Guest Pittsburgh]

Hi Christian,>>What I meant was, I only have vertices, so to get the >vectors, you'd have to get the vectors from the vertices, >but I think this is what you meant, and it's easy to do... Just to make it clear what I meant: I would just interpret the vertices as vectors from the origin (0, 0, 0) to the point defined by the vertex. Think we both agree this far :-)>>What I don't understand yet: it's a clear case for 2 vectors >indeed. But the polygon consists of many vectors. If I now >take the crossproduct of each of the vectors, one by one, >the resulting vector would point god knows where (I think).I think so too :-lol>Say, take to vectors, the resulting vector would point in z >direction as you said. But then I go to the next vector in >the polygon, so the resulting vector will point somewhere in >the xy plane again. Next vector and it will point into z >direction again. I doesn't seem to work like that... Ok, here I am getting on slightly shaky ground: I think all vertices that make up a polygon must be defined either as counter-clockwise or clockwise. I think it is so for all the sceneries I have laid my eyes upon. This is primarily for purposes of determining which side of a polygon that gets shaded. The graphics engine (and definitely DirectX) uses this information, i.e. the the direction of the crossproduct, to determine if a polygon is facing us or facing away from us. So, I would be surprised if the sequence of vertices that make up a polygon suddenly changed orientation (that is going from counter clockwise to clockwise or vice versa). Again, I am sort of new in the field of sceneries etc. so I could very well be wrong.>If I take just 2 vectors out of the set I think that won't >work. The polygon doesn't have to be of circle shape but can >always come back (think of a C shape maybe). The >crossproduct would depend on which vectors you chose. I may >be wrong, I'm also trying to remember all this old maths. >Maybe I'm wrong here, and you can indeed just take any two >vectors next to each other... Hmmm... Some part of me want to agree with you on the above statement and some part wants to disagree. If what I stated above, that is with the sequence of vertices, holds true, then any two vertices adjacent should be enough to determine if the sequence is cw or ccw. I see what you mean by the example of the C-shape. But in the C-shape you still can define a sequence in which all the vertices are either ccw or cw.>I think your theory is probably right, but I think something >is still missing... Hope this helps....