Andy Ross writes: > The cowbox is too small. At only 1m high, it's really a more > appropiate size for a sheepcase.
OK, I'll fix that. Next time I'll go to the Central Experimental Farm near my house with a measuring tape. I'm pretty sure, though, that the sheep are no more than 1.5-2ft high at the shoulder. > At the other extreme the 8 story building, while scaled correctly, is > too large. Buildings this large are very rare, and occur in large > numbers only in downtown areas that are better handled by "real" > static scenery. Yes, I agree -- 8-story apartment buildings are not uncommon even in cities of 15,000 people, but they rarely have three sections like that one. I made the building originally to be placed manually at the turn to base leg on the rwy 22 approach at my local airport, and I used it for the urban scenery simply because it was already available. WE NEED BUILDINGS! Preferably we need buildings that are (a) generic and (b) big enough to be clearly identifiable from the air, but no matter what, they must be easy on the texture and poly budgets. Something the size of a barn or house, say, is distinguishable in the middle of a field but not in the middle of a town or city. We need strip malls, three-story suburban office buildings, apartment buildings, low rises of various types, and maybe even the occasional shopping mall or parking garage or row houses. Mostly, we need a variety of non-descript low-rises and stip malls. > I'd suggest replacing the "urban" scenery object with something > like a 2-3 story building, or perhaps a cluster of small buildings. > Right now, you can look accross the bay from San Francisco and see > a huge urban skyline stretching from Oakland to Fremont which isn't > even close to what's there in real life. Agreed. > My reading of the code is that there is a separate ssgTransform node > in front of every one of the objects. That's likely to be a > performance bottleneck, if the OpenGL matrix state has to change every > four vertices (most GPUs want to flush the stream when the matrix > changes). > > Instead, why not "pre-compile" the scenery objects for each tile into > a single vertex buffer at load time. Unfortunately, then we'd lose LOD granularity and overwhelm the GPU. I agree that we could get away with some grouping, but even individual triangles can be extremely large in flat terrain and can create hundreds or thousands of trees all in range at the same time. We could also pregroup, so that we have clusters of buildings and trees as single objects. That would look nice, but it would cause trouble near the edges of triangles, where several trees or buildings might stick out into the middle of a lake or river (or a runway, for that matter). What framerates are you getting with and without random objects, using today's CVS? I can no longer see any measurable difference on my system. > Even better, you could get a very cheap "continuous LOD" by drawing a > distance-dependent prefix of this vertex buffer. That is, draw only > the first N objects based on your distance from the tile centroid. > Writing a new ssgLeaf node type really isn't so hard -- take a look at > the fgPanelNode implementation for a minimalist example. That would be wonderful, if someone wanted to contribute it. All the best, and thanks for the comments, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
