Norman Vine writes: > Curtis L. Olson writes: > > > >> I'll try testing with KBOS again but I was teleporting there > >> as part of my regression testing because of its unique tile > >> arrangement > > > >Try --airport-id=KBOS --heading=270 > > > >> Yikes good catch :-( > >> > >> Hmm..... hey this still works in my test bed :-) > > > >What I'm seeing *definitely* happens on the tile boundaries. Part of > >KBOS is good, but you cross the tile boundary and instantly everything > >is 'wrong'. It's reporting elevations that are 450' too high. > > forcing the tile boundary crossing with --airport-id=KBOS --heading=270 > causes my fork to mis-behave too :-(
Well hey, reproducing the problem could be considered progress. :-) > So this has got to be something endemic to how the airport scenery > can be in different 'tiles'. My guess is that inorder to make this new > routine work with scenery that isn't 'strictly tiled' like this there will > have > to be something stuffed into the userdata part of the ssgBranch Node > so that the graph walking functions know where to 'jump to' inorder to > get the proper transform. > > But that kindof sucks in that this means an extra test for every ssgBranch > :-( > > IMHO The 'right' way to fix this of course is to split the airport data into > the tile structure so that 'all' surface data follows the same > scheme. Norman, We need a line / geometry intersection routine that works with any arbitrary valid ssg scene graph. It's certainly fine to discuss how flightgear splits up the geometry, but let's save that for another day and maybe for the terragear list. I wonder if airports are a special case and if there is some error in how you build up the transformation matricies as you walk down the tree that is triggered just by this particular scenario? Really, we need a routine that works with an arbitrary ssg scene graph. It's very concievable that someone could import scenery from some other project with a completely different layout. Also, we are talking about non-vertical intesection lines when it comes to landing gear, so a line could intersect 'outside' the current tile there. I was talking to someone else recently about a terrain collision warning tool and in this case, we'd be projecting a line forward so there is a high likelihood that the intersection point there would be outside the 'current' tile. It's fine to flag special cases and optimize for them, but we need a robust intersection routine that works for all cases. > Well I really only 'decloaked' because there appeared to be considerable > confusion as to how the scenery went together so I thought I could help > by posting what I had gleaned of your magic over the years. > However given the rukus this caused ..... > > FWIW If I were you I would seriously consider changing > the way FGFS handles the airport data so that it is not a > 'special case' > > FWIW2 - I agonized a long time over forking the code < read years > > so I would be surprised if my decision to go the other way could > be made any quicker > > apologies for the line noise Norman, here is the view from my perspective: I am more than happy to have you participate in this project and contribute code. Your past contributions have been robust and useful and valuable. If you want to fork your own private version and work on that, there's no rule against that. However, if you periodically de-cloak, submit half working code, then re-cloak, either I have to spend a ton of time figuring out your code and winding my way through your optimizations myself in order to hopefully fix the bugs, or I simply can't accept the code. 'Almost' working code just doesn't cut it. It's one thing if you are a full time participant and you are 'hot on the trail' and expect a fix real soon. Then perhaps we can tolerate a short lived bug. But if we never know if you'll ever reappear with a fix, then what am I supposed to do? I can't just go breaking stuff in the project. Code that runs faster isn't helpful if it doesn't produce the correct answer all the time. I really value your participation here, but when you are straddling the fence like this it makes it really difficult for me to know what to do. The current geometry intersection code is expensive so a faster routine would be *really* nice, but I have my own time limits and working on this part of the code right now wasn't in my plans and is now pushing everything else I am working on back a day or two or three, maybe several more days (?) if we don't come up with a fix quickly. Again to summarize, we value your participation, and normally you produce very robust code, but in this case since we never know when you are lurking or not, it's difficult to accept broken code with no promise of a fix ... Norman posted a link to the code, so if someone else wants to take a crack at figuring out what's wrong, feel free. I'll be happy to share with you what I've discovered so far. It would be nice to have this code working robustly and integrated. Best regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
