Re: [Flightgear-devel] DC-3 3d cockpit
Josh Babcock [EMAIL PROTECTED] said: Well, I already changed the slop constatnt in my plib librarys to a much smaller number, but for this application, I need something that will work right with a clean flightgear install. Josh We might be able to get something into the next release plib to allow setting the slop constant. Steve mentioned it a couple months back when the current setting in plib cvs was reduced to 1.0mm (it was 1.0cm!). It just needs to someone to write a function for it. Then we could add a property driven setting to simgear and end up with something that could work on a clean flightgear install. For Andy's patch to be added I think it will require some slight reorganization of the ac3d loader/optimizer code. Basically the optimization routines (including Andy's version) need to be exposed to an external API so that SimGear and other plib users can select which to use. Maybe the current AC3D loader wrapper that calls the current optimizer should be left alone. Note, I'm suggesting adding Andy's work to plib as an alternative optimizer function, not a replacement for the current code. It is possible that there are some apps out there that use a lowres sphere or some similar thing that would render poorly with Andy's optimizer. Simgear (and other apps) could have there own routine that calls plibs' raw AC3D loader and plibs' new optimizer (aka Andy's version) individually. That reminds me, another requirement for adding Andy's patch to plib would probably be a function to set the crease angle which is currently hardcoded. Or maybe it could be a parameter in the external interface for the optimizer? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
Jim Wilson wrote: Note, I'm suggesting adding Andy's work to plib as an alternative optimizer function, not a replacement for the current code. No need for this. They produce identical results if you set the sharp angle to 180 degrees. All someone needs to do is export the value via the loader API. I give up on the plib folks. All reports are that the current version of this patch produces better looking models in all cases. Are there any real-world cases where we want something different? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
On Wednesday, 7 January 2004 20:07, Andy Ross wrote: I give up on the plib folks. All reports are that the current version of this patch produces better looking models in all cases. Are there any real-world cases where we want something different? Andy Why are you giving up on the plib folks? Are they resisting the integration of your code into plib? Dragging their feet? Rejecting patches? (I would check to see what has been happening if the mailing list archives actually worked on SF) If so is there anything we can do collectively to make things happen quicker short of sending them personal threats? ;-) Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
Andy Ross [EMAIL PROTECTED] said: Jim Wilson wrote: Note, I'm suggesting adding Andy's work to plib as an alternative optimizer function, not a replacement for the current code. No need for this. They produce identical results if you set the sharp angle to 180 degrees. Theoretically yes, but are you sure of that? All someone needs to do is export the value via the loader API. I give up on the plib folks. All reports are that the current version of this patch produces better looking models in all cases. Are there any real-world cases where we want something different? Got me. I'm not involved directly with that project. I guess I'm taking the conservative approach. We certainly aren't the only users. If the patch was finished, with the support for the old method (or an exact match as you mentioned above) then I can't imagine that the plib folks would not accept the patch. Steve seemed to support the idea of alternate optimizers and like you said all reports are good. When it is ready I'm sure all the Flight Gear folks including yours truly will lobby for it and it will get in. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
Jim Wilson writes: Andy Ross [EMAIL PROTECTED] said: Jim Wilson wrote: Note, I'm suggesting adding Andy's work to plib as an alternative optimizer function, not a replacement for the current code. No need for this. They produce identical results if you set the sharp angle to 180 degrees. Theoretically yes, but are you sure of that? All someone needs to do is export the value via the loader API. I give up on the plib folks. All reports are that the current version of this patch produces better looking models in all cases. Are there any real-world cases where we want something different? Got me. I'm not involved directly with that project. I guess I'm taking the conservative approach. We certainly aren't the only users. If the patch was finished, with the support for the old method (or an exact match as you mentioned above) then I can't imagine that the plib folks would not accept the patch. Steve seemed to support the idea of alternate optimizers and like you said all reports are good. When it is ready I'm sure all the Flight Gear folks including yours truly will lobby for it and it will get in. I'd love to see this get into plib too. Maybe it's time to ask about it on the plib list and try and pin them down on exactly what their objections are if any, and if there aren't any maybe a reminder or two would be all it takes to get someone to apply the changes. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
Hmm, I compiled and installed plib, then did a make clean, make and make install on simgear, then a make clean on FlightGear, and the make for Flightgerar still gives the same kind of error: snip g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -D_REENTRANT -c -o viewmgr.o `test -f viewmgr.cxx || echo './'`viewmgr.cxx rm -f libMain.a ar cru libMain.a main.o fg_commands.o fg_init.o fg_io.o fg_props.o globals.o logger.o options.o splash.o util.o viewer.o viewmgr.o ranlib libMain.a source='bootstrap.cxx' object='bootstrap.o' libtool=no \ depfile='.deps/bootstrap.Po' tmpdepfile='.deps/bootstrap.TPo' \ depmode=gcc3 /bin/sh ../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -D_REENTRANT -c -o bootstrap.o `test -f bootstrap.cxx || echo './'`bootstrap.cxx g++ -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -D_REENTRANT -L/usr/X11R6/lib -o fgfs bootstrap.o ../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Autopilot/libAutopilot.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/ExternalPipe/libExternalPipe.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../../src/Network/libNetwork.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/MultiPlayer/libMultiPlayer.a ../../src/Objects/libObjects.a ../../src/Replay/libReplay.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Environment/libEnvironment.a -lsgclouds3d -lsgroute -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgxml -lsgsound -lsgserial -lsgstructure -lsgthreads -lpthread -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lz -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm -lplibsl -lplibsm ../../src/Main/libMain.a(main.o)(.text+0x804): In function `trRenderFrame()': ../../src/Scenery/scenery.hxx:369: undefined reference to `ssgCullAndDraw(ssgRoot*)' ../../src/Main/libMain.a(main.o)(.text+0x844):../../src/Scenery/scenery.hxx:369: undefined reference to `ssgCullAndDraw(ssgRoot*)' ../../src/Main/libMain.a(main.o)(.text+0x858):../../src/Scenery/scenery.hxx:369: undefined reference to `ssgCullAndDraw(ssgRoot*)' ../../src/Main/libMain.a(main.o)(.text+0x1377): In function `fgRenderFrame()': ../../src/Scenery/scenery.hxx:369: undefined reference to `ssgCullAndDraw(ssgRoot*)' ../../src/Main/libMain.a(main.o)(.text+0x13b0):../../src/Scenery/scenery.hxx:369: undefined reference to `ssgCullAndDraw(ssgRoot*)' ../../src/Main/libMain.a(main.o)(.text+0x13ce):../../src/Scenery/scenery.hxx:369: more undefined references to `ssgCullAndDraw(ssgRoot*)' follow collect2: ld returned 1 exit status make[2]: *** [fgfs] Error 1 make[2]: Leaving directory `/usr/local/src/FlightGear-0.9.3/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/FlightGear-0.9.3/src' make: *** [all-recursive] Error 1 After re-installing the regular 1.6.0 distribution of plib and cleaning, making and installing plib, SimGear and FlightGear, everything is back the way it was before. Something is definitely broken with the patch, it is the only thing that I changed between the two builds. Is it possible that I picked up a bug in FlightGear from CVS recently and the plib patch is activating it? Josh Andy Ross wrote: Josh Babcock wrote: OK, the snapshot file solves that problem, but I think that main.o is failing to link. See here: You swapped plib versions, but still have some SimGear and/or FlightGear files compiled against the old one. In general, C++ libraries aren't binary compatible across versions. You need to do a complete rebuild. Andy ___ 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] DC-3 3d cockpit
You should also check *very* carefully to make sure you don't have a stray packaged copy of plib installed on your system somewhere. If that was built with a different version of the compiler (very plausible) then you would see errors similar to what you are reporting. Regards, Curt. Josh Babcock writes: Hmm, I compiled and installed plib, then did a make clean, make and make install on simgear, then a make clean on FlightGear, and the make for Flightgerar still gives the same kind of error: snip g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -D_REENTRANT -c -o viewmgr.o `test -f viewmgr.cxx || echo './'`viewmgr.cxx rm -f libMain.a ar cru libMain.a main.o fg_commands.o fg_init.o fg_io.o fg_props.o globals.o logger.o options.o splash.o util.o viewer.o viewmgr.o ranlib libMain.a source='bootstrap.cxx' object='bootstrap.o' libtool=no \ depfile='.deps/bootstrap.Po' tmpdepfile='.deps/bootstrap.TPo' \ depmode=gcc3 /bin/sh ../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -D_REENTRANT -c -o bootstrap.o `test -f bootstrap.cxx || echo './'`bootstrap.cxx g++ -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -D_REENTRANT -L/usr/X11R6/lib -o fgfs bootstrap.o ../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Autopilot/libAutopilot.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/ExternalPipe/libExternalPipe.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../../src/Network/libNetwork.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/MultiPlayer/libMultiPlayer.a ../../src/Objects/libObjects.a ../../src/Replay/libReplay.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Environment/libEnvironment.a -lsgclouds3d -lsgroute -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgxml -lsgsound -lsgserial -lsgstructure -lsgthreads -lpthread -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lz -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm -lplibsl -lplibsm ../../src/Main/libMain.a(main.o)(.text+0x804): In function `trRenderFrame()': ../../src/Scenery/scenery.hxx:369: undefined reference to `ssgCullAndDraw(ssgRoot*)' ../../src/Main/libMain.a(main.o)(.text+0x844):../../src/Scenery/scenery.hxx:369: undefined reference to `ssgCullAndDraw(ssgRoot*)' ../../src/Main/libMain.a(main.o)(.text+0x858):../../src/Scenery/scenery.hxx:369: undefined reference to `ssgCullAndDraw(ssgRoot*)' ../../src/Main/libMain.a(main.o)(.text+0x1377): In function `fgRenderFrame()': ../../src/Scenery/scenery.hxx:369: undefined reference to `ssgCullAndDraw(ssgRoot*)' ../../src/Main/libMain.a(main.o)(.text+0x13b0):../../src/Scenery/scenery.hxx:369: undefined reference to `ssgCullAndDraw(ssgRoot*)' ../../src/Main/libMain.a(main.o)(.text+0x13ce):../../src/Scenery/scenery.hxx:369: more undefined references to `ssgCullAndDraw(ssgRoot*)' follow collect2: ld returned 1 exit status make[2]: *** [fgfs] Error 1 make[2]: Leaving directory `/usr/local/src/FlightGear-0.9.3/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/FlightGear-0.9.3/src' make: *** [all-recursive] Error 1 After re-installing the regular 1.6.0 distribution of plib and cleaning, making and installing plib, SimGear and FlightGear, everything is back the way it was before. Something is definitely broken with the patch, it is the only thing that I changed between the two builds. Is it possible that I picked up a bug in FlightGear from CVS recently and the plib patch is activating it? Josh Andy Ross wrote: Josh Babcock wrote: OK, the snapshot file solves that problem, but I think that main.o is failing to link. See here: You swapped plib versions, but still have some SimGear and/or FlightGear files compiled against the old one. In general, C++ libraries aren't binary compatible across versions. You need to do a complete rebuild. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
Actually, I think that I nuked the base makefile by unzipping the patch in that directory. That brings me back to the original problem, which is that I can't log into the CVS repository. I guess I'll just keep trying. I tried applying the patches to the regular plib distribution and they compiled alright, but after rebuilding flightgear i didn't see any changes. Josh Andy Ross wrote: Josh Babcock wrote: Well, this download is working better, but it is complaining: Makefile:315: *** missing separator. Stop. Which Makefile? I also had to move Makefile.am back into the base directory. Had to or... what? As always, bug reports with complete symptom descriptions are easiest to resolve. Try a complete rebuild of plib, and leave the base directory makefile alone. One thought: you must be using the CVS version of plib for the new files to work. Andy ___ 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] DC-3 3d cockpit
Josh Babcock writes: Actually, I think that I nuked the base makefile by unzipping the patch in that directory. That brings me back to the original problem, which is that I can't log into the CVS repository. I guess I'll just keep trying. I tried applying the patches to the regular plib distribution and they compiled alright, but after rebuilding flightgear i didn't see any changes. Plib is hosted at source forge and apparently they are still struggling with spotty access to the cvs repository. I think that if you keep trying you will eventually get through. Otherwise, I think they also make a snapshot of the latest source available for ftp/http download. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
OK, the snapshot file solves that problem, but I think that main.o is failing to link. See here: [EMAIL PROTECTED] FlightGear-0.9.3]$ make SNIP Making all in Main make[2]: Entering directory `/usr/local/src/FlightGear-0.9.3/src/Main' g++ -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -D_REENTRANT -L/usr/X11R6/lib -o fgfs bootstrap.o ../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Autopilot/libAutopilot.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/ExternalPipe/libExternalPipe.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../../src/Network/libNetwork.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/MultiPlayer/libMultiPlayer.a ../../src/Objects/libObjects.a ../../src/Replay/libReplay.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Environment/libEnvironment.a -lsgclouds3d -lsgroute -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgxml -lsgsound -lsgserial -lsgstructure -lsgthreads -lpthread -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lz -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm -lplibsl -lplibsm ../../src/Main/libMain.a(main.o)(.text+0x804): In function `trRenderFrame()': ../../src/Scenery/scenery.hxx:369: undefined reference to `ssgCullAndDraw(ssgRoot*)' ../../src/Main/libMain.a(main.o)(.text+0x844):../../src/Scenery/scenery.hxx:369: undefined reference to `ssgCullAndDraw(ssgRoot*)' ../../src/Main/libMain.a(main.o)(.text+0x858):../../src/Scenery/scenery.hxx:369: undefined reference to `ssgCullAndDraw(ssgRoot*)' ../../src/Main/libMain.a(main.o)(.text+0x1377): In function `fgRenderFrame()': ../../src/Scenery/scenery.hxx:369: undefined reference to `ssgCullAndDraw(ssgRoot*)' ../../src/Main/libMain.a(main.o)(.text+0x13b0):../../src/Scenery/scenery.hxx:369: undefined reference to `ssgCullAndDraw(ssgRoot*)' ../../src/Main/libMain.a(main.o)(.text+0x13ce):../../src/Scenery/scenery.hxx:369: more undefined references to `ssgCullAndDraw(ssgRoot*)' follow collect2: ld returned 1 exit status make[2]: *** [fgfs] Error 1 make[2]: Leaving directory `/usr/local/src/FlightGear-0.9.3/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/FlightGear-0.9.3/src' make: *** [all-recursive] Error 1 In plib/src/ssg I see this though: [EMAIL PROTECTED] ssg]$ grep ssgCullAndDraw * Binary file libplibssg.a matches ssg.cxx:void ssgCullAndDraw ( ssgBranch *r ) ssg.h:void ssgCullAndDraw ( ssgBranch *root ) ; Binary file ssg.o matches I don't see what's broken here, is ssgCullAndDraw mistyped? That FlightGear build came out of CVS last night, btw. Josh Curtis L. Olson wrote: Josh Babcock writes: Actually, I think that I nuked the base makefile by unzipping the patch in that directory. That brings me back to the original problem, which is that I can't log into the CVS repository. I guess I'll just keep trying. I tried applying the patches to the regular plib distribution and they compiled alright, but after rebuilding flightgear i didn't see any changes. Plib is hosted at source forge and apparently they are still struggling with spotty access to the cvs repository. I think that if you keep trying you will eventually get through. Otherwise, I think they also make a snapshot of the latest source available for ftp/http download. Regards, Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
Josh Babcock wrote: OK, the snapshot file solves that problem, but I think that main.o is failing to link. See here: You swapped plib versions, but still have some SimGear and/or FlightGear files compiled against the old one. In general, C++ libraries aren't binary compatible across versions. You need to do a complete rebuild. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
I just tried to get the latest CVS version to try this, and got this: [EMAIL PROTECTED] plib-1.6.0]$ cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/plib login Logging in to :pserver:[EMAIL PROTECTED]:2401/cvsroot/plib CVS password: cvs [login aborted]: end of file from server (consult above messages if any) Is it critical to use the CVS version, or can I use 1.6.0? I did try using the 1.6.0 version, but got this: Makefile.am: required file `./depcomp' not found which I am not familiar with. I'm playing with this because I am designing an ac3d model in Blender, and am having a great deal of trouble getting the edges and shading to look right. Currently fixing most of the problems will be very dificult and involve creating a lot more groups and objects in the .ac file than there really need to be, and some, like making the leading edge of a wing smooth and the trailing edge sharp, seem impossible. I don't want to go and add a bunch more polys around the sharp edges because A) it would be a lot of work at this point and b) I'm pushing 9000 polys right now and am way over the budget that I set. Add to the fact that this model has a greenhouse cockpit canopy with lots and lots of little polys that each need to look seperate from each other, and I'm getting quite frustrated. Looks great in Blender though. [EMAIL PROTECTED] wrote: Hi, Andy Andy Ross [EMAIL PROTECTED] wrote: Ilja wrote: 1. The trim wheel looks in AC3D like this [...] is just an ugly object: [...] The orange mixture stick doesn't look correct too. Off hand, it looks to me like the normals are wrong. The bright white vertices usually result from a normal being far too large. AC3D has been known to generate some very strange geometry in the past, and it's possible that it is confusing plib's normal calculation. Try to look through the file and verify that you don't have any degenerate triangles, etc... I will do that. Or, if you are feeling adventurous, try my plib patch which replaces the normal calculation step with a smarter one that understands the difference between smooth and sharp edges: http://www.plausible.org/vertsplit/vertsplit2.tar.gz (Make sure you are using the CVS version of plib, dump all the files in the tarball into src/ssg, then rebuild plib and FlightGear). I´m sorry, but I´m using the precompiled FlightGear v 9.3 for Windows and I haven´t got any compiler. The two implementations share no code, so if the problem persists with the patch, the bug is almost certainly in your model file. 2. The instrument panel shines through the fuselage: [...] but the dc3 model is not alone there, when you look at other aircrafts with 2d panels, you can find the same bug (or feature?). So I took screenshots from c172, a4 and c310u3a. This is a known issue that gets reported from time to time. The 2D panels use a depth buffer offset to draw the layers, and it ends up being too coarse on 16 bit depth buffers. Try setting your screen depth to 24bpp and see if that fixes the issue. It seems to depend on models' surfaces, but what can you see in FlightGear v. 9.2? [...] There is no bug! Are you sure you didn't change your display settings and/or take the screenshots on a different machines? Yes, I´m sure. Ilja ___ 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] DC-3 3d cockpit
On Sunday, 4 January 2004 15:38, Josh Babcock wrote: I'm playing with this because I am designing an ac3d model in Blender, and am having a great deal of trouble getting the edges and shading to look right. Currently fixing most of the problems will be very dificult and involve creating a lot more groups and objects in the .ac file than there really need to be, and some, like making the leading edge of a wing smooth and the trailing edge sharp, seem impossible. What I do is separate flat surfaces into separate objects. Flat/planar objects can obviously not be smoothed so it works great for cockpit windows. However I'm not sure how this will work for trailing edges. I've only just started doing some wing modeling so I'll let you know tommorrow if I managed to get it right. I'm also using Blender (2.31) with the AC3D Python export script and so far I've had no hassles. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
Josh Babcock wrote: I'm playing with this because I am designing an ac3d model in Blender, and am having a great deal of trouble getting the edges and shading to look right. [...] I don't want to go and add a bunch more polys around the sharp edges [...] Looks great in Blender though. There are patches to plib available that should fix this problem. Erik Hofman has the current version at: http://www.a1.nl/~ehofman/fgfs/downloads/Andy_Ross_vertsplit2-EMH.tar.gz Try them. If you like them, please let the plib folks know and ask them to apply the patches. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
The problem that I have is that if you seperate the top and bottom halves, you get an edge on the leading edge. If you leave them as one object, you get shading artifacts on the trailing edge. It would be really great if the export script and plib supported the crease-angle attribute that the new ac3d supports. That or if it didn't join up vertices that I purposely seperated to prevent smooth shading on that edge. Josh Paul Surgeon wrote: On Sunday, 4 January 2004 15:38, Josh Babcock wrote: I'm playing with this because I am designing an ac3d model in Blender, and am having a great deal of trouble getting the edges and shading to look right. Currently fixing most of the problems will be very dificult and involve creating a lot more groups and objects in the .ac file than there really need to be, and some, like making the leading edge of a wing smooth and the trailing edge sharp, seem impossible. What I do is separate flat surfaces into separate objects. Flat/planar objects can obviously not be smoothed so it works great for cockpit windows. However I'm not sure how this will work for trailing edges. I've only just started doing some wing modeling so I'll let you know tommorrow if I managed to get it right. I'm also using Blender (2.31) with the AC3D Python export script and so far I've had no hassles. Paul ___ 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] DC-3 3d cockpit
is this one differnt than the one at: http://www.plausible.org/vertsplit/vertsplit2.tar.gz? That's the one that I'm trying to apply now, without luck. Josh Andy Ross wrote: Josh Babcock wrote: I'm playing with this because I am designing an ac3d model in Blender, and am having a great deal of trouble getting the edges and shading to look right. [...] I don't want to go and add a bunch more polys around the sharp edges [...] Looks great in Blender though. There are patches to plib available that should fix this problem. Erik Hofman has the current version at: http://www.a1.nl/~ehofman/fgfs/downloads/Andy_Ross_vertsplit2-EMH.tar.gz Try them. If you like them, please let the plib folks know and ask them to apply the patches. :) Andy ___ 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] DC-3 3d cockpit
Josh Babcock wrote: is this one differnt than the one at: http://www.plausible.org/vertsplit/vertsplit2.tar.gz? That's the one that I'm trying to apply now, without luck. It is basically the same, I've just modified the code a bit to integrate it some more with plib. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
Josh Babcock wrote: is this one differnt than the one at: http://www.plausible.org/vertsplit/vertsplit2.tar.gz? That's the one that I'm trying to apply now, without luck. It's essentially identical. It should just work to drop the files into your src/ssg directory and do a rebuild. What problems are you having? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
Well, this download is working better, but it is complaining: Makefile:315: *** missing separator. Stop. I also had to move Makefile.am back into the base directory. Josh Andy Ross wrote: Josh Babcock wrote: is this one differnt than the one at: http://www.plausible.org/vertsplit/vertsplit2.tar.gz? That's the one that I'm trying to apply now, without luck. It's essentially identical. It should just work to drop the files into your src/ssg directory and do a rebuild. What problems are you having? Andy ___ 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] DC-3 3d cockpit
Josh Babcock [EMAIL PROTECTED] said: The problem that I have is that if you seperate the top and bottom halves, you get an edge on the leading edge. If you leave them as one object, you get shading artifacts on the trailing edge. It would be really great if the export script and plib supported the crease-angle attribute that the new ac3d supports. Andy's patch to plib basically does this without the crease-angle attribute, although it doesn't have a good way to control the effect other than to split surfaces (stepped angles) if you want roundness. Plib doesn't support the ac3d 4.0 format and I haven't seen signs that it will yet. Basically Andy Colburne stiffed all his current users. And once one part of a contract is broken it's hard to know what will be next. More than likely AC3D will always be a minor player. I for one won't be making an effort to update the ac3d support. The next step for plib (and FlightGear) should probably be VRML support. That or if it didn't join up vertices that I purposely seperated to prevent smooth shading on that edge. That requires some modification to the loader. I started on it a while ago with some success but real work got in the way. The problem is plib doesn't track the surface/poly level data which is essential to calculating normals on the fly. This means that if the vertices are identical they will be identified as the same for normal calculations, even if they are on different surfaces (so long as both surfaces are grouped in the same object). If the plib loader/optimizer didn't snap all vertices less than 1mm apart (a stupid feature?) then we could work around by exploding the seperated vertices by 0.1 or something like that. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
Well, I already changed the slop constatnt in my plib librarys to a much smaller number, but for this application, I need something that will work right with a clean flightgear install. Josh Jim Wilson wrote: Josh Babcock [EMAIL PROTECTED] said: The problem that I have is that if you seperate the top and bottom halves, you get an edge on the leading edge. If you leave them as one object, you get shading artifacts on the trailing edge. It would be really great if the export script and plib supported the crease-angle attribute that the new ac3d supports. Andy's patch to plib basically does this without the crease-angle attribute, although it doesn't have a good way to control the effect other than to split surfaces (stepped angles) if you want roundness. Plib doesn't support the ac3d 4.0 format and I haven't seen signs that it will yet. Basically Andy Colburne stiffed all his current users. And once one part of a contract is broken it's hard to know what will be next. More than likely AC3D will always be a minor player. I for one won't be making an effort to update the ac3d support. The next step for plib (and FlightGear) should probably be VRML support. That or if it didn't join up vertices that I purposely seperated to prevent smooth shading on that edge. That requires some modification to the loader. I started on it a while ago with some success but real work got in the way. The problem is plib doesn't track the surface/poly level data which is essential to calculating normals on the fly. This means that if the vertices are identical they will be identified as the same for normal calculations, even if they are on different surfaces (so long as both surfaces are grouped in the same object). If the plib loader/optimizer didn't snap all vertices less than 1mm apart (a stupid feature?) then we could work around by exploding the seperated vertices by 0.1 or something like that. Best, Jim ___ 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] DC-3 3d cockpit
Josh Babcock wrote: Well, this download is working better, but it is complaining: Makefile:315: *** missing separator. Stop. Which Makefile? I also had to move Makefile.am back into the base directory. Had to or... what? As always, bug reports with complete symptom descriptions are easiest to resolve. Try a complete rebuild of plib, and leave the base directory makefile alone. One thought: you must be using the CVS version of plib for the new files to work. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Aw: Re: [Flightgear-devel] DC-3 3d cockpit
Yes, I am. Ilja Von: Marcio Shimoda [EMAIL PROTECTED] Hi, Ilja! Are you running on Windows? Marcio Shimoda ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
Hi, Andy Andy Ross [EMAIL PROTECTED] wrote: Ilja wrote: 1. The trim wheel looks in AC3D like this [...] is just an ugly object: [...] The orange mixture stick doesn't look correct too. Off hand, it looks to me like the normals are wrong. The bright white vertices usually result from a normal being far too large. AC3D has been known to generate some very strange geometry in the past, and it's possible that it is confusing plib's normal calculation. Try to look through the file and verify that you don't have any degenerate triangles, etc... I will do that. Or, if you are feeling adventurous, try my plib patch which replaces the normal calculation step with a smarter one that understands the difference between smooth and sharp edges: http://www.plausible.org/vertsplit/vertsplit2.tar.gz (Make sure you are using the CVS version of plib, dump all the files in the tarball into src/ssg, then rebuild plib and FlightGear). I´m sorry, but I´m using the precompiled FlightGear v 9.3 for Windows and I haven´t got any compiler. The two implementations share no code, so if the problem persists with the patch, the bug is almost certainly in your model file. 2. The instrument panel shines through the fuselage: [...] but the dc3 model is not alone there, when you look at other aircrafts with 2d panels, you can find the same bug (or feature?). So I took screenshots from c172, a4 and c310u3a. This is a known issue that gets reported from time to time. The 2D panels use a depth buffer offset to draw the layers, and it ends up being too coarse on 16 bit depth buffers. Try setting your screen depth to 24bpp and see if that fixes the issue. It seems to depend on models' surfaces, but what can you see in FlightGear v. 9.2? [...] There is no bug! Are you sure you didn't change your display settings and/or take the screenshots on a different machines? Yes, I´m sure. Ilja ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
Andy Ross [EMAIL PROTECTED] said: Ilja wrote: 1. The trim wheel looks in AC3D like this [...] is just an ugly object: [...] The orange mixture stick doesn't look correct too. Off hand, it looks to me like the normals are wrong. The bright white vertices usually result from a normal being far too large. AC3D has been known to generate some very strange geometry in the past, and it's possible that it is confusing plib's normal calculation. Try to look through the file and verify that you don't have any degenerate triangles, etc... Plib snaps vertices together. Yet another why do we need this? feature that is always on by default. I think the snap value has been reduced from 1cm to 1mm in plib cvs. Also there is a fix in plib cvs that partially fixes a problem where perfectly good triangles were being found degenerate. When plib finds degenerate triangle it just puts a 1,0,0 normal on the vertices (hence the white). It is still possible for plib to detect a good triangle as degenerate. 2. The instrument panel shines through the fuselage: [...] but the dc3 model is not alone there, when you look at other aircrafts with 2d panels, you can find the same bug (or feature?). So I took screenshots from c172, a4 and c310u3a. This is a known issue that gets reported from time to time. The 2D panels use a depth buffer offset to draw the layers, and it ends up being too coarse on 16 bit depth buffers. Try setting your screen depth to 24bpp and see if that fixes the issue. It seems to depend on models' surfaces, but what can you see in FlightGear v. 9.2? [...] There is no bug! Are you sure you didn't change your display settings and/or take the screenshots on a different machines? It isn't showing in 24bpp mode. Some aircraft do a range select on the panel object so that it doesn't show at all when in external views (e.g. c172p-3d). Maybe that is where the confusion is. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] DC-3 3d cockpit
Hello, I´m working on a 3d-cockpit for dc3, but I got some problems. You can download these aircraft files from: http://home.arcor.de/iljamod/dc3.zip 1. The trim wheel looks in AC3D like this: http://home.arcor.de/iljamod/object_in_ac3d.jpg, but in FlightGear it is just an ugly object: http://home.arcor.de/iljamod/dc3-throttle-bug.jpg The orange mixture stick doesnt look correct too. 2. The instrument panel shines through the fuselage: http://home.arcor.de/iljamod/dc3-model-bug.jpg, but the dc3 model is not alone there, when you look at other aircrafts with 2d panels, you can find the same bug (or feature?). So I took screenshots from c172, a4 and c310u3a. http://home.arcor.de/iljamod/c172-model-bug.jpg http://home.arcor.de/iljamod/a4.jpg http://home.arcor.de/iljamod/c310u3a.jpg It seems to depend on models´ surfaces, but what can you see in FlightGear v. 9.2? http://home.arcor.de/iljamod/c172-fgfs-9-2.jpg There is no bug! What´s wrong there? Thank you very much in advance Ilja ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] DC-3 3d cockpit
I´m sorry some adresses were incorrect, these are right: http://home.arcor.de/iljamod/dc3.zip http://home.arcor.de/iljamod/object_in_ac3d.jpg http://home.arcor.de/iljamod/dc3-throttle-bug.jpg http://home.arcor.de/iljamod/dc3-model-bug.jpg http://home.arcor.de/iljamod/c172-model-bug.jpg http://home.arcor.de/iljamod/a4.jpg http://home.arcor.de/iljamod/c310u3a.jpg http://home.arcor.de/iljamod/c172-fgfs-9-2.jpg Ilja ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
Hi, Ilja! Are you running on Windows? Marcio Shimoda -- ___ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
Ilja wrote: 1. The trim wheel looks in AC3D like this [...] is just an ugly object: [...] The orange mixture stick doesn't look correct too. Off hand, it looks to me like the normals are wrong. The bright white vertices usually result from a normal being far too large. AC3D has been known to generate some very strange geometry in the past, and it's possible that it is confusing plib's normal calculation. Try to look through the file and verify that you don't have any degenerate triangles, etc... Or, if you are feeling adventurous, try my plib patch which replaces the normal calculation step with a smarter one that understands the difference between smooth and sharp edges: http://www.plausible.org/vertsplit/vertsplit2.tar.gz (Make sure you are using the CVS version of plib, dump all the files in the tarball into src/ssg, then rebuild plib and FlightGear). The two implementations share no code, so if the problem persists with the patch, the bug is almost certainly in your model file. 2. The instrument panel shines through the fuselage: [...] but the dc3 model is not alone there, when you look at other aircrafts with 2d panels, you can find the same bug (or feature?). So I took screenshots from c172, a4 and c310u3a. This is a known issue that gets reported from time to time. The 2D panels use a depth buffer offset to draw the layers, and it ends up being too coarse on 16 bit depth buffers. Try setting your screen depth to 24bpp and see if that fixes the issue. It seems to depend on models' surfaces, but what can you see in FlightGear v. 9.2? [...] There is no bug! Are you sure you didn't change your display settings and/or take the screenshots on a different machines? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
[EMAIL PROTECTED] wrote:
1. The trim wheel looks in AC3D like this:
http://home.arcor.de/iljamod/object_in_ac3d.jpg, but in FlightGear it is just an ugly
object: http://home.arcor.de/iljamod/dc3-throttle-bug.jpg
The orange mixture stick doesnt look correct too.
That's a plib bug -- any vertices closer than 1cm together get merged,
messing up surfaces. It's easy to fix, but the plib project isn't always
fast to take up patches. I run a patched copy locally, and you might want
to do the same thing:
Index: src/ssg/ssgOptimiser.cxx
===
RCS file: /cvsroot/plib/plib/src/ssg/ssgOptimiser.cxx,v
retrieving revision 1.31
diff -c -u -r1.31 ssgOptimiser.cxx
--- src/ssg/ssgOptimiser.cxx4 Dec 2002 20:42:28 - 1.31
+++ src/ssg/ssgOptimiser.cxx5 Dec 2003 15:29:08 -
@@ -26,7 +26,7 @@
static float optimise_vtol [3] =
{
- 0.01f, /* DISTANCE_SLOP = One centimeter */
+ 0.001f, /* DISTANCE_SLOP = One millimeter */
0.04f, /* COLOUR_SLOP = Four percent */
0.004f, /* TEXCOORD_SLOP = One texel on a 256 map */
} ;
2. The instrument panel shines through the fuselage:
http://home.arcor.de/iljamod/dc3-model-bug.jpg, but the dc3 model is not alone there,
when you look at other aircrafts with 2d panels, you can find the same bug (or
feature?). So I took screenshots from c172, a4 and c310u3a.
http://home.arcor.de/iljamod/c172-model-bug.jpg
http://home.arcor.de/iljamod/a4.jpg
http://home.arcor.de/iljamod/c310u3a.jpg
I think that's mainly a matter of where the panel comes in the object order,
but I'm not sure.
All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
