Re: [Flightgear-devel] Will my updates be used/useful?
On Sunday 15 January 2006 12:08, Christian Mayer wrote: (*) unless you want to get fancy with blending the textures, etc. pp. But this will create an big overhead. Well yes but a half decent scenery engine using texture blending like the one in X-Plane and MSFS would do just fine and they actually run faster than FG when I increase the visibility to about 50km or greater. We must be doing something wrong to get the worst of both worlds. Paul --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Will my updates be used/useful?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Paul Surgeon schrieb: On Sunday 15 January 2006 12:08, Christian Mayer wrote: (*) unless you want to get fancy with blending the textures, etc. pp. But this will create an big overhead. Well yes but a half decent scenery engine using texture blending like the one in X-Plane and MSFS would do just fine and they actually run faster than FG when I increase the visibility to about 50km or greater. We must be doing something wrong to get the worst of both worlds. Have you compared the frame rates when everything apart from the ground is disabled (no other planes and no objects on the ground)? Is the resolution the same (IIRC FGFS has a resolution of 30 or 40 meters)? Does X-Plane or MSFS use a CLOD algorithm or are they tile based (do those tiles have LOD or not)? If we know the answers to those questions are the same for FGFS and the other simes we can try to compare texture blending vs. not texture blending. CU, Christian --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Will my updates be used/useful?
Hi all, my reading of the situation; a) No adjustment of the textures takes place at the moment for sloping terrain...hence the stretch problem. b) a cylindrical solution has been proposed(that I don't understand the maths of) that may/will have an unacceptable performance hit. c) x-plane and MSFS have solutions to this problem that look great and don't have a performance hit at 50km distance (assumption; at 50km they do have a performance hit) d) we put up with seams with very little performance hit has anyone actually tested the various options to quantify the performance hits and/or the visual effects involved in the various solutions. Objective data would certainly be helpful? or we could all join the flat earth society g Cheers Dene From: Paul Surgeon [EMAIL PROTECTED] On Sunday 15 January 2006 12:08, Christian Mayer wrote: (*) unless you want to get fancy with blending the textures, etc. pp. But this will create an big overhead. Well yes but a half decent scenery engine using texture blending like the one in X-Plane and MSFS would do just fine and they actually run faster than FG when I increase the visibility to about 50km or greater. We must be doing something wrong to get the worst of both worlds. Paul _ Become a fitness fanatic @ http://xtramsn.co.nz/health --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Will my updates be used/useful?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 dene maxwell schrieb: Hi all, my reading of the situation; a) No adjustment of the textures takes place at the moment for sloping terrain...hence the stretch problem. b) a cylindrical solution has been proposed(that I don't understand the maths of) that may/will have an unacceptable performance hit. c) x-plane and MSFS have solutions to this problem that look great and don't have a performance hit at 50km distance (assumption; at 50km they do have a performance hit) d) we put up with seams with very little performance hit has anyone actually tested the various options to quantify the performance hits and/or the visual effects involved in the various solutions. Objective data would certainly be helpful? a), b) and d) would have *no* runtime performance hit. b) has a scenery generation performance hit (that depends on the number of vertices that belong to one terrain type) d) has a little, neglectable scenery generation performance hit - but the visual results would be really ugly c) would have a runtime performance hit (i.e. the frame rate drops) I don't know the quantities of the hits though. But I'd try b) first as it's compatible to the current approach and doesn't create any runtime overhead. CU, Christian --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: OSG? was Re: [Flightgear-devel] Re: Graphics Engine
Hi, On Saturday 14 January 2006 19:07, Ampere K. Hardraade wrote: That was a suggestion. I current am not working on any document regarding the graphic engine, so I have nothing to share. However, I along with several others, are working on a document regarding the architecture of FG. If you have concrete plans, you need to put them in a document so those people who want to help can understand what you are trying to do, then make addition or proposal modifications to some of your ideas. Well not that concrete. :) It is just that I have already a plan in my desk if we want to do that. A plan which has prooven good in an other projekt. I have for example a list of things just required to be done before. I believe it is out of discussion that the ac reader must just work like the plib one does. The idea is to get the design and analysis done before writing a single line of code. For a project as big as FlightGear, writing design reports should not be an option; it should be a must. Well, a scenegraph is a scenegraph - more or less. At least in this direction. There is nothing I know of you can do with plib you cannot do with osg. There are aprioriate callbacks in osg so that you can implement the animation infrastructure like we have it with ssg*. So there is not much design to do in this area. Given that the precautions are are all satisfied, that is - all required loaders for osg work like expected, - we have an additional loader for the scenery files - we have a good tri/quad striper for osg geometries. - we have a short proof of concept to see how this interacts with pui and most important - *we* have *decided* to do that(!) then, I think the plan would be as follows: - build up a very thin envelope around the ssg* calls just taking scenegraph independent datastructure which could be translated to the aprioriate scenegraph. The best case is here that the datatypes are scenegraph independent but fit directly into the ssg functions directly. That is how I designed that vectors this discussion started from. Consequently no copying needs to be done. The envelope calls will be inlined and optimized away. - From that point we will not have any direct ssg call in the sources except in that envelop classes. - Now we can provide a set of envelop classes with osg as backend. - Now see how we can integrate our direct OpenGL calls into that stuff to make it work with both envelopes. - Past that we can play with that and can even easily go back if there are some unsolvable problems (I do not expect them). - If osg turns out the way to go, one can remove the ssg envelopes and may remove the indirections through the osg envelope. - Now you are really free to just use the cool features osg provides. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: OSG? was Re: [Flightgear-devel] Re: Graphics Engine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mathias Fröhlich schrieb: The sg* vectors and matrices are created in such a way that they'll offer the higest possible performance and compatability for using OpenGL. column major like fortran :) Well, I worked, together with some collegues, on getting a linux cluster into the top500 some time ago :) Good to hear. (BTW: my diploma thesis [= roughly a masters thesis] was the creation of cache oblivious matrix operations in C++ using the space filling Peano curve; I could beat the Intel Math Kernel Library in optimal cache use - und even performance wise when I used only x87 instructions :) I put the code and the thesis at http://tifammy.sf.net/ Space filling curves have very interesting properties for high performance computing - not only for cache efficiency but also for partitioning of problems for parallel computers / clusters) Yep, I believe that this small vector set will even provide more performance since it will just work with all ss?g* functions natively. Instead of that horrible mix of sg* and simgear point3d datatypes we have at the moment, which do not interface well and thus needs masses of hand coded copies from one datatype to the other. You can just use such a thing as a drop in replacement for any sg type. At the times I did active FGFS development I also didn't like the many different vector classes. It takes me regularily needless time to clearify what I have in my hands if I get a Point3D datatype. Different classes (or just class names) sound like an good idea. It might be interesting to offer the use of SSE values internally. This could give a little performance boost for modern IA-32 processors. CU, Christian --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: OSG? was Re: [Flightgear-devel] Re: Graphics Engine
Hi, On Sunday 15 January 2006 12:54, Christian Mayer wrote: (BTW: my diploma thesis [= roughly a masters thesis] was the creation of cache oblivious matrix operations in C++ using the space filling Peano curve; I could beat the Intel Math Kernel Library in optimal cache use - und even performance wise when I used only x87 instructions :) I put the code and the thesis at http://tifammy.sf.net/ Space filling curves have very interesting properties for high performance computing - not only for cache efficiency but also for partitioning of problems for parallel computers / clusters) Sounds interresting. Downloaded that matrix kernels. ... let's see what I can make use of :) What did you study? Yep, I believe that this small vector set will even provide more performance since it will just work with all ss?g* functions natively. Instead of that horrible mix of sg* and simgear point3d datatypes we have at the moment, which do not interface well and thus needs masses of hand coded copies from one datatype to the other. You can just use such a thing as a drop in replacement for any sg type. At the times I did active FGFS development I also didn't like the many different vector classes. Yep, the aim is that you have an intuitive usable thing you can use directly with the scenegraph. It might be interesting to offer the use of SSE values internally. This could give a little performance boost for modern IA-32 processors. Well, wait for gcc 4.2. There is much work going on in the direction of autovectorization. The tree optimization infrastructure has brought many improovments for optimizations. But a patch which has arrived yesterday in the svn head revision makes now definitly use of that. Richard Günther has yesterday checked in a patch which makes gcc see that array elements of the same array with different indices cannot alias. This now opens the door to do autovectorizations for small arrays. There is a tunable maximum array length of 4, but first tests with 16 for the typical transform matrices have shown that gcc now uses some addp[sd]'s instead of the unpacked versions ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: OSG? was Re: [Flightgear-devel] Re: Graphics Engine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mathias Fröhlich schrieb: Hi, On Sunday 15 January 2006 12:54, Christian Mayer wrote: (BTW: my diploma thesis [= roughly a masters thesis] was the creation of cache oblivious matrix operations in C++ using the space filling Peano curve; I could beat the Intel Math Kernel Library in optimal cache use - und even performance wise when I used only x87 instructions :) I put the code and the thesis at http://tifammy.sf.net/ Space filling curves have very interesting properties for high performance computing - not only for cache efficiency but also for partitioning of problems for parallel computers / clusters) Sounds interresting. Downloaded that matrix kernels. ... let's see what I can make use of :) What did you study? Technomathematik (= applied mathematics) Oh, I've just seen that I didn't link the thesis yet. Should be there under documentation in a few minutes It might be interesting to offer the use of SSE values internally. This could give a little performance boost for modern IA-32 processors. Well, wait for gcc 4.2. gcc isn't the only compiler though. For the IA-32 are at least the MSVC++ and the Intel ICC important, too. And my expericence (with ICC) are, that the vectorisation does only work for loops. The code of my thesis uses recursions and explicitly coded operations. The ICC wansn't able to auto vectorise any of those. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDyj2LlhWtxOxWNFcRAtuRAJ9UXqusko5friqZfIWRXwcYElst7gCgpEyK xsMhESvH1STx6Y7K+9oF5fc= =V/7g -END PGP SIGNATURE- --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: OSG? was Re: [Flightgear-devel] Re: Graphics Engine
Hi, On Sunday 15 January 2006 13:18, Christian Mayer wrote: Technomathematik (= applied mathematics) Karlsruhe? Mathematician from Tübingen, did numerical analysis, mostly timestepping. Oh, I've just seen that I didn't link the thesis yet. Should be there under documentation in a few minutes Thanks! It might be interesting to offer the use of SSE values internally. This could give a little performance boost for modern IA-32 processors. Well, wait for gcc 4.2. gcc isn't the only compiler though. :) For the IA-32 are at least the MSVC++ and the Intel ICC important, too. And my expericence (with ICC) are, that the vectorisation does only work for loops. The code of my thesis uses recursions and explicitly coded operations. The ICC wansn't able to auto vectorise any of those. Ok, interresting. I heared that MSVC does vectorization for some time. But as long as I am that used to unix in contrast to windows, MSVC is not an option for me :) ICC is something I play with at some times. But I never tried how it vectorizes. Also the gcc development is much more interresting since you can watch that development including the internal comments. With closed compilers you can see marketing headlines which mostly do not have any technical relevance ... ... 'see now you have only two clicks to refactor whatever' :) Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: OSG? was Re: [Flightgear-devel] Re: Graphics Engine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mathias Fröhlich schrieb: Hi, On Sunday 15 January 2006 13:18, Christian Mayer wrote: Technomathematik (= applied mathematics) Karlsruhe? Nope, TU München Mathematician from Tübingen, did numerical analysis, mostly timestepping. Numerics is also the stuff that I do most (as well as lots of fluid dynamics). And my expericence (with ICC) are, that the vectorisation does only work for loops. The code of my thesis uses recursions and explicitly coded operations. The ICC wansn't able to auto vectorise any of those. Ok, interresting. I heared that MSVC does vectorization for some time. I've only used the .NET 2003 version (i.e. 7.1 IIRC). And that couldn't do any vectorisation. It could use the scalar SSE instructions instead of the x87 though (they are faster for the Pentium 4; my Pentium M was a bit slower) Also the gcc development is much more interresting since you can watch that development including the internal comments. With closed compilers you can see marketing headlines which mostly do not have any technical relevance ... Yes, but at least a shot time ago the IIC was supposed to do better optimisations (I *think* that's still true - but have no measurements) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDykD8lhWtxOxWNFcRAg0vAJ4oGTbTR87EUl5kHAM0zSjOkeO6fQCgjVVZ URw5Mepsztd5voZAZAbzVTg= =RXXx -END PGP SIGNATURE- --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: OSG? was Re: [Flightgear-devel] Re: Graphics Engine
Hi, On Sunday 15 January 2006 13:33, Christian Mayer wrote: Numerics is also the stuff that I do most (as well as lots of fluid dynamics). Ok, so you are actually writing on your PHD? Ok, interresting. I heared that MSVC does vectorization for some time. I've only used the .NET 2003 version (i.e. 7.1 IIRC). And that couldn't do any vectorisation. It could use the scalar SSE instructions instead of the x87 though (they are faster for the Pentium 4; my Pentium M was a bit slower) Ok, just the scalar ones is not something really interresting ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: OSG? was Re: [Flightgear-devel] Re: Graphics Engine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mathias Fröhlich schrieb: Hi, On Sunday 15 January 2006 13:33, Christian Mayer wrote: Numerics is also the stuff that I do most (as well as lots of fluid dynamics). Ok, so you are actually writing on your PHD? Nein. Ich muß erst noch die Hauptdiplomprüfungen im Februar/März überstehen. Dann mach evtl. bei BMW einen Dr. (falls die endlich mit der Stelle in die Gänge kommen...) oder suche mir eine normale Anstellung. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDykvJlhWtxOxWNFcRAiHcAKCgul5yHNBTNnG+4DXW7LHrQAO4XACfZ2/a lYC6WXncQr718+wvIWCN4dA= =7FF2 -END PGP SIGNATURE- --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: OSG? was Re: [Flightgear-devel] Re: Graphics Engine
Hi Aem, sorry for that noise, As Christian started to reply in german, I thought that we have private mails Sorry! Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Will my updates be used/useful?
dene maxwell wrote: Hi Paul, From: Paul Surgeon [EMAIL PROTECTED] On Sunday 15 January 2006 10:25, dene maxwell wrote: Hi Paul, to my way of thinking the resolution is not important. Pythagarus is more important, the distance as seen in a birds-eye view as seen by FGSD is not the distance of the terrain. Hence if you cut a material to a birds-eye distance of say 10 what ever units it will be stretched to say 14.14 units when the slope is 45 degrees. The greater the slope the larger the slope distortion, in the nth degree a vertical slope will have zero length stretched to infinite length. Dene What I mean is that from a top down view you need to increase the resolution of textures on the slopes so that when you look at the slope from a perpendicular angle you still get the same resolution as on flat ground. Example : If a flat piece of ground has a texture resolution of 1m/pixel then a slope of 45 degrees should also have a texture resolution of 1m/pixel if you look at it from a perpendicular perspective. agreed A 45 degree slope viewed from the *top* should have a texture resolution of 0.707 m/pixel. So from a top down view the texture resolution will be higher. This will unstretch those slope textures. Paul this certainly seems to follow the geometric logic. One problem...it doesn't seem to work. Without being familiar with the code concerned, my impression is that this logic is not being applied in a way that produces the desired result or something very important is being over looked in the logic. Perhaps applying this sinusoidal algorithm is the problem, why not try giving all perspectives a 1m/pixel view and see if the result is more pleasing? This might aleast give some idea where the observed stretching is occurringyeah? Here's the downside though ... if you change the texture resolution or how you project the texture onto the surface based on slope, then you lose the seamless tiling across triangle edges. We eventually need to come up with a better way to blend/dither non-tiled edges together, but for the moment we can't do that. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: OSG? was Re: [Flightgear-devel] Re: Graphics Engine
Mathias Fröhlich wrote: Hi Aem, sorry for that noise, As Christian started to reply in german, I thought that we have private mails Sorry! I was reading through the thread this morning and as it progressed there were more and more german words intermixed and then wham all german. I've been working on a large vehicle steering and guidance controller (snowplow/truck) for my day job and if pavement==english and grass==german, the language use of this thread, closely approximates what my truck does if I try to drive through a corner too fast. :-) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Will my updates be used/useful?
Ralf Gerlich writes: Hi, Paul Surgeon schrieb: When TerrorGear does the UV mapping calculations on the terrain polys it should take the terrain slope into account. Flat ground = standard resolution More slope = higher resolution I think the only point where TerraGear assign UV coordinates is during generation of airports (texture coordinates for the taxiways and runways). All the other UV calculations are done by FlightGear when loading the tile, IIRC. No, I'm pretty sure that TerraGear does them all. In the past I've extended the TerraGear uv generator to allow seamless tiling of the OSGB36 grid [--useUKgrid], and within a UTM zone, to remove the discontiunity at degree-latitude lines that the current TerraGear scheme gives, so unless something drastic has changed since then, it's definiately TerraGear that generates them. FG does the ocean tile though, IIRC. With regards to the slope texture stretching, unless I'm very much mistaken I've seen exactly the same problem in MSFS 2002. Cheers - Dave --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A little experiment with KSFO
On January 13, 2006 08:04 pm, Ampere K. Hardraade wrote: The process is trivial. In each file, there are lines that represent latitude and longitude. http://204.108.4.16/d-tpp/0513/00375AD.PDF The user would first use a program like Inkscape to rename at least four of those lines to the latitude and longitude that they represent. Then, he/she would use a custom program to generate a new SVG file that have all the vertices of the airport in their proper location. (Alternately we could integrate this program into FG, so that the users don't have to go through an extra step.) The program would recongize those latitude and longitude lines by their id field. The correct coordinates of a vertex in the SVG file could then be computed by finding the shortest-distance between that vertex and the latitude/longitude lines. It is simple algebra, but we need someone to code it. Ampere Okay, here is a little example: http://www.cs.yorku.ca/~cs233144/export_ksfo2.svg Open the file in a text editor, and search for the strings lat and long. You should find the followings: line id=lat37:36N y2=1.0930041 x2=0.062879607 y1=1.0381277 x1=-0.015509823 inkscape:label=#line3669 / line id=long122:24W y2=0.28113425 x2=0.18312363 y1=0.49137598 x1=0.03586068 inkscape:label=#line3671 / line id=lat37:38N y2=0.5338757 x2=0.48925012 y1=0.28250575 x1=0.13024202 inkscape:label=#line3691 / line id=long122:23W y2=0.25000599 x2=0.54600322 y1=0.49837247 x1=0.37225437 inkscape:label=#line3687 / So, we know what latitude/longitude the lines represent, and we know the end points of each of those lines. Now, we can use the method shown here: http://mathcentral.uregina.ca/QQ/database/QQ.09.04/carly1.html to calculate the latitude and longitude of each vertices in the SVG file. As I said, simple Algebra. :) Ampere --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Will my updates be used/useful?
Hi Curt, I suppose I'm less sensitive to the abrupt change problem as most of the scenery both face material and triangle edges show some form of abrupt change due the the mountainous terrain that covers most of the country. Personally I like the blending solution for edges although this still doesn't solve the stretching problem. This could possibly be done for both face material changes and slope changes (smoothed edges) There seem to be two issues; a) the stretching on slopes and b) the seamless edges. At the moment we have pretty much seamless edges on adjacent tiles of the same face material. This isn't the case for edges on adjacent tiles of different face material. This is a known issue. I suggested a way to try and get a handle on it, unfortunately this would be at the cost of seamless edges. But this investigation process doesn't have to effect the production version. Could this be done locally by someone who can implement different slope alogrithms and report back findings. I think the objective data would assist, rather than what appears to be most subjective assessment albeit very well educated. I might be way off target here and I hope that I haven't caused offence to anyone. I realise I'm making rather bold statements for a newbie. Cheers Dene From: Curtis L. Olson [EMAIL PROTECTED] dene maxwell wrote: Hi Paul, From: Paul Surgeon [EMAIL PROTECTED] On Sunday 15 January 2006 10:25, dene maxwell wrote: Hi Paul, to my way of thinking the resolution is not important. Pythagarus is more important, the distance as seen in a birds-eye view as seen by FGSD is not the distance of the terrain. Hence if you cut a material to a birds-eye distance of say 10 what ever units it will be stretched to say 14.14 units when the slope is 45 degrees. The greater the slope the larger the slope distortion, in the nth degree a vertical slope will have zero length stretched to infinite length. Dene What I mean is that from a top down view you need to increase the resolution of textures on the slopes so that when you look at the slope from a perpendicular angle you still get the same resolution as on flat ground. Example : If a flat piece of ground has a texture resolution of 1m/pixel then a slope of 45 degrees should also have a texture resolution of 1m/pixel if you look at it from a perpendicular perspective. agreed A 45 degree slope viewed from the *top* should have a texture resolution of 0.707 m/pixel. So from a top down view the texture resolution will be higher. This will unstretch those slope textures. Paul this certainly seems to follow the geometric logic. One problem...it doesn't seem to work. Without being familiar with the code concerned, my impression is that this logic is not being applied in a way that produces the desired result or something very important is being over looked in the logic. Perhaps applying this sinusoidal algorithm is the problem, why not try giving all perspectives a 1m/pixel view and see if the result is more pleasing? This might aleast give some idea where the observed stretching is occurringyeah? Here's the downside though ... if you change the texture resolution or how you project the texture onto the surface based on slope, then you lose the seamless tiling across triangle edges. We eventually need to come up with a better way to blend/dither non-tiled edges together, but for the moment we can't do that. Regards, Curt. _ Discover fun and games at @ http://xtramsn.co.nz/kids --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New JSBSim code
Richard Harrison wrote: I 100% agree with the way Jon has fixed this. Suggesting that there is simpler way of doing it indicates a lack of understanding of the complexities. Yes, of course. I didn't say the way it's fixed is bad, or that it doesn't work. But as I never tried to code a FDM myself I really lack an understanding of the complexities, and so I ask. I'd say the question is the beginning of wisdom :) I do not demand an answer, but if someone has a document or something about this at hand, so I can understand it better, it would just be nice. I'm always interested in learning. Nine --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
