Sebastian Bechtold schrieb:
..
> 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.
...
Hi Sebastian,
once again my suggestion would be in accordance to your point of view
a) to _minimize all changes to the actual given code
_b) doing all work and calculation *off* runtime .
Then it should be possible to
1. have the lat/lon coordinates calculated for all 4 corners of the used
_new texture_ of any size
2. calculate the lat/lon coordinates of every corner of every _triangle_
out of the *.btg file and sort the tiles
(the fileformat is sure documented anywhere, I looked for it but did not
find any documentation)
3. split the new texture into the sizes of all given triangles using the
precalculated triangles area/lat-lat-corners
3.a uncomplicated for all triangles fully located within the new
texture area = only new texture is used
3.b more problematic for "boarder triangles" only partly located
within the new texture area = merging of "old" ground texture for the
outside part and "new" texture for the inside part has to be done.
4. this results in a special ground-texture for every given triangle
5. there must be already a marker in the actual *.btg format for every
ground-triangle which ground-texture to use.
But there is only a limited number of ground-textures and therefore
the marker might not have the data-format for a *big* number
of different ground-textures (what would be necessary if we split
bigger textures and create a lot of different new ground-textures).
So a slight change of the *.btg format might be necessary.
6. With this the actual display-routines for OSG and PLIB should work
principally, only the new *.btg data-format (for the really bigger
number of available ground-textures) must be handled
_I know, this solution is suboptimal but can be made with a overviewable
amount of coding_ (and therefore the chance to have very little
negative sideeffects) but makes a big ground-texture improvement
possible. And I know that this can really get more complicated if the
new ground-texture-area uses partly 2 or more *.btg files.
Once working pretty well, this changes could be improved more and more
in little further steps - that is what everyone likes to avoid big
coding-problems.
Some years ago I did this for X-Plane with own new groundtextures from
Landsat 7 . This was a lot easier as a) the used data-format was well
documented b) there where only little squares with regular size to split
the big texture to (very easy to handle, OLD X-Plane elevation data
format, has changed since then). But I think it was _generally_ the same
process to improve the ground-view as I suggested from 1 to 6 and should
therefore work for FlightGear as well.
Just my thoughts :-)
Regards
Georg EDDW
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
