Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (especially addressing Harald Johnsen)

[Sebastian B. <seb...@we...>]

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.