Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (especially addressing Harald Johnsen)
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
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (especially addressing Harald Johnsen)
Sebastian Bechtold schrieb: Georg Vollnhals schrieb: ... 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. Ok, I'll wait and see :-) Almost everything will be better than the actual state. With best regards, Sebastian PS.: Did you try my patch? Well, I had a lot of workload at the end of last week as I worked some days from 7:00 am to sunset around 10:00 pm. So there was not so much time for FlightGear. Sometimes I am able to look at the forum or eMail, but I have no FG to do any work with (I only have a very old and poor performing laptop :-/ ). This whole weekend I am working on call (and just came back home) and if my mobile phone is quite for some hours I would like to compile and test your nice patch. Of course, I will give feedback to you, as I am really interested in this feature :-) Thank you once again for explaining me what you would like to do. Regards Georg - 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
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (especially addressing Harald Johnsen)
Harald JOHNSEN schrieb: Sebastian Bechtold wrote: Your thread title is misleading, Sorry, but I don't think so. The title describes my intentions pretty well. what you really want to do is to add layers, so to add some geometry drapped around the terrain. No, I don't I want to do that. I want to do what I've been talking about in my posting. Best regards, Sebastian Ok, I was reading a bit fast and saw rounded curve and you'll never get that with textures. The texture mapping we are using today is done with the function in simgear/texcoord.cxx. I supposed you've read the explanation of how it's done in msfs on the fsinsider site, the problem I see here is that we do not have a regular mesh grid so we will have the boundary triangles that will span on several textures. In msfs they have a regular grid (it's just a height map) so the mapping is direct. 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 - 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
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (especially addressing Harald Johnsen)
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). HJ. - 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
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (especially addressing Harald Johnsen)
Hi! Harald JOHNSEN wrote: The point 1) will give worse ground texture than today if we set the texture size at 4090^2. Not necessarily. Currently we have the same basic texture resolution everywhere. With the approach Sebastian wants to try one could use tiles of different sizes depending on the distance from the viewer. Which may or may not be a good thing but we won't know until somebody tries. 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). There won't be triangles oriented along the bay. If I understood Stefan right, there will be a regular triangle grid depicting the elevation structure and the borders between different regions will be depicted by a change in the master texture. 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). Exactly. The question that comes to mind is whether OpenSceneGraph does not already have support for such a thing. The applications of OSG I have seen seem all to use this concept so maybe it is reasonable to believe s.th. like that has been included in OSG? Mathias? As I said I'm skeptical about the outcome, but I would say it's worth a try. Sebastian seems to be committed, so why not? Cheers, Ralf - 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
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (especially addressing Harald Johnsen)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Gerlich wrote: Hi! Harald JOHNSEN wrote: 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). Exactly. The question that comes to mind is whether OpenSceneGraph does not already have support for such a thing. The applications of OSG I have seen seem all to use this concept so maybe it is reasonable to believe s.th. like that has been included in OSG? Mathias? OSG has primitive support for rendering heightfields, but it has good support for producing geocentric (even whole earth), paged databases with overlay textures and Level-Of-Detail from DEMs... the same sources that FlightGear uses. The polygons are not a grid but a TIN. So if you really want to depart from the btg format, there you go. See http://www.openscenegraph.com/projects/VirtualPlanetBuilder. I don't think this scheme is the best possible, and you'd still need to support the surface properties somehow, but it gets a lot of use from the OSG community. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGjk6deDhWHdXrDRURAqLJAJ9IUCqQ6ADdPsPsPIeKVKI59PxakACdGXbZ qFb72DUrZlT2XdWj/HjXIb0= =MkkV -END PGP SIGNATURE- - 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
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (especially addressing Harald Johnsen)
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
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (especially addressing Harald Johnsen)
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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
