Re: [Flightgear-devel] new_hitlist
Wolfram Kuss writes: > >The bigger problem, I suspect, will be main memory (or maybe disk > >bandwidth). An impostor scheme is going to be really tile hungry -- > >constantly dragging tiles off of disk, rendering them into textures, > >and forgetting about them. > > I know a sim that does what Norman suggest and it does not seem to > have problems with loading tiles, although it rerenders tiles all the > time (about one tile per frame). I misunderstood Norm's original suggestion, but I still see no major problem with using a simpler scheme like I suggested in an earlier posting: 1. At distance (a), replace the tile with a single quad (or two triangles) using the texture for the most common material on the tile -- these would be similar to our current ocean tiles. 2. At distance (b), replace the tile with a single quad (or two triangles) untextured and using the ambient colour for the most common material on the tile. This probably wouldn't be hard to implement using SSG, and wouldn't have any dependencies on hardware capabilities -- we could generate the two alternative tiles at tile load time as well as the main one, since they would be very small. I think that SSG already has LOD support of some kind, so we wouldn't have to do much at all. This approach would let us experiment with different distances and see if we need Norm's imposters as an intermediate layer. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new_hitlist
>The bigger problem, I suspect, will be main memory (or maybe disk >bandwidth). An impostor scheme is going to be really tile hungry -- >constantly dragging tiles off of disk, rendering them into textures, >and forgetting about them. I know a sim that does what Norman suggest and it does not seem to have problems with loading tiles, although it rerenders tiles all the time (about one tile per frame). >You're no longer limited by texture memory >here, However, one problem is that not all gfx cards can render into a texture, so you have to do some moving of textures, which in some instances is *very* slow. There is a factor of 1000 between different moves of the same texture on my GeForce 3, as you may easily see with the readily available benchmarks. I am still not 100% sure whether the problem (texture movement sometimes leads to stutter) is a bad implementation of the idea or a basic problem of the algorithm. One certainly has to spend some thought on texture ram management. I *think* the easiest idea - if you dont need the texture any more and need memory, throw it away and when the user views again in that direction, rerender it, is also the fastest algorithm. Rendering may be faster than moving textures between texture mem and main mem. >Andy Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new_hitlist
Curtis L. Olson wrote: > One thing we'd need to think about before we got too far down this > path is the texture RAM requirements of such a scheme. That's a manageable problem. If you think about it, the amount of impostor texture memory required is exactly that required to draw the tiles on the screen -- it's bounded by screen area. Clearly there will be a significant amount of overdraw. But there's no need for a 256x256 texture for an impostor that only subtends 20-30 pixels on the screen. The bigger problem, I suspect, will be main memory (or maybe disk bandwidth). An impostor scheme is going to be really tile hungry -- constantly dragging tiles off of disk, rendering them into textures, and forgetting about them. You're no longer limited by texture memory here, but you're still trying to cram huge datasets into a finite resource. This is the reason I'm still a CLOD bigot at heart -- with really huge datasets like terrain, any LOD scheme really needs to be done top-down (mip-mapped heightfields, for example), rather than bottom up (assembling huge terrains from huge numbers of maximum-LOD tiles). Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] new_hitlist
David Megginson writes: > Curtis L. Olson writes: > > > One thing we'd need to think about before we got too far down this > > path is the texture RAM requirements of such a scheme. > > They should be minimal. For the first tier of imposter tiles, we're > using textures that we already have, and just replacing the tile with > a single quad (or two triangles) that use the most common texture. > For the second tier, we're not using textures at all. It should > work. I think Norman original mentioned 'imposters' which specifically means 'texture image' replacements of geometry. Here you would do something along the lines of rendering the entire tile from a satellite view into a single texture, and then just render that texture on a simple quad rather than the entire geometry. There are any number of ways to skin the cat though. > > We would need to do something like put 'long enough' skirts around all > > the tiles (including the ones with terrain mesh) to hide the gaps. > > By skirts do you mean something like these? > > http://java.sun.com/products/jfc/tsc/articles/jcanyon/#SECTION3.1.2 If that's the article I'm thinking of, then yes. 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
RE: [Flightgear-devel] new_hitlist
Curtis L. Olson writes: > One thing we'd need to think about before we got too far down this > path is the texture RAM requirements of such a scheme. They should be minimal. For the first tier of imposter tiles, we're using textures that we already have, and just replacing the tile with a single quad (or two triangles) that use the most common texture. For the second tier, we're not using textures at all. It should work. > We would need to do something like put 'long enough' skirts around all > the tiles (including the ones with terrain mesh) to hide the gaps. By skirts do you mean something like these? http://java.sun.com/products/jfc/tsc/articles/jcanyon/#SECTION3.1.2 All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] new_hitlist
David Megginson writes: > Norman Vine writes: > > > but IMHO what is needed are "imposter tiles" > > > > "imposters" are where you use a 'texture only" substitute > > for the geometry that are computed on the fly 'often enough' > > This is 'radical' LOD but in our case the tiles out on the > > boundary are really just 'little slivers' and there is no need for > > anyting else. I would think that we could easily lump many > > tiles together into these impostors to form a 2 level ring of > > 'near' and 'far' "impostors" around our current scenery. > > Yes, I think that's a very good idea; in fact, if you wanted to go to > three layers, the furthest one could be simply untextured, coloured > polys (that's what you'd see from 120,000ft, for example). For each > tile, we need to sample to find the commonest material and then use it > for the texture (and/or colour) at load-time. One thing we'd need to think about before we got too far down this path is the texture RAM requirements of such a scheme. > Curt is worried about joining meshed tiles (with irregular terrain) to > flat tiles, but I don't think that will be a big problem if the flat > ones are far enough away. If we wanted to, we could also sample the > elevation variation for each tile to help us decide how far away it > should be drawn as a full mesh: flat tiles could go to a single poly > much earlier than mountainous ones, for example. It will be a problem. If you don't account for even the tiniest gaps between tiles, they can show up as a whole line of pixels no matter how far away. If you are then trying to match complex terrain in one tile to a flat rectangle being the next tile, this problem will only get worse. These pixel wide gaps glimmer and shimmer and change every frame drawing undue attention to themselves. We would need to do something like put 'long enough' skirts around all the tiles (including the ones with terrain mesh) to hide the gaps. This could certainly be done though and is something I've begun to look at for airport areas. 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
Re: [Flightgear-devel] new_hitlist
> Yes, I think that's a very good idea; in fact, if you wanted to go to > three layers, the furthest one could be simply untextured, coloured > polys (that's what you'd see from 120,000ft, for example). For each > tile, we need to sample to find the commonest material and then use it > for the texture (and/or colour) at load-time. Each tile has a replacement of a single color at the lowest altitude in that tile at the near edge and the highest altitude at the far edge. These colors and altitudes are stored in textures that are statically computed in TerraGear. I figure a couple dozen textures can do the whole planet; of each texture pair, one does the color without alpha and the other uses the RGB to store that altitude information. > Curt is worried about joining meshed tiles (with irregular terrain) to > flat tiles, but I don't think that will be a big problem if the flat > ones are far enough away. If we wanted to, we could also sample the > elevation variation for each tile to help us decide how far away it > should be drawn as a full mesh: flat tiles could go to a single poly > much earlier than mountainous ones, for example. We start with the whole planet only being those thousand-mile textures, mapped onto the sphere at sea level altitude. When the viewpoint is closer than a thousand miles to any of those textures, it gets broken up into triangles of the same texture mapping and the altitude data is used to position the triangle above sea level somewhere. When tile-pixels are more than 10 screen pixels wide, i.e. nearer than 400 miles for most, we load and draw full tiles. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new_hitlist
David Megginson wrote: > Norman Vine writes: > > > but IMHO what is needed are "imposter tiles" > > > > "imposters" are where you use a 'texture only" substitute > > for the geometry that are computed on the fly 'often enough' > > This is 'radical' LOD but in our case the tiles out on the > > boundary are really just 'little slivers' and there is no need for > > anyting else. I would think that we could easily lump many > > tiles together into these impostors to form a 2 level ring of > > 'near' and 'far' "impostors" around our current scenery. I have no clear view on the impact of this, but it sure looks like an interresting idea. It bascally redices CLOD to 'split' LOD. > > Yes, I think that's a very good idea; in fact, if you wanted to go to > three layers, the furthest one could be simply untextured, coloured > polys (that's what you'd see from 120,000ft, for example). For each > tile, we need to sample to find the commonest material and then use it > for the texture (and/or colour) at load-time. I was thinking about mixing the most common used color and the avarage color. I haven't tested this but looks like a good start. I realy should try it some time. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] new_hitlist
Norman Vine writes: > but IMHO what is needed are "imposter tiles" > > "imposters" are where you use a 'texture only" substitute > for the geometry that are computed on the fly 'often enough' > This is 'radical' LOD but in our case the tiles out on the > boundary are really just 'little slivers' and there is no need for > anyting else. I would think that we could easily lump many > tiles together into these impostors to form a 2 level ring of > 'near' and 'far' "impostors" around our current scenery. Yes, I think that's a very good idea; in fact, if you wanted to go to three layers, the furthest one could be simply untextured, coloured polys (that's what you'd see from 120,000ft, for example). For each tile, we need to sample to find the commonest material and then use it for the texture (and/or colour) at load-time. Curt is worried about joining meshed tiles (with irregular terrain) to flat tiles, but I don't think that will be a big problem if the flat ones are far enough away. If we wanted to, we could also sample the elevation variation for each tile to help us decide how far away it should be drawn as a full mesh: flat tiles could go to a single poly much earlier than mountainous ones, for example. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] new_hitlist
> Erik Hofman writes:
> >
> >I'm realy impressed by the effect of the code. The higher I get, the
> >higher the framerate! This makes me believe we could actually enlarge
> >the view range when getting at a higher altitude.
This would be really nice for very high flying ("X") aircraft.
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] new_hitlist
Erik Hofman writes: > >I'm realy impressed by the effect of the code. The higher I get, the >higher the framerate! This makes me believe we could actually enlarge >the view range when getting at a higher altitude. Cool glad it works for you but IMHO what is needed are "imposter tiles" "imposters" are where you use a 'texture only" substitute for the geometry that are computed on the fly 'often enough' This is 'radical' LOD but in our case the tiles out on the boundary are really just 'little slivers' and there is no need for anyting else. I would think that we could easily lump many tiles together into these impostors to form a 2 level ring of 'near' and 'far' "impostors" around our current scenery. This will of course work best for slow flying aircraft but I don't see any need for these "impostors" to need to be updated ie regenerated any more often then say once per tile change for the "near impostors" and once every 'several' tile changes for the 'far impostors''. This of course could be spread out over tile change period so the effect on the frame rate should be quite small < certainly less then the improvement the new hitlist gives >. Doing something like this would allow flying with an effective tile radius of at least an order of magnitude greater then what you can do now at almost the same fps :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new_hitlist
Norman Vine wrote: > Erik Hofman writes: > >>Norman Vine wrote: >> >> >>>I'd better just go back into lurk mode I guess >>> >>Preferably not. The code improves the framerate by a factor which you >>meantioned earlier, but also makes the framerate quite steady. >> >>So you must have done something right! >> > > The routine is useless if it isn't perfect though :-( Well that's been solved. Thanks! > > But as you say the improvement is rather dramatic esp. when > in the vicinity of an airport and it's MANY 'teeny' triangles :-) I'm realy impressed by the effect of the code. The higher I get, the higher the framerate! This makes me believe we could actually enlarge the view range when getting at a higher altitude. I start from 10 fps on the runway all the way up to 22 fps at 5000 feet (when starting with --disable-skyblend). Deactivating the textures at that altitude gives even 27 fps! This *must* be the right way. ;-) Thanks again Norman. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] new_hitlist
Norman,
This does appear to work great! Thanks for tracking this down. I
able to fly successfully both at KBOS and KSFO which I couldn't do
before.
Thanks,
Curt.
Norman Vine writes:
> Curtis L. Olson writes:
> >>
> >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 ...
>
> Hey thanks for the lecture and I'll leave the
> "PLEASE JUST TRY San Francisco Bay" story for another day
> when we NEED to swap stories about other peoples code being
> bottomless timesinks :-)
>
> >It would be nice to have this code working robustly and integrated.
>
> FWIW
> It looks like I made a dumb typo when I added all the special cases :-(
>
> inside of
> void FGHitList::IntersectBranch( ssgBranch *branch, sgdMat4 m,
>sgdVec3 orig, sgdVec3 dir )
>
> try this
>
> switch ( primType ) {
> case GL_POLYGON :
> case GL_TRIANGLE_FAN :
> IntersectPolyOrFanLeaf( (ssgLeaf *)kid, m, orig_leaf, dir_leaf );
> break;
> case GL_TRIANGLES :
> IntersectTriLeaf( (ssgLeaf *)kid, m, orig_leaf, dir_leaf );
> break;
> case GL_TRIANGLE_STRIP :
> case GL_QUAD_STRIP :
> IntersectStripLeaf( (ssgLeaf *)kid, m, orig_leaf, dir_leaf );
> break;
> case GL_QUADS :
> IntersectQuadsLeaf( (ssgLeaf *)kid, m, orig_leaf, dir_leaf );
> break;
> default:
> IntersectLeaf( (ssgLeaf *)kid, m, orig_leaf, dir_leaf );
> }
>
> Enjoy !
>
> Norman
>
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
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
RE: [Flightgear-devel] new_hitlist
Curtis L. Olson writes:
>>
>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 ...
Hey thanks for the lecture and I'll leave the
"PLEASE JUST TRY San Francisco Bay" story for another day
when we NEED to swap stories about other peoples code being
bottomless timesinks :-)
>It would be nice to have this code working robustly and integrated.
FWIW
It looks like I made a dumb typo when I added all the special cases :-(
inside of
void FGHitList::IntersectBranch( ssgBranch *branch, sgdMat4 m,
sgdVec3 orig, sgdVec3 dir )
try this
switch ( primType ) {
case GL_POLYGON :
case GL_TRIANGLE_FAN :
IntersectPolyOrFanLeaf( (ssgLeaf *)kid, m, orig_leaf, dir_leaf );
break;
case GL_TRIANGLES :
IntersectTriLeaf( (ssgLeaf *)kid, m, orig_leaf, dir_leaf );
break;
case GL_TRIANGLE_STRIP :
case GL_QUAD_STRIP :
IntersectStripLeaf( (ssgLeaf *)kid, m, orig_leaf, dir_leaf );
break;
case GL_QUADS :
IntersectQuadsLeaf( (ssgLeaf *)kid, m, orig_leaf, dir_leaf );
break;
default:
IntersectLeaf( (ssgLeaf *)kid, m, orig_leaf, dir_leaf );
}
Enjoy !
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new_hitlist
> 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. I agree. Can we put vertical walls around each tile, that are transparent for rendering but will be hit during intersection searches ? For all non-airport tiles, there are only four walls so the impact is trivial. Given that premise, we can do our intersection search efficiently for a single tile. Only if the search decides that the vertical wall is the closest triangle do we panic and force a global search of all scenery. The airline people are going to want GPWS and the helicopter people really need radar altimeters. Ground effect modelling by the FDMs also needs accurate terrain heights on the perimeter of airports. The only reason why this looks like a gear problem is because the other features are absent. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] new_hitlist
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 n
Re: [Flightgear-devel] new_hitlist
David Megginson wrote: > Curtis L. Olson writes: > > I had to copy sgdPointInTriangle() as well as one other routine from > > the old hitlist.cxx to get things to compile. We made a decision a > > while back that we wouldn't require a development version of plib, > > but require only the most recent 'stable' version. So, these > > routines need to be included. > > Can we #ifdef them in somehow? How close are the plib folks to a new release? Since we just released 0.7.9, it will be a while before we do another point release of our own. While I'd certainly agree that we want to build against the stable plib for our releases, it doesn't seem so terrible to use the development version for our own inter-release development. The only risk would be that we'd have to wait on them if we wanted to release 0.8.0 before they got to 1.4.3 (or 1.6, or whatever is next). And since David's 3D models are waiting on the wrong-normal-generation fix to the AC3D model loader, we're going to want to require a new version soon, anyway. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] new_hitlist
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 :-( 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. >> I'd better just go back into lurk mode I guess > >I guess you have to eventually pick one side of the fence or the >other. :-) 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] new_hitlist
Norman Vine writes: > the routine has the 'smarts' to try the whole graph if and > when it doesn't get an intersection in the 'current tile' so > the tile boundary thing shouldn't be the problem. Ok, that sounds correct. > 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. > FYI > This was developed against my fork of FGFS which I made > when the view stuff changed a month or so ago and regression > tested against the then current FGFS snapshot where this still > works and I didn't move to the current FGFS code or base until this > morning when I discovered why YASIM was blowing up so I got > fresh CVS snaps and it seemed to work OK against these > so I announced it. > > What has changed !!! Nothing related to scenery structure and representation has changed recently. I've done some work on runway lighting, but that hasn't touched the terrain branch. I'm using plib-1.4.2, have you tried it with the stable plib branch? Maybe there's a bug/difference between the stable/development trees of plib? > Except for the highest level fgCurrentElev() call everything is I believe > FGFS independent ie pure SSG code operating directly with the data > stored in the scenegraph. > > Has the FGFS scenery node linkage changed subtly somehow in > the last month or so ? Not that I'm aware of ... David? > FWIW > It appears to me as if you get one frame of KBOS at the correct > altitude then get pushed into the sky How can you tell that? I thought you said it was working on your end? > Arrgh I really don't know when or even if I'll get to this as I really > have forked the code I am working on and this runs fine there. > > My apologies for the line noise > > I'd better just go back into lurk mode I guess I guess you have to eventually pick one side of the fence or the other. :-) 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
Re: [Flightgear-devel] new_hitlist
Curtis L. Olson writes: > I had to copy sgdPointInTriangle() as well as one other routine from > the old hitlist.cxx to get things to compile. We made a decision a > while back that we wouldn't require a development version of plib, > but require only the most recent 'stable' version. So, these routines > need to be included. Can we #ifdef them in somehow? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new_hitlist
Norman Vine wrote: > My apologies for the line noise > > I'd better just go back into lurk mode I guess Preferably not. The code improves the framerate by a factor which you meantioned earlier, but also makes the framerate quite steady. So you must have done something right! :-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] new_hitlist
Curtis L. Olson writes: > >Norman Vine writes: >> tarball for new hitlist code >> http://www.vso.cape.com/~nhv/files/fgfs/new_hitlist.tgz >> >> For those of you not using the CVS version of PLib >> you will need a copy of sgdPointInTriangle() >> from the older hitlist.cxx this one replaces > > >I'm finding that I get wrong elevations reported for portions of >airports that span multiple tile boundaries. Such airports are >attached to one particular tile in the scene graph, but they can >extend into neighboring tiles. For instance, KBOS (Boston) sits right >on top of the corners of 4 tiles. However, in the scene graph it is >root below only one tile (chosen arbitrarily for all practical >purposes.) the routine has the 'smarts' to try the whole graph if and when it doesn't get an intersection in the 'current tile' so the tile boundary thing shouldn't be the problem I'll try testing with KBOS again but I was teleporting there as part of my regression testing because of its unique tile arrangement Yikes good catch :-( Hmm. hey this still works in my test bed :-) FYI This was developed against my fork of FGFS which I made when the view stuff changed a month or so ago and regression tested against the then current FGFS snapshot where this still works and I didn't move to the current FGFS code or base until this morning when I discovered why YASIM was blowing up so I got fresh CVS snaps and it seemed to work OK against these so I announced it. What has changed !!! Except for the highest level fgCurrentElev() call everything is I believe FGFS independent ie pure SSG code operating directly with the data stored in the scenegraph. Has the FGFS scenery node linkage changed subtly somehow in the last month or so ? FWIW It appears to me as if you get one frame of KBOS at the correct altitude then get pushed into the sky Arrgh I really don't know when or even if I'll get to this as I really have forked the code I am working on and this runs fine there. My apologies for the line noise I'd better just go back into lurk mode I guess Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new_hitlist
Norman Vine writes: > tarball for new hitlist code > http://www.vso.cape.com/~nhv/files/fgfs/new_hitlist.tgz > > For those of you not using the CVS version of PLib > you will need a copy of sgdPointInTriangle() > from the older hitlist.cxx this one replaces Norman, Thanks for your continued work on this section of code. Just a quick report for those that may want to try this code out before some fixed version of this can be put in cvs. I had to copy sgdPointInTriangle() as well as one other routine from the old hitlist.cxx to get things to compile. We made a decision a while back that we wouldn't require a development version of plib, but require only the most recent 'stable' version. So, these routines need to be included. I'm finding that I get wrong elevations reported for portions of airports that span multiple tile boundaries. Such airports are attached to one particular tile in the scene graph, but they can extend into neighboring tiles. For instance, KBOS (Boston) sits right on top of the corners of 4 tiles. However, in the scene graph it is root below only one tile (chosen arbitrarily for all practical purposes.) I don't know if that helps you track down what's going on. If no one else can reproduce this problem in this latest code (from Norman's web site, not yet commited to cvs), then let me know ... maybe I screwed up something on this end. Being that this code is critical to the overall operation of the sim, I can't commit these changes just yet. We obviously need something that works reliably in every situation, even if it isn't as optimal as it could be. Hopefully it's an easy fix ... (?) Thanks again, 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
[Flightgear-devel] new_hitlist
tarball for new hitlist code http://www.vso.cape.com/~nhv/files/fgfs/new_hitlist.tgz For those of you not using the CVS version of PLib you will need a copy of sgdPointInTriangle() from the older hitlist.cxx this one replaces Enjoy Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
