[Flightgear-devel] Simple math
A quick question I almost hate to ask. Is there any way to do simple math from within the xml files? For example, in the windows 0.9.2 version, when I created a display to show the magnetic compass in a digital format, it rolled to negative numbers (depending on variance). Is there a way to correct this, along with other quirks without a ridiculously long list of conditions based on manually displaying every corrected negative number? This problem of variance seems to show its head on various calculations. Another example would be in the raw data from the ADF values in the kr-87 radio. The raw data appears to be uncorrected for variance. Any advice or suggestions would be appreciated. Thank you, Marisa ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with AC3D 4.0
* [EMAIL PROTECTED] (Andy Ross) [2003.10.29 18:09]: > Some "before & after" FlightGear screenshots are available at: > > http://www.plausible.org/vertsplit > > [Be patient if things seem slow; there is 400k of images on that page >and my DSL line has a 128kbps upload rate. If you don't want to >wait, download the code instead and try it for yourself. :)] > http://www.plausible.org/vertsplit/vertsplit.tar.gz I almost gave up on loading the page. Here's a mirror: http://unbeatenpath.net/software/fgfs/www.plausible.org/vertsplit/ Thanks, Andy -- Cameron Moore [ I tried to draw my shadow once, but my arm kept moving. ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with AC3D 4.0
Andy Ross <[EMAIL PROTECTED]> said: > > Some "before & after" FlightGear screenshots are available at: > > http://www.plausible.org/vertsplit > > [Be patient if things seem slow; there is 400k of images on that page >and my DSL line has a 128kbps upload rate. If you don't want to >wait, download the code instead and try it for yourself. :)] > This looks great. Actually on my local copy of the 747 I've split the objects so that the flap surfaces look like that now. In addition to this change, it'd still be good IMHO to eliminate the merging of vertices (so that the modeler can decide where the splits are in AC3D and have it then rendered correctly in plib). How does the performance look (I'll take a look at your code tomorrow)? When I got into this a couple weeks ago, flightgear seemed to really drag for a while (longer) loading the KSFO area after I added the angle tests. BTW, I was also using the j3cub as a test case. The change really makes it look good! One maybe nit...is there an unintended split occuring down the center of the 747 fuselage? It seems like a sharp shade transition there (after pic). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with AC3D 4.0
On Thursday 30 October 2003 00:06, Andy Ross wrote: > I wrote: > > Jim Wilson wrote: > > > Wolfram Kuss wrote: > > > > I can even guess what the new info does: It says edges less than > > > > 45 degrees are smooth and more than 45 degrees are sharp. > > > > > > That might be difficult to implement in plib anyway. I did a > > > little looking into this recently (as a parameter setting by the > > > app,not a ac3d 4.0 attribute). Basically my investigation > > > revealed that plib would have to split vertices (create duplicates > > > on adjacent polygons) if their normal values weregreater than x > > > degrees from each other. > > > > I have working code that does this, from my game project a few > > months back. Indeed, the idea is to start at each vertex in the > > mesh and walk around it, checking the angle of each edge you cross. > > Angles sharper than your threshold are flagged. You end up with a > > list of "zones" of smooth edges, which each get a new vertex with an > > appropriately averaged normal. > > OK, I got this code working in Plib. It took a little hunting around, > but I finally discovered the OptVertexList stuff in ssgOptimizer which > works in pretty much the same data model that my code was expecting. > As implemented, this replaces the makeNormals() routine in the > optimizer with a further-optimizing variant which intelligently splits > vertices across sharp edges, to prevent the non-physical lighting > artifacts that are seen when a vertex normal points in a radically > different direction from that of the face to which it is attached. > > Some "before & after" FlightGear screenshots are available at: > > http://www.plausible.org/vertsplit > > [Be patient if things seem slow; there is 400k of images on that page >and my DSL line has a 128kbps upload rate. If you don't want to >wait, download the code instead and try it for yourself. :)] > > IMHO, the geometry of the models looks much more solid and realistic > with correct lighting. The effect that this patch has depends on the > model that is being lit, of course. Models that are already highly > tesselated (Lee's, for example) won't see much effect, but low poly > models (like David's DC-3, 172 or Cub) look much better. > > Amusingly, one thing this patch doesn't do is fix the AC3D parser > issue that started the discussion. Right now, the definition of > "sharp" is fixed in code at an (interior) edge angle of 52°. It > shouldn't be hard to get this parsed and turned into a property of the > resulting ssg branch, but since I don't know much about either area of > the code I thought I'd leave it for someone with more ssg experience. > The new code isn't AC3D-specific, of course. It will work > automatically for any Plib objects that call the optimizer to > calculate their normals. > > Anyway, grab the new code (two new files, associated additions to > Makefile.am and a modified ssgOptimizer.cxx) from > http://www.plausible.org/vertsplit/vertsplit.tar.gz and try it out. > Let me know what breaks; I've tested it only with FlightGear. > > Andy That looks good. This should certainly allow me to reduce the vertex count quite a lot because I won't need to split so many objects ( which results in duplicate vertices & edges). I'm not sure how much I'll be able to reduce the face count though. For example, if you look at an engine nacelle from the side you don't need many points to make the surface look smooth but when you look at it from the front or back the poly outline is pretty clear - that's when I tend to use more polys. I can't really see any way around that. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with AC3D 4.0
I wrote: > Jim Wilson wrote: > > Wolfram Kuss wrote: > > > I can even guess what the new info does: It says edges less than > > > 45 degrees are smooth and more than 45 degrees are sharp. > > > > That might be difficult to implement in plib anyway. I did a > > little looking into this recently (as a parameter setting by the > > app,not a ac3d 4.0 attribute). Basically my investigation > > revealed that plib would have to split vertices (create duplicates > > on adjacent polygons) if their normal values weregreater than x > > degrees from each other. > > I have working code that does this, from my game project a few > months back. Indeed, the idea is to start at each vertex in the > mesh and walk around it, checking the angle of each edge you cross. > Angles sharper than your threshold are flagged. You end up with a > list of "zones" of smooth edges, which each get a new vertex with an > appropriately averaged normal. OK, I got this code working in Plib. It took a little hunting around, but I finally discovered the OptVertexList stuff in ssgOptimizer which works in pretty much the same data model that my code was expecting. As implemented, this replaces the makeNormals() routine in the optimizer with a further-optimizing variant which intelligently splits vertices across sharp edges, to prevent the non-physical lighting artifacts that are seen when a vertex normal points in a radically different direction from that of the face to which it is attached. Some "before & after" FlightGear screenshots are available at: http://www.plausible.org/vertsplit [Be patient if things seem slow; there is 400k of images on that page and my DSL line has a 128kbps upload rate. If you don't want to wait, download the code instead and try it for yourself. :)] IMHO, the geometry of the models looks much more solid and realistic with correct lighting. The effect that this patch has depends on the model that is being lit, of course. Models that are already highly tesselated (Lee's, for example) won't see much effect, but low poly models (like David's DC-3, 172 or Cub) look much better. Amusingly, one thing this patch doesn't do is fix the AC3D parser issue that started the discussion. Right now, the definition of "sharp" is fixed in code at an (interior) edge angle of 52°. It shouldn't be hard to get this parsed and turned into a property of the resulting ssg branch, but since I don't know much about either area of the code I thought I'd leave it for someone with more ssg experience. The new code isn't AC3D-specific, of course. It will work automatically for any Plib objects that call the optimizer to calculate their normals. Anyway, grab the new code (two new files, associated additions to Makefile.am and a modified ssgOptimizer.cxx) from http://www.plausible.org/vertsplit/vertsplit.tar.gz and try it out. Let me know what breaks; I've tested it only with FlightGear. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] (no subject)
I'm planning to put together a "commercial"(though I don't plan to sell it) version of FlightGear. Does anyone know whether this has been done before, and if so, where can I find it?(also, is this the appropriate board to post on, or should this be posted somewhere else?) Thank you, Ethan Want to check if your PC is virus-infected? Get a FREE computer virus scan online from McAfee. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: make error - help please
Did you try doing make clean before doing make. --- Richard Hornby <[EMAIL PROTECTED]> wrote: > I took my first tentative steps into Linux in July > when I purchased SuSE8.2. > I decided to build FlightGear as a learning > experience. Boy has it been! > > My first attempts to make FG failed with an odd make > error pointing to > SimGear - though I didn't know it at the time. > Acting on advice recieved I > found and removed the SuSE SimGear and installed > 0.3.3 CVS version, then > found and worked around the FG 'main.cxx' problem, > deleted and updated that, > then recompiled FG CSV and it worked! (mostly). This > took about three > months. > > A week later 0.9.3 was released. I thought I knew > what I was doing now. > > Went back to CVS for the new source and data files, > got SimGear 0.3.4 and > CVS'd that, and got back to the exact same build > error as stopped me the > first time. I have got both FG and SG in CVS > version, fully checked out at > the same time. I cannot find more than one version > of SimGear on the > machine (though I have only looked for *simgear*, > not any other reference. > I have plib 1.6.0 and zlib both of which came with > the SuSE distro and which > I have not rechecked out. > > Here is the persistent error message. It has always > and only been this > problem which has stopped the make. > > test-up.o(.text+0xc2): In function `main': > /usr/local/FlightGear/ccvs/ > CVSsource/FlightGear-0.9.N/source/tests/test-up.cxx:31: > undefined reference to `sgGeodToGeoc(double const&, > double const&, double*, > double*)' > test-up.o(.text+0x164): In function `main': > /usr/local/include/simgear/math/point3d.hxx:283: > undefined reference to > `sgGeodToGeoc(double const&, double const&, double*, > double*)' > collect2: ld returned 1 exit status > make[1]: *** [test-up] Error 1 > make[1]: Leaving directory > `/usr/local/FlightGear/ccvs/CVSsource/FlightGear-0.9.N/source/tests' > make: *** [all-recursive] Error 1 > > Please could I have some helpful thoughts - I > really have tried everything > which I can find or have been told! > > Tks, RH :-( > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel Yahoo! India Matrimony: Find your partner online. Go to http://yahoo.shaadi.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: make error - help please
This almost sounds like you may have built simgear (or portions of it) with a different version of the compiler than you currently using. C++ can change it's name mangling scheme across versions and across platforms and that can generate errors similar to what you are seeing. It might be good to do a make clean of everything (including plib) and work on building it from scratch. Regards, Curt. Charu Sharma writes: > Did you try doing make clean before doing make. > > > > --- Richard Hornby <[EMAIL PROTECTED]> wrote: > I > took my first tentative steps into Linux in July > > when I purchased SuSE8.2. > > I decided to build FlightGear as a learning > > experience. Boy has it been! > > > > My first attempts to make FG failed with an odd make > > error pointing to > > SimGear - though I didn't know it at the time. > > Acting on advice recieved I > > found and removed the SuSE SimGear and installed > > 0.3.3 CVS version, then > > found and worked around the FG 'main.cxx' problem, > > deleted and updated that, > > then recompiled FG CSV and it worked! (mostly). This > > took about three > > months. > > > > A week later 0.9.3 was released. I thought I knew > > what I was doing now. > > > > Went back to CVS for the new source and data files, > > got SimGear 0.3.4 and > > CVS'd that, and got back to the exact same build > > error as stopped me the > > first time. I have got both FG and SG in CVS > > version, fully checked out at > > the same time. I cannot find more than one version > > of SimGear on the > > machine (though I have only looked for *simgear*, > > not any other reference. > > I have plib 1.6.0 and zlib both of which came with > > the SuSE distro and which > > I have not rechecked out. > > > > Here is the persistent error message. It has always > > and only been this > > problem which has stopped the make. > > > > test-up.o(.text+0xc2): In function `main': > > /usr/local/FlightGear/ccvs/ > > > CVSsource/FlightGear-0.9.N/source/tests/test-up.cxx:31: > > undefined reference to `sgGeodToGeoc(double const&, > > double const&, double*, > > double*)' > > test-up.o(.text+0x164): In function `main': > > /usr/local/include/simgear/math/point3d.hxx:283: > > undefined reference to > > `sgGeodToGeoc(double const&, double const&, double*, > > double*)' > > collect2: ld returned 1 exit status > > make[1]: *** [test-up] Error 1 > > make[1]: Leaving directory > > > `/usr/local/FlightGear/ccvs/CVSsource/FlightGear-0.9.N/source/tests' > > make: *** [all-recursive] Error 1 > > > > Please could I have some helpful thoughts - I > > really have tried everything > > which I can find or have been told! > > > > Tks, RH :-( > > > > > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > > Yahoo! India Matrimony: Find your partner online. > Go to http://yahoo.shaadi.com > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: make error - help please
I took my first tentative steps into Linux in July when I purchased SuSE8.2. I decided to build FlightGear as a learning experience. Boy has it been! My first attempts to make FG failed with an odd make error pointing to SimGear - though I didn't know it at the time. Acting on advice recieved I found and removed the SuSE SimGear and installed 0.3.3 CVS version, then found and worked around the FG 'main.cxx' problem, deleted and updated that, then recompiled FG CSV and it worked! (mostly). This took about three months. A week later 0.9.3 was released. I thought I knew what I was doing now. Went back to CVS for the new source and data files, got SimGear 0.3.4 and CVS'd that, and got back to the exact same build error as stopped me the first time. I have got both FG and SG in CVS version, fully checked out at the same time. I cannot find more than one version of SimGear on the machine (though I have only looked for *simgear*, not any other reference. I have plib 1.6.0 and zlib both of which came with the SuSE distro and which I have not rechecked out. Here is the persistent error message. It has always and only been this problem which has stopped the make. test-up.o(.text+0xc2): In function `main': /usr/local/FlightGear/ccvs/ CVSsource/FlightGear-0.9.N/source/tests/test-up.cxx:31: undefined reference to `sgGeodToGeoc(double const&, double const&, double*, double*)' test-up.o(.text+0x164): In function `main': /usr/local/include/simgear/math/point3d.hxx:283: undefined reference to `sgGeodToGeoc(double const&, double const&, double*, double*)' collect2: ld returned 1 exit status make[1]: *** [test-up] Error 1 make[1]: Leaving directory `/usr/local/FlightGear/ccvs/CVSsource/FlightGear-0.9.N/source/tests' make: *** [all-recursive] Error 1 Please could I have some helpful thoughts - I really have tried everything which I can find or have been told! Tks, RH :-( ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
