Harald JOHNSEN schrieb: > Sebastian Bechtold wrote: > > >> Yes, that's true. This might really be something that makes the >> implementation a bit more complicated. Currently, I have two >> ideas to solve this problem: >> >> 1.) >> Apply the textures on tile-level. The tiles have a regular rectangular >> shape, so you could map one texture on one tile, without any >> overlapping. A problem with this could be the dimensions. You'd need >> quite large textures to get an acceptable low value of square-meters per >> pixel. I don't yet know enough about 3D programming to judge if this >> is feasible or not (hardware-limited maximum texture size, OSG / FlightGear >> performance with handling such huge textures and so on), but at least >> we could try it. >> >> 2.) >> Use smaller textures (for example 2x2 or 4x4 per tile) and draw >> overlapping redundant borders to their neighbor textures. Mhh...I have >> problems to write a good explaination of this in english...I mean...near the >> borders of each texture (for example a 100 Pixel wide "frame"), you draw >> exactly the same pixels as you draw on the corresponding "frame" of the >> neighbor >> texture in each direction. You would then apply the textures so that they >> "overlap" and decide with triangle in the "border area" is filled with >> which >> one of four adjacent textures. When the "frames" are wide enough to >> cover every >> irregular shape that could occur, it should be possible to handle the >> problem this way. >> >> A clear disadvantage of this approach is, of course, the additional graphics >> memory requirement, and it's perhaps a bit harder to implement. >> >> I don't know what's better or if there are other, better ways to solve this. >> Feel free to help finding a solution! :) >> >> >> Cheers, >> >> Sebastian >> >> >> > The point 1) will give worse ground texture than today if we set the > texture size at 4090^2. > The point 2) is better except that this 100 pixel border is arbitrary. > Sometimes it will be ok but i'm afraid there is some triangles that will > go very far inside adjacent texture (some sea triangles inside the bay > are very long for example). > But if the the real problem is those anoying triangle why not simply > delete them ? Frankly we don't care about the geometry in the btg file, > we just need a height field, let just built this grid and voila (this is > for the display, the btg is still used for agl computation, > intersection, etc or not because finding a height in a grid is instant, > no more sequential scan of a soup of triangles).
Mh...I have to admit that I can't completely follow your words here. You talk about deleting the problematic triangles. Do you mean deleting at runtime or by rebuilding the scenery file? If possible, I'd like to try to do this without doing such further changes. I'd like to avoid a plan where one feature requires another, and this one requires another again, and so on. The more you change, the higher is the risk of unplanned side effects and work to adapt other things to the changes. As I've already said: For myself, some kind of "golden rule" here is to change as little of the existing concepts and code as possible. This may rise problems which require some odd and maybe suboptimal solutions, but I think that's still better than running into a situation where the list of things which have to be changed is growing longer and longer. Not to mention the inacceptable problems related to project coordination and the different opinions everyone has. I also think that the ground texture resolution you'd get with one big texture per tile won't be that good. Especially not when your original intention to do this was to make things like road markings(!) possible. In the end, the ground might look worse than before. But anyway - I'm convinced that this is in principle an important feature which opens the door to a lot of visual improvements, given that texture resolution and performance are fine. So I think it's absolutely worth working on it. If the first version won't pay off, there will surely be ways to improve it. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
