Georg Vollnhals schrieb: > 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) > I hope/think that I don't have to care about the .btg file format. I would like to plug my stuff into the code somewhere "downstream" from the point where the terrain is loaded from the .btg file, and ignore how and from where it is loaded. When the triangles are instantiated in the scene graph, it must be possible to get the world coordinates of their vertices and apply the textures based on this information. > 3. split the new texture into the sizes of all given triangles using the > precalculated triangles area/lat-lat-corners > Well, no. You wouldn't split up the textures. First, it's not possible (as far as I know, textures are always rectangular, I have never heard of triangular textures. Correct me if I'm wrong). Second, there's no reason to do so. You simply work with big textures that cover many triangles, and you do this by telling your 3D engine which area of the big texture should be mapped onto which triangle. This is not specific to my plan, it's the standard solution (I'm pretty sure you know this from Blender).
> 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. > This would be one theoretically possible solution to handle the "irregular triangulation problem" (see the conversation with Harald Johnsen). Practically, I think it would be very complicated. In my concept, the texture generation process knows nothing about the underlying and surrounding triangulation and texturing of the terrain at the place where a certain texture tile will be mapped. So you don't know when, where and how you'd have to do this texture merging. The two methods discussed with Harald Johnsen are probably better ways to go. > 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 > Well, as explained above and also noticed by yourself here: There's no "one triangle - one texture"-association, and we don't need or want it. You can happily forget points 4 to 6 :). > _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. > As far as I know, each .btg file contains a number of complete tiles, and the border of a scenery described in one .btg files consists of the borders of the tiles in the border area. When we map one texture on one tile (or several textures on one tile, but no texture across several tiles), there should be no problem here. > 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. > As for the way an end-user (scenery designer) would make use of my approach: First, it should be possible to implement some kind of interface (xml file?) to change the parameters of the automatic "pseudo aerial image" generation process. This would give you a way to control -what- is rendered and how it looks. Second, if we save these auto-generated textures on the hard disk (what should generally be a good idea for performance reasons), you could load them into an image manipulation program and add your own stuff or, for example, replace the auto-generated images with real aerial photos (if you have them and you're allowed to use them for FlightGear). In other words, you could paint anything anywhere. There are "endless possibilities", if only the texture resolution is high enough. With best regards, Sebastian PS.: Did you try my patch? ------------------------------------------------------------------------- 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
