Re: [Flightgear-devel] [Rembrandt] the plan
Frederic Bouvier wrote: The Rembrandt renderer is enabled with the --enable-rembrandt option. *ALL SHADERS SHOULD BE SET TO OFF* unless someone want to begin to convert other shaders. On Linux Debian/AMD64 (6.0) using Nvidia's 295.33 driver and a one-hour old GIT checkout plus this: jive: 11:05:16 ~ find .fgfs* # - make sure no autosave-cruft present find: No match. jive: 11:05:18 ~ env | grep \^FG FG_HOME=/opt/FlightGear # - binary install prefix FG_ROOT=/home/martin/SCM/FlightGear/fgdata # - Base Package jive: 11:05:22 ~ fgfs --prop:/sim/rendering/shaders/quality-level=0 --timeofday=noon --enable-rembrandt I'm getting a picture like this: http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_01.png Without Rembrandt everything looks as usual. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Rembrandt] the plan
Martin Spott wrote: http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_01.png Default console output is here - nothing particularly exciting: http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_01.txt Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Rembrandt] the plan
Hi Martin, - Mail original - De: Martin Spott Martin Spott wrote: http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_01.png Default console output is here - nothing particularly exciting: http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_01.txt The interesting part is here : RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cda Warning: RenderStage::runCameraSetUp(State) Pbuffer does not support multiple color outputs. Warning: RenderStage::runCameraSetUp(State) Pbuffer does not support multiple color outputs. Warning: RenderStage::runCameraSetUp(State) Pbuffer does not support multiple color outputs. 0x8cda is FRAMEBUFFER_INCOMPLETE_FORMATS_EXT Can you check that your card support extension ARB_texture_rg ( glxinfo | grep ARB_texture_rg ) ? What kind of NVidia card is it ? Regards, -Fred -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Rembrandt] the plan
Frederic Bouvier wrote: Can you check that your card support extension ARB_texture_rg ( glxinfo | grep ARB_texture_rg ) ? jive: 11:40:31 ~ glxinfo | grep -1 ARB_texture_rg GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, GL_ARB_texture_rg, GL_ARB_texture_storage, GL_ARB_texture_swizzle, GL_ARB_timer_query, GL_ARB_transpose_matrix, What kind of NVidia card is it ? GeForce 7950 GT. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] simgear zlib 1.2.6 lowlevel
Hi all I had some problems compiling simgear release/2.6.0 using zlib 1.2.6 on OSX. Looks like the main problem is here (independent of platform?): lowlevel.hxx void sgReadString ( gzFile fd, char **var ) ; lowlevel.cxx int c = gzgetc ( fd ) ; While this seems to work with zlib 1.2.3 and 5, documentation says this (probably ... sorry for any misinterpretation) doesn’t work anymore for 1.2.6 I tried cmake build with -DZLIB_INCLUDE_DIR etc. to the right version, but this didnt’t work at all. I’m sure I did something wrong there with cmake, #include zlib.h linked always against my newest version. So I changed lowlevel.hxx the hard way to include a /usr/include/zlib.h (OSX installed version 1.2.3) and now I can compile. Nomen est omen, so this note here to the devellist is some kind of a lowlevel report, unfortunately I’m not able to patch cmakelist nore lowlevel.hxx/cxx to work with zlib 1.2.6. I changed lowlevel.hxx directly for my purposes, but this IS lowlevel. Am I the only one with this small zlib issue ? Cheers, Yves -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear zlib 1.2.6 lowlevel
On 28 Mar 2012, at 12:21, HB-GRAL wrote: I had some problems compiling simgear release/2.6.0 using zlib 1.2.6 on OSX. Looks like the main problem is here (independent of platform?): lowlevel.hxx void sgReadString ( gzFile fd, char **var ) ; lowlevel.cxx int c = gzgetc ( fd ) ; While this seems to work with zlib 1.2.3 and 5, documentation says this (probably ... sorry for any misinterpretation) doesn’t work anymore for 1.2.6 I tried cmake build with -DZLIB_INCLUDE_DIR etc. to the right version, but this didnt’t work at all. I’m sure I did something wrong there with cmake, #include zlib.h linked always against my newest version. So I changed lowlevel.hxx the hard way to include a /usr/include/zlib.h (OSX installed version 1.2.3) and now I can compile. Nomen est omen, so this note here to the devellist is some kind of a lowlevel report, unfortunately I’m not able to patch cmakelist nore lowlevel.hxx/cxx to work with zlib 1.2.6. I changed lowlevel.hxx directly for my purposes, but this IS lowlevel. Am I the only one with this small zlib issue ? It happened for me, I fixed it by forcing Macports to use zlib 1.2.5, instead of 1.2.6 which has introduced the extra issue. The real issue is that we're finding zlib.h in /opt/local/include, but using the libz from /usr. (The Apple supplied version) I tried to find a solution, so that we use one header + library consistently, but didn't yet figure this out. Since zlib doesn't have a subdir in include, we're at mercy of the search paths a little. For the library we can force an explicit absolute path to link against, but Cmake's FindZLIB is finding the one in /usr (correctly, I would say), the problem is the header search order at compile time. James -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear zlib 1.2.6 lowlevel
Am 28.03.12 15:08, schrieb James Turner: The real issue is that we're finding zlib.h in /opt/local/include, but using the libz from /usr. (The Apple supplied version) I tried to find a solution, so that we use one header + library consistently, but didn't yet figure this out. Since zlib doesn't have a subdir in include, we're at mercy of the search paths a little. For the library we can force an explicit absolute path to link against, but Cmake's FindZLIB is finding the one in /usr (correctly, I would say), the problem is the header search order at compile time. James Hi James Didn’t dive into but noticed OSG has probably a more sophisticated cmake zlib check already. Maybe it’s worth to have a look there? Doesn’t type change of gzFile need a change in lowlevel.cxx anyway, once ? Cheers, Yves -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Rembrandt] the plan
What is the exact g-buffer format rembrandt tries to set up? NV4x/NV5x have some serious restrictions. 1 attachment is RG16 (normals.xy) 2 attachments are RGBA8 (diffuse color, and monochrome specular, emissive and shininess) 1 GL_DEPTH_COMPONENT32 (depth) Regards, -Fred -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG caching and other OSG issues
Hi, I've pushed a fix for a larger memory issue, mainly affecting effects/texture images, but also other objects. Once loaded, these stuck in memory until shutting down flightgear - so memory consumption was continually growing when flying larger distances. Probably wasn't much of an issue initially, when we only had few or generic textures. Now, with lots of custom models and eye candy, we obviously should be able to drop stuff again. We've discussed this about a year ago. Tim suggested using observer pointers instead of references in the cache maps. The discussed patch was never pushed to sg/next though, since I was running into stability issues with OSG 2.8.3. Since we don't support OSG 2.8.3 any longer, I've revived this again and changes are in simgear now. Keeps memory consumption a lot lower. I'm still seeing a slight memory growth when moving - but by far, it's not as bad as it was. Simple test is to relocate-on-ground to a series of airport locations and watch process memory. Mathias, maybe you can have a look at the simgear changes. Maybe you see a way to improve this even further - i.e. do we still need all these cache maps? Or could we simply rely on some OSG cache in some places? cheers, Thorsten Am 03.05.2011 21:49, schrieb ThorstenB: On Mon, Apr 18, 2011 at 9:55 AM, Tim Mooretimoor...@gmail.com wrote: On Sun, Apr 17, 2011 at 6:10 PM, ThorstenBbre...@gmail.com wrote: There is a global cache in simgear/makeEffect.cxx (effectMap), and it has no condition to ever drop anything. So, created effects always stay in memory until shutdown - hence also their textures. It seemed like a good idea at the time :) The Effect cache could be changed to use osg::observer_ptr, which is a weak pointer. Good idea. Here's a patch using observers instead of references for caching. Puts some live into the effect/texture destructors - so these can finally free up some memory once the objects are no longer used anywhere: http://www.gitorious.org/~thorsten/fg/thorstenbs-simgear/commit/71d14629076b3a56c40cc0309b42b3a22d579bec -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
