Durk,
On Monday, August 01, 2011 11:18:02 Durk Talsma wrote:
On 30 Jul 2011, at 21:31, Stuart Buchanan wrote:
So, I quickly wrote an alternative to the current Nasal system
geodinfo(), using the groundcache instead of the current scenery
method.
This sounds very interesting: As far
Stuart,
On Monday, August 01, 2011 21:51:16 Stuart Buchanan wrote:
I'm looking to see whether we should just have a single way to query
the ground elevation using the groundcache, and use that everywhere.
See the lenghty explanation in the response to the weather system.
However, the AI call
Hi Stuart,
I have checked in a version of the ground intersection routines that
just use the bvh trees in the scenegraph.
This should improove the run time behaviour for the ground queries.
That should be even faster than the variant you tried since it avoids the
extra computations/allocations
Hi,
On Sunday, August 07, 2011 12:32:36 Stuart Buchanan wrote:
2011/8/7 Mathias Fröhlich:
I have checked in a version of the ground intersection routines that
just use the bvh trees in the scenegraph.
This should improove the run time behaviour for the ground queries.
That should
Hi,
On Sunday, August 07, 2011 20:46:46 Stuart Buchanan wrote:
I think this may have broken YASim aircraft. I've tried a selection (dc3,
dc-3, a4f) and they all start at 36,000ft altitude with 0 IAS.
I suspect it might be an initialization order issue,
I've raised it as bug 397
Hi,
On Tuesday, August 09, 2011 02:30:18 syd adams wrote:
After a git pull and recompile of fgdata , flightgear and simgear
today , it seems that fly-by view is broken . Were there any recent
changes to the nasal geo.* functions ? Just guessing here , I cant
tell if the camera viewpoint is
Hi,
On Monday, September 05, 2011 14:47:44 Alan Teeder wrote:
Please don´t.
I reverted from VC100 to VC90 as the Cmake process was always failing.
There is a difference between Hudson saying that all is OK with Cmake and
Visual Studio VC100 producing working executables.
This was all
Hi Durk,
On Saturday, September 10, 2011 10:28:22 Frederic Bouvier wrote:
FindOpenSceneGraph.cmake is in the Cmake distribution, in the share
directory. You certainly need to tell Cmake where the installed OSG is.
Correct, this should be cmake provided.
So, cmake does not find its own files.
Hi,
On Saturday, September 10, 2011 10:46:03 Durk Talsma wrote:
Thanks; looking at /usr/share/cmake/Modules, I see that I have a
Findosg.cmake file, as well as several Findosg*.cmake files, but no
FindOpenSceneGraph.cmake. FWIW, this is one an opensuse 10.0, running
cmake version 2.6 - patch
Hi,
On Sunday, September 11, 2011 12:55:33 Christian Schmitt wrote:
This is now solved with the latest FG git version. Thanks!
Ok, thanks, I was on the way asking for that :)
Mathias
--
Using storage to extend the
Hi Curt, Durk,
On Monday, September 12, 2011 07:45:49 Durk Talsma wrote:
based on my experience with building FlightGear from yesterday, I'd say
that cmake is a great tool and most likely a step forward. But. it does
take a little getting used to, in particular the finer details of compiler
Hi Durk,
On Sunday, September 11, 2011 21:29:28 Durk Talsma wrote:
My error was in SimGear, and your fix was for FlightGear, it I'm correct.
So, I'm not sure if that would fix it.
Hmm, then probably not...
... but I have done the same change in the identical file in simgear now.
I did not know
Hi,
On Monday, September 12, 2011 00:18:47 Stuart Buchanan wrote:
The problem definitely seems to be that any other objects in the scenery
with an alpha layer are rendered after the clouds, so are rendered in
front of them, irrespective of the viewpoint and their relative positions.
By
Hi,
I am a bit away from that stuff currently. Currently checking mail in vacation
...
But:
On Saturday, September 17, 2011 19:29:14 Citronnier - Alexis Bory wrote:
alexis@duck:~/fgfs/install/build-flightgear$ cmake -D
CMAKE_INSTALL_PREFIX:PATH=/home/alexis/fgfs/install/fgfs -D
Sid,
On Saturday, September 24, 2011 04:09:51 Sid Boyce wrote:
# ./configure --prefix=/usr/local/lib64
The prefix seems suspicious to me. Probably the lib64 is too much.
The rest what you were reporting looked somehow like a 32/64 bit mixed
objects/libs problem. No clue where this might
Hi,
On Thursday, September 22, 2011 10:07:48 Jason Cox wrote:
I am having an issue with compiling the lattest git version due to a
lack of a libhal on my system
after check the web site for libhal
(http://www.freedesktop.org/wiki/Software/hal) I found that it now in
maintenance mode and
Hi,
On Friday, September 23, 2011 20:41:41 Francesco Angelo Brisa wrote:
I am trying to take one step ahead, and start adapting the script to
work with the upcoming ubuntu relase of october.
after a little modification (libapr1-dev needed and renaming
libboost1.46-dev) I failed to succeed
Hi,
On Tuesday, September 20, 2011 01:22:08 Roland Häder wrote:
I have finally fixed this myself:
http://www.flightgear.org/forums/viewtopic.php?f=45t=13539
Just extend 'fgpanel_LDADD' with -lsgthreads. Can someone commit this
fix?
I also needed to add some GL stuff to the same command.
Hi,
On Saturday, September 24, 2011 10:38:28 James Turner wrote:
On 24 Sep 2011, at 09:04, Mathias Fröhlich wrote:
Yes, I can see that libGL and libz is just pulled indirectly which no
longer works on very new linux ld variants.
Arrgh, really? That's news to me.
I do not know the real
Hi,
On Sunday, September 25, 2011 02:10:27 Francesco Angelo Brisa wrote:
Can you retry?
Same problem, nothing changed
Did you regenerate the Makefile.in's from Makefile.am's using autogen.sh in
simgears toplevel directory?
Also since we want to move to cmake, does this work already?
Hi,
On Tuesday, October 18, 2011 02:01:33 Csaba Halász wrote:
While investigating a reported compilation error, I had a look in the
SGMath headers. I noticed some of them don't properly include their
dependencies (for example, SGMisc is missing SGCMath, SGGeodesy is
missing SGVec3 and
Hi,
On Tuesday, October 18, 2011 10:40:41 James Turner wrote:
I've written this up, at least a first attempt, will commit it later today,
and people can review it for sanity / correctness / omissions :)
Great thanks!
Mathias
Hi,
On Sunday, October 23, 2011 21:44:53 James Turner wrote:
I'm not sure *exactly* what you're doing wrong, but in general I would say
you're over controlling things a little.
I'm not clear why you are installing each component in a subdir of install
- that's making your life complicated.
On Monday, October 24, 2011 22:12:15 Martin Spott wrote:
George Patterson wrote:
Btw, Berlios is closing on 31/12/2011 so grab what you need now. I am
not sure if Mathias has moved the above project to another host.
I'm sure Mathias will speak about the details himself, but aside from
Hi,
Some of you have already noticed that berlios is closing at the end of the
year. So OpenRTI needs to find a new home.
I have recently just changed my upstream repository to
git://gitorious.org/openrti/openrti.git
This is not a full replacement for the berlios site, but currently at
Hi,
On Monday, October 24, 2011 10:27:11 thorsten.i.r...@jyu.fi wrote:
My understanding is that
* the vertex shader computes stuff for each vertex
Yes.
If I don't use a fragment shader (as e.g. in the 3dclouds), things like
shading get a linear interpolation between vertices.
You need to
Hi,
On Friday, October 28, 2011 20:20:55 Geoff McLane wrote:
Re: In Windows (XP WIN32) - using CMake GUI
=
Unfortunately, here not so good ;=(( for building
FG. SG was not too bad...
As mentioned, I had to add two options,
PTW32_STATIC_LIB, to use pthreads (for
Hi,
I have yesterday checked in a change to move the system dependent part of the
sleep + busy loop sleep stuff in frame rate throtteling into a system dependent
file. Also it makes use of the today available more finegrained posix clock
implementation on linux.
Like always I have tested what
Hi Geoff,
On Saturday, October 29, 2011 18:21:29 Geoff McLane wrote:
Thank you for your reply and ideas... and
hope I can answer some things regarding Windows...
And as usual, sorry in advance that this is so
long...
So, my disclaimer is that I do not have any win32 system running.
I just
Hi,
As usual, I did not take the time to really look into the code. So please
excuse more or less obvious questions about the current implementation.
On Monday, December 05, 2011 09:26:09 thorsten.i.r...@jyu.fi wrote:
Since according to the newsletter Stuart's current ongoing quest is to get
Hi,
On Monday, December 05, 2011 12:07:31 Stuart Buchanan wrote:
I had come to the conclusion that the only way to get a signficant increase
in performance would be move to using Impostors. That's a big change,
particularly as the OSG implimentation appears to be broken/bit-rotted.
I've
Hi Stuart,
On Sunday, December 11, 2011 23:04:02 you wrote:
I've had a look, and I think I can change the code to create a single
PrimitiveSet for each cloud fairly easily.
I think you can try.
As an answer to the previous mail, point sprites may help here too. You will
get the bilboard
Hi,
On Tuesday, December 13, 2011 15:31:43 Csaba Halász wrote:
2011/12/12 Mathias Fröhlich mathias.froehl...@gmx.net:
As an answer to the previous mail, point sprites may help here too. You
will get the bilboard effect for free.
We have a queriable limit in the maximum supported point
Stuart,
On Monday, December 12, 2011 14:38:37 Vivian Meazza wrote:
IIRC clouds were moved into bin 10 to improve appearance vis-à-vis
particles. If we put clouds back into bin 9 and particles remain in 10 all
the cooling towers, chimney efflux, aircraft contrails, exhausts etc. are
drawn
Stuart,
On Wednesday, December 14, 2011 15:49:22 Stuart Buchanan wrote:
2011/12/14 Mathias Fröhlich wrote:
But, the question is how many cloud drawables do we have? The render Bin
sorting bottleneck - if we run into this - is O(log(n)*n) with the n=
number depth sorted drawables. Which
Hi,
On Saturday, December 17, 2011 18:43:17 ThorstenB wrote:
No idea though why this affects fonts...
Hmm, no that should not affect font loading.
But yes I can see the splash screen having the wrong font too.
Looking into this...
Mathias
Hi,
Fixed.
Mathias
--
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
Hi Stuart,
On Saturday, December 17, 2011 20:14:22 you wrote:
I've committed the code changes to my repository clones for the impostors,
some configuration for LoD nodes, and having a geometry per cloud, with
a bubble sort for ordering.
It would be fantastic if people could take the time
Hi Fred,
On Sunday, December 18, 2011 09:37:04 Frederic Bouvier wrote:
Shaders in C++ code (CameraGroup.*xx, renderer.cxx, and in the effect code
in SG - maybe I will revert that). But the ultimate goal is to make them
configurable. All effects would have to be rewritten because the renderer
Hi,
On Sunday, December 18, 2011 12:06:22 Stuart Buchanan wrote:
One question for the release managers: Do performance improvements such as
these count as bug fixes or features? Should we try to get this into
the 2.6.0 release,
or wait until 2.8.0?
Given that you have already prepared this
Hi,
On Wednesday, December 21, 2011 00:42:04 Csaba Halász wrote:
Really nobody else seeing this? Any ideas what I could look at to
investigate further?
Yes, I saw this a few weeks ago on a long flight.
But I did not see a chance to reproduce what I saw. So I did not look
closer...
Mathias
Hi,
On Wednesday, December 21, 2011 21:25:11 Csaba Halász wrote:
Seems to be gone now :)
Ok. So, still I could not easily reproduce...
Any comments for my other question, about background model loading?
Well, models *are* loaded in the background. More than it was in the good old
times where
Hi,
On Friday, December 23, 2011 17:05:03 James Turner wrote:
==
glValidateProgram FAILED id=12 contextID=0
infolog:
Validation Failed: Sampler error:
Samplers of different types use the same texture image unit.
- or -
A sampler's texture unit is out of range (greater
Fred,
On Sunday, December 18, 2011 10:18:39 Frederic Bouvier wrote:
Your patronage will be welcome.
Ok.
My problem is that I have too many open projects currently. So, promising to
help here is something I cannot do today. But Sure, if you have questions feel
free to ask. But I currently
Hi,
On Saturday, December 24, 2011 11:12:10 James Turner wrote:
According to this, there should be no extension required:
http://lists.apple.com/archives/mac-opengl/2007/Oct/msg00108.html
And 'glxinfo' reports:
OpenGL vendor string: ATI Technologies Inc.
OpenGL
Hi,
On Tuesday, December 27, 2011 00:27:41 Stuart Buchanan wrote:
Vivian - are you anticipating the materials-dds.xml file replacing
materials.xml at some point? Any plans for further DDS texture work?
Hmm, regarding dds.
I have to say, that not all OpenGL drivers support texture compression,
Hi,
On Wednesday, December 28, 2011 15:29:50 James Turner wrote:
So, this is where my knowledge runs out - can someone suggest the next
debugging step, to identify the problem in the water effect?
Can you post the output from glxinfo -l.
Where the -l prints 'some interresting limits' ...
Or
Hi,
On Tuesday, December 27, 2011 10:49:07 Erik Hofman wrote:
Actually for the F-16 I did not switch because of compression but
because livery switching is almost instant while the previous textures
is took about 10 seconds to switch from internal view to external for
the first time.
That's
Hi,
On Wednesday, December 28, 2011 16:22:20 James Turner wrote:
On 28 Dec 2011, at 16:15, Csaba Halász wrote:
Since we are talking about shaders, aren't the limits
GL_VERTEX_SHADER_ARB:
GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB = 16
Vivian,
There is no intention to migrate as a whole to .dds: it is offered as an
appearance and performance upgrade for those who wish to use it. It is up to
aircraft developers to decide which format they will use. Indeed - they
could provide models with either format so that the user could
Hi Erik,
On Thursday, December 29, 2011 13:33:09 Erik Hofman wrote:
Setting compression to 'none' does speed up texture switching
considerably. Unfortunately there's little difference in switching from
internal to external view for the first time.
Thanks.
I do also see an initial frame drop
Vivian,
On Thursday, December 29, 2011 17:36:24 Vivian Meazza wrote:
I don't fully understand the point - we're not using .dds, and fancy shaders
as the default option - what else isn't working with open source drivers?
Well, the default f16 does not work anymore for example.
I have also
Hi,
On Friday, December 30, 2011 00:09:20 Csaba Halász wrote:
I wonder if there is an open standard counterpart that can do the same
as the dds compression? Or is the whole idea patented? (Eww, too broad
software patents are the work of the devil).
No, Sadly.
It is all about an OpenGL
Happy new year!
Vivian,
On Friday, December 30, 2011 10:48:40 Vivian Meazza wrote:
The hangs are caused by mipmap generation on the fly by OSG?
The hangs are caused by mipmap generation by the driver which happens on forst
use of a texture.
The old texture files are static and I would
Hi,
On Friday, December 30, 2011 11:11:39 Frederic Bouvier wrote:
* If it's just the mipmaps. May be we can precompute the mipmaps using
the cpu in the database loader thread. This would help all textures not
only the ones that could be converted. May be this is the most generic
Hi Erik,
On Friday, December 30, 2011 11:39:37 Erik Hofman wrote:
On Fri, 2011-12-30 at 10:42 +0100, Mathias Fröhlich wrote:
* If it's just the mipmaps. May be we can precompute the mipmaps using
the cpu in the database loader thread. This would help all textures not
only the ones
Hi,
On Friday, December 30, 2011 11:45:21 Frederic Bouvier wrote:
The problem I have to solve currently is how to feed the G-Buffer
to the Effect system because the textures used to store it are
camera-dependent (in a multi screen context) but the pass (which
is a stateset) is built once for
Hi,
On Sunday, January 01, 2012 11:41:22 Mathias Fröhlich wrote:
I think then, computing mipmaps for any texture file on the CPU in the
loader thread should globally improove the situation.
Also avoiding the compression already in the files should help every use
case. Except that the on disk
Hi,
On Saturday, January 14, 2012 20:17:22 Gijs de Rooy wrote:
is there an easy way to disable this message?
since i'm using dds texture, it's flooding the console...
+1
Every single texture of --material=materials-dds.xml seems gives an error...
How about moving these messages to
Hi,
On Sunday, January 15, 2012 10:56:14 Vivian Meazza wrote:
Just what is the user meant understand or to do about it?
What do you want to read?
Mathias
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Hi Fred,
On Sunday, January 01, 2012 16:14:17 Frederic Bouvier wrote:
Exactly. I want to give access to every stage of the rendering to the
effect system. The geometry pass outputs to render target, but the fog,
the lights, the bloom need to have access to the textures of the buffer,
and
Hi Fred,
On Sunday, January 15, 2012 13:08:03 Frederic Bouvier wrote:
Well, for the moment my solution works pretty well. I posted some videos
on the forum to show progress on lights
(http://www.flightgear.org/forums/viewtopic.php?f=47t=14883)
Nice!
I was able to attach the same depth
Vivian,
On Sunday, January 15, 2012 12:08:14 Vivian Meazza wrote:
I would suggest
Image D:/Git_New/my_fgdata/Textures/Terrain/sand6.dds uses compressed DDS
textures which may be unsupported by your video driver and not display
properly.
Ok,
Can you help me further:
It's not limited to
Hi Emilian,
On Sunday, January 15, 2012 14:33:40 Emilian Huminiuc wrote:
There are a couple of isue with that though. Biggest one is it will increase
disk/RAM usage by at least 4 times, if not 8 depending on
texture/compression method used. That basicaly negates all the advantages
of the dds
Hi Vivian,
Sorry for the long delay, also in face of the pending release.
Thanks for the suggestions.
On Sunday, January 15, 2012 19:08:17 Vivian Meazza wrote:
On the other hand, if you are trying to tell aircraft modelers not to use
these forms (.dds .ivs) of compression, then:
Image
Martin,
It's sad to hear that this central scenery database should have failed.
I never cared myself much about how our scenery is built.
This is just because all my interrests and work are in completely different
corners of this project. So concentrating on other corners than scenery can
Hi Fred,
On Friday, March 02, 2012 19:03:13 Frederic Bouvier wrote:
thoughts ?
Since we are now at the beginning of a release cycle, I would think now is the
right time.
For the question to preserve both renderers, compatibility of models I think
that we need to preserve both if we cannot
Hi,
On Wednesday, March 07, 2012 11:54:39 Gijs de Rooy wrote:
Same here on Nvidia Geforce GT 540M, see screenshot at:
https://lh3.googleusercontent.com/-YGfvue1R00s/T1c-OMTX83I/CdQ/nnik0
ZI1_Wk/s1024/fgfs-screen-055.png
No screenshot here, but I also agree that the current lights are
Hi,
On Wednesday, March 07, 2012 14:58:26 Lauri Peltonen wrote:
3. define an XML format for describing the two possible rendering
pipelines (the current and new). The format will introduce optional
elements (such as shadows, ambient occlusion, glow).
I want to point out my work on my
Hi,
Also for the breginning of the development cycle, I started working on
improoving fgviewer and cleanup scenery/model loading.
I have now checked in a change that should fix some long standing problems with
modelss that appear to have z-fighting. This change should not harm and works
so
Hi,
On Friday, March 09, 2012 21:37:32 Anders Gidenstam wrote:
This change breaks my setup. I consider it a feature that FG used
to load objects from all scenery directories visited up until the first
one that contains terrain for the tile. It made it possible to have
scenery object
Hi,
On Thursday, March 08, 2012 23:13:56 Clement de l'Hamaide wrote:
Without this little tweaks the tile can't be loaded. In conclusion, with
your change we need to associate Object AND Terrain folder. It's just a
feedback of my experience, don't take it as a critics ;)
That's fine.
Have
Hi Jon,
On Friday, March 09, 2012 10:43:55 Jon Stockill wrote:
Can you explain exactly how the loading now works, and if it's still
possible to use extra local objects trees in the way I describe?
Thanks for the response.
Well, I guess this hits the same problem that I try to solve now with
Hi,
On Sunday, March 11, 2012 21:07:37 Martin Spott wrote:
Mathias Fröhlich wrote:
The problem is that these sea tiles (Objects/e000n60/e001n61/2975201.stg
for example) with models never contain a base tile line where we could
know when to stop seraching the FG_SCENERY directory sequence
Good Evening,
Ok, no feedback to my comments here except Martin who tells me that the
current checked in version behaves as expected.
I personally can understand that people want to have a local seperated
directory for their own personal additions. Let it be additions to the scenery
that are
Hi,
On Tuesday, March 20, 2012 08:15:54 Renk Thorsten wrote:
Once you understand how the scattering integrals work it's natural to
compute them also from the outside of the atmosphere.
Okay, now I am *really* confused. Are we trying to solve the same problem?
I think so.
Light
Hi Jon,
On Tuesday, March 20, 2012 17:27:52 Jon Stockill wrote:
Except a bunch of scenery developers pointing out it completely breaks
their method of working.
Merging the work into an existing tree isn't really an option - the
ability to completely erase a tree and rebuild by script
Hi,
I had a busy week, so sorry for the delay.
On Saturday, March 17, 2012 10:07:07 Anders Gidenstam wrote:
I have not had time to consider the proposal carefully, but I agree that
the ocean tiles are problematic in the old (old) scheme if you have
object directories with overlapping objects
Hi,
On Wednesday, March 21, 2012 13:29:52 Renk Thorsten wrote:
Mathias, maybe it's just me - but I have a serious problem understanding
what you write. I have greatest respect for what you do, and I've seen some
amazing things like the factor 50 speed increase of the geodinfo() call,
but
Hi,
On Saturday, March 24, 2012 09:29:41 James Turner wrote:
Tangental, but, yes please!
This and a few other similar options, like generating a low-detail terrain
node 'automatically' for distant tiles, were some ideas I considered last
year to allow further draw distances.
Yes, the spt
Hi,
I try to catch up on things past an other busy week.
On Thursday, March 29, 2012 00:22:46 ThorstenB wrote:
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
Hi,
On Saturday, April 14, 2012 09:49:18 James Turner wrote:
On 13 Apr 2012, at 23:28, Chris Forbes wrote:
Presumably you could just ask osg or the gl to discard the top mip
level(s) rather than altering the source art to work around apple's
driver bugs?
Yeah, unfortunately I think
Hi,
On Saturday, April 14, 2012 11:05:10 James Turner wrote:
On 14 Apr 2012, at 10:10, Mathias Fröhlich wrote:
But every image goes through our hands. We can just rescale this under
certain conditions. At least the uncompressed textures are unproblematic.
I would introduce some property
Hi,
On Saturday, April 14, 2012 13:51:33 ThorstenB wrote:
On 14.04.2012 13:08, Stuart Buchanan wrote:
I like the idea of resizing textures at model loading time a lot.
The other option would be to switch the shader off. Presumably that
would not load the normal map into the GPU.
Hi,
On Saturday, April 14, 2012 17:16:52 ThorstenB wrote:
On 14.04.2012 15:18, Mathias Fröhlich wrote:
Shader textures are loaded unconditionally, at least into main memory.
Hopefully GPU loading is optional - but I'm not sure.
Textures are loaded in main memory when the model
Hi,
On Wednesday, April 18, 2012 10:25:55 Stuart Buchanan wrote:
For those interested, the technical background is as follows:
- a Quadtree is used to ensure very fast culling of the buildings -
based on the work that Tim Moore did for the forests.
- a single 1024x1024 texture is used for
Hi,
On Wednesday, April 18, 2012 17:21:56 Stuart Buchanan wrote:
I think I've already got that covered. I'm using a single osg::PrimitiveSet,
and a single list of QUADS/vertices/normals/colors/textureCoords at the
leaf of each Quadtree.
Great!
Thanks!
Mathias
Hi,
On Thursday, April 19, 2012 15:32:46 castle...@comcast.net wrote:
We need to fix the problem, just not sure best way to proceed.
Send me that change, I will see how to incorporate that.
This will take some time since my next two weeks are extremely full for me,
but somewhere past that ...
Hi,
On Tuesday, April 24, 2012 13:39:59 James Turner wrote:
Okay, then I realise this isn't useful for you, but I'm stumped why it
crashes for you. In particular, the hashForAirport function is being passed
something that looks like a valid pointer (I think), and it crashing on a
line that
Hi,
On Tuesday, April 24, 2012 22:51:34 James Turner wrote:
Okay, I guess I was assuming I can use SGreferenced the same way I use
release/retain in Cocoa, or addRef/decRef in COM/XPCOM. But it seems as if
this is not the case, from looking at your commit - I can't use
SGreferenced as a
Hi,
On Thursday, April 26, 2012 08:32:19 James Turner wrote:
On 25 Apr 2012, at 14:56, Stuart Buchanan wrote:
If you're going to be looking in the code anyway, the depth of the
quad tree is set in some constants at the top of the SGBuildingBin.cxx
file, and (IIRC) the LoD range is also
Hi,
On Wednesday, May 23, 2012 10:37:00 Stuart Buchanan wrote:
So
- Does anyone have any bright ideas on what I can do to reduce the
base memory occupancy? One option might be to not generate the
basement if the terrain is level.
- Could a fresh pair of eyes take a look at the obj.cxx,
Good morning,
On Friday, May 25, 2012 19:48:32 Stuart Buchanan wrote:
Thanks for taking a look.
I think that the SGBuildingBin destructor will be called when I call
the list clear()
method on the SGBuldingBinList (SGBuildingBin.cxx line 654). That in
turn calls clear()
I have no current
Hi,
On Sunday, June 17, 2012 13:00:15 castle...@comcast.net wrote:
This email rekindled an idea from a while back. Last year while working on
the 747 sim with multiple projectors and a quad core CPU I experimented
with setting up three instances of fgfs - one for each cpu, graphics card,
and
Hi,
On Monday, June 18, 2012 13:20:17 castle...@comcast.net wrote:
The HLA/RTI architecture is far more sophisticated than what might be
needed. The idea is not to split FlightGear into a distributed, federated
application across a multi-platform machine or network although that is an
Hi,
On Thursday, July 19, 2012 17:09:09 James Turner wrote:
I have some plans in that direction post 2.8, especially to flatten the LOD
quadtrees and transforms of the tiles. Each tile will get some top-level
LOD groups for all objects (shared and static). I'm hoping in combination
with the
Hi,
On Thursday, July 19, 2012 15:32:01 Tim Moore wrote:
The depth-pass-only pass is a well known optimization, but the fact it
is not helping implies that our bottleneck is not in fragment
processing. I've suspected for years that it lies on the CPU, and have
been trying to optimize our
Hi,
On Monday, July 16, 2012 07:20:32 Chris Forbes wrote:
If DDS is not politically acceptable, there should be an alternative
way of providing premipped textures.
Mipmap generation is a *significant* portion of the load time,
particularly on the nicer aircraft with large textures.
Even
Hi,
On Friday, July 13, 2012 21:20:33 Stuart Buchanan wrote:
I can see a number of options to resolve this (and I'm sure there are more):
The 4. Method that I can imagine is to precompute the mipmaps in the loader.
IIRC tests with some of the guys suffering from this problem, providing
Hi,
On Friday, July 13, 2012 21:20:33 Stuart Buchanan wrote:
I can see a number of options to resolve this (and I'm sure there are more):
Oh, I forgot in the previous mail:
There is a 5. Solution:
Provide premipmapped uncompressed dds files and compress them with something
like gzip. Osg can
301 - 400 of 434 matches
Mail list logo
