Andy Ross writes: > How about doing the light generation at tile load time, instead of > generation time? This would have big payoffs for maintenance -- > someone could fix lighting configurations without regenerating the > whole tile. > > My assumption would be that this process is pretty quick -- one > hitlist computation per light -- and wouldn't impact performance > noticeably.
Andy, I have thought about it, and there are advantages and disadvantages to both offline and runtime approaches. For now I went with the offline approach because (a) there were less technical issues to solve and (b) I was nervous about the possible runtime performance issues. There are hundreds of lights per airport and doing 100's of terrain intersections certainly would cause a noticable frame rate blip. Note that with the random ground cover objects and random ground cover lighting, we are doing a clever trick to avoid having to do any terrain intersections at all. This trick doesn't work for runway lighting. There is also a problem with doing terrain intersections on tiles that are freshly loaded, but haven't been fully pushed into the render pipeline yet. That's a technical issue we haven't solved yet, but we need to at some point. Also consider the case of an airport that lies on the corner of 4 tiles. When the first tile is requested and an airport is attached to that tile, the airport needs to be loaded. But, we would also need to somehow identify this situation and make sure the remaining tiles are also loaded so that the terrain intersections in the neighboring tiles also return valid results. Most likely if a tile intersection comes up with a void, that would trigger a tile load request for the missing void. But, we'd have to wait until that missing tile load is done, then redo the original intersection test and then keep going. This could be a substantial pause as we wait for additional tiles to load. Oh, and what if the 3 other tiles that we are suddenly forced to load, also have airports that span other tile boundaries and we are forced to load those first too. We could concievably have a nastly little cascading tile loading problem. Probably generally rare, but anyone want to take bets on whether or not it would happen someplace? This need for cascaded tile loading might also factor interestingly with our threaded tile loader ... the threaded tile loader code is something that I'd really rather not go out of my way to make more complex than it already is. Especially with threads, complexity usually equals bugs that are nearly impossible to track down. I'm doing a *lot* of wgs_84 math for positioning the lights -- things like start at point A and move 100' in the direction of the runway to arrive at point B. This also get's to be really expensive. There are probably lots of ways to optimize this and stay within a pixel or two error, but it's nice to be able to use accurate math and not have to worry about it. So there you go. A runtime approach is certainly possible, but there are quite a few significant issues that need to be considered and solved first, and the path of least resistance clearly took me down the offline route. 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
