Re: [Flightgear-devel] Problems with AC3D 4.0
Jim Wilson wrote: 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). Can anyone please tell me where to put those cxxs, hxx and makefile files to compile successfully? - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Problems with AC3D 4.0
* Matevz Jekovec -- Thursday 30 October 2003 10:21: Can anyone please tell me where to put those cxxs, hxx and makefile files to compile successfully? Put them into $PLIB/src/ssg/, then configure and compile plib. You have to relink fgfs to see any effect. (touch src/Main/main.o make) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] F-16 simulator (pictures/movies)
Hi, As promised, here are a few pictures and two movies showing the commercial F-16 simulator I mentioned a week ago: http://www.a1.nl/~ehofman/fgfs/sim/ Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Problems with AC3D 4.0
Melchior FRANZ wrote:
* Matevz Jekovec -- Thursday 30 October 2003 10:21:
Can anyone please tell me where to put those cxxs, hxx and makefile
files to compile successfully?
Put them into $PLIB/src/ssg/, then configure and compile plib.
You have to relink fgfs to see any effect.
("touch src/Main/main.o make")
m.
Ah, thanks. I'll post some of J-22 before/after shots.
- Matevz
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: make error - help please
Curt and Charu - thanks I will give it a go. However, my makes of SG and FG were in the same hour, so I think the compiler version problem is unlikely unless different compilers are actually called. I will get inside the code and see if I can resolve that question, unless you can tell me otherwise. Just to check - I am assuming that make clean will not prejudice my ability to 'cvs -z3 up -dP' in the future, whereas dist clean will. If this is so (and dist clean will) is it nonetheless something else to try? Tks for the help - it's nice to know I'm not alone! R - Original Message - From: Curtis L. Olson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Wednesday, October 29, 2003 10:16 PM Subject: 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Re: First real flight
Matthew Law writes: I agree :-) In a C152 with one aboard it certainly gets a little bumpy around the circuit even nauseous sometimes. The worst turbulence I've been in so far was just beneath a bank of fluffy cumulus clouds. I thought the airframe was going to fail and for the first time since I started flying I wished I had my parachute on! I know that's a joke, but I wonder what the odds of successfuly exiting a falling 152 would be -- assume that you're already well below circuit altitude by the time your brain has processed the failure. You'd probably be better to stick with the plane unless the structural failure were total (i.e. a lost wing rather than just a bent one). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: First real flight
Frederic Bouvier writes: I am trying to avoid to fly on the afternoon in summer. It even happened that my head hit the top of the canopy. I wouldn't imagine what could happen if I'd forgot to fasten my seat belt. Been there -- I bruised my head on the roof of my Warrior during a practice instrument approach one afternoon. When I'm flying VFR, I can stay high and then come in on a fairly steep approach path, limiting my time in the worst of the turbulence; IFR, I'm stuck at the ridiculously low step-downs and approach slopes designed for big airliners. In real-life, the kind of low IFR that I can fly in safely tends to be fog, which means calm air, so the real problem is flying under the foggles on VFR days. I noticed that it is more difficult to maintain straight and level with low powered planes (100hp) than with more powerful planes. My Warrior is more stable in turbulence than a 172 at the same weight and hp -- I think it's because the wing loading is higher (hence, the slightly higher stall speed as well). I often have to maintain the stick frankly on the left ( with no trim ) to avoid the plane to tilt. And with a heat bubble hitting only one wing on occasion, you are assured to get sensations. In a Cherokee (and most or all other low-wings), you have no choice but to burn fuel from one tank at once -- I always start with the left tank when I'm flying alone. Since the fuel is further out on the roll arm than you are, a little fuel can make a big difference for balance. I don't know how you feel about not using the BOTH setting in a Cessna, but for a long cross-country, it might be worth thinking about (just make sure you set a timer so that you don't forget to switch tanks). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] F-16 simulator (pictures/movies)
Erik Hofman writes: As promised, here are a few pictures and two movies showing the commercial F-16 simulator I mentioned a week ago: http://www.a1.nl/~ehofman/fgfs/sim/ The trees in the visuals look like they were really well done ... Curt. -- 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] F-16 simulator (pictures/movies)
Curtis L. Olson wrote: Erik Hofman writes: As promised, here are a few pictures and two movies showing the commercial F-16 simulator I mentioned a week ago: http://www.a1.nl/~ehofman/fgfs/sim/ The trees in the visuals look like they were really well done ... True, but they are still billboards. What makes them impressive is that they are grouped together in the wooded areas. One nice aspect is that fact that in the winter they don't contain leaves and carry snow on the branches ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Re: First real flight
Given the difficulty of getting in and out of a 152 on the ground it's probably impossible at our circuit height of 800ft to survive a bailout. A larger aircraft at 1000ft and reasonable speed, say 100kts, would be quite survivable. The key is the airspeed. You'd get a far faster deployment at 100kts than from stall speed. Unfortunatley, most emergency aircrew parachutes I've seen are pitifully old or badly maintained. Modern square reserve parachutes of the type used by skydivers are very fast to open and very, very reliable if the mandatory inspection and repack cycle is adhered to. I use one of these too: http://www.cypres2.com just in case ;-) Regards, Matt. On Thu, 2003-10-30 at 12:39, David Megginson wrote: I know that's a joke, but I wonder what the odds of successfuly exiting a falling 152 would be -- assume that you're already well below circuit altitude by the time your brain has processed the failure. You'd probably be better to stick with the plane unless the structural failure were total (i.e. a lost wing rather than just a bent one). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] J-22 shots
I've tested new vertex split code on my J-22 Orao model. Screenshots can be found here: http://www2.arnes.si/~mjekov/fgfs I noticed a big difference in ailerons, rudder, elevators and flaps part. Even some stabilizators (on wings) are differently shaded. The difference can be seen in a pilot body as well (it's more flat than before). However, an overall feeling is *way* better (as can be seen on shot 3). I am only conserned about the fps (I didn't encountered much of the diff though)... Good work. - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] J-22 shots
Matevz Jekovec writes: I've tested new vertex split code on my J-22 Orao model. Screenshots can be found here: http://www2.arnes.si/~mjekov/fgfs I noticed a big difference in ailerons, rudder, elevators and flaps part. Even some stabilizators (on wings) are differently shaded. The difference can be seen in a pilot body as well (it's more flat than before). However, an overall feeling is *way* better (as can be seen on shot 3). I am only conserned about the fps (I didn't encountered much of the diff though)... Anyone know if plib has been patched with these yet or of we need to do additional lobbying to get the patches applied? Thanks, Curt. -- 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
[Flightgear-devel] Re: J-22 shots
* Curtis L. Olson -- Thursday 30 October 2003 15:55: Anyone know if plib has been patched with these yet Hasn't. But the changes were presented on the plib list. No comment from Steve yet. or of we need to do additional lobbying to get the patches applied? Wouldn't hurt. :-) m. -- Failure is not an option. It comes bundled with your Microsoft product. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] J-22 shots
Curtis L. Olson [EMAIL PROTECTED] said: Matevz Jekovec writes: I've tested new vertex split code on my J-22 Orao model. Screenshots can be found here: http://www2.arnes.si/~mjekov/fgfs I noticed a big difference in ailerons, rudder, elevators and flaps part. Even some stabilizators (on wings) are differently shaded. The difference can be seen in a pilot body as well (it's more flat than before). However, an overall feeling is *way* better (as can be seen on shot 3). I am only conserned about the fps (I didn't encountered much of the diff though)... Anyone know if plib has been patched with these yet or of we need to do additional lobbying to get the patches applied? Curt, I'm not sure the patch is a good idea as it stands. It has to add overhead for scenery models and it actually makes the underlying plib problem worse...that of plib messing with the geometry data. It is easy to make models that look right in AC3D, the problem is that plib runs through this optimization step that corrupts the model data. This patch actually corrupts it even more, introducing with it other problems. We can fix the problem with a much less intrusive patch. The only question I have is what this for Blender users. Is it possible to specify adjacent surfaces with distinct vertices in Blender and then convert those intact to AC3D? Is this something that can be added to the blender-ac3d converter. In a nutshell can we export models from blender that look the same in the ac3d editor as they did in blender? If we can approach these issues a little more carefully we can end up with a couple of decent wsiwig options for building flightgear models. At the very least, if folks insist on going this way, there should be a way to turn it on or off and have it configurable on a per model basis. Please note several models in FlightGear that _do not_ have these shading issues. Lee mentioned that he could reduce vertex counts but actually this just replaces those he deletes with automatically generated ones. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] J-22 shots
Curtis L. Olson writes: Anyone know if plib has been patched with these yet or of we need to do additional lobbying to get the patches applied? Impatient aren't we :-) FWIW - I would give this, as any other proposed PLIB changes, at least a 'couple of days' vs a 'couple of hours' so as to let some of the other users of PLIB a chance to test / comment on this or any other proposed PLIB changes before I began lobbying. Note the above coment in no way is meant to reflect on the proposed patch at hand in any way shape or form Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] J-22 shots
On Thursday 30 October 2003 15:22, Jim Wilson wrote: Curtis L. Olson [EMAIL PROTECTED] said: Matevz Jekovec writes: I've tested new vertex split code on my J-22 Orao model. Screenshots can be found here: http://www2.arnes.si/~mjekov/fgfs I noticed a big difference in ailerons, rudder, elevators and flaps part. Even some stabilizators (on wings) are differently shaded. The difference can be seen in a pilot body as well (it's more flat than before). However, an overall feeling is *way* better (as can be seen on shot 3). I am only conserned about the fps (I didn't encountered much of the diff though)... Anyone know if plib has been patched with these yet or of we need to do additional lobbying to get the patches applied? Curt, I'm not sure the patch is a good idea as it stands. It has to add overhead for scenery models and it actually makes the underlying plib problem worse...that of plib messing with the geometry data. It is easy to make models that look right in AC3D, the problem is that plib runs through this optimization step that corrupts the model data. This patch actually corrupts it even more, introducing with it other problems. We can fix the problem with a much less intrusive patch. The only question I have is what this for Blender users. Is it possible to specify adjacent surfaces with distinct vertices in Blender and then convert those intact to AC3D? Is this something that can be added to the blender-ac3d converter. In a nutshell can we export models from blender that look the same in the ac3d editor as they did in blender? If we can approach these issues a little more carefully we can end up with a couple of decent wsiwig options for building flightgear models. At the very least, if folks insist on going this way, there should be a way to turn it on or off and have it configurable on a per model basis. Please note several models in FlightGear that _do not_ have these shading issues. Lee mentioned that he could reduce vertex counts but actually this just replaces those he deletes with automatically generated ones. Best, Jim Ah - tanstaafl then:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] J-22 shots
Lee Elliott [EMAIL PROTECTED] said: Ah - tanstaafl then:) LeeE Depends on who's buying :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] socket communication
Hi All, Can anyone tell me which part of FlightGear code deals with programming of socket communication(which we use for multiple displays)? I want to run flightgear on a computer(slave machine) which has no controls like keyboard, joysticks etc from a machine(server) which has all these controls. Any ideas and suggestions would be very helpful? thanks 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
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 6, Issue 58
snip Message: 1 Date: Wed, 29 Oct 2003 22:38:38 -0600 From: Marisa and Pat [EMAIL PROTECTED] Subject: [Flightgear-devel] Simple math To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 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 -- next part -- An HTML attachment was scrubbed... URL: http://mail.flightgear.org/pipermail/flightgear-devel/attachments/20031029/a01ae9fc/attachment-0001.htm big snip In answer to part of my question, Flightgear 0.9.3. I just finished downloading it (and importing the panel I was working on). It seems the problems of the negative numbers were repaired in this build. However, I would still be interested in any way to do simple math (other than scale, switch values, etc...) any advice anyone has would be appreciated. As for the second part of my question (regarding ADF in real degrees), I am still going through the internal variables for 0.9.3. Thank you, Marisa. P.S. Anyone have a server to which I can upload a c172 panel and a few new instruments? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Plib-devel] Re: [Flightgear-devel] J-22 shots
Jim Wilson wrote: I'm not sure the patch is a good idea as it stands. It has to add overhead for scenery models and it actually makes the underlying plib problem worse...that of plib messing with the geometry data. It is easy to make models that look right in AC3D, the problem is that plib runs through this optimization step that corrupts the model data. This patch actually corrupts it even more, introducing with it other problems. That's not really correct. It's easy to make models look correct in AC3D precicely *because* AC3D is intelligently calculating vertex normals for you. The .ac file format doesn't even include normal data at all, so it's provably impossible to display such a file without making some sort of guess as to what the proper normal directions should be. In fact, if I understand the original crease issue correctly, the new version of AC3D is doing exactly the same thing that the new code is attempting to do. It's just not as simple as saying that plib is corrupting data -- what it gets from AC3D is incomplete. You can't do vertex lighting without normals; AC3D files don't have 'em. Plib has to make a guess. Your preference seems to be that it guess dumbly, leaving as much flexibility as possible in the hands of the modeller. A dumb guess will fail (produce flat shading) for accidentally duplicated vertices, however, which is why it tries to apply some intelligence in the vertex coalescing. But that, too, fails in the presence of sharp edges, so the new code tries to recreate them by re-splitting the vertices. On the whole, I think most people agree that with the exception of a few aircraft (which are hopefully tickling fixable bugs), things look better with than without the vertex splitter. Most of the time, it does the right thing; and hand-splitting vertices is a real pain for the modeller if they are forced to do it on every sharp edge. Try hand-splitting the Cub's engine, for example. And regardless, you can (or should be able to, modulo bugs) force the splitter off by setting the threshold to zero. There just needs to be a data path from the input file and/or Plib client code through to the Plib optimizer. AC3D 4 provides this automatically via the crease directive, apparently. There's no reason we couldn't add the capability via other means. Anyway, looking at the bo105 model more closely, it looks like the problem isn't so much duplicate vertices (which, as it turns out, *must* be coalesced by the plib optimizer in the process of building its triangle list) but degenerate triangles. Looking only at the rotor object, I found a bunch of quads with four vertices, two of which turned out to be duplicates. Degenerate triangles, of course, have zero-length normals and will thus look like sharp edges when dotted against their neighbors' normals. I'm still looking. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Plib-devel] Re: [Flightgear-devel] Problems with AC3D 4.0
Erik Hofman wrote: Andy Ross wrote: Anyway, try doing a remove duplicate vertices pass on the weird-looking models and see if that fixes the problem. I'll take a look to see if I can find and reenable the old merging code. I am pretty sure I don't have them in the Fokker 50. I do optimizations very regularly during design time and it also isn't the sharping angle because it also happens in the slightly curved wings. I found the problem. The modeller (are you using Blender or AC3D?) is generating meaningless texture coordinates. A vertex will appear once with a UV of, say, [1 0] and then again with [0 1], etc... Plib can combine duplicated vertices, but it won't do so when they *appear* to be different due to differing texture coordinates. So it passes them on to me. The original normal calculator understands this, apparently, but I wasn't expecting to be fed geometrically identical vertices. My original splitter code was written to be used with with my own blender exporter which required/enforced projected textures (the bump mapping doesn't work well with hand-tweaked UV coordinates), so I never noticed this issue. Or maybe Blender doesn't exhibit this behavior; dunno. Really, this is a problem with the modeller and/or export code; the texture coordinates I'm seeing are nonsensical (the bo105 doesn't even *have* any textures defined, yet something has generated multiple UV coordinates for each vertex -- bizarre). But nonetheless, painting weird textures on a model shouldn't cause the normals (which are a geometric property -- they have nothing to do with texturing) to look funny. Basically, I need to preprocess the data to distinguish geometric identity from logical identity. It shouldn't be too hard, gimme a day or so. Regardless, take a very close look at your texture coordinates and make that unless you have a really good reason, you have only one, unique UV tuple per physical vertex. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Plib-devel] Re: [Flightgear-devel] J-22 shots
Andy Ross [EMAIL PROTECTED] said: Jim Wilson wrote: I'm not sure the patch is a good idea as it stands. It has to add overhead for scenery models and it actually makes the underlying plib problem worse...that of plib messing with the geometry data. It is easy to make models that look right in AC3D, the problem is that plib runs through this optimization step that corrupts the model data. This patch actually corrupts it even more, introducing with it other problems. That's not really correct. It's easy to make models look correct in AC3D precisely *because* AC3D is intelligently calculating vertex normals for you. The .ac file format doesn't even include normal data at all, so it's provably impossible to display such a file without making some sort of guess as to what the proper normal directions should be. In fact, if I understand the original crease issue correctly, the new version of AC3D is doing exactly the same thing that the new code is attempting to do. Not true to the first part. Check out this screenshot of flaps isolated from the 747 model: http://www.spiderbark.com/fgfs/flapshade.png These are identical, except that the edges don't share vertices on the flap on the right. Yes it is likely that the crease value is exactly for this purpose, but we are not talking about supporting that property. Changes to the ssg structure would be required...while we are at it, there should also be a place for the shading flag. It's just not as simple as saying that plib is corrupting data -- what it gets from AC3D is incomplete. You can't do vertex lighting without normals; AC3D files don't have 'em. Plib has to make a guess. We aren't all that far off from what I can see. Your preference seems to be that it guess dumbly, leaving as much flexibility as possible in the hands of the modeler. A dumb guess will fail (produce flat shading) for accidentally duplicated vertices, however, which is why it tries to apply some intelligence in the vertex coalescing. But that, too, fails in the presence of sharp edges, so the new code tries to recreate them by re-splitting the vertices. On the whole, I think most people agree that with the exception of a few aircraft (which are hopefully tickling fixable bugs), things look better with than without the vertex splitter. Most people who understand the models? I'm not against leaving this in, but it should be optional, and that we can initiate with a setting in the model's xml wrapper. Most of the time, it does the right thing; and hand-splitting vertices is a real pain for the modeler if they are forced to do it on every sharp edge. Try hand-splitting the Cub's engine, for example. It is very easy in ac3d: Object/Fragement followed by Object/Merge. Or if only a group of surfaces need to be done like the top of a flap, select the surfaces and then Surface/Cutaway Object followed by selecting the two resulting objects and then Object/Merge. Lee and others do it all the time, except currently we cannot combine the surfaces back together in one object because plib will merge those vertices that were created. AC3D does not do this merge, even on reloading the model data from the ac file. And regardless, you can (or should be able to, modulo bugs) force the splitter off by setting the threshold to zero. A little more definitive setting would be better, but yeah that would work. The same goes for having a function to set the distance slop (optmise_vtol[0]) as was discussed earlier. If the tolerance test was tolerance then identical vertices would not be merged if the setting was 0. But a flag would be better documentation for this too. There just needs to be a data path from the input file and/or Plib client code through to the Plib optimizer. AC3D 4 provides this automatically via the crease directive, apparently. There's no reason we couldn't add the capability via other means. Anyway, looking at the bo105 model more closely, it looks like the problem isn't so much duplicate vertices (which, as it turns out, *must* be coalesced by the plib optimizer in the process of building its triangle list) but degenerate triangles. Looking only at the rotor object, I found a bunch of quads with four vertices, two of which turned out to be duplicates. Degenerate triangles, of course, have zero-length normals and will thus look like sharp edges when dotted against their neighbors' normals. I'm still looking. There is a bit of code in the existing OptVertexList::makeNormals() that attempts to deal with those. After a patch in cvs it still doesn't work. You'll see it in there (it makes a straight up normals when it finds one). The problem is that while the current method of detecting these is slightly better, it still gets false positives on certain arrangements of triangles on planes whose axes are parallel to the XZ. I haven't yet thought out why it is that the current shortcut (normal
Re: [Plib-devel] Re: [Flightgear-devel] Problems with AC3D 4.0
Andy Ross [EMAIL PROTECTED] said: Erik Hofman wrote: Andy Ross wrote: Anyway, try doing a remove duplicate vertices pass on the weird-looking models and see if that fixes the problem. I'll take a look to see if I can find and reenable the old merging code. I am pretty sure I don't have them in the Fokker 50. I do optimizations very regularly during design time and it also isn't the sharping angle because it also happens in the slightly curved wings. I found the problem. The modeller (are you using Blender or AC3D?) is generating meaningless texture coordinates. A vertex will appear once with a UV of, say, [1 0] and then again with [0 1], etc... Plib can combine duplicated vertices, but it won't do so when they *appear* to be different due to differing texture coordinates. So it passes them on to me. The original normal calculator understands this, apparently, but I wasn't expecting to be fed geometrically identical vertices. Ah yes. That is exactly right. Hmmm...I wonder why this is so? If the vertices are from identical index positions why would it be looking at texture coordinates? I'm wondering if this is really an old hack that was designed to fix someone's problem with the optimiser snapping together vertices. Until a couple weeks ago it was snapping anything a centemeter or less apart. But of course it wouldn't if the uv coords were different. My original splitter code was written to be used with with my own blender exporter which required/enforced projected textures (the bump mapping doesn't work well with hand-tweaked UV coordinates), so I never noticed this issue. Or maybe Blender doesn't exhibit this behavior; dunno. If you map adjacent surfaces to different (non-adjacent) parts of the texture then this will happen. I'm not sure about the helicopter, but the 747 has each side of the fuselage mapped to different parts of the same texture file (to get differing left and right sides). Really, this is a problem with the modeller and/or export code; the Speaking as a modeler... I'll blame it on the plib code :-D Actually I don't quite understand as I mentioned above, why this is being done this way. texture coordinates I'm seeing are nonsensical (the bo105 doesn't even *have* any textures defined, yet something has generated multiple UV coordinates for each vertex -- bizarre). Maybe...but not strange in the case of the 747 fuselage example, in the context of the ac format. But nonetheless, painting weird textures on a model shouldn't cause the normals (which are a geometric property -- they have nothing to do with texturing) to look funny. Basically, I need to preprocess the data to distinguish geometric identity from logical identity. It shouldn't be too hard, gimme a day or so. That would be great. It'd be nice to understand the original reason (if it was a good one). Regardless, take a very close look at your texture coordinates and make that unless you have a really good reason, you have only one, unique UV tuple per physical vertex. Please may I? ;-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
