Re: [Flightgear-devel] Atmospheric Light Scattering
On Fri, Apr 26, 2013 at 8:39 AM, Renk Thorsten thorsten.i.r...@jyu.fiwrote: I've also taken a bit of a look at merging Rembrandt and ALS, and I think I understand the Rembrandt pipeline enough that I could add ALS to it. Just to provide some expectation management: Rembrandt (as deferred rendering) is very heavy on the fragment shader. ALS at low quality is currently rather balanced between vertex and fragment shader and at high quality adds all additional load to the fragment shader. An ALS implementation in Rembrandt will require that basically all light computations which are currently in the vertex pipeline move to the fragment shader as well. That's not a small workload, sunlight is about 100 times heavier to compute in ALS than in default or Rembrandt (that's what ALS burns framerate for). I don't think it's quite that bad. In a deferred shader like Rembrandt, the ALS would run in the deferred lighting pass. While it's true that the heavy work is done in a fragment shader, it only runs for each pixel on the screen, not for every rendered fragment. Also, in many cases the sky would take up a large portion of the out-the-window scene; is computing ALS for the blue sky as expensive as for an object in the scene? Not to mention that you don't need to run ALS in the cockpit... Tim -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Moonlight reloaded
On Sun, Nov 11, 2012 at 1:41 PM, Renk Thorsten thorsten.i.r...@jyu.fiwrote: I suspect the difference in light intensity (dynamic range) doesn't fit in an 8-bit 3-component color. It sure doesn't, but I think you're thinking way too complex. We don't want to render physical light intensity, we want to render perceived light intensity, and there the Weber Fechner law is relevant, and that says that we roughly want to render the log of the physical light intensity. For instenace, full daylight has 10,000 lux, and a very dark overcast day has 100 lux - yet if you multiply the sun (rgb) = (1,1,1) which works fine for a sunny day with 0.01, you don't get an overcast day - 0.6 is more the factor you need, i.e. every factor 10 reduction in luminous flux is about -0.2 from the base light. A full moon has about 0.1 - 1 lux, so we get (rgb) values of ~(0.1..0.2) in the light vector - which works visually just fine (I've been using vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight * scattering; for the pics) - which gives imo a decent visual appearance. You need to do High Dynamic Range rendering to accurately capture these differences and the eye's ability to adapt to them. Basically, you do all the rendering in floating point and at the end convert the values to RGB colors with a mapping operator. We don't do that yet. Tim -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud layer performance
I haven't really been following this thread closely... are the tracers basically occludes? Are they completely opaque? One possible optimization for the cloud rendering would be to use polygons that closely follow the outline of the sprite instead of quads; this saves on fill costs. Also, I'm pretty sure you don't want two-sided lighting for the tracers. Tim On Wed, Oct 24, 2012 at 8:53 AM, Renk Thorsten thorsten.i.r...@jyu.fi wrote: I've managed to get a test implementation for the idea of filling the depth buffer early by clouds by inserting tracers into some of the cloud calls. The tracers are in essence just opaque white sheets marked with a top shade factor of 0.0 (black - no real cloud can ever have that low a value). There follow then two passes for cloud rendering - the first one does just the tracers and basically passes by all real clouds, the second pass does not consider tracers. During the first pass, depth buffer is written. Since there's one tracer per 10-50 sprites and the operations done on the tracer are bare minimum, the additional workload caused by tracer rendering is small. This has some quirks (the tracers become visible while the layer is drawn, although they are normally hidden by the real clouds, tracers at the edge of the range flicker,...), but it works... halfway. The depth buffer filled by the tracers does have a notable effect on other clouds, but not on the terrain. In numbers - in my benchmark situation I am halfway between a 2000 ft high Nimbus layer and the terrain. I get 20 fps looking straight at the horizon and 23 fps looking 30 deg up through the layer. With tracers I get 24 fps looking straight and 38 fps looking 30 degrees up, i.e. I am doing way faster to render the layer only. However, going above the cloud layer looking down, my framerate never changes. Even if I render only the tracers and zoom in so that only a while sheet is in my field of view (and no terrain pixels at all would have to be done) my framerate is still the same as without the tracer. In other words, the tracers in the depth buffer don't seem to work for the terrain, although they do work for other clouds. I've tested that I am not vertex-shader dominated by discarding half the pixels of the terrain in my field of view - that gave a noticeable framerate boost, so there's something else. I attach the effect xml for the additional first pass below. I'm not completely sure about all the aspects, but... it does the job on clouds, so it can't be that wrong. This should be done in render bin -1, i.e. before terrain. Very similar code for trees does have an impact for terrain rendering, i.e. an early tree pass does fill the depth buffer with effect on the terrain. What am I not seeing? pass lightingtrue/lighting material ambient type=vec4d0.5 0.5 0.5 1.0/ambient diffuse type=vec4d0.5 0.5 0.5 1.0/diffuse color-modeoff/color-mode /material depth functionlequal/function write-masktrue/write-mask /depth render-bin bin-number-1/bin-number bin-nameRenderBin/bin-name /render-bin texture-unit unit0/unit type2d/type imageusetexture[0]/image/use/image wrap-sclamp/wrap-s wrap-tclamp/wrap-t /texture-unit program vertex-shaderShaders/tracer.vert/vertex-shader fragment-shaderShaders/tracer.frag/fragment-shader attribute nameusrAttr1/name index10/index /attribute attribute nameusrAttr2/name index11/index /attribute /program uniform namebaseTexture/name typesampler-2d/type value type=int0/value /uniform uniform namerange/name typefloat/type valueuserange/use/value /uniform vertex-program-two-sidetrue/vertex-program-two-side /pass Some other idea: If I extend the Nimbus layer all the way to 75 km visibility distance, I eventually become vertex-shader dominated in which case tracers are no longer a good strategy. It occurred to me that there's a fairly simple scheme we could try for this situation: We assign a random number [0..1] to each of the sprites such that all four vertices of the quad get the same number and pass that as attribute. Inside the shader, we dynamically compute a threshold based on distance (or perhaps better view angle) and check the random number against the threshold, so that say for 50 km distance we render a quad only if its random number is above 0.8, for 70 km only if its number is above 0.95. This would allow to dynamically dilute the clouds as we go further out, the checks inside the shader are computationally light and the visual effect should not be pronounced as we see the clouds under a very shallow angle at large
Re: [Flightgear-devel] Cloud layer performance
On Wed, Oct 24, 2012 at 10:40 AM, Renk Thorsten thorsten.i.r...@jyu.fi wrote:
I haven't really been following this thread closely... are the
tracers basically occludes? Are they completely opaque?
Yes, they're completely opaque. That's tracer.frag - if it gets a white
gl_Color from the vertex shader, it's a real cloud and the fragment is
dropped, if it gets any other color the pixel is that of a tracer it produces
an opaque white pixel:
void main(void)
{
if (gl_Color == vec4(1.0, 1.0, 1.0, 1.0)) // this is a real cloud
{discard;}
gl_FragColor = vec4 (1.0, 1.0, 1.0, 1.0);
}
'occluders' would perhaps be a more intuitive name then...
Yes, I meant occluders; perhaps I was on occludes :)
One possible optimization for the cloud rendering would be to use
polygons that closely follow the outline of the sprite instead of
quads; this saves on fill costs.
The tracer/occluder is supposed to deal with the whole cloud, not any
individual sprite (individual sprites may be just a bit transparent even in
the center, but a collection of 20 of them is no longer, and in any case
doing it on a per-sprite basis means 20 times the load for the vertex
shader). We don't know the shape of the cloud before we create them, and to
generate a polygon representing in detail the opaque part of the final cloud
which is a collection of sprites with varying transparency and looks
different from various positions is something which sounds highly non-trivial
to me. The tracer is just the simplest guess occluding part of the opaque
core of the cloud. It doesn't need to be hugely efficient on an individual
cloud, because there'll be hundreds of them in a row, so even if we get only
20 % of any individual cloud, the end result is that we get opaque everywhere
after 10 clouds rather than doing a row of 200 everywhere.
I was thinking more of the sprite rendering, so my comment was a bit
off-topic here. How are you generating the tracer? I gather that it
doesn't use any textures.
I realize that I'm confused about whether you are working on Stuart's
clouds in C++ or clouds in Nasal. Your shader seems like an expensive
way to toggle between tracers and real sprites; it would be much
better to not render the sprite geometry at all in your tracer pass.
Also, I'm pretty sure you don't want two-sided lighting for the tracers.
Okay - I'll switch this off then. But that can't explain the depth buffer
issue, can it?
Probably not.
You should use a color-mask type=vec4d0 0 0 0/color-mask
declaration to turn off color writes when rendering the tracers, since
you don't want them to actually appear in the output. That will save
you some fill costs.
As for not seeing much improvement when the terrain is occluded, I can
think of several possibilities. You said that I've tested that I am
not vertex-shader dominated by discarding half the pixels of the
terrain in my field of view; how did you do that?
This optimization depends on being able to do an early Z test to not
rasterize big regions of the terrain triangles and avoid running the
terrain shaders on those pixels that will fail the Z test, but this
can only be done if the shader can't affect the Z output value.
Writing the fragment depth would do that (urban shader), but the
classic offenders are discard and alpha testing. It's probably worth
checking that the terrain shaders aren't doing those things. A quick
look at terrain-default.eff shows that alpha-test is set to
transparent which, IIRC, means that it is set based on whether or
not the texture is transparent; it should probably just be off.
Tim
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud layer performance
On Wed, Oct 24, 2012 at 1:27 PM, Renk Thorsten thorsten.i.r...@jyu.fi wrote:
I realize that I'm confused about whether you are working on Stuart's
clouds in C++ or clouds in Nasal.
How are you generating the tracer? I gather that it
doesn't use any textures.
If a flag is set in the cloud definition, after a cloud (consisting of a
number of sprites) has been generated, a tracer is inserted at the same
position in the center of the cloud. Currently only works if you insert
clouds from Nasal. Formally a tracer is a cloud with just a single sprite,
but a cloud with a top shade factor set to zero (i.e. a pitch-black top) -
which is why we know in the shader it can't be a real cloud.
Your shader seems like an expensive
way to toggle between tracers and real sprites; it would be much
better to not render the sprite geometry at all in your tracer pass.
I basically don't - if a vertex not belonging to a tracer arrives in
tracer.vert, all the vertex shader does is to move it out of the view
frustrum (come to think of it, the if-statement in the fragment shader
shouldn't even be necessary - sorry, this is just mess in progress). Also the
effect currently declares a texture which I'm not using because at some point
I wanted to test round tracers.
If I understand correctly, you have only one model of the cloud, which
has a bunch of sprites and a few tracer polygons. I don't know if this
is practical in the current system, but I'm saying that it would be
better to draw only the tracers in the tracer pass and the sprites in
the real pass as you do know which is which in advance. I do
appreciate the clipping trick in the vertex shader :)
As for not seeing much improvement when the terrain is occluded, I can
think of several possibilities. You said that I've tested that I am
not vertex-shader dominated by discarding half the pixels of the
terrain in my field of view; how did you do that?
By putting
if (gl_FragCoord.y 300) {discard;}
early into the terrain fragment shader.
OK
but this
can only be done if the shader can't affect the Z output value.
Writing the fragment depth would do that (urban shader), but the
classic offenders are discard and alpha testing.
Thanks for the pointers - I'll have a look. How come it works for clouds
then? The normal cloud passes all use alpha testing...
They don't write the Z buffer at all, do they?
Tim
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader optimization
Thanks for writing this up. I have a couple of comments, nitpicks really. On Mon, Oct 15, 2012 at 9:43 AM, Renk Thorsten thorsten.i.r...@jyu.fi wrote: I thought it might be a good idea to write up a few things I've tried recently and not seen in widespread use - so that either others know about them as well or I can find out what the pitfalls are. Basically this is about reducing the number of varyings, which is desirable for at least two reasons. First, their total amout is quite limited (I think 32?). Second, they cause work per vertex and per pixel, so their load scales always with the current bottleneck. Their actual workload is just a linear interpolation across a triangle though, so the optimization I'm talking about here is maybe all together 10-20% gains, not something dramatic, and it's not unconditionally superior to save a varying if the additional workload in the fragment shader is substantial. Also, the techniques are somewhat 'dirty' in the sense that they make it a bit harder to understand what is happening inside the shader. * making use of gl_FrontColor and gl_BackColor - gl_Color As far as I know, these are built-in varyings which are already there regardless if we use them or not. So if we don't use them at all because all color I don't think that any varyings -- except for the fragment coordinates -- are mandatory, except perhaps on very old hardware. Generally the total shader program is optimized to remove any unnecessary computations. However... computations are in the fragment shader, they can carry four components of geometry, if we use a color but know the alpha, there is one varying which can be saved by using gl_Color.a to encode it. I agree that using a coordinate in a varying that you already need is a good trick, better than assigning a new varying. One can assume that a vec4 varying is no more expensive than a vec3. By the way, we only encode the front/back facing info in alpha in order to get around shader language bugs. The prime example is terrain rendering where we know that the alpha channel is always 1.0 since the terrain mesh is never transparent. In default.vert/frag gl_Color.a is used to transport the information if a surface is front or backfacing, but in terrain rendering we know we're always above the mesh, so all surfaces we see are front-facing, and we do backface culling in any case. ... * light in classic rendering Leaving Rembrandt aside, the direction of the light source (the sun) is not a varying but actually a uniform. In case we need this in world space in the fragment shader, doing a lightdir = normalize(vec3(gl_ModelViewMatrixInverse * gl_LightSource[0].position)); in the vertex shader and passing this as varying vec3 is quite an overkill. One reason to pass this as a varying is that on old hardware, GeForce 7 and earlier, it is very expensive to change a uniform that is used by a fragment shader. It forces the shader to be recompiled. So, this is actually a well-known optimization for old machines. Also, I want to point out that, in your example, lightdir is in the local coordinate system of the terrain, if in fact you are shading terrain. I would call world space the earth-centric coordinate system in which the camera orientation is defined. Due to the complexity of the coordinate system of the terrain, it's not clear to me how to get the world space light direction really into a uniform, but we do have it's z-component (the sun angle above the horizon) as a property and can use this as uniform. Since light direction is a unit vector, it means that only the polar angle of the light needs to be passed as a varying then, saving two components. We could include per-tile uniforms as state attributes in the scene graph if we decide that we really want them.. In particular for water reflections computed in world space, passing normal, view direction and light direction in world coordinates from the vertex shader (9 varying) is really not efficient - the normal of water surfaces in world space is (0,0,1) and not varying at all (we do have formally water on steep surfaces in the terrain, but we never render this correct in any case since in reality rivers don't run up and down mountainslopes and foam when they run really fast on slopes, and to worry about getting light reflection wrong when the whole setup is wrong is a bit academic), the light direction is really just the polar angle, since we later dot everyting with the normal we really only need the z-component of the half-vector, and that means just two components of the view direction - so it can in principle be done with 3 varyings rather than 9. I'm not sure it's useful to think of each component of a varying vector as a varying i.e., three vec3 varying values use up three varying slots, and so do 3 float varying values. On the other hand, if you can back all the lighting info into one varying,
Re: [Flightgear-devel] Shader optimization
On Tue, Oct 16, 2012 at 12:05 PM, Renk Thorsten thorsten.i.r...@jyu.fi wrote: One can assume that a vec4 varying is no more expensive than a vec3. (...) I'm not sure it's useful to think of each component of a varying vector as a varying i.e., three vec3 varying values use up three varying slots, and so do 3 float varying values I dunno... Just counting the number of operations, mathematically the best case scenario for interpolating a general vector across a triangle is in Cartesian coordinates where each coordinate interpolates as an independent number, so the cost of a vec4 would be the same as the cost for 4 floats. In any other case, like curved coordinates or Minkowski space, a Jacobian comes to bite and the vector is more expensive than just 4 scalar numbers. Yes, I acknowledge that interpolating a vec4 requires more operations than interpolating a float :) Now, what I don't know if there's some fancy hardware trick which makes a Cartesian vec4 as cheap as a float. In this case, we could use this by combining every four varying float into one varying vec4 and get the same job done for 25% of the cost. But... That's the crux of it. I thought the answer was obvious, but it very much depends on the hardware. For a very long time graphics hardware has had to rasterize, i.e., interpolate, multiple values across screen space: depth, color, alpha, texture coordinates I just assumed that it would be no more expensive to interpolate vector values. However, this very good web page, http://fgiesen.wordpress.com/2011/07/10/a-trip-through-the-graphics-pipeline-2011-part-8/, contains this quote: Update: Marco Salvi points out (in the comments below) that while there used to be dedicated interpolators, by now the trend is towards just having them return the barycentric coordinates to plug into the plane equations. The actual evaluation (two multiply-adds per attribute) can be done in the shader unit. So the cost of interpolating values is indeed incurred as operations in the (prolog of the) fragment shader. Even the oldest hardware that supports OpenGL programmable shaders implements vector operations, and a vector multiply-add has, as far as I know, the same cost as a scalar operation. On the other hand, the shader compiler might be able to combine multiple scalar interpolations into vector ops. You can examine the assembly language for shaders if you want to see what's actually going on. I do recommend that web page and the others in the series; they are quite interesting. ... the thing I did try is that in adapting the urban shader to atmospheric scattering I ran out of varying slots, I needed two more varying float. I solved this by deleting one varying vec3 (the binormal) and computing it as the cross product - and that gave me the two slots I needed (and presumably one left, but I didn't try that). So this would suggest that indeed each vector component counts the same as a varying float. They do at the OpenGL API level, which doesn't necessarily correspond to the hardware implementation. One reason to pass this as a varying is that on old hardware, GeForce 7 and earlier, it is very expensive to change a uniform that is used by a fragment shader. It forces the shader to be recompiled. So, this is actually a well-known optimization for old machines. Okay, I didn't know that... But pretty much all weather and environment-dependent stuff (ground haze functions, the wave amplitude for the water shader, overcast haze for the skydome,...) makes use of slowly but continuously changing uniforms (I think gl_LightSource is technically also a uniform), so it doesn't really make sense to have this old machine friendly code in one place in the shader but not in other places in the same shader. True. Also, I want to point out that, in your example, lightdir is in the local coordinate system of the terrain, if in fact you are shading terrain. I would call world space the earth-centric coordinate system in which the camera orientation is defined. gl_Vertex is in some coordinate system which I've usually encountered as 'world space' in shader texts as opposed to gl_Position which is supposed to contain the vertex coordinates in 'eye space'. I realize that gl_Vertex is *not* in the global (xyz) coordinates of Flightgear Earth, although I don't know how the two relate. Somehow once in the shader world, z is always up... Just a matter of semantics? I think more usual usage for the local coordinate system is model coordinates. The model matrix transforms those coordinates into world coordinates; the view matrix transforms world coordinates into eye coordinates. In OpenGL, even in pre-shader days, we tend not to talk about world space much because there is (was) only one matrix stack, which contains the concatenation of the model and view matrices. z is always up is a matter of convenience. Z is up only at the center of a tile. The tile
Re: [Flightgear-devel] Shader optimization
On Tue, Oct 16, 2012 at 2:54 PM, James Turner zakal...@mac.com wrote: On 16 Oct 2012, at 13:38, Tim Moore wrote: The tile data on disk is actually stored in a coordinate system that is aligned with the earth-centric system, so Z points to the north pole. We rotate the coordinates back to a local coordinate system because that provides a much more useful bounding box for intersection testing and culling... and also lets you program snow lines in shaders :) Uh, are you sure about that? My understanding is that the BTG coords on the disk are in 'tile local' coords, i.e 'Z is up' James https://gitorious.org/fg/simgear/blobs/next/simgear/scene/tgdb/obj.cxx#line925 I don't have access to a local copy of the tree at the mo', but I remember that this was introduced by Mathias when he added BVH. Tim -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata trouble
On Fri, Sep 21, 2012 at 11:51 PM, ThorstenB bre...@gmail.com wrote: On 21 Sep 2012, at 13:03, Anders Gidenstam wrote: The master branch of fgdata has become messed up. A number of commits ... It has happened again, fgdata history is messed up. It looks as if my last commits (6d46fe7, f722671) were applied to fgdata multiple times now (duplicates are 818b92f and e7452f7). With gitk itself, I can't even see how where these originated (looks as if I had pushed them multiple times). Only the gitorious.org history shows that these were indeed not pushed by me: https://www.gitorious.org/fg/fgdata/commit/818b92fa07a49c333f80ac21f483b33fd5e2b7c7 https://www.gitorious.org/fg/fgdata/commit/e7452f70358e67824e499294fd32d6d6f8d3dd93 Can we please make it a requirement that _local_ merge operations must not become visible on our public repository, so _everyone_ has to rebase before pushing anything? The only merge/branch operations that should be visible in our public repo should be those that affect public branches (release branch creation/merges etc). I haven't looked at this latest problem in detail, but you can do as much damage rebasing as merging. I suspect the real problem here is rampant cherry-picking. I happen to think merging, at least when pushing local changes to the public tree, is a lot better than rebasing, because then a given set of changes only appears in a single commit in the repository. There's really no reason why other people should see that user XYZ has merged his local branch 1-15 times with gitorious, before pushing back. It only results in the git history becoming unreadable. And apparently it results in more issues. Yes, pushing a branch that has numerous merges from master/next is unpleasant. There are many pages on the Web describing git workflows that avoid rebasing and keep a clean history. If you compare simgear's or flightgear's history with fgdata's history, you'll see how nice and readable a git history can be - since obviously (almost) everyone pushing to sg/fg knows hows how to rebase. Except that I never rebase before pushing to sg/fg :) I should qualify that: I do interactively rebase before pushing, often rearranging commits and divying them up to make more sense. But I *never* rebase onto a different head than the one on which I started the branch. Resolving merge operations locally, to reorder and cleanup the history is really simple - and only requires a few seconds. If you have uncommited changes in your local directory, you can temporarily stash them - so that rebase won't complain. For fgdata: git stash git rebase origin/master git stash pop (And for simgear/flightgear: git stash git rebase origin/next git stash pop ) It is also a good idea to check the git history (gitk) before pushing to gitorious: you can read and double check your own changes a final time - and also check the history for local merge or funny duplication issues. If you're having local Git trouble (like duplications), *please* ask before pushing to gitorious. Can't argue with that. cheers, Thorsten -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] X-Plane sued for patent infringement
http://games.slashdot.org/story/12/09/14/2048240/patent-troll-sues-x-plane It turns out that the patent has nothing to do with flight simulation but with remote license checking, but still. The Slashdot article has the line X-plane is a cross-platform flight simulator app, notably the only serious one that supports Mac OSX and Linux. In the comments the serious part refers to X-Plane being FAA certified. Now, I know that software isn't FAA certified -- complete systems --are and that FlightGear has been used in commercial simulators too, but someone (Curt?) with the real details might want to chime in with a correction. Tim -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] license
On Mon, Sep 3, 2012 at 4:27 PM, Michael scrat_h...@yahoo.com wrote: Hi saw this: http://wiki.flightgear.org/File:Joystick_Configuration_Dialog.jpg which is Creative Commons Attribution-Share Alike 3.0 license. Will that go into default 3.0? Hence I would use the same license to keep off scammers. Sorry, seems I've missed if default releases only contain GPL license or not. By scammers you mean developers? Tim -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory issues
On Mon, Aug 13, 2012 at 7:40 PM, James Turner zakal...@mac.com wrote: On 11 Aug 2012, at 18:21, Tim Moore wrote: This is what osg::PagedLOD does, though we often forget that the paging of the higher LODs is triggered in the cull phase. I can't recall what scene modifications are / are not permitted inside a cull-callbacl, however. You would want to let the OSG loader mechanism and the database pager do their thing. Geometry doesn't have to be loaded from files... Could you outline the pieces of machinery needed for this to work? Given that we already create LOD nodes, I assume it's switching those to be PagedLOD, and setting the filename / extension / reader-writerOptions to some magic, and creating a loader which matches that, which creates the buildings geometry. That is how PagedLODs work, without too much magic. Some data will need to be passed to the loader. A low-tech way to do that is to encode parameters in the file name passed to the loader, but in this case you will probably need access to the scenery to place buildings. You can subclass the DatabaseOptions object stored in the PagedLOD to store whatever you need. You would choose a file extension that doesn't correspond to a real file type, and then register a loader with that extension. If you could point to an example of such a loader, I'm pretty sure Stuart or I could adapt his code. James We register loading callbacks using both osgDB mechanisms and some SimGear goo to control optimizations, construction bvh trees, etc. grep for ModelRegistryCallbackProxy. For the body of the loader, there is nothing special; just don't read any files. Tim -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release 2.8.0 - closing release/2.8.0 branch
On Tue, Aug 14, 2012 at 3:40 PM, Curtis Olson curtol...@gmail.com wrote: On Tue, Aug 14, 2012 at 3:30 AM, Torsten Dreyer tors...@t3r.de wrote: Hi all, I have just suggested off-list to close the release/2.8.0 branches (FG+SG+FGDATA) on Thursday (16th) in the morning (UTC) to give those packing the binaries and tarballs enough time for the task. Please shout if there are any objections. Do we have a volunteer (Thorsten?) to tag the branches as 2.8.0 to mark the official close of changes for 2.8.0(.0)? You might want to wait until you cut the release before laying down the tag... Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory issues
On Fri, Aug 10, 2012 at 12:50 PM, James Turner zakal...@mac.com wrote: On 9 Aug 2012, at 21:49, Stuart Buchanan wrote: Do we have any ideas addressing these issues? Random thought, hopefully someone with more OSG knowledge can confirm or deny: Can we create the geometry (and unload it) in the cull-callback? I.e set an appropriate bounding volume for the LOD node, and only build the geometry when the node actually passes culling. And obviously after some number of frames of being culled, unload the geometry again. This is what osg::PagedLOD does, though we often forget that the paging of the higher LODs is triggered in the cull phase. I can't recall what scene modifications are / are not permitted inside a cull-callbacl, however. You would want to let the OSG loader mechanism and the database pager do their thing. Geometry doesn't have to be loaded from files... Tim -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git help request
On Thu, Aug 9, 2012 at 2:45 PM, Curtis Olson curtol...@gmail.com wrote: It looks like every time you rebase you have to reapply the same set of patches over top the target branch. So even if I figure out a way through it once, I'll have to repeat the same conconction of craziness each time I rebase. I think I'm going to create a new branch, untar my changes on top, lose all my history and forget about it. I didn't budget 2 full days to fiddle with this and I'm frustrated and annoyed now and unsure what/if/anything I've lost or broken -- blahhh ... little things you might not notice for 6 months because you don't work with every file every day ... Curt. If you are going to keep a branch for a long time that you are not merging back into e.g., master, there are a couple of possibilities. One is to merge (pull) master into your branch. Another is to check out git-rerere (I kid you not), which records merge conflict resolutions and reapplies them automatically when needed. With that you can either rebase repeatedly or never rebase and periodically do test merges with master. Tim On Thu, Aug 9, 2012 at 1:56 AM, Renk Thorsten thorsten.i.r...@jyu.fi wrote: The typical fix is to edit the conflicting files and git add them the run git rebase --continue. But these files don't exist so I can't edit them, git add fails, git rm also fails since they don't exist. If the files no longer exist, I think one solution is to tell the system to skip the patch: git rebase --skip did the trick for me on a similar occasion. The rebase operation then goes on with the next patch. If you actually want the files, git checkout branch where files still exist -- non-existing file should fetch them from the branch where they still exist. I also frequently use git status to track what exactly the problem is. Although I am probably not the best source for GIT troubleshooting, I feel your pain. I've had similar trouble a few times. Cheers, * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git help request
It sounds like your local tree has not been completely committed. See what git status says. Check out the man page for git-mv. I can't say more right at the moment, but I'll see if I can add more details later. Tim On Wed, Aug 8, 2012 at 5:45 PM, Curtis Olson curtol...@gmail.com wrote: A quick update here. Rob pointed out the git rebase --abort command which got me back to a sensible working state. I was able to reevaluate my original problem which turned out to be a simple merge conflict in my branch vs. changes in master and I was able to fix that and successfully merge -- so I'm in a reasonable working state again. But I would mind rebasing my local changes, but I still get an error. I think what happened originally is I changed the directory name of my aircraft from Malolo1 to Resolution, then thought for a second and changed it again to ATI-Resolution -- and then did that all as a single commit. Now the rebase throws fits on that patch. It complains about whitespace errors, then falls back to a 3-way merge, then reports conflicts with all the files in the 2 old directories, for example: Aircraft/Malolo1/Engines/18x8.xml: needs merge Aircraft/Resolution/Engines/18x8.xml: needs merge The typical fix is to edit the conflicting files and git add them the run git rebase --continue. But these files don't exist so I can't edit them, git add fails, git rm also fails since they don't exist. I suppose I could abandon this branch, figure out the diffs against master manually, create a new branch, and copy those diffs into my new branch -- but then I would lose all my history and that just doesn't seem very git-ish -- I hate to go against the spirit of git which is more along the lines of performing brain surgery on myself when I don't quite feel happy -- what could go wrong? Or what do I do when something goes wrong? :-) Curt. On Wed, Aug 8, 2012 at 9:27 AM, Curtis Olson curtol...@gmail.com wrote: I've run into a problem with git and I seem to hit a dead end no matter which way I turn. I'm hoping this is something easy to solve, but the details might be complicated to communicate? I'll try to start simple -- I'm working with the fgdata repository. I created my own branch and have been tracking some experimental stuff there. This has been working well and when I do a git pull I will checkout my local branch and merge with the master to make sure everything is tracking well and stays compatible. With my most recent attempt to merge my local branch with master I got an error (unfortunately now I do not remember what the exact error was, and I had to do a reboot for other reasons in the mean time.) My first thought after getting an error trying to merge was maybe I should rebase since I've just been merging all along. So I ran git rebase and that ran did a lot of work, but then generated some error messages about whitespace, and then displayed some message that it had to fall back to a 3-way diff. That ran and ran for quite some time and (I think?) errored out. Again, I don't have the message any more. :-( Now after my reboot, I'm trying to figure out what's going on. If I run git branch I get: $ git branch * (no branch) If I try to checkout any branch I get a list of files that need merge and then the message: error: you need to resolve your current index first. If I git add any of these files, what branch am I adding them to and merging them into? (no branch)? It seems like all the git help I can find for these error messages presumes I can checkout a branch -- but I can't. Any suggestions? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list
Re: [Flightgear-devel] Scenery
On Mon, Aug 6, 2012 at 10:00 AM, Martin Spott martin.sp...@mgras.net wrote: Moin Yves, ys wrote: [...], it's just in responsability of the core developers to show how 2nd-row developers can help to improve apt.dat without being blocked by a deprecated. I tend to disagree. You're probably asking for a recipe on how to square a circle ;-) According to my experience there's little chance to establish a procedure having the potential to stand real practise without a couple of wise guys making terrible noise, claiming they're blocked. Therefore I think trying to guide 2nd-row developers is a waste of time in most cases. How does scenery production, including airport modeling, scale without 2nd (and 3rd and 4th)-row developers? Tim -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
On Wed, Jul 25, 2012 at 1:43 PM, Martin Spott martin.sp...@mgras.net wrote: James Turner wrote: Or to put it another way - the actual hard part is running the widgets in the main OpenGL window - which *is* a requirement for full-screen apps and multi-monitor setups. (Some people have claimed otherwise, but I believe we need the option of 'in-window' UI for many cases). I object - at last I can't envision a case where running the UI inside a separate window in front of a (full-screen) viewer is inferior to an in-window UI. All supported window systems provide the required information on screen/window-geometry or -placement to position a separate UI-window wherever you like. One avoids OpenGL rendering to more than one window if possible because graphics context switches are expensive. I have no idea if this would affect normal FG usage. Portions of the OpenGL window buffer that are obscured by other windows are not guaranteed to be rendered correctly or at all, and in most implementations are not. This is less of an issue in newer OpenGL versions that support frame buffer objects and can do multi-pass rendering in an off screen buffer. For the die-hards just think of a menu bar positioned in front of the upper left corner of the viewer-screen or -window having just very thin borders. From my perspective that's a pretty appealing approach because running the UI outside the viewer and probably/hopefully outside the main program could lead to a consistent management-/ control-interface in FlightGear. A system menu bar is a slightly different. By definition it is not obscuring the main rendering window, and it is not updated unless the user interacts with it. It might be possible to simulate the same thing in FG with a menu bar in a separate window, but it would be very complicated to manage updating those windows differently from the main simulation window. I agree that separate user interface windows would be nice in several interesting use cases, but I don't think the default single-screen case is one of them. Tim Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Functions to textures?
On Wed, Jul 25, 2012 at 12:16 AM, Chris Forbes chr...@ijw.co.nz wrote: Somewhat inversely, I'm also wondering if a simple texture1D() lookup might not be faster than evaluating the light function e / pow((1.0 + a * exp(-b * (x-c)) ),(1.0/d)) three times to get an (rgb)-triplet. That depends a lot on the GPU, and how coherent the texture coordinates are across a triangle. You also need enough ALU work elsewhere in the shader to mask the latency of the texture lookup. For the existing noise texture generation, take a look at make3DNoiseImage in scene/material/TextureBuilder.cxx in the simgear tree. This particular texture is filled CPU-side, but if you're more comfortable expressing things in a shader, you/someone could rig up some FBO wiring to quickly render a shader-defined function into a texture. Actually, the code that creates the texture is in scene/util/StateAttributeFactory.cxx, but you would have to do something similar to the noise texture code in TextureBuilder to access your texture from a texture. It would be nice if the Effects framework had a way to load arbitrary textures and make them available to effects. These days you aren't limited to 8 bit texture components. There is a rich set of data formats for textures: 32 bit floats, 16 bit floats, exotic combinations of different length floats per RGB component... I don't know if there is a better way to create your texture offline than write C++ code in simgear. OSG will read a TIFF file with 32bits per component as a floating point texture... assuming you can create such a thing. Tim -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rendering passes question
On Sat, Jul 21, 2012 at 10:42 AM, Mathias Fröhlich mathias.froehl...@gmx.net wrote: 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 scene graph a bit... It *is* on the cpu. At least for most of the use cases. Every now and then there is an other limit that comes up for specific stuff. But we are *mostly* draw limited. The draws are way too small to be efficient. That is a big problem, but we also have CPU bottlenecks upstream too. James and I were talking about this some time ago. I would go even further for the LOD's. In the meantime I have in fgviewer a PagedLOD whole world database tree running. This is similar to osg's marble dataset but carefully designed around our tile structure. Using this I think we can really replace a lot of our fine structured scenery tiles with something more croase that is used for tiles more far away. I would really like to see that code! Drawback with our current codebase: Our integration of the particle systems need to be rethought as this contains geometry with culling disabled which makes a pagedlod just never expire. Switching the particle systems off works pretty good so far. Yikes, I didn't know about that problem. Tim -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rendering passes question
On Thu, Jul 19, 2012 at 6:09 PM, James Turner zakal...@mac.com wrote: On 19 Jul 2012, at 14:32, Tim Moore wrote: Do we really not run the terrain fragment shader when the terrain is seen through the cockpit floor (my system seems to slow down even though no terrain is seen in the event and the framerate responds to my shader quality settings)? That would be nice, but the near/far camera defeats that optimization :( Which is very unfortunate, since in the common case it would allow a huge amount of tile/terrain pixels to be dumped. Could we use a buffer copying to trick to initialise a stencil plane on the far camera based on the near-camera Z-buffer? I've no idea what the penalty of a z-buffer read and stencil buffer write on the two camera would look like, but my impression is 'out of the window' pixels are wy more expensive in terms of shaders and fog / distance effects than in-cockpit pixels. We could use the stencil buffer without copying anything: render the near scene first, setting stencil bits, then enable the stencil test for the far scene. I believe that the stencil test has been extremely fast for years. ... 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 scene graph a bit... 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 LOD-scale function in OSG, this will mean we can automatically drop random tress / building and STG objects to keep frame-rate up. (as an optional mode of course!) Good plan. The trick is to minimize the number of LOD nodes introduced into the scene graph while avoiding popping effects. Tim -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rendering passes question
On Fri, Jul 20, 2012 at 10:23 AM, Frederic Bouvier fredfgf...@free.fr wrote: Hi Tim James, De: James Turner On 20 Jul 2012, at 07:22, Tim Moore wrote: We could use the stencil buffer without copying anything: render the near scene first, setting stencil bits, then enable the stencil test for the far scene. I believe that the stencil test has been extremely fast for years. Oooh, yes - I was forgetting the cameras are rendering to the same buffers. That seems like some low-hanging fruit indeed! Rembrandt can't use a scheme where the depth buffer is cleared in between because it rely on it to compute positions. But it exhibits depth buffer precision problems too, especially when computing lights (if the light volume is too tight, it can miss to intersect the terrain). So I was thinking of playing with depth ranges : the far camera renders with a range [0.5..1] and then the near camera renders with the range [0..0.5]. I think this could be unified with the classical renderer. What do you think about that ? I would probably give more of the range to the far camera e.g., [0.1..1.0]. This would probably work best with a floating point depth buffer, but if you do that, you might be able to go back to using only one pass. http://outerra.blogspot.fr/2012/06/couple-of-opengl-notes.html has some interesting insights into the various approaches. Tim Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rendering passes question
On Fri, Jul 20, 2012 at 9:59 AM, James Turner zakal...@mac.com wrote: On 20 Jul 2012, at 07:22, Tim Moore wrote: We could use the stencil buffer without copying anything: render the near scene first, setting stencil bits, then enable the stencil test for the far scene. I believe that the stencil test has been extremely fast for years. Oooh, yes - I was forgetting the cameras are rendering to the same buffers. That seems like some low-hanging fruit indeed! The problem with this approach just became all too clear as I was checking out the PAF dc-3 (wow wow wow!): transparency. It can't handle transparent objects in the near scene -- e.g., the windshield -- without using either alpha bits in the frame buffer or doing a third pass for near transparent objects. Historically we have avoided frame buffer alpha as being exotic and /or slow; I don't know if we want to move in that direction. Tim James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rendering passes question
On Thu, Jul 19, 2012 at 1:16 PM, Renk Thorsten thorsten.i.r...@jyu.fi wrote: This is an optimization to avoid running really expensive shaders on geometry that will be hidden from view. The GPU has an early Z capability and won't run a fragment shader if it knows the result will be discarded. But that can't be all that is going on. In this case I'd expect that if I leave the pass out, the system would slow down. However, what actually happens when I remove the first pass is that the system runs just a bit faster, but I get z-ordering problems for distant objects which sometimes appear in front. I realize that I'm not sure what you mean by the first pass. This information is for the classic renderer: In order to combat depth buffer precision problems, we draw the whole scene in two passes, with a near camera and a far camera. See Viewer/CameraGroup.cxx. The far view is drawn first, then the depth buffer is cleared and the near scene is drawn on top. Within each of those ranges we get good depth buffer precision. Hmm, on further reflection, it's clear that you don't mean that. OK. Within effects, we do a first pass that writes the depth buffer. If you remove that pass and don't change anything else, you will see artifacts because the later passes don't write to the depth buffer. Within each camera pass (far camera, near camera), all the passes of a technique are run. Do we actually draw all the scenery in one go, or on a per-tile basis? All in one go, within the near/far scenes. All the geometry associated with a pass is collected and rendered at once. Do we really not run the terrain fragment shader when the terrain is seen through the cockpit floor (my system seems to slow down even though no terrain is seen in the event and the framerate responds to my shader quality settings)? That would be nice, but the near/far camera defeats that optimization :( Much to my annoyance, coordinate systems for instance are discontinuous across tile boundaries, which leads for instance to artefacts when using 3d noise to create variations in the fog density, but I don't know if coordinate discontinuities have anything to do with what we draw. That's a different issue. Earth centric coordinates can't be stored in single precision floating point at the required precision, so each tile has a local coordinate system. A world wide noise basis would be a good project. Somehow, this connects to the render bins, right? Yes, the geometry for a pass is sorted into a specific render bin. The cull phase does this. EffectCullVisitor walks the scene, putting geometry into multiple render bins according to the pass description in the effect files. Then all the render bins are rendered by OSG. Thanks, for any help, I'd really like to understand this better (I am reading up the theory as we talk...), so I promise to (mostly) ask Flightgear specific things. 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 scene graph a bit... Tim * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rendering passes question
On Wed, Jul 18, 2012 at 8:27 AM, Renk Thorsten thorsten.i.r...@jyu.fi wrote: May I ask yet another dumb question? Yes, although this isn't a dumb question. In the first rendering pass of default terrain rendering, we use default.vert and terrain-nocolor.frag as shaders. I have so far mindlessly copied the first pass since I had no real clue as to what it is for. Its purpose seems to be to establish that faraway scenery is not rendered in front of nearby scenery (I think Fred called this 'initializing the z-buffer'). This is an optimization to avoid running really expensive shaders on geometry that will be hidden from view. The GPU has an early Z capability and won't run a fragment shader if it knows the result will be discarded. Of course, to be effective the shaders run when the depth buffer is filled need to be fast :) My question is - why do we use shaders which texture and fog the terrain at this stage? Every texture2D() statement seems to cost me ~12% of my framerate. I've experimentally replaced default.vert and terrain-nocolor.frag by trivial.vert which is just ftransform(); and trivial.frag which is just gl_FragColor = vec4 (1.0, 1.0, 1.0, 1.0);, and apart from my ~12% increase in framerate I haven't seen any bad side effects - the z-ordering of scenery looks sane, fogging, texturing and colors work normal,... So, was there a reason we texture and fog during the first pass and should I see any unexpected side effects, or can I simply use the trivial shaders and get my 12% framerate? The main reason to render textures at this stage is that textures with transparency do change the fragments that are rendered. Calculating the fog color seems wrong, but I don't have the sources in front of me and gitorious is acting up. one texture2D() call - 12% framerate drop seems a bit excessive. What is the time difference in milliseconds? Hardware? Tim Thanks, * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader menu structure
First of all, apologies for tuning out over the last year+. I have been keeping an eye on things from afar, and am quite impressed with all the goings on in the FlightGear world. This post did catch my eye... On Thu, Jul 12, 2012 at 2:54 PM, Renk Thorsten thorsten.i.r...@jyu.fi wrote: Admittedly, I can't really laugh. Fun aside, here's my problem: I think about shader work in terms of operators living in a special corner of differential geometry. So if I were to describe what I did recently straight and short, that would be: 'I found a way to reduce texture tiling by distorting the metric tensor of the texture with true position dependent noise.' Who here would understand this? I'm not in a General Relativity class, and I'm not talking as if I were. So I try to translate things into a non-technical framework, and then it gets longer. Do you really want me to stop doing this? Believe it or not, computer graphics researchers (not me) think about shader work in those terms too. It comes off as a bit pompous to assume that no one here would understand what you are talking about or be able to come up to speed on the math if necessary. I don't know, I find this whole experience once again really, really frustrating. I don't think it's asked too much from people who are interested in having a discussion to spend 5 minutes reading a longer block of text, trying to understand it and ask if anything is unclear. * Thorsten (P.S.: As for the meaning of the above sentence - I have actually managed to come up with a scheme which reduced both tiling in the 30 km range significantly and gives much higher apparent texture resolution when close to the ground (~20-40 cm per pixel instead of ~2-4 m) at very modest framerate expense. See here: http://www.flightgear.org/forums/viewtopic.php?f=47t=16884 These are cool results. It's also a classic technique. SGI had hardware support for it in the Reality Engine series of graphics hardware in the early 90s, and variations of it are used in commercial game engines. Google detail texture. If I could give some gentle advice, perhaps based on out-of-date observations: you could really benefit from a serious study of computer graphics. I highly recommend the book Real Time Rendering by Akenine-Moller et al. If resources (cash) are a problem, that book's website has lots of great material. All the chapters of the GPU Gems books are available for free on NVidia's website. You obviously can handle the math, and I bet that within two weeks you would be unstoppable. Mailing lists, especially this one, aren't a good medium for learning fundamentals. Tim -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] new An-2
Hi Yuri, I chose the An-2 as the aircraft that I would delete first from the fgdata repository and move to its own repo, and I am about to do that. I can check your new work into the new repository. Should I remove the Tutorials directory? Are they now completely broken? Tim On Mon, Aug 8, 2011 at 9:16 AM, Yurik V. Nikiforoff yurik@gmail.com wrote: Hi all! I re-done old An-2 model. It have whole new visual model, modern shaders animations, new 3D cockpit, deep reconstructed FDM. Model intend for replacing old an-2 model cause old an-2 don't work since years. Please, replace old an-2 with new from here: http://yurik.flightgear.ru/an2/an2-2.0.zip It seems, it work Ok with new FG 2.4 but comments are welcome. -- Wbr, Yurik -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] new An-2
I have created the ac-an2 repository, which includes only the An-2 (duh), and deleted the an2 from fgdata. Tim On Fri, Aug 12, 2011 at 11:19 AM, Tim Moore timoor...@gmail.com wrote: Hi Yuri, I chose the An-2 as the aircraft that I would delete first from the fgdata repository and move to its own repo, and I am about to do that. I can check your new work into the new repository. Should I remove the Tutorials directory? Are they now completely broken? Tim On Mon, Aug 8, 2011 at 9:16 AM, Yurik V. Nikiforoff yurik@gmail.com wrote: Hi all! I re-done old An-2 model. It have whole new visual model, modern shaders animations, new 3D cockpit, deep reconstructed FDM. Model intend for replacing old an-2 model cause old an-2 don't work since years. Please, replace old an-2 with new from here: http://yurik.flightgear.ru/an2/an2-2.0.zip It seems, it work Ok with new FG 2.4 but comments are welcome. -- Wbr, Yurik -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
I've started the first phase of trimming down fgdata. I've removed the an2 from fgdata and put it in its own repository called ac-an2 under the Flightgear project. I'm going to proceed with moving other aircraft which haven't been touched in a while into their own repos as well. When we get down to a working set of aircraft that are currently under development, I will turn off commit rights in fgdata for a short period while I extract those aircraft. I will then regenerate fgdata without the history of all the aircraft, which will shrink the fgdata repository a great deal. I've started putting ac- in front of the aircraft repository names in order to aid tools that manage aircraft downloads, etc. Aircraft developers: please don't add new aircraft to fgdata! You can easily set up your own repositories on gitorious and later request that we incorporate a repository into the Flightgear project. Tim On Thu, Aug 4, 2011 at 9:53 PM, Martin Spott martin.sp...@mgras.net wrote: Frederic Bouvier wrote: Funny (!) that the last one in the first list will be unmaintain from now if I read this ml correctly. Let's sit down and have a beer/wine/tea/vos...dka ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [SPAM] Re: Proposal: Move airplanes to an SVN repository
On Fri, Aug 12, 2011 at 1:23 PM, Emilian Huminiuc emili...@gmail.com wrote: On Friday 12 August 2011 14:02:16 Tim Moore wrote: I've started the first phase of trimming down fgdata. I've removed the an2 from fgdata and put it in its own repository called ac-an2 under the Flightgear project. I'm going to proceed with moving other aircraft which haven't been touched in a while into their own repos as well. When we get down to a working set of aircraft that are currently under development, I will turn off commit rights in fgdata for a short period while I extract those aircraft. I will then regenerate fgdata without the history of all the aircraft, which will shrink the fgdata repository a great deal. I've started putting ac- in front of the aircraft repository names in order to aid tools that manage aircraft downloads, etc. Aircraft developers: please don't add new aircraft to fgdata! You can easily set up your own repositories on gitorious and later request that we incorporate a repository into the Flightgear project. Tim Hi, let's say I would like the Lockheed L10 Electra included, how would I go about doing that (or is it too early to think about this ? ) Repo is currently here https://gitorious.org/lockheed-l10-electra At the moment, James Turner or I would create a repo in the Flightgear project that clones yours. I think we would give you commit rights in that new repo. To make this easier, I should add a couple of people from the modeling side of the house as administrators of the Flightgear project on gitorious. However, before I start adding repositories for completely new aircraft, we should think about why new aircraft should be under the Flightgear project. Pros: centeralized location for obtaining aircraft, Flightgear seal of approval Cons: Flightgear project has to manage new repos, aircraft must be under the license that Flightgear chooses (GPL) Other thoughts? Perhaps the wiki would be a better place to promulgate aircraft! Tim -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] new An-2
On Fri, Aug 12, 2011 at 4:31 PM, Alex Romosan romo...@sycorax.lbl.gov wrote: Tim Moore timoor...@gmail.com writes: I have created the ac-an2 repository, which includes only the An-2 (duh), and deleted the an2 from fgdata. so where is the new repository? is there a way of integrating it with the rest of the data so that when i do a 'git pull' in fgdata it automatically does a 'git pull' in the ac-an2 repository as well? thanks. It's under the Flightgear page at gitorious, https://gitorious.org/fg. The git url for the repo is git://gitorious.org/fg/ac-an2.gitgit://gitorious.org/fg/ac-an2.git. You can look at git submodules, which would give you a way to do that. Tim --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- FREE DOWNLOAD - uberSVN with Social Coding for Subversion. Subversion made easy with a complete admin console. Easy to use, easy to manage, easy to install, easy to extend. Get a Free download of the new open ALM Subversion platform now. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Tue, Aug 2, 2011 at 11:39 AM, Francesco Angelo Brisa fbr...@gmail.com wrote: Any news about a possible separation of aircrafts data from the fgdata folder ? I am afraid this topic is sligtly falling into the forget about it folder :-( Cheers Francesco Some of the inertia -- on my part -- comes from the fact that the benefits are not visible until the end: until all the aircraft are removed from fgdata and fgdata is effectively regenerated through various git magic, the repository will still keep all the history, including any deleted files. However, we need to start somewhere. I had been thinking that the aircraft needed to be grouped into repos -- by theme, author, era, whatever -- but perhaps that is totally unnecessary. One thing (perhaps the only thing) that was nice about keeping aircraft in fgdata is that enforced synchronization between the aircraft and other common nasal and instrument files. However, if they are split out, maybe we will be forced to be more mature about backward compatibility, etc. So, let's choose an aircraft, preferably not one being considered for the base distribution, and suck it into its own repo. I'll perform and document the git magic, which uses git-filter-branch, to preserve history for an aircraft in the new repo. If this goes well, we'll do it with all the rest, build a new fgdata without aircraft, and drop the old one. Sound good? Any nominations? I favor the an2, which I like, has lots of textures and sounds, and which hasn't seen any recent activity. Tim -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Improved forests
On Thu, Jul 28, 2011 at 8:33 AM, Gene Buckle ge...@deltasoft.com wrote: On Thu, 28 Jul 2011, Stefan Seifert wrote: On Thursday 28 July 2011 01:00:10 Hal V. Engel wrote: But there is one minor and very common issue with the code that should be fixed. In the for loop for (..; ..; j++) should be for (..; ..; ++j) if you use j++ the compiler has to make a copy of j with each iteration of the loop but if you use ++j it does not have to make a copy. This will make the loop more efficient although only by a small amount. Are you sure about that? I just tried it with a little example and at least gcc compiles both variants to the exact same assembly code. Tried it with and without -O2. That would freak me out. Doesn't ++j mean increment j, then test whereas j++ means test j, then increment? No, in both cases the test is done before the increment. The difference between these cases is that in the post-increment case the initial value of the variable must be saved and returned as the value of the operation. In a typical for-loop that value won't be used, so in simple cases -- such as just incrementing an index or pointer -- the compiler might very well generate the same code. The difference is seen when the variable is an iterator with hairy overloaded functions for the increment operations. Tim g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT source
Sorry that I've dropped the ball on this. I will take a look at that code soon and try to get it into the source tree. Tim On Tue, May 17, 2011 at 9:58 PM, cas...@mminternet.com wrote: Hi Jack, I'm kind of slogging through a stressful day today with some other stuff hanging over my head. If the patches are intended to go into the main line, I'd love to have Tim take a pass at reviewing them. For a quick hack you could just do a traditional diff -c sort of patch if you wanted to share the changes and let other people try them or take a look at the code. Ok, let me try that. The goal is to move them into the main line at some point and a review is definitely in order. In the near term, a quicky would work ATM slogging through the code to understand how shaders work. The edge blending will be a shader program, most likely a fragment shader at the pixel level. But having a tough time getting my head around how to include the shader in the code as part of the scene graph. The Docs help, but more info than what is needed ( at least that's my impression ). Just need to understand how to incorporate, say, an edgeblend.frag chunk of GLSL code into the scenegraph, It's pretty much a static set of functions with zero options, no fancy animation, techniques, quality-levels, or other predicates. The code will test the pixels in the overlap region, adjust the RGB values based on position and then apply a gamma correction. Any thoughts or examples from the community of a basic template and a howto for adding a fragment shader would help. Thanks Jack Curt. On Mon, May 16, 2011 at 11:45 PM, cas...@mminternet.com wrote: Hi Curt, A while back Tim Moore offered to post the image warping code onto the GIT site. Since then I've not heard from him and emails have gone unanswered -- no idea as to why... :-( At any rate, tried to setup a GIT library myself and nothing but frustration and zero success in setting up a branch or whatever to make the code public. Might you have a moment to help me get it posted? Would tomorrow be a good time? And best time and number to call if you have the patience to walk me through the process. Or if you're too busy, no problem -- sooner or later I'll get it figured out. is there a good howto somewhere that would do the trick? Regards Jack -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG caching
On Sun, Apr 17, 2011 at 6:10 PM, ThorstenB bre...@gmail.com wrote: On 16.04.2011 21:16, Anders Gidenstam wrote: If I'm not mistaken the particles issue has been around since we got particles, so it is apparently not that bad (leak and race condition) in practice. Ok, thanks! I've create a bug issue as a reminder, in case someone else noticed the issue some day. http://code.google.com/p/flightgear-bugs/issues/detail?id=305 Not sure, but I guess the issues with Effect objects is probably worse than with particles. There's a larger number of Effect objects - and each is connected to a texture (.rgb/.png images) - which may occupy a lot of memory. Just by starting at KSFO, loads of KSFO terminal textures - and textures of 15 different MP aircraft immediately stick in memory... Yes, the big textures will eat memory fast. Particle systems usually use small textures (the effect of the accumulation of particle system updaters is noticeable with wildfire, though - but you'd need a lot of MP aircraft passing through to generate anywhere near those numbers of particle systems). The effect/texture mystery is also solved - alas - explained. 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. If that's used for scenery/MP aircraft a lot, it _might_ accumulate a lot of memory. Tim might know more about this :). 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. Also, there may be some places where effects are not being found in the cache and are being recreated. Tim cheers, Thorsten -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG caching (was: Texture cache)
On Sun, Apr 3, 2011 at 3:41 PM, ThorstenB bre...@gmail.com wrote: Maybe someone could do some tests when changing the setting (SGPagedLOD.hxx:56) from CACHE_NONE to CACHE_IMAGES or even to CACHE_ALL (then recompile/install sg+fg). Would be interesting to know how this changed loading times, run-time fps and memory consumption. After 30 minutes more of testing: It also works in practice. I have seen no averse side effects, and the performance drop from loading new clouds is now almost completely gone - the framerate drops I still see are mainly associated with terrain sampling. The actual rendering performance is, as far as I can see, not changed, i.e. once everything is there, it is there. But all in all this makes things way smoother. It should be most pronounced on single CPU machines. I've also been using CACHE_ALL since then - not seeing any problems. But I haven't checked memory consumption. So, what's the status about the OSG caching options, should we enable these? Tim? There are two issues I can think of. One is that animations might not work correctly with caching enabled, but I think the copying we do elsewhere should take care of that. The other is that memory usage will be higher with caching enabled. Tim cheers, Thorsten -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On Sat, Mar 26, 2011 at 6:27 AM, Robert dogg...@googlemail.com wrote: Indeed the jitter is caused by Nasal's garbageCollect method. Simple test: add a printf (apply attached patch to simgear) and you should see the stutter is synchronized with it. True! The text is printfed with every jitter. Well, there is a workaround! Use a faster CPU :). I see a jitter of about 7ms with most aircraft. Wow 7 ms is very good. I hardly notice a 10 ms jitter, at full 75 fps. But something around 20 ms gets very prominent. However, the garbage collector does a complete scan of all Nasal objects to detect and remove unreachable elements. So, the more Nasal data elements we have, the worse the jitter gets. Large Nasal data structures will eventually break every CPU. And since it's done in the context of normal Nasal calls, and not in a separate background thread, it directly affects the duration of our main update loop - hence frame rate. Not so nice. Hmm. Other script languages rely on reference counting for garbage collection, which means much more stable performance. Python does that for example. But, well... GSoC anyone? ;-) Reference counting doesn't provide a strong performance advantage over conventional garbage collection, and a reference-counting scheme can take an unbounded amount of time. Reference counting schemes that do have real-time or bounded behavior are very complicated. I don't know much about our Nasal implementation, but I suspect that the garbage collector could be changed to trace only a portion of Nasal's heap at each invocation, at the risk of increased memory use. Python support would be a great feature I think. It is used in many products (e.g. in Blender) and that is a plus. However it's not guaranteed that it is free of such problems until you port all current Nasal scripts to Python and test it. What I am thinking about is a possibility to convert Nasal scripts to C or C++ and compile them as shared objects (.so .dll). Then we could load them dynamically at fgfs runtime. So in the end we get raw C/C++ performance to our modules. Is this possible or am I dreaming of something impossible here? What do you think? Why not write the modules in C++ to begin with? Tim -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Best pratice for debugging multi threaded programs?
On Mon, Mar 21, 2011 at 3:04 PM, Holger Wirtz dcored...@googlemail.com wrote: Hi all, sorry - a little bit off-topic (in fact not so much as you might think, it's for a third-party software for FG): Has anyone some hints/websites/programs for debugging C -based multi threaded programs (exactly: glib based C code)? Currently I am developing with vi and a little bit gdb (command line) and very much debug output. But this setup seems to be very frustrating while searching for dead-locks and race-conditions :-( On the other hand I won't invest too much time for studying rocket engeneering only to use framework XYZ. Has anyone some ideas how to debug with less effort? Just a couple of ideas to add to others' suggestions. First, if you are starting from scratch, do some reading on design of multi-threaded programs in order to reduce sharing -- and the potential for races -- right from the start. A good strategy is to set up queues of work for auxiliary threads and also have queues where those threads can place their results. The helgrind tool, which is part of valgrind, is very useful for rooting out race conditions at an API level. You might not be able to run FlightGear with it in a practical way, but you can certainly run graphical applications with it. In gdb there are several breakpoint and scheduling commands which give you the flexibility to only break in certain threads and to only let one thread continue. This can be useful when several threads have entered the same function (which might be perfectly reasonable) and gdb appears to be bouncing all around. Finally, command line gdb is intolerable; I haven't debugged that way for years. I run gdb inside of emacs, which gives you instant access to the source code. I won't push emacs on a vi user :), but there are many alternatives these days on Linux which will provide a friendlier debugging experience. Tim Thanks, Holger -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Texture cache (was: Adventures in dds)
On Mon, Mar 21, 2011 at 10:03 PM, Lauri Peltonen lauri.pelto...@gmail.com wrote: Hi. Inspired by the talk in the dds thread about cloud performance and other things, I did some quick grepping through the source about textures. I found out FG/SG has at least 5 different way of storing textures: It is important to keep in mind the difference between the texture in main memory as loaded from disk -- what OSG calls an Image -- and the texture object on the GPU -- called a Texture2D -- which includes other state in addition to the bits of the image. OSG does keep a cache of Images, so it shouldn't be going out to disk each time it needs to load a texture. However, OSG also avoids using up memory without bound, so if an Image becomes completely unreferenced it will drop out of the cache. 1. FGTextureManager in FG's Cockpit/panel.*, which at least tries to keep track of texture files which are loaded and should not load them again. This is used in some instruments and 2d panel? No comment. 2. Effects (SG: scene/material/TextureBuilder.*) have their own texture cache which reloads textures only if their parameters in effect file changes. Seems to reload the texture if e.g. clamping changes? Yes, the Effects system caches Texture2D texture objects. If a parameter such as the clamping is different from a texture that is otherwise identical in the cache, it has to create a new texture object. That's just the way it is. Note that this should not force the image to be loaded from disk again. 3. Material library (scene/material/mat.*) which handles the materials.xml. This one seems to use TextureBuilder so it might load the iamges only once, if all parameters are the same. Right, these textures should be only be loaded once. 4. Individual pointer in subsystems. At least sky elements, splash screen, maybe trees and clouds etc use these. Texture pointers are stored inside the class and they are not exposed for other systems to use. 5, maybe worst: osg plugins which load 3d models seem to load textures directly and store them... somewhere. So no caching, if two models use the same texture it gets always loaded, no matter what. This should not be true in general; the images should be cached and the texture objects should be too, unless some parameter is animated so the texture can not be shared. Now, I notice that cacheing is turned off for a class of models that includes AI models and may include models created through Nasal (simgear/scene/model/SGPagedLOD.hxx, line 53); I don't know what the rationale is for that and that may be the cause of the current problems. I think the problem with local weather could be that the models are always re-loaded and that's why the osg plugin re-loads the textures too... I checked some models in Models/Weather and they do point to the textures. You can put a breakpoint in ModelRegistry::readImage(), which should handle *all* images read by fgfs, and see if it seems to be invoked too often. I think this is quite a big mess currently. I think there should be only one place to store the images (maybe just the images, even if other texturing parameters change?) which should be used everywhere and the textures should be exposed so that the same image can be used in effects or animations or wherever necessary. That place is supposed to be OSG's Image cache. Tim Any thoughts on this and how to solve it? - Lauri Peltonen, Zan -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] File sizes in fgdata, clean up needed?
I've been threatening for some time to break up the aircraft portion of fgdata into several repositories by using some git magic. It's true that the current repository size is out of hand. I would encourage people to check in their source files whenever possible. I'd also encourage people to add new aircraft to their own repositories on gitorious and think about moving past the central repository model. Tim On Fri, Mar 18, 2011 at 9:48 PM, Hal V. Engel hven...@gmail.com wrote: On Friday, March 18, 2011 09:50:50 AM HB-GRAL wrote: Hi all Today I checked the current fgdata/Aircraft folder for sizes. It’s about 4,3 GB here. Nice. Now some statistics (and this is no critcs on aircrafts of course, I like all the development and improvements a lot!): We have 372 aircrafts in the directory. 22 of this aircrafts have more than 30 MB and this 22 aircraft gives 1,1 GB of the aircraft folder. Number One is p51d with 104.5 MB (!). 50 MB in the models folder comes from GIMP .xcf-files and from Blender files (.blend). Do we distribute this files uncompressed? i. e. compressing .xcf to .gz will give a 1,2 file instead of a 4,3 MB. I think 12 MB vs. 43 MB. Number Two is 767-300 with 82,2 MB. I. e. this one comes with widely used .wav-sounds in the cabin ;-) This sounds, or better short loops, take 17,3 MB here. One livery (VRN.png) takes 6.3 MB. Number three is MiG-15, a really nice one, with a lot of instruments, and it seems like every byte is used here. I am looking deeper into the files and I see a radio-tune.wav which has 3.5 MB for 10 seconds of sound and 10 seconds of silence ;-) Some models like IAR80 have liveries with 13 MB .png-files. Totally we distribute 18 blender files with the directory. This is only 16,4 MB. Not much. But we distribute also 310 MB of original GIMP files. Some of this files are .gz already, when I .gz the rest I get another 100 MB, or in other words I get two MiG-15 or another p51d. Cheers, Yves I think Yves has several good points. First many of these advanced models have working files that are not actually used when the model is being flown in sim. The p51d GIMP files and blender files are two examples. Now there are valid reasons for these to be source controlled. For example the gimp files in the p51d/Models directory are complex multi layer files that are intended to make working with the resulting textures easier and they do indeed do that. Reading Yves comments I think one of the things he hionted was not so much that these working files made GIT bigger but that that they made the distribution size to users bigger and really served no purpose for users other than wasting disk space and bandwidth. This is a valid concern at least if the size of these working files is significant and in some of these case they are. A look at p51d/Models clearly shows that the three big space users are (in order of the highest space useage) the working files mostly in the form of high resolution multi layer textures, 3D models and the actual textures. In the case of the p51d all 3D models are AC3D files and many of the textures except some newer ones are *.rgb files. These are not the most compact formats and changing these could reduce the size of the model significantly but the 800 pound gorrila is still the working files. In the case of the p51d, and I suspect that this is true for most models, the working files could be located anywhere in the file system tree. And perhaps it makes sense to have a directory with a standard name that is used for these types of files that is always excluded (somehow?) when regular user gets a copy but is included for GIT clones. In the case of the p51d this would cut the size of the distributed copy almost in half. The 3D and texture parts of the p51d are now fairly far along and will not grow too much more even though there is still 3D work that needs to be done. It's size will only grow by perhaps 10% as it 3D model and FDM are finalized. There may be other models that get implemented for more complex aircraft that could result in significantly larger models. I suspect that the 100 meg p51d to 310+ meg IAR80 sort of represents the size range we will be seeing for really advanced highly detailed models with a few really careful modelers being able to bring these numbers down to lower levels while achiving the same effective level of detail like the Mig-15 does. I really think we are only seeing the begining of a period where are will see more efforts to take existing models to the next level and where we will start seeing new additions that enter GIT already in a very advanced state. As this process unfolds we will see many more models that approach the size of the ones listed by Yves. We don't want to discourage that work but if we can create a set of best practices we can perhaps help those working on this stuff create these highly detailed
Re: [Flightgear-devel] Coordinate conventions
If you're referring to coordinates in the multiscreen support, they are OpenGL coordinates: x to the right, y up, z comes out of the screen. Tim On Thu, Mar 3, 2011 at 10:16 PM, cas...@mminternet.com wrote: What are the coordinate conventions used for eye position offsets in 2.0? standard right-hand rule or something else? Messing with the camera offsets and not getting the results expected. OTOH, the documentation on the subject is VERY old (circa 2002!). Is it still valid? John -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear and OSG out of sync?
I've committed one more fix that should make things right on 2.8.3. Tim On Wed, Feb 16, 2011 at 8:16 PM, Tim Moore timoor...@gmail.com wrote: OK, I see that merely removing the 2.8.3 case from my conditional, which I checked in a couple of hours ago, isn't correct. I'll have another go. On Wed, Feb 16, 2011 at 7:10 PM, ThorstenB bre...@gmail.com wrote: On 15.02.2011 13:41, Tim Moore wrote: I've checked in fixes for this change in osgDB:DatabasePager to the SimGear and FlightGear next and releases/2.2.0 branches. Still doesn't compile with OSG = 2.8.5. We also need the patch that Bertrand sent yesterday, i.e. the #ifdef logic for the _readerWriterOptions attribute is still incorrect (inverted): diff --git a/simgear/scene/model/SGPagedLOD.hxx b/simgear/scene/model/SGPagedLOD.hxx index a9e55d9..4e25931 100644 --- a/simgear/scene/model/SGPagedLOD.hxx +++ b/simgear/scene/model/SGPagedLOD.hxx @@ -72,7 +72,7 @@ public: protected: virtual ~SGPagedLOD(); -#if SG_PAGEDLOD_HAS_OPTIONS +#if !SG_PAGEDLOD_HAS_OPTIONS osg::ref_ptrosgDB::ReaderWriter::Options _readerWriterOptions; #endif }; = Fixes the compile for any OSG version without SG_PAGEDLOD_HAS_OPTIONS support. By the way, I committed the changes to releases/2.2.0 and then merged that branch into next. This is the way fixes should move between the two branches. Please don't commit a fix to next and then cherry-pick it to the release branch. It is very messy to have the same change committed on several different branches. Hmm. On the other hand this means applying all (experimental) patches to the stable release/2.2 branch first. I'm not a git expert, but generally I like the opposite approach of applying patches to a project's experimental (master / next / ... ) branch first. And only after the patch proved to be ok and stable for everyone, eventually move it to the stable release branch. Reduces the risk of (temporarily) breaking a release branch (like we did now :) ). Well, in this case I should have tested with 2.8.3, which I don't happen to have checked out. Anyway, we chose a simple branching model, http://nvie.com/posts/a-successful-git-branching-model/ , where fixup work done on the release branches is merged into the development branch. It is very messy to have a commit virtually checked in on several different branches. As there is no good reason for the development branch not to have all the commits made to the release, the commits should originate on the release branch and be merged into development. Now, you don't have to work this way locally, and in this case I didn't; I had next checked out, so hacked away on a fix and committed it locally. I then rebased that fix onto the release branch, tested (hah!), committed that and pushed it to gitorious. I then reset the next branch to blow away my commit at the head, merged in releases/2.2.0, and pushed that. You can use git rebase to get things in shape before committing to the master repo in the way I've described. Tim cheers, Thorsten -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear and OSG out of sync?
I was confused, by my git SVN import of the OSG source tree, about what commits are in 2.8.3. I'll check in a correction soon. Tim On Wed, Feb 16, 2011 at 8:51 AM, Frederic Bouvier fredfgf...@free.fr wrote: - Bertrand Coconnier a écrit : 2011/2/15 Tim Moore timoor...@gmail.com: I've checked in fixes for this change in osgDB:DatabasePager to the SimGear and FlightGear next and releases/2.2.0 branches. Part of the delay resulted from the fact that the Open Scene Graph change introduced a new bug; I have waited until my patch for that was accepted in OSG to avoid a situation where people could compile with OSG SVN and then crash immediately. So, You need to have revision 12170 or later of OSG SVN in order to run fgfs from the release and next branches. Otherwise you should use OSG 2.8.3 or 2.9.10. I will not conditionalize code in fgfs based on individual revisions of OSG SVN; if you are using OSG SVN, then you are, by definition, living on the bleeding edge. Hi Tim, Your commit broke SimGear for me (using OSG 2.8.1). I have attached a tiny patch that restores the ability to compile the last SG git revision with OSG 2.8.1 Could you please review it and apply it if it makes sense ? Your patch doesn't work for OSG = 2.9 because _readerWriterOptions is unconditionally used in SGPagedLOD.cxx Regards, -Fred -- Frédéric Bouvier http://www.youtube.com/user/fgfred64 Videos -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear and OSG out of sync?
OK, I see that merely removing the 2.8.3 case from my conditional, which I checked in a couple of hours ago, isn't correct. I'll have another go. On Wed, Feb 16, 2011 at 7:10 PM, ThorstenB bre...@gmail.com wrote: On 15.02.2011 13:41, Tim Moore wrote: I've checked in fixes for this change in osgDB:DatabasePager to the SimGear and FlightGear next and releases/2.2.0 branches. Still doesn't compile with OSG = 2.8.5. We also need the patch that Bertrand sent yesterday, i.e. the #ifdef logic for the _readerWriterOptions attribute is still incorrect (inverted): diff --git a/simgear/scene/model/SGPagedLOD.hxx b/simgear/scene/model/SGPagedLOD.hxx index a9e55d9..4e25931 100644 --- a/simgear/scene/model/SGPagedLOD.hxx +++ b/simgear/scene/model/SGPagedLOD.hxx @@ -72,7 +72,7 @@ public: protected: virtual ~SGPagedLOD(); -#if SG_PAGEDLOD_HAS_OPTIONS +#if !SG_PAGEDLOD_HAS_OPTIONS osg::ref_ptrosgDB::ReaderWriter::Options _readerWriterOptions; #endif }; = Fixes the compile for any OSG version without SG_PAGEDLOD_HAS_OPTIONS support. By the way, I committed the changes to releases/2.2.0 and then merged that branch into next. This is the way fixes should move between the two branches. Please don't commit a fix to next and then cherry-pick it to the release branch. It is very messy to have the same change committed on several different branches. Hmm. On the other hand this means applying all (experimental) patches to the stable release/2.2 branch first. I'm not a git expert, but generally I like the opposite approach of applying patches to a project's experimental (master / next / ... ) branch first. And only after the patch proved to be ok and stable for everyone, eventually move it to the stable release branch. Reduces the risk of (temporarily) breaking a release branch (like we did now :) ). Well, in this case I should have tested with 2.8.3, which I don't happen to have checked out. Anyway, we chose a simple branching model, http://nvie.com/posts/a-successful-git-branching-model/ , where fixup work done on the release branches is merged into the development branch. It is very messy to have a commit virtually checked in on several different branches. As there is no good reason for the development branch not to have all the commits made to the release, the commits should originate on the release branch and be merged into development. Now, you don't have to work this way locally, and in this case I didn't; I had next checked out, so hacked away on a fix and committed it locally. I then rebased that fix onto the release branch, tested (hah!), committed that and pushed it to gitorious. I then reset the next branch to blow away my commit at the head, merged in releases/2.2.0, and pushed that. You can use git rebase to get things in shape before committing to the master repo in the way I've described. Tim cheers, Thorsten -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear and OSG out of sync?
I've checked in fixes for this change in osgDB:DatabasePager to the SimGear and FlightGear next and releases/2.2.0 branches. Part of the delay resulted from the fact that the Open Scene Graph change introduced a new bug; I have waited until my patch for that was accepted in OSG to avoid a situation where people could compile with OSG SVN and then crash immediately. So, You need to have revision 12170 or later of OSG SVN in order to run fgfs from the release and next branches. Otherwise you should use OSG 2.8.3 or 2.9.10. I will not conditionalize code in fgfs based on individual revisions of OSG SVN; if you are using OSG SVN, then you are, by definition, living on the bleeding edge. By the way, I committed the changes to releases/2.2.0 and then merged that branch into next. This is the way fixes should move between the two branches. Please don't commit a fix to next and then cherry-pick it to the release branch. It is very messy to have the same change committed on several different branches. Tim On Sun, Jan 16, 2011 at 12:43 PM, James Turner zakal...@mac.com wrote: On 16 Jan 2011, at 10:56, fiers...@zonnet.nl wrote: When I saw this, I removed all sources for OSG and Simgear and restarted with a fresh git clone, but the error remains. I searched the forums and noticed someone else has the same problem with a completely freshly cloned git version. Did I miss something that causes this in the past few weeks? OSG SVN made an API change to Paged LOD, no one yet updated FG to work with it. While some developers do track OSG SVN, that's a slightly ambitious goal for everyone - personally I stick with the most recent developer release of OSG (2.9.9 or 2.9.10 at the moment, depending on who you ask) I believe for this paerticular change Tim Moore has a fix pending, but each such change (not associated with a version release) requires additional configure/cmake complexity to check for the changed API - as was done for CullSettings, for example. James -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] urgent git help requested
Backing out is done with git reset --hard last_good_commit. Often the name of the last good commit is HEAD^, the last commit. However, after a botched merge it is good to verify that with git log or graphically with gitk. If you've pushed a commit to a public repo and then it later turns out that the commit wasn't a good idea, then you want git revert which creates the reverse patch for a given commit. However, if you make a real hash out of a public repo you may still want git reset. Tim On Tue, Feb 8, 2011 at 8:04 PM, Anders Gidenstam anders-...@gidenstam.orgwrote: On Tue, 8 Feb 2011, Curtis Olson wrote: I made a commit into a branch of a --local clone of my fgdata repository. I pushed that to the matching branch in my main fgdata.git repository. Then I attempted to merge one commit into the master branch ... however it merged *all* my changes. How can I back this out (I've made some hacks to some f-14b nasal files which are intended for personal expermentation and break standard behavior.) How can I cherry pick one particular commit to merge into the master branch? Backing it out might be a bit tricky, but you can rename your messed up branch out of the way easily with git branch -m oldname newname. To cherry-pick commits from your other repository into a branch you first fetch the branch you want to pick, e.g. git fetch theOtherRepro.git theotherbranch:suitableName/theotherbranch Or just theotherbranch:suitableOthername Then you can inspect the commits on it with git log -u theOtherRepro/theotherbranch And finally cherry-pick the one you want with git cherry pick commitID I always use a clean local copy (e.g. git branch -t mrClean origin/master) of origin/master to cherry-pick commits to before pushing to origin. I leave that branch around since the next time I just need to check it out, do git pull which will be a clean fast forward and cherry-pick and push again. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] urgent git help requested
On Wed, Feb 9, 2011 at 7:49 PM, Andy Ross a...@plausible.org wrote: On 02/09/2011 12:02 AM, Tim Moore wrote: Backing out is done with git reset --hard last_good_commit. Often the name of the last good commit is HEAD^, the last commit. However, after a botched merge it is good to verify that with git log or graphically with gitk. I should have said HEAD^ is the previous commit on the current branch. I believe this is the case in the absence of exotic options to git merge. Actually, unless I've misunderstood your point, this won't work: the commit history following a merge is an interleaved mix of two branches. You can't just walk back to before the merge. Doing that gets to to the equivalent of git merge-base, which is the last version that includes *none* of the changes in *either* branch. A merge commit has two parent commits (leaving aside octopus commits). If you are not happy with the results of the merge, usually you want to revert back to the parent that was on your branch. As you say, the reflog can be useful for checking this, but usually the parent of the botched merge on your branch is HEAD^. I'm not sure what you mean by the history is an interleaved mix of two branches. git log shows the commits in reverse chronological order by default, but the parent-child relationships of the commits in the two branches is definitely preserved. Tim I don't think that's what Curt wants. See my comment to Anders about git reflog. (and yes, I've made exactly this mistake in the past, heh) Andy -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] modern X-Plane airport format; Was: Magnetic North
Interesting discussion. By the way, I highly recommend http://xplanescenery.blogspot.com/ Ben Supnik is the main graphics guy for XPlane and a very good writer; obviously they encounter many of the same issues. Terrain rendering has quite a bit of headroom in terms of raw number of polygons. That part of the rendering engine is reasonably well optimized. But there are good reasons not to carve polygons into the terrain for every taxiway marking. Curt makes a very good point about aliasing of sharp features vs. blurring of the same features when viewed close up. Intersection queries can be a real bottleneck if we are not careful. Mathias did a lot of good work to optimize these queries without any change to the .btg format by building bounding volume hull trees at load time. I think we could gain performance by pushing some of this work back to scenery generation time. One of the problems we have with bumping up the polygon count is that we don't have an LOD scheme for terrain, and creating one is hard because our terrain skin is irregular. I've said before that the best way forward is to have a very regular height-field for terrain and generate the textures for areas of terrain on-the-fly. This will be a lot of work for someone. Airports don't need to handled in the same way as normal terrain. They could be treated more like a complex model with arbitrary geometry. We have access to many texture units these days, so not everything has to be baked into a single texture. Tim On Tue, Jan 18, 2011 at 5:26 PM, Curtis Olson curtol...@gmail.com wrote: Here's my 2 cents: If we cut all the curves and lines and markings into the base triangle mesh: - Huge polygon count (large file sizes, memory footprint, etc.) - Lots of problems with aliasing along all the line edges - All the lines and markings will have very sharp edges. (Good if we want to zoom in forever, but not so good from the standpoint of realistic visuals.) - slow terrain intersection lookups (?) If we draw all the lines and markings on a separate layer above the runway: - This is a common approach. - Possible z-buffer fighting issues (which can look really bad) - GLPolygonOffset can counter z-buffer fighting, but historically it's not been implemented consistently by vendors so it's hard to get consistent for everyone. - FlightGear has non-flat runways so it's hard to cheat and just use draw order tricks (or we could see the markings that should be obscured behind a rise in the runway.) - Still, this may be the most promising approach we have available to us ... We could cook all the markings into custom textures for each airport. - This has the advantage of no z-buffer fighting, and no hard edges on the markings and no crazy edge aliasing problems. (Look at a power pylon from a distance as you fly if you wonder what I mean by edge aliasing problems.) - Would require a much bigger texture foot print. - Would require much bigger texture storage (unless we could figure out a way to render/generate textures on the fly.) - Probably wouldn't be very high res, so close in ... like when taxiing or taking off, we could have big problems with the whole texture just bluring out and making the marking hard or impossible to distinguish from the rest of the blurry mess. - This approach could have the advantage though of being able to cook all kinds of extra details into the custom textures for each airport (skid marks, pavement flaws, paint chips, all kinds of fun stuff ...) - I like thinking about this approach if we could get enough texture resolution so the results aren't too blurry when the aircraft is on/near the ground. Curt. On Mon, Jan 17, 2011 at 3:01 PM, Martin Spott wrote: Frederic Bouvier wrote: As John said, the missing bit is scenery generation. I think it's a split task. As with almost every technical problem, there is _some_ way to a solution ;-) I'm certain we'd find a reasonable way of nicely casting the new X-Plane layouts into Terrain tiles without the triangle count or other ressource requirements going through the roof - but this is most likely letting us end up with something that FlightGear can't parse :-) Basically (at the risk of triggering another pointless debate) I think there are two problems to solve: a) There would be the need for supporting more 'complex' geometries in FlightGear Terrain, like polygons (at least) instead of triangles, at least until shortly before the rendering stage, to save FlightGear from sorting countless triangles just for one simple elevation lookup. An alternative solution would be to make extremely high triangle counts extremely cheap :-) b) There would be the need for drawing line features, the yellow taxiway lines in particular, _on_top_ of the existing runway, taxiway or apron textures. The funny side of the issue: We're not the only ones struggling with a 'proper' design for smooth airfield layouts: Two years
Re: [Flightgear-devel] git question
On Mon, Jan 10, 2011 at 5:31 PM, Curtis Olson curtol...@gmail.com wrote: Here is my next git question (possibly another dumb one) :-) When I did a git pull in simgear/flightgear this morning I saw something like the following: simgear$ git pull remote: Counting objects: 1, done. remote: Total 1 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (1/1), done. From gitorious.org:fg/simgear * [new branch] releases/2.2.0 - origin/releases/2.2.0 * [new tag] 2.2.0-rc1 - 2.2.0-rc1 Already up-to-date. Ok, cool I think, it looks like the 2.2.0 release branch has been created. But my question is how can I switch to this new branch? When I list my branches I see: simgear$ git branch maint * next The new branch is not listed. Does this branch only exist on the server? What do I have to do to see the branch locally? Do I have to manually copy any remote branch that I want to work with locally? What's the git thought process and reasoning here? How would a person typically know that a new remote branch got created and be able to access it? Why doesn't the new branch automatically show up in my list of branches? You can see the remote branches with git branch -r or git branch -a. You can create a local version of a remote branch with git branch releases-2.2.0 origin/releases-2.2.0or git checkout -b releases-2.2.0 origin/releases-2.2.0. Git doesn't create a local branch automatically. I don't know all the reasons, but it would not be clear what to call the local branch, especially if there are multiple remote repositories with identical branch names. Tim Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/ -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
On Tue, Jan 4, 2011 at 5:36 PM, Curtis Olson curtol...@gmail.com wrote: I have a git question. I'm trying to git push a new joystick config someone sent me. When I run git push I get the following message: $ git push To g...@gitorious.org:fg/fgdata.git ! [rejected]master - master (non-fast-forward) error: failed to push some refs to 'g...@gitorious.org:fg/fgdata.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. Make sense, so next I run git pull and get the following message: $ git pull remote: Counting objects: 31, done. remote: Compressing objects: 100% (17/17), done. remote: Total 17 (delta 13), reused 0 (delta 0) Unpacking objects: 100% (17/17), done. From gitorious.org:fg/fgdata aaef799..4affc2c master - origin/master error: Your local changes to 'Aircraft/f-14b/Nasal/SAS.nas' would be overwritten by merge. Aborting. Please, commit your changes or stash them before you can merge. Ok, I remember tweaking the file Aircraft/f-14b/Nasal/SAS.nas a few weeks ago, and in the mean time I've done a git stash and git stash apply to get around this problem before. I could probably do it again. But here's my question. Now that I've done the git stash and git stash apply commands, when I run git diff, I don't see my local differences. Is a git stash apply similar to a git commit in that it actually commits my local edits to my local repository. No. git stash is sort of like a commit + a reset to the previous commit. git stash apply and git stash pop are like applying a patch. A simple thing you can do is git status, which tells you git's idea of the modified files in your working tree. When I'm just fiddling around, I'd prefer some times to just carry my edits forward as non-committed edits so it's easy to see what I've fiddled with and can clean things up if I no longer need or want my local tweaks. What's the best way now to see what my local changes are after doing a git stash apply? What is the best way to carry local experimental edits forward while I'm still experimenting and aren't sure if I want to keep them? As everyone else has said, commit 'em in a branch. Please explain in simple language. :-) Tim -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
On Thu, Dec 16, 2010 at 5:17 PM, Jacob Burbach jmburb...@gmail.com wrote: Ok then, trying to make sense of this whole model effects loading code... Good luck; it goes with the territory :) In `modellib.cxx' the `loadFile' and `loadModel' functions, which check the file extensions for a `.ac' file and if so sets a flag for instantiation of effects. This flags is only checked in the 'ACOptimizePolicy::optimize' method in `ModelRegistry.cxx' and appears it's only purpose is to make sure non xml wrapped `.ac' files get the default model effect applied. This is done by calling an overloaded `instantiateEffects' function in `model.hxx' that simply calls the other version of the function with an empty effects property tree causing default model effect to get used. Ok... The support for raw .ac models exists for the random models associated with materials, which I think are the only use of non-wrapped models in FG. Perhaps you can include them directly in scenery too. ... So here is the kicker...`instantiateEffects' does indeed seem to be called for every single model wrapped in an xml regardless of whatever format that might be. So then it seems the effect code is simply failing silently on non ac3d formats. Perhaps in the `MakeEffectVisitor' or further up the chain somewhere who knows...deeper down the rabbit hole we go... So umm Tim...could you maybe explain the process of the whole model loading, getting effects applied, what the effects system expects from a model, the reasoning behind it and so on? There is a lot of static local functions and classes and so on in this code that is completely undocumented and not at all trivial to unwind and try and fit the pieces together. Would be really, really helpful if you could lay out the code flow here, what functions are involved and inter-dependent on each other, what processing is needed for the effect system to work, etcin the mean time I'll keep digging. I'm not going to document the whole model loading process; it would be nice one day to have better comments in the code, but this code has accreted over many years, starting long before my involvement with FG. At a very high level, when a model is loaded, its OSG subgraph is copied, except for its textures and geometry. This is not-optimal, but it allows animation of all models without a complicated optimizer. In the monster function sgLoad3DModel_internal, effects mentioned in the .xml file are gathered, along with any created implicitly by animations. An effect is associated with named objects in the model. The .XML file can also specify a default effect for the whole file; by default that is Effects/model-default.eff. The model itself is transformed by instantiateEffects, which uses MakeEffectVisitor. For each named object in the model, this MakeEffectVisitor sets the appropriate effect as a parent effect, and then creates a new effect for any osg::StateSet found, inheriting from the parent. osg::Geode objects are replaced with simgear::EffectGeode objects that will apply the effect at runtime. There is quite a bit of hair to share effects and avoid creating new ones where possible. The dependency on .ac exists at this level in MakeEffectVisitor. The visitor expects to find osg::StateSet objects only in osg::Geode objects i.e., near the leaves of the scene graph. It only works with the simple attributes created by the .ac loader (see makeParametersFromStateSet): osg::Material properties, smooth vs. flat shading, polygon culling, blending (for transparency), and one texture binding. Any other attributes are ignored. If you want to apply effects to other kinds of models, you would need to generalize MakeEffectVisitor in both directions. StateSet objects can appear in any scene graph node and also in the Geometry nodes that sit below osg::Geode. A more general effects visitor needs to track the graphics state as it traverses the scene graph and also needs to examine the geometry. Effects sit at the Geode level. Alternatively you could ignore any state attributes in the model and specify it all in the .xml file, but this would quickly get tiresome. I recommend you use the osgconv program to dump out the .osg representation of our .ac models and the models that interest you and get an idea of the differences you are up against. For .ac you should use our Optimizer options found in ModelRegistry.cxx; you can set them with the OSG_OPTIMIZER environment variable. I'll try to write more comments in the code over the next few weeks. In the mean time, keep hitting me with questions. I don't have the bandwidth to answer basic OSG questions, but I think you are beyond that and I'll do my best :) Tim -- Forrester recently released a report on the Return on Investment (ROI) of Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even within 7 months. Over 3 million businesses have
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
On Wed, Dec 22, 2010 at 4:34 PM, Jacob Burbach jmburb...@gmail.com wrote: Hey thanks for taking the time to respond, especially during the holidays. So what I see currently in the model loading code in regard to effects is really something just hacked together to 'get er done' and make it work. Which is fine of course, but I think we can do better and I Pretty much. really believe we can do this in a general fashion that should work for all model formats...but still allow specific processing if needed. I mean yes, each model loader may organize a models scene graph a bit differently...but the effects/material system is only concerned with state sets and geode/geometry for it's purpose. And OSG makes it very easy to drill down through a scene graph to find those particular things so there really shouldn't be a problem here. Not to say that it I think general state tracking over the OSG state graph is pretty messy, but if you want to have a go at at, great! will be trivial of course, but certainly doable. I'll be working on it when things settle down after the holidays and will of course be bouncing ideas and design stuff at you so we can find the best way to get it done and into flightgear. I recommend you use the osgconv program to dump out the .osg representation of our .ac models and the models that interest you and get an idea of the differences you are up against. Already been doing this, along with writing some code using OSG to load/texture my model and dump them out to see how I can define more advanced techniques in the model files. I currently have multiple models in my scenery in osg2 binary (.osgb) format making use of multiple texture units and texcoords, some texenv stuff, and also some very nice anisotropic filtering ;) Sounds good; that's an advantage of using OSG and it's rich model format support. Tim Of course it would be much better if I could make use of flightgears material system, interface with flightgear properties, and. cheers! -- Forrester recently released a report on the Return on Investment (ROI) of Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even within 7 months. Over 3 million businesses have gone Google with Google Apps: an online email calendar, and document program that's accessible from your browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] message: Warning: TangentSpaceGenerator: unknown primitive mode 9 why?
On Mon, Dec 20, 2010 at 4:51 PM, John Denker j...@av8n.com wrote: On 12/20/2010 05:42 AM, henri orange wrote: At FG load, i get a lot of these warning messages: TangentSpaceGenerator: unknown primitive mode 9 Is it just me ? is there any possibility to avoid it ? It's not just you. There are at least two or three bugs involved here. 1) It is a bug that one part of OSG would generate a primitive mode that cannot be handled by other parts of OSG. ... 2) It is a bug in OSG that the error message is remarkably uninformative. The message doesn't say what caused the problem. It doesn't say how ... 3) It's not clear to me whether this can be considered a bug in FG, or whether changing FG so as to avoid provoking the OSG bug would be worth the trouble. Changing FG would be a royal pain, because of item (2) above. I consider this to be a bug in the OSG .ac plug-in. It runs the GLU tessellator on convex polygons, which produces a collection of triangles and polygons, but doesn't turn the polygons into triangles. These days there is little to recommend the OpenGL primitive type. On 04/22/2010 03:12 PM, Tim Moore wrote: It would be best to get the polygons out of the loaded geometry. The INDEX_MESH optimizer that was recently added to OSG will do this. How recently was it added? How soon will it fix the problem? git log -SINDEX_MESH ... commit 595d04fec8cf0faee7bd7e6a9e97872e78a022d7 Author: robert rob...@16af8721-9629-0410-8352-f15c8da7e697 Date: Thu Mar 11 18:15:20 2010 + From Time Moore, This submission implements 3 optimizations for meshes. INDEX_MESH turns DrawArrays style geometry into DrawElements, uniquifying the vertices in the process. This is useful for certain loaders, like ac3d, which just spit out DrawArrays. VERTEX_POSTTRANSFORM and VERTEX_PRETRANSFORM optimize mesh triangle and vertex order for the caches on a modern GPU, using Tom Forsyth's algorithm. I describe this and the big difference it makes (38% improvement on a very large mesh) in my blog, http://shiny-dynamics.blogspot.com/2010/03/vertex-cache-optimization-for-osg.html . git branch -a --contains 595d04fec8 ... remotes/OpenSceneGraph-2.8 remotes/tags/OpenSceneGraph-2.8.3 remotes/tags/OpenSceneGraph-2.8.3-rc1 remotes/tags/OpenSceneGraph-2.8.3-rc2 remotes/tags/OpenSceneGraph-2.8.3-rc3 remotes/tags/OpenSceneGraph-2.9.10 remotes/tags/OpenSceneGraph-2.9.8 remotes/tags/OpenSceneGraph-2.9.9 (Yes, I am cheating by using git svn to work with OSG sources.) Installing the latest OSG SVN does not appear to be sufficient to fix the problem. These optimizers are not part of the default set because they are not always appropriate. A small code change is needed in Simgear to use INDEX_MESH. Time[sic] -- Forrester recently released a report on the Return on Investment (ROI) of Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even within 7 months. Over 3 million businesses have gone Google with Google Apps: an online email calendar, and document program that's accessible from your browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
On Sat, Dec 11, 2010 at 9:56 PM, Jacob Burbach jmburb...@gmail.com wrote: This is considered a feature, by some anyway :) I added this with the idea that one could optimize ac model and substitute the optimized version. It's never been used much and has led to complaints about getting the wrong cows. I still think the idea is a reasonable one, but perhaps it needs to be removed in its current form. Personally I think it's better that if I specify a certain file to be loaded that it is honored, rather than having something trying to be clever and second guess me in the background. That depends on whether you view fgfs as a model preview tool or as a real-time program. I don't mean to be snarky in saying that; as hardware improves, the balance between what should be done before runtime and what can be done at model load time changes. But I think you can see that, for optimal real-time performance, it would be best to load an optimized form of a model. Effects only work with .ac files because the code knows how to extract material parameters from the loaded representation of the .ac files. Those parameters are used by the default effects in the Effects folder. It should be possible to apply a complete effect with no missing parameters to a named object in a different kind of file, but I haven't tried it. Tim Damn, was hoping I was just doing something wrong...I really need this. I think we should at the very least support OSG native formats (osg,ive,osgb,osgt). But really, shouldn't we get be reading the pertinent data from OSG interfaces after the plugin has loaded it up, rather than doing file specific stuff at all? I thought that was the Yes, and of course we do that. .ac is a very simple format, so it is easy to walk the graph of a loaded .ac file and extract the material and texture bindings. This becomes much harder as you move to the general OSG formats, as these bindings could be anywhere in the scene graph, above or below the named objects. .osg files can even contain their own effects in the form of shader programs or osgFX nodes. whole point about all the osg loaders...to abstract that stuff away as much as possible. So what can I do to help move this along? I do really need it for my projects as the ac3d format just doesn't cut it for me. Look at the source in simgear/scene/model, find where it looks for .ac files, and change it. modellib.cxx:143, for example. Tim cheers! -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
On Sun, Dec 12, 2010 at 4:21 PM, Jacob Burbach jmburb...@gmail.com wrote: Will do. I take it your the maintainer/creator of this particular bit of code then? I feel this is very important for the future of fgfs graphics and performance wise and I'm quite willing to put in some work to make it happen. I do need to know there is support for this idea to be rolled into fgfs though, that I won't be wasting my time for something that won't be used...or not receive any support on. I wrote the effects framework and am interested in improving it, of course. I can't guarantee in advance that any particular work will be committed, so you should undertake any hacking to fulfill your own needs and not solely because you think it will be committed. I'm willing to help if you want to dive in. Tim thanks! --Jacob -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
On Sat, Dec 11, 2010 at 7:01 PM, Jacob Burbach jmburb...@gmail.com wrote: Hi all, I'm experimenting with various model file formats and the effects system and have some questions/comments. First I found that if you have a file 'model.ac', but also have a file 'model.osg', flightgear always loads the .osg version despite me explicitly requesting the '.ac' in the models xml file. Personally I don't see any point in automatically choosing one text based format over another, especially when I explicitly told the system I want the '.ac' via the model xml. So yeah is this considered some sort of feature..or just a bug...because it only served to frustrate me and waste my time until I realized what it was doing. This is considered a feature, by some anyway :) I added this with the idea that one could optimize ac model and substitute the optimized version. It's never been used much and has led to complaints about getting the wrong cows. I still think the idea is a reasonable one, but perhaps it needs to be removed in its current form. Second up is does the effect system not work with anything other than '.ac' file format? With '.ac' my effect is loaded, using any other format I tried (.osg, .ive , .osgb, .osgt) the effect seems to be ignored. Is the effect system currently crippled to using only the ac3d format, or what's going on here? Effects only work with .ac files because the code knows how to extract material parameters from the loaded representation of the .ac files. Those parameters are used by the default effects in the Effects folder. It should be possible to apply a complete effect with no missing parameters to a named object in a different kind of file, but I haven't tried it. Tim cheers! -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SegFault on Current Git
On Sun, Dec 5, 2010 at 9:18 AM, Jeff Taylor jefftaylo...@gmail.com wrote: On 02/12/10 12:05 AM, Tim Moore wrote: Can you move up the stack into SGText::UpdateCallback::operator() and see what is being passed to createUTF8EncodedString? Thanks, Tim OK, this is bugging me. I needed to recompile OSG with debugging symbols, so I did a pull from SVN first, which apparantly fixed the You don't need to recompile OSG with debugging symbols to move up the stack. I'm interested in the values of variables in a SimGear function. Tim -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SegFault on Current Git
Can you move up the stack into SGText::UpdateCallback::operator() and see what is being passed to createUTF8EncodedString? Thanks, Tim On Thu, Dec 2, 2010 at 8:46 AM, Jeff Taylor jefftaylo...@gmail.com wrote: On 29/11/10 12:45 AM, Erik Hofman wrote: So it looks like to be a JSBSim problem, now you could try to test a turbine powered aircraft like the F-16 to try to pinpoint the problem. It would probably be a good idea to try running FlightGear inside a debugger an provide a backtrace if possible. The F-16 works. I have updated to current git (as of the time of this e-mail). I'll post the backtrace again. It hasn't changed since I last posted, but here it is. My guess is that it's a graphics problem, and something specific to the c172p triggers it. Also, randomly, remember that I know how to use the debugger, so if it helps, I can probe variables, etc. Backtrace from gdb: #0 0x75fb6410 in osgText::String::createUTF8EncodedString() const () from /usr/local/lib64/libosgText.so.68 #1 0x00919946 in SGText::UpdateCallback::operator() (this=0x117b5900, node=0x11832ff0, nv=0xdf6260) at SGText.cxx:76 #2 0x004396f8 in handle_geode_callbacks (this=0xdf6260, node=...) at /usr/local/include/osgUtil/UpdateVisitor:94 #3 osgUtil::UpdateVisitor::apply (this=0xdf6260, node=...) at /usr/local/include/osgUtil/UpdateVisitor:51 #4 0x74e69898 in osg::Geode::accept(osg::NodeVisitor) () from /usr/local/lib64/libosg.so.68 #5 0x74ec3009 in osg::Group::traverse(osg::NodeVisitor) () from /usr/local/lib64/libosg.so.68 #6 0x0043ba36 in traverse (this=0xdf6260, transform=...) at /usr/local/include/osg/NodeVisitor:191 #7 handle_callbacks_and_traverse (this=0xdf6260, transform=...) at /usr/local/include/osgUtil/UpdateVisitor:86 #8 apply (this=0xdf6260, transform=...) at /usr/local/include/osgUtil/UpdateVisitor:57 #9 SGUpdateVisitor::apply (this=0xdf6260, transform=...) at /usr/local/include/simgear/scene/util/SGUpdateVisitor.hxx:162 #10 0x74f0e25a in osg::NodeVisitor::apply(osg::MatrixTransform) () from /usr/local/lib64/libosg.so.68 #11 0x765bdb30 in osg::MatrixTransform::accept(osg::NodeVisitor) () from /usr/local/lib64/libosgViewer.so.68 #12 0x74ec3009 in osg::Group::traverse(osg::NodeVisitor) () from /usr/local/lib64/libosg.so.68 #13 0x76f37234 in osg::Group::accept(osg::NodeVisitor) () from /usr/local/lib64/libosgFX.so.68 #14 0x74ef4847 in osg::LOD::traverse(osg::NodeVisitor) () from /usr/local/lib64/libosg.so.68 #15 0x74ef4f12 in osg::LOD::accept(osg::NodeVisitor) () from /usr/local/lib64/libosg.so.68 #16 0x74ec3009 in osg::Group::traverse(osg::NodeVisitor) () from /usr/local/lib64/libosg.so.68 #17 0x76f37234 in osg::Group::accept(osg::NodeVisitor) () from /usr/local/lib64/libosgFX.so.68 #18 0x74ef4847 in osg::LOD::traverse(osg::NodeVisitor) () from /usr/local/lib64/libosg.so.68 #19 0x74ef4f12 in osg::LOD::accept(osg::NodeVisitor) () from /usr/local/lib64/libosg.so.68 #20 0x74ec3009 in osg::Group::traverse(osg::NodeVisitor) () from /usr/local/lib64/libosg.so.68 #21 0x0043ba36 in traverse (this=0xdf6260, transform=...) at /usr/local/include/osg/NodeVisitor:191 #22 handle_callbacks_and_traverse (this=0xdf6260, transform=...) at /usr/local/include/osgUtil/UpdateVisitor:86 #23 apply (this=0xdf6260, transform=...) at /usr/local/include/osgUtil/UpdateVisitor:57 #24 SGUpdateVisitor::apply (this=0xdf6260, transform=...) at /usr/local/include/simgear/scene/util/SGUpdateVisitor.hxx:162 #25 0x74f0e25a in osg::NodeVisitor::apply(osg::MatrixTransform) () from /usr/local/lib64/libosg.so.68 #26 0x765bdb30 in osg::MatrixTransform::accept(osg::NodeVisitor) () from /usr/local/lib64/libosgViewer.so.68 #27 0x74ec3009 in osg::Group::traverse(osg::NodeVisitor) () from /usr/local/lib64/libosg.so.68 #28 0x0043ba36 in traverse (this=0xdf6260, transform=...) at /usr/local/include/osg/NodeVisitor:191 #29 handle_callbacks_and_traverse (this=0xdf6260, transform=...) at /usr/local/include/osgUtil/UpdateVisitor:86 #30 apply (this=0xdf6260, transform=...) at /usr/local/include/osgUtil/UpdateVisitor:57 #31 SGUpdateVisitor::apply (this=0xdf6260, transform=...) at /usr/local/include/simgear/scene/util/SGUpdateVisitor.hxx:162 #32 0x74f0e28c in osg::NodeVisitor::apply(osg::PositionAttitudeTransform) () from /usr/local/lib64/libosg.so.68 #33 0x74f28ba2 in osg::PositionAttitudeTransform::accept(osg::NodeVisitor) () from /usr/local/lib64/libosg.so.68 #34 0x74f930ea in osg::Switch::traverse(osg::NodeVisitor) () from /usr/local/lib64/libosg.so.68 #35 0x74f940a0 in osg::Switch::accept(osg::NodeVisitor) () from /usr/local/lib64/libosg.so.68 #36 0x74ec3009 in osg::Group::traverse(osg::NodeVisitor) () from /usr/local/lib64/libosg.so.68 #37
Re: [Flightgear-devel] Aircraft model/cockpit rating
On Tue, Nov 30, 2010 at 5:54 PM, Martin Spott martin.sp...@mgras.netwrote: thorsten.i.r...@jyu.fi wrote: What do the numbers mean? = Roughly, anything below 5 means that it isn't really finished and that I think they should be alpha status. 7 and 8 are really nice cockpits, and 9 an 10 usually create a spontaneous 'wow!'. I think the risk of doing harm by rating aircraft and their cockpits after just a quick test is rather high compared to the potential benefit - especially when you're too unfamiliar with some of the respective real-life references. To put in into different words: By assigning too many inappropriate ratings, you're putting the entire effort at the risk of not being taken as seriously as you would expect. If I were you, I'd refrain from posting ratings as 'delicate' as this one. I for one really enjoyed the list and plan to check out some of the more highly rated ones with which I'm not familiar. I can't believe that the ratings will come as a surprise to any aircraft developer, and I hope that their egos aren't so fragile as to be discouraged by a low rating! Tim Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D clouds and precepitation affects.
On Mon, Nov 29, 2010 at 9:39 AM, thorsten.i.r...@jyu.fi wrote: One more observation. Yesterday I was doing tweaks to the spin related functions in my model and during spin tests I noticed that I get the same affect when I am in a spin only the clouds are rotating about a vertical axis ... Yes - same reason - rapid change of the orientation of the view axis. The problem is generic: a real cloud is a 3-d distribution of droplets, i.e. for rendering purposes a function f(x,y,z) of opaqueness where projections like \int f(x,y,z) dz = c(x,y) determine the appearance of the cloud as seen from the z-direction. I don't quite know if one could render that in real time if enough interpolation is used (I'm no 3d rendering expert), but even coming up with a physically correct f(x,y,z) which projects in all directions into something like a cloud is a pretty hard task. The current state of the art in cloud rendering does treat the cloud as some kind of 3d density function and then renders it using tricks that more-or-less emulate ray-tracing. Such a system would require a lot of work to implement in fgfs (GSoC project?) The advantage of the current system is that it looks pretty good and doesn't need very powerful graphics hardware. So we have to fake it by using texture sheets projected onto something, and then there is always some situation in which the nature of the fake is apparent. I can given you clouds which look more or less realistic in level flight and normal airplane operation (by using rather high-resolution cloud images as done now) - but they rotate in an odd way when you do aerobatics. An alternative might be to use non-rotating crosses -- like the trees -- for the cloud blobs. The problem is that the blending between the blobs becomes even trickier than what we have now. I can give you static cloud sheets which look great from far below or high above - but they look unrealistically flat when level with them (doesn't work for convective clouds though - I did some of the Cirrus sheets that way). I can give you clouds which are stable against the rotations you observe in aerobatics - but they behave in an odd way when you are close to them. I can give you clouds which are stable against aerobatics and have the right behaviour when you are close to them and look straight - but when you look out of the side window or take an external view they look odd. The problem isn't going to go away - you simply can't make a 2d sheet appear like a 3d object without the 2d nature being revealed somewhere, in some situation - it's like asking from a stage magician that you should be allowed to sit and observe behind the stage as well - if you want something which looks always and everywhere like a genuine 3d object, you need a genuine 3d object. All you can do is decide where you want the problem to be. And I guess that having clouds which are stable against an airplane flying through them are more desirable as clouds which look good from a spin... But you could simply edit the cloud shaders to insert the relative position vector to the object as the reference vector for the transform rather than the view axis just to see if you like that better - it's one line to edit I think. Stacking many 2d illusions into a 3d volume is a step towards a genuine 3d object, and Tim appears to think it can be done I've been looking at the clouds code again recently, which is oddly slow on my monster machine (Phenom II x6, GTX 460) . It has the same problem that the trees code did before a big makeover: it uses instancing techniques on geometry (flat quads) that is to far simple to be treated as an instance. It would be much better to take the same approach we do in trees and treat a cloud as a list of quad or triangle polygons. The messy part is the distance sorting that is not optional for the cloud sprites. (I have no real idea as to what all this means... since I am not a 3d rendering expert). All I'm saying is that the current implementation could be improved and that we seem to have headroom for more cloud blobs per cloud. But then you run into a different problem - right now, the cloud code doesn't need to know any convective physics, because the cloud texture is a photograph and has all the information where a cloud looks how. If you break that and build the whole shape from 200 different elements, you need to input the whole information about where the texture should look how yourself, i.e. to get the same visual quality, the code to place the texture elements must have some rough idea about convection. There's no free lunch... Either that or create the clouds statically in a modeling program. So, I guess rather than more information where the current cloud schemes fail (which I at least know, I've spent 3 months with dreaming up and testing schemes adn trying to come up with workarounds), an opinion where you
Re: [Flightgear-devel] 3D clouds and precepitation affects.
While the unrealistic behaviour in loops can't really be cured, it could be lessened by doing what nature does - using more cloudlets with less features (up-down distinction) and build cloud structure not by texture but by positioning selected cloudlets with better control. That would need a factor of maybe 20-100 more cloudlets per cloud. This is probably right on. With the resources of a current PC in the Flightgear environment, you can have 5000-1 cloudlets, i.e. you'd be limited to 50 Cumulus clouds in the sky or so. I concluded that under these circumstances, fixing the aerobatics problem is not worth pursuing. You can experiment with building clouds that way - the local weather menu point has a 'cloudbox' entry, that is designed to build such many-cloudlet clouds (you may have to edit a bit of you want different textures). I've been looking at the clouds code again recently, which is oddly slow on my monster machine (Phenom II x6, GTX 460) . It has the same problem that the trees code did before a big makeover: it uses instancing techniques on geometry (flat quads) that is to far simple to be treated as an instance. It would be much better to take the same approach we do in trees and treat a cloud as a list of quad or triangle polygons. The messy part is the distance sorting that is not optional for the cloud sprites. It would be nice to have a GPU-based particle system that did the clouds, smoke, etc., but we don't yet. I have cooked up also schemes with static (non-rotated models) clouds - these would have none of the above problems, but the trouble is that Flightgear (OSG?) doesn't display a stack of multiple semi-transparent surfaces correctly if they are not exactly parallel - so these schemes don't work. This is more of an OpenGL / graphics hardware problem. There are schemes to do order-independent transparency, but it's hard to see the benefits of rewriting the entire renderer to take advantage of them. So unless Cheers, * Thorsten -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ProFlightSimulator The Most Realistic
What a marketing opportunity! Tim On Sat, Nov 27, 2010 at 9:47 AM, Frederic Bouvier fredfgf...@free.frwrote: By the way, look what I received in my inbox : Support Requests item #3117965, was opened at 2010-11-24 20:24 Message generated for change (Tracker Item Submitted) made by gwself You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=510694aid=3117965group_id=65363 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Install Problem (example) Group: None Status: Open Priority: 5 Private: No Submitted By: greg self (gwself) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to launch Initial Comment: The proflightsimulator launch control does not launch pro flight -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance change?
On Sat, Nov 27, 2010 at 2:33 PM, thorsten.i.r...@jyu.fi wrote: Can you compare the OSG statistics between the two binaries? Choose cycle onscreen statistics three times. I sure can, but I have no idea what I am looking at when I do that - I basically get a table with numbers which change when I move or change view direction. I'd make screenshots available, except they don't work with multithreading on. What information from the screen do you need? What am I supposed to compare? Cheers, * Thorsten Take a screenshot with one of the system tools. I want to know which traversal -- update, cull, draw, or gpu -- appears to be slower. Tim -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance change?
Can you compare the OSG statistics between the two binaries? Choose cycle onscreen statistics three times. Tim On Fri, Nov 26, 2010 at 5:03 PM, thorsten.i.r...@jyu.fi wrote: I've had just occasion to compare performance of a GIT binary compiled on Nov 24th with a GIT binary compiled Nov 13th in one of my standard benchmark tests (which I described a while ago), and the test confirmed an impression I had yesterday in just test-flying - I've lost almost 1/3 of available framerate. The flags are --enable-fullscreen --geometry=1920x1200 --disable-real-weather-fetch --enable-auto-coordination --timeofday=noon --airport=KINS --aircraft=ufo followed by spawning a cold sector tile and observing framerate upon loading and when fully loaded. Multitherading support is 'Automatic'. With empty sky (in otherwise default condition) I get 180 fps with the Nov 13th binary and 130 fps with the new one. With the cumulus clouds fully spawned, I get 80 fps with the Nov 13th binary and 55 fps with the recent one. Less formal, my impression from yesterday was that I get 20 fps where I used to have 30 which ties in well with the above numbers. The only difference is the binary - fgdata/ and the set of comandline options are completely identical. Am I the only one? Cheers, * Thorsten -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wiki article about GIT: commiting changes wrong?
On Thu, Nov 25, 2010 at 5:31 PM, Heiko Schulz aeitsch...@yahoo.de wrote: Congrats! Will you add the steps you followed to achieve this to the wiki? That's the idea behind a wiki after all ;) I used exactly the same steps like you described in the wiki. My problem was a 503error when requesting the merge. And according to gitorious.orgour repo seems coming more and more to the limits. Quote Marius, gitorious.org: *One thing that would help immensely is to split the repository into several, perhaps using git submodules. I realize this requires some effort on your hand, discussions about reorganizing code can grow into flame wars in large projects - I know :-)* * * Well.. We're aware of the problem. Recent changes to the code have made it more practical to split the aircraft directories into different repositories. I've started this work. Tim -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multithreading pattern and frame rate
Lots of variables. It sounds like you're using up-to-date scenery, so there could have been a change there. New code has also been checked in that deals with paging in the scenery, though I doubt that's causing the problems you are seeing. Can you check out of git the source code from a week ago, compile it, run it, and see if you still see the same performance difference? FPS is not a good performance metric. If you have vsync turned on in your driver, a very tiny change in the time of an operation can make a big fps difference. Also, everyone has different hardware... It's more useful to look at the OSG statistics (choose Cycle On-Screen Statistics twice) and report the times reported for each traversal. Or include a screenshot of them. Did you update anything else, like OSG? Tim On Sat, Nov 20, 2010 at 11:33 AM, fiers...@zonnet.nl wrote: Hi All I rebuilt from GIT this morning. I am sitting on the runway at a quiet airport, doing absolutely nothing. No AI traffic, no other multiplayers around. Global weather. I have no other applications running, except fgrun. And I am waiting until terrasync has updated all it wants to update and the log window is showing no more activity. I have done two tests, directly after eachother. Same conditions, same METAR. Compared to a version of one week ago, there seems to be a different pattern in CPU usage. The older GIT version had one thread 75% busy and two more threads of about 30% busy and a frame rate of a little over 40 FPS. In the version of today, I have one thread 85% busy and one other thread about 20% busy and the frame rate is about 20 FPS. When I take off and during flight, I have one thread 100% busy all the time, where in the previous versions there were only brief moments that one of the threads was running at 100%. I know there has been done some work on caching and loading of 3D elements... perhaps it is related... Has anyone else noticed a difference? m -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS-Release was Scenery tile management and further property heads up...
On Sun, Nov 21, 2010 at 2:58 AM, Scott Hamilton scott.hamil...@popplanet.biz wrote: The important point here is that it has been nearly twelve months since the last major release, the codebase appears to be looking forward, and in the past it has required quite a bit of planning and work to ensure we have a consistent and stable product to release. I'm not sure which changes provoked your initial email. The tile manager change is big, but it addresses longstanding, severe bugs. My property tree hash work was also in response to bugs, and I think we've established that it is not in fact a major change. James' work isn't changing anything yet, as far as I know. Part of that work is first finding a suitable point in time and code to take a snapshot of the code, that includes simgear, flightgear and fgdata. Then I think it would be wise to test that snapshot and fix any of the problems that may be uncovered. But before we can start any of that, we have to make a decision to make a release and set a tentative release date. We are going to make a release branch soon. Tim S. On Sun, 2010-11-21 at 02:25 +0100, Csaba Halász wrote: On Sun, Nov 21, 2010 at 2:09 AM, Heiko Schulz aeitsch...@yahoo.de wrote: Well... * Route manager works here with current GIT, certainly doesn't crash. -Inserting an airport crashes FGFS -choosing a rwy crashes FGFS Not here, it doesn't. * not sure what issues the water shader has with the sun, except for a slight misalignment: http://imagebin.ca/view/SeUwOd.html slight? Very noticeable! Noticeable, but the previous release didn't even have such an effect did it? And it is simply too awesome to not release just because it is slightly, but noticeably, misaligned :) Some shadertypes seems to be immun against fog, which make the whole scenery looks a bit akward: www.hoerbird.net/fgfs-screen-064.png Even more on detailed sceneries like LOWI... Noticed by several people now already... Ahha, I see. That is quite ugly indeed. For me, FGFS is in no worse shape than some previous releases ;) Let's decide the users... For these features, I count myself as an user. Even if some new features don't work perfectly, as long as they are not regressions, I would like to have them. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] property tree heads up
I committed a change that removes the cache from property tree path lookups. This cache causes significant thread safety and other headaches, and my tests show a negligible speedup from the caching. If you notice a big performance hit and you think it might be related to this change, let me know and we'll take a look. Tim -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Hey Curt... :)
There's never been a guarantee that the development sources compile for everybody at all moments. That's why they are development sources. I appreciate the Hudson process and quite often the change to get things compiling on a given platform are obvious, but sometimes they aren't and one needs to rely on the help of those who know the other platforms better. I don't see why they would have get their own copy of the offending source code from anywhere other than the next branch. Tim On Sat, Nov 13, 2010 at 5:57 PM, Alex Perry alex.pe...@ieee.org wrote: On Sat, Nov 13, 2010 at 7:35 AM, Arnt Karlsen a...@c2i.net wrote: On Sat, 13 Nov 2010 09:57:14 +, James wrote in message On 12 Nov 2010, at 23:44, Curtis Olson wrote: My personal rule-of-thumb is to only commit when I've got time to watch the Hudson board go green - it's on an hourly poll at the moment, though we can allow other users to manually kick off builds, if you ask Gene nicely. Ah, sorry to disappoint, but you have to commit to Git first - unlike some setups, we haven't engineered a 'compile before publish' system. Hence my ensuring I have time to watch Hudson *after* a commit, and, for example, make a fix commit if I broke something. ..an idea; a bad commit that doesn't compile successfully, can it be reverted automatically? That way git would stay unbroken, until new unbroken code is added etc and compiles successfully. I like automatic build systems which, if .. * a commit fails to build for any platform, * the prior build passed for every platform, * only one commit happened in that time, * the word CRITICAL is nowhere in the change description, ... automatically rolls back ... and tells someone. As a bonus, if it fails at the third bullet, it can automatically submit builds for all the intervening releases in an attempt to make the bullet pass. As another bonus, after the rollback, the fifth bullet looks back at the first bullet to see whether it failed to build for every platform and, if so, it would be nice for someone to be notified. -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightProSim advert on FaceBook
On Fri, Nov 12, 2010 at 11:38 AM, Mally ma...@tklm.freeserve.co.uk wrote: ?Hi Chris I have reservations about this. It could easily backfire on you personally or turn out to be a traumatic event, particularly if it turns out to be more of a confrontation than a reasonable discussion. What are the odds of the latter do you think? I wouldn't want anyone to go to jail over enforcing the GPL :) I think the same could be achieved (at least partially) by sending the guy individual messages or an agreed collective letter on behalf of all of the FG community, but having said that, I do actually agree that face-to-face can ultimately be the most effective option - but at the same time, with somone who is completely unknown, it is a risk. It's possible of course that the gentleman in question is reading the forum, in which case I would just ask that he take some time to reflect seriously about the ethics of what he is doing, and attempt to find within his better nature the capacity to change the way he is going about this. There's little chance of that. FlightProSim seems to be a scam, though it's not clear who is being scammed. It's not us; after all, we're giving it away, though you might argue that he is besmirching the good name of FlightGear. It's possible some users are getting scammed, but I think the ultimate victims will be the affiliates in the multi-level marketing scheme. This guy has hit on free software as the vehicle for the scam; if not it would be cleaning products, cell phone plans, water filters, matches, whatever. From my viewpoint, it is not about giving a bit back. The main issues for me are that potential purchasers should be able to make a fully informed choice, that they should know completely what they are buying, and that he should comply fully with the GPL, i.e. by charging a fee ONLY for the physical act of transferring a copy of FG and optionally for a warranty if he wants to provide the same. If he did this and made it clear that this was That language from the GPL refers only to the act of supplying the source code. There used to be a time when the only practical way to get a copy of the emacs source was on 9 track tape, so the costs could be considerable. The GPL says nothing at all about the permitted price of the object code or any derived product. There is an idea that, because the cost of the source code is free (or nearly so), the value of a complete product or distribution is close to zero. This is patently false; you just have to look at all the questions that people ask about building fgfs from scratch, and all the effort that has gone into making this process automatic, to see that a pre-built package has a lot of value. Not to mention the value of a real professional version of fgfs... what he was doing in his main web page/advertising, i.e. clearly informing potential purchasers that they were paying for these services rather than buying a product, then I would be very happy to see him succeed in his venture, and I'm sure he would be providing a valuable service. In the case of FlightProSim, there is probably very little there that cannot be obtained for free. But that's not a GPL violation, nor is it illegal; it's the very essence of capitalism :) Tim Mally - Original Message - From: Chris Wilkinson blobster...@yahoo.com.au To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Friday, November 12, 2010 5:59 AM Subject: Re: [Flightgear-devel] FlightProSim advert on FaceBook This looks to be more of a moral issue than a legal one. I'll tell you what I'll do about this. I was born and raised in Christchurch, where this guy operates from, and I will be visiting the city in a months time. Perhaps I should pay the guy a visit? I wanna know where this guy gets off taking all YOUR hard work, and PROFITING from it, with NOTHING returned to the flightgear community. The legality of his actions could be debated in a court of law forever, but perhaps a bit of face time to directly express the sentiments of the flightgear community with the dude might convince him that there are REAL people who consider his actions immoral - you guys are more than just names attached to code commits on the internet, and I think this guy needs to be reminded that without your efforts his little endeavour would amount to NOTHING. I'm sure with some 'friendly persuasion' I can convince the guy to give a bit back. After all if he can help the efforts to improve flightgear, that will have a flow-on effect for him. He scratch our back, we scratch his... Regards, Chris Wilkinson, YBBN/BNE. - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1153 / Virus Database: 424/3251 - Release Date: 11/11/10 -- Centralized Desktop Delivery: Dell and VMware Reference Architecture
Re: [Flightgear-devel] FlightProSim advert on FaceBook
On Fri, Nov 12, 2010 at 12:45 PM, Chris Wilkinson blobster...@yahoo.com.auwrote: My goal will be open dialog as to why this guy seems unwilling to honor the exacting word of the GPL, and why he isn't giving back to the community. Probably done over coffee. I'll probably smile. And my solemn promise is that I wont hurt him (much)... :-) I thought someone had paid the money and determined that they did follow the letter of the GPL: you could download it and build it with a great deal of effort. Frankly this guy is a big part of the reason I have yet to commit my scenery and aircraft to the community. I do NOT want someone making money from my efforts without either my consent or without some form of input to the community as a condition of being allowed to profit from all your work. Failing a positive outcome there I support a re-licensing of the software, to prevent this kind of thing. Simple as that. That would be difficult for the code. I wouldn't agree to relicense my contributions made under the LGPL. That might not be a show-stopper, but I don't think I'm the only one who feels that way. I'm not sure what I'd do if the modelers and scenery guys managed to put everything under a different license. On the one hand, I suspect that a lot of models are not really GPL compliant now, as we don't store .blend files, .tiff files, etc. in the data repository. On the other hand, if all the content switched to a non-commercial license I would quickly lose interest. Tim Regards, Chris Wilkinson, YBBN/BNE. -- *From:* Mally ma...@tklm.freeserve.co.uk *To:* FlightGear developers discussions flightgear-devel@lists.sourceforge.net *Sent:* Fri, 12 November, 2010 8:38:08 PM *Subject:* Re: [Flightgear-devel] FlightProSim advert on FaceBook ?Hi Chris I have reservations about this. It could easily backfire on you personally or turn out to be a traumatic event, particularly if it turns out to be more of a confrontation than a reasonable discussion. What are the odds of the latter do you think? I think the same could be achieved (at least partially) by sending the guy individual messages or an agreed collective letter on behalf of all of the FG community, but having said that, I do actually agree that face-to-face can ultimately be the most effective option - but at the same time, with somone who is completely unknown, it is a risk. It's possible of course that the gentleman in question is reading the forum, in which case I would just ask that he take some time to reflect seriously about the ethics of what he is doing, and attempt to find within his better nature the capacity to change the way he is going about this. From my viewpoint, it is not about giving a bit back. The main issues for me are that potential purchasers should be able to make a fully informed choice, that they should know completely what they are buying, and that he should comply fully with the GPL, i.e. by charging a fee ONLY for the physical act of transferring a copy of FG and optionally for a warranty if he wants to provide the same. If he did this and made it clear that this was what he was doing in his main web page/advertising, i.e. clearly informing potential purchasers that they were paying for these services rather than buying a product, then I would be very happy to see him succeed in his venture, and I'm sure he would be providing a valuable service. Mally - Original Message - From: Chris Wilkinson blobster...@yahoo.com.au To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Friday, November 12, 2010 5:59 AM Subject: Re: [Flightgear-devel] FlightProSim advert on FaceBook This looks to be more of a moral issue than a legal one. I'll tell you what I'll do about this. I was born and raised in Christchurch, where this guy operates from, and I will be visiting the city in a months time. Perhaps I should pay the guy a visit? I wanna know where this guy gets off taking all YOUR hard work, and PROFITING from it, with NOTHING returned to the flightgear community. The legality of his actions could be debated in a court of law forever, but perhaps a bit of face time to directly express the sentiments of the flightgear community with the dude might convince him that there are REAL people who consider his actions immoral - you guys are more than just names attached to code commits on the internet, and I think this guy needs to be reminded that without your efforts his little endeavour would amount to NOTHING. I'm sure with some 'friendly persuasion' I can convince the guy to give a bit back. After all if he can help the efforts to improve flightgear, that will have a flow-on effect for him. He scratch our back, we scratch his... Regards, Chris Wilkinson, YBBN/BNE. - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1153 / Virus Database:
Re: [Flightgear-devel] Global Coordinate System
On Thu, Nov 11, 2010 at 9:14 AM, Paul Guhl ad...@simtechnologies.de wrote: Hello! I'm a hobby programmer and work on a flight simulation project as well and would like to ask probably a trivial question: Lets the global origin of the coordinate system be at 0deg lat and 0deg lon. While moving an aircraft within 100km off the global origin, the movement and camera rotation / position work smooth. When moving further away the transformations start to jitter increasingly, transformations are less exact. The problem is most probably rooted in rounding error. Solution for this problem is the switch to the local coordinate system. My question is: how the local/global coordinates are managed in FlightGear? The short answer is: use double precision and forget about the problem. This isn't the whole story, of course, because you can't pass doubles to OpenGL and expect sensible results or good performance, even on the latest, fanciest hardware. So, we rely on Open Scene Graph to manage this for us. The geometry for a scenery tile (tiles are about 14km on a side) is stored in single precision relative to the tile center. Above that we place an OSG MatrixTransform which stores the geocentric position in double precision. The eyepoint is also stored in a double. When OSG renders the scene, it creates a single precision ModelView matrix for each drawable. In the context of earthly rendering you can count on being able to use floats to position anything visible. Where in the code i could reivew your solution? Nowhere and everywhere. Before fg switched to Open Scene Graph there was a lot of code to deal with this. How do you solve the momentum of entering critical distances of the local coordinate system, ergo moving local coordinate system to get the aircraft back again within the limits of the local coordinate system? I'm not sure if you're referring to the same issue here. Tim -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather: Clouds redrawn
On Thu, Nov 11, 2010 at 6:16 PM, Arnt Karlsen a...@c2i.net wrote: On Thu, 11 Nov 2010 07:58:08 +0100, fiers...@zonnet.nl wrote in message 4cdb9400.1090...@zonnet.nl: I limited the frame rate to 30, used a smaller window. No difference. ..any change when you play with X Window frame rates and X desktop size? _They_ are still drawn at your full X Window xorg.conf Modeline controlled speeds, even when you play with FG frame rates and FG window sizes, and both X and FG are drawn by the same iron. Also check that you use the same color space for these 2. Uh, what? Tim -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance and multiple GPU?
This mirrors comments to the OSG mailing list, where people have reported performance issues with multiple GPUs and screens. There hasn't been much of a resolution there; some people have the problem, others don't. I've put together a multi-GPU machine to explore these issues; now I just need to buy another screen :) What threading mode are using? Could you post a screenshot of the OSG statistics (cycle debug statistics twice) and your X configuration file? Tim On Mon, Nov 1, 2010 at 9:06 AM, Torsten Dreyer tors...@t3r.de wrote: Hi, as pointed out in other threads, I am currently assembling a machine with five nVidia cards. The machine and the cards are fast enough to render a steady 60fps, synced to vblank. But this is only with shaders disabled. The moment, I enable shaders and 3d- clouds, the frame rate drops to 20fps and sometimes even less. This does not happen when I limit the display to just one single GPU. One GPU with dual screen (TwinView) runs at framerates beyond limits even with all shaders on and quality level to highest. The moment I add a second card to the setup, it slows down significantly. I know that shaders are little program fragments running on the GPU itself. Now, what happens, if a shader effect spawns multiple GPU's, e.g. a cloud which is visible across the entire window? Cheers, Torsten -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Material shader problem?
I'll take a look. It could be that the default shaders are using constructs that aren't supported on older hardware, or provoke bugs there, or are buggy themselves in ways that don't show up on post G80 hardware. Tim On Sat, Oct 30, 2010 at 9:50 PM, Martin Spott martin.sp...@mgras.netwrote: D-NXKT wrote: All model faces that are orientated to the sun are white. Oooh, this sounds very familiar :-) SimGear, FlightGear and Base Package pulled from current GIT, Xorg server 1.7.7 and Nvidia driver 260.19.12 on Linux-2.6.36/AMD64 (Debian Squeeze). Graphics card is a is a 7100GS, which probably has limited shader capabilities: # ~ fgfs --prop:/sim/rendering/shader-effects=true results in: http://foxtrot.mgras.net/static/fgfs-white.png Anyone interested in details ? Output of 'glxinfo' is available here: http://foxtrot.mgras.net/static/glxinfo.log.gz Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Compiler error
On Thu, Oct 7, 2010 at 5:12 PM, fiers...@zonnet.nl wrote: I used OSG version 2.9.10. The error probably has something to do with a recent change, because yesterday's compilation was fine. I guess I could roll back to an older version of OSG, like you suggested, but I was rather hoping my message would ring a bell with someone that committed a change between yesterday and today. Am I missing the point? Sort of. The problem is due to a change in OSG between yesterday and today. Tim m Op 07-10-10 16:19, willie schreef: On 07/10/10 14:09, fiers...@zonnet.nl wrote: Hi all, I am compiling fgfs with download_and_compile.sh on Ubuntu 10.04. Latest GIT (one hour ago) is giving errors in hud.cxx: hud.cxx: In function ‘void fgUpdateHUDVirtual(osg::State*)’: hud.cxx:348: error: ‘gluPerspective’ was not declared in this scope hud.cxx:361: error: ‘gluLookAt’ was not declared in this scope hud.cxx: In function ‘void fgUpdateHUD(osg::State*, GLfloat, GLfloat, GLfloat, GLfloat)’: hud.cxx:397: error: ‘gluOrtho2D’ was not declared in this scope please check the version of OpenSceneGraph you are using. /bin/osgversion in your OSG install dir I think that script is slightly flawed in that it grabs the SVN version of OSG which may have been correct when the script was written but not now. Download a stable version of OSG (2.9.8 works for me) and try again, please. Let us know how it goes. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Disappearing scenery
On Sun, Sep 19, 2010 at 4:40 PM, ThorstenB bre...@gmail.com wrote: Hi, good news - I've done more debugging in the tile cache module and think I already found something... I'm seeing two issues with the tile cache, sometimes causing active scenery to be kicked when the cache is full - and this results in the missing patches. I'm also seeing cases where all active scenery tiles are dropped. This can also happen when cycling through the tower view - so this doesn't always help. Both issues are timestamp related (maybe depend on frame rate, system load, slow USB disks :-) or so...). * First problem is that the tiles' timestamps are only updated when the tiles are freshly loaded from disk or they are actively displayed (some magic osg CullCallback does that - haven't fully understood this yet). So when a tile belonging to the current position was not The cull callback is called from OSG's culling traversal. If OSG determines that an object's bounding sphere intersects the viewing frustum, it calls the cull callback -- if there is one -- to traverse that object and perform finer grain culling. If there is no cull callback, OSG does the traversal itself. Anyway, it's a good way to perform an action when an object is in view. displayed for a while, its timestamp is old. When the view then moves or teleports into a new position, and then back to the original position, the same tiles get scheduled again - but are still found in the cache. Since their timestamps remain old, they are kicked from the cache soon afterwards, when more tiles are loaded. This is what causes the random scenery tiles disappear effect... = I'm testing a fix now, which updates a tile's timestamp whenever it is scheduled to be loaded, but then found in the cache. That sounds correct. * The second issue is about the timestamps updated through this magic osg CullCallback. These timestamps can be newer than the current time used by the cache module for loading new tiles (seems to be a frame ahead or so). When a new set of tiles is scheduled to be loaded, and the cache is already filled with many future timestamp tiles, then the new tiles immediately kick each other from the cache (are never really loaded). When this happens, all scenery for a new position is lost (complete whiteout)... The timestamp used by the cull callback comes right from OSG's frame stamp and should be consistent with the tile code. there could be a logic error in the tile cache. Is all the tile cache and osg code single-threaded? If these osg callbacks, the cache management and tile loading were not in the same thread, it would explain where future timestamps could come from (maybe on slow machines only). If it's all single-threaded then I'll have another look to locate this. It is possible for the tile cache code, which runs in the update traversal, and the cull callback to run in different threads. However, they should never run at the same time: the cull traversal starts when the the update traversal has finished, and the next update traversal blocks on the cull and draw traversals. Now, the code that actually loads the tiles -- the database pager -- does run asynchronously. I'll need to check if any of the tile cache code runs in the database pager thread, but don't think any does. Tim Another option I'm already testing is introducing a flag to lock all tiles belonging to the current view position in the cache. The primary condition checked by the cache would then be to never kick tiles belonging to the current position (i.e. current inner or outer ring). Timestamps remain a secondary condition to pick from tiles not belonging to the current position. This would make things a lot more robust than relying on whacky timestamps alone. FG only supports one view position at a time, right? Multiple view positions (e.g. one screen for the tower view and a second screen for the plane) would complicate a locked to cache flag quite a lot... Yes, and that's not really supported by the current architecture, neither by the tile cache nor by osgViewer::Viewer. We would need to move to a CompositeViewer model, which supports several scene graphs, and rely completely on the osg database paging machinery. Tim Maybe someone could comment on the threading issue. I'll do some more testing, and then hope to propose a patch... cheers, Thorsten -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Start uncovering the many advantages of
Re: [Flightgear-devel] Musings on optimizing Nasal code
On Thu, Sep 16, 2010 at 1:28 PM, thorsten.i.r...@jyu.fi wrote: You just discovered that Nasal is 10x slower than C++ code! This is exactly why I prefer core code to end up in C++ in the end. I don't think that's a valid interpretation of my results. Consider the two cases where I achieved a significant performance gain by replacing hard-coded structures with my own Nasal code (range animation, distance_to() method) - you wouldn't conclude from that that Nasal is faster either. I think what I have discovered is that well-designed code runs much faster than merely working code and that there's room for improvement in some places and it's worth looking for that room. Here's a case where your original Nasal code was the better algorithm: it ought to be better to hold the property tree nodes and index them explicitly using getChild() than to create a property tree path string for each child. However, the code that parses property tree paths has been optimized, especially to allocate as little heap storage as possible, so its speed outclasses the Nasal parser. The algorithm being equal, I don't think there's a question that C++ is faster (I doubt the factor 10 though - that seems to be an extreme case). Everything else being equal, I also don't think there's a question that Nasal code is more accessible. And I would base any decision what to hard-code and what not on that balance. Well, just my 2 cents... * Thorsten There's no question that scripting languages are good; fgfs has a lot of Nasal code now. In my profiling I have never seen the nasal interpreter as a hot spot, though I haven't profiled the new weather or some of Vivian's experiments. At some point we might need to get more eyeballs looking at Nasal performance. Tim -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Musings on the range animation
On Sun, Sep 5, 2010 at 6:01 PM, thorsten.i.r...@jyu.fi wrote: Hi Curt, Are you placing your range animation node above each tile or above each object in each tile? One has to work with the tools available - or write one's owns... with range animation I literally mean the xml-tag in the wrapper of a model: There's an existing 3D cloud animation system which has had a lot of optimization work done on it. Have you looked at this at all? What could we do to integrate your work with that system? Tim typerange/type min-m0/min-m max-m31000/max-m /animation Using that tool, you can't organize a scene in subnodes with models spawned from Nasal (or maybe you can and I just don't know how). I suspect that some careful scene graph organization could yield better results than nasal ... I have organized clouds in a quadtree structure I wrote for Nasal and in arrays when I need it for different purposes. For the problem at hand, I want to limit the amount of possible models written into the scenery (which is by far the slowest operation) - so the quadtree doesn't buy me much - in my scheme I have 10 range comparisons per frame (at the expense of not processing everything every frame - which I don't need anyway) - the quadtree would need much more (but would process everything every frame). I tend to use the quadtree representation for things which need to be fast, on a per-frame basis, and the array representation for things which can be slow and be dragged out over many frames. The quadtree isn't so good to solve slow problems - which, surprisingly, exist in rendering :-) * Thorsten -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders heads up
There needs to be some coordinate for the fog. You could try using gl_FogFragCoord instead. Tim On Wed, Aug 25, 2010 at 1:00 AM, HB-GRAL flightg...@sablonier.ch wrote: Am 24.08.10 23:58, schrieb HB-GRAL: Am 24.08.10 23:44, schrieb HB-GRAL: Am 14.08.10 00:20, schrieb Tim Moore: Let me know of any new problems. Tim A new problem is the last line in default.vert: fogCoord = abs(ecPosition.z / ecPosition.w); For what is this needed exactly? It kills the light or light direction here with only default shaders enabled. Really nobody else encountering such problems? I am wondering. I will give my card to a museum once. Thanks, Yves Just to add: I commented this line out and at least terrain seems to work fine. But the question remains, for what is this needed in the hack? It produce a known ATI issue, so I am going from one issue to the next (from gl_FrontFacing to .z/.w). Cheers, Yves Sorry, wrong. It does not work fine, it just breaks the terrain-default shader, and thats why it looks good and I didn’t see the new problem ;-) - Yves -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] shaders heads up
I've checked in some changes to the shaders in attempt to fix bugs on some platforms and generally optimize them. I've eliminated the use of gl_FrontFacing, which seems to give us problems on certain Macintosh platforms. I've also reworked the way material animations are handled. Let me know of any new problems. Tim -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Curved screens
On Thu, Aug 12, 2010 at 5:03 AM, John Wojnaroski cas...@mminternet.comwrote: There is a program called Nthusim ( http://nthusim.com ) that will warp an MS windows screen for projection onto a curved surface. Is there any such capability in OSG? If not, any thoughts on adding the function to FlighrGear or OSG that would work with X windows under Linux. OSG has built-in support for some specific displays e.g. domes with a fisheye lens and some eLumens displays. If you wanted to take this further you could use that existing code as an example. Tim JW -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git questions
On Fri, Jul 2, 2010 at 10:21 PM, dave perry skida...@mindspring.com wrote: Thanks Tim, Here's the result: [...@dave-pc fgdata]$ git push origin master fatal: protocol error: expected sha/ref, got ' -- The git:// protocol is read-only. Please use the push url as listed on the repository page. --' Do I need authorization to be able to push changes to fgdata? Yes, you do. Register on gitorious, upload an ssh key, ping me You won't need to download the whole repo again :) Tim On 07/02/2010 11:48 AM, Tim Moore wrote: On Fri, Jul 2, 2010 at 5:43 PM, dave perry skida...@mindspring.comwrote: I am having syntax issues trying to push changes to the git fgdata repository. I have made the edits and git add's, git rm's, git submit, and git status shows my local fgdata master branch clean. But I have not been able to push these changes to the repository. I presume you meant git commit instead of git submit. What is the syntax for this? Can I do this from the two local directories that have changes? Assuming you've committed your changes to your local master branch, then git push origin master will do the trick. If your local branch is no longer up-to-date because someone else has committed something to the repo, then you'll need to merge those changes before you can commit your own, either with git pull origin or git fetch origin; git merge origin/master. Tim Thanks in advance, Dave P. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing listflightgear-de...@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/SimGear (git) segfaults
On Tue, May 25, 2010 at 10:27 PM, Curtis Olson curtol...@gmail.com wrote: Hi Torsten, On Tue, May 25, 2010 at 2:57 PM, Torsten Dreyer wrote: There's no difference between Technique.cxx in the cvs vs. git repositories, The CVS version of flightgear runs fine against the fgdata-git tree. The git version of flightgear crashes. I do observer there are a bunch of shader/effect code differences between simgear-cvs and simgear-git. Could something new in that code be breaking FlightGear? Is anyone else having trouble running the git version of FlightGear? For me, the lates git sources of SimGear+FlightGear run on the current git and latest cvs base, I have. I observe no difference between cvs and git in the data/Shader and data/Effects files - if yours differ, maybe that is the problem? I see quite a few differences in data-cvs/Shaders versus data-git/Shaders, but the Effects directories are identical. My problem is that I cannot run simgear-git + flightgear-git + fgdata-git ... this should be the new default for developers. When I run all the git pieces together I get the segfault I reported. The segfault also happens when I run the git compiled code with data-cvs. The problem does not happen when I run the CVS compiled code. If I am the only one seeing this problem, then it must be something on my end. I thought my system was pretty main stream and pretty current ... hmmm Tim: is there a way to check out a version of the git code that represents the first conversion/import of the cvs repository before any subsequent changes were made? I'm still a git-novice. There's a last-cvs tag in each of the repos. If you want to get the code that was the last thing from cvs, then git checkout last-cvs. Tim Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] Fix fgviewer segfault
On Sat, May 22, 2010 at 10:30 PM, Jeff Taylor jefftaylo...@gmail.comwrote:
Hello,
fgviewer crashes when reading channel options (which it doesn't use).
Here is a patch which fixes this by adding a pointer check.
This is my first ever patch to any open source project, so feedback
would be appreciated. :)
I've committed this; thanks for the patch. There's not much to say about
the code in the patch, but I do have some advice about the comments. It's
almost never necessary to justify a null pointer check, so the comment there
is redundant. The comment is actually a justification for why we should
accept the patch; as such, it belongs in the commit message i.e., the body
of your email.
The second comment about the return value not being checked is not relevant
at all in this function and is quite likely to be made obsolete. I replaced
it with an XXX style comment in the caller of add_channel as a reminder to
look into this.
Tim
Jeff Taylor
---
src/Main/options.cxx |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/Main/options.cxx b/src/Main/options.cxx
index bededfb..0132c02 100644
--- a/src/Main/options.cxx
+++ b/src/Main/options.cxx
@@ -530,6 +530,14 @@ parse_fov( const string arg ) {
static bool
add_channel( const string type, const string channel_str ) {
+// This check is neccessary to prevent fgviewer from segfaulting when
given
+// weird options. (It doesn't run the full initailization)
+if(globals-get_channel_options_list() == NULL)
+{
+SG_LOG(SG_GENERAL, SG_ALERT, Option type =
channel_str
+ ignored.);
+return false; // This isn't checked for, but it shouldn't matter
+}
SG_LOG(SG_GENERAL, SG_INFO, Channel string = channel_str );
globals-get_channel_options_list()-push_back( type + , +
channel_str );
return true;
--
1.7.0.1
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Developers
On Fri, May 21, 2010 at 3:32 AM, Peter Morgan p...@freeflightsim.orgwrote: Its is/was bit of a dark how to get commit permission to FG and its seems to be one Curt in control. Can someone explain to process to submitting patches to this new git scenario, or are we to be held in the grey area of hopefulnes as well ? eg I'd like to submit a patch for the 787 that actually makes it boot up! I encourage people to submit patches either to the mailing list -- using git format-patch -- or through the merge request process on gitorious. By the way, I merged two of Anders' merge requests today. I did this because they seem to be well isolated and I trust Anders not to screw things up, but in general I will not be handling merge requests in fgdata because I'm simply not qualified to vet random changes to aircraft. I encourage people who have commit rights to fgdata to review merge requests and merge them; I'll be happy to help with the git mechanics. Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Flightgear git repositories (was Re: GIT or CVS - Confusion)
The Git source repositories for Simgear, Flightgear, and the data repositories are now fully enabled at gitorious.org. A group of developers and modelers have been making checkins for some days now and all appears to be working. The repositories are available at: http://gitorious.org/fg. http://wiki.flightgear.org/index.php/FlightGear_and_Git is filled with good information on how to get started with Git, and this will be updated over the coming days. If you are a developer or modeler and had commit access to the CVS repository, please register at gitorious.org, upload an SSH key, and send me a message, either on gitorious or to timoore33 at gmail.com. I will then add you to the collaborators list. The flightgear and simgear repositories are mirrors that I've maintained for about a year-and-a-half. They are not strict mirrors of the old CVS repo because the commit history was different, but the bits are all the same. These repositories contain history going back to 1997, which I believe was the start date of the project. The fgdata repository is a copy of the repository at git://mapserver.flightgear.org/fgdata, plus a couple of commits to get the data back in sync with the last known CVS state. A big thanks goes out to Martin Spott for maintaining this, and for supplying me with an up-to-date CVS checkout! One major difference between Git and CVS is that the entire history is stored locally. This isn't a big deal for the source code repos, but the history for fgdata is quite large, over 2.5Gig. If this is a problem for you, look into the git technique of making a shalllow clone, which doesn't download the history. You won't be able to make check-ins if you do this. If you already have a local clone of the mapserver.flightgear.org fgdata repository, you can add the gitorious.org repo as a remote to it and then fetch. This will be quite fast because the vast majority of the history is shared between the two. If you have any questions, feel free to ask here or drop by irc.flightgear.org. Tim On Wed, May 12, 2010 at 11:10 PM, Martin Spott martin.sp...@mgras.netwrote: Heiko Schulz wrote: So the next question is: As far as I can tell, details are being arranged after the repositories have been migrated properly - which, obviously, is the most relevant step now. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] landmass geometry shader rewrite
On Fri, Apr 23, 2010 at 11:14 AM, Erik Hofman e...@ehofman.com wrote: Tim Moore wrote: Looks like the same attribute problem. What hardware? NVidia 9600GT/512Mb on AMD X2 250 wn 2Gb memory. I've eliminated some varying parameters from the landmass vertex and geometry shaders. Please give it a try and see if it works better. Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] landmass geometry shader rewrite
On Fri, Apr 23, 2010 at 10:46 AM, Erik Hofman e...@ehofman.com wrote: Tim Moore wrote: Hi, I hacked on the landmass geometry shader a bit. On my machine I got the frame rate to improve from 14 fps to 52 fps using the ufo at ksfo. This technique may be promising, although it could certainly stand some new textures. Anyone playing with geometry shaders in the terrain (and also models) should follow the example of landmass-g.vert and landmass.geom. Let me know if I broke anything in the graphical appearance, or if any OpenGL problems are introduced. After this change I get te following in all quality levels: glLinkProgram FAILED Program infolog: Fragment info - (61) : warning C7050: ds might be used before being initialized (61) : warning C7050: dp might be used before being initialized (63) : warning C7050: d might be used before being initialized Link info - Vertex attribute output count exceeds hardware limits. Program's vertex attrib binding 7, binormal Program's vertex attrib binding 15, normal Program's vertex attrib binding 6, tangent Before this change I did have proper landmass shaders with the quality level set above 3.5, now I don't get proper shader in any level (dark green untextured landmass). Erik Looks like the same attribute problem. What hardware? Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Enable headtracking in FlightGear?
On Thu, Apr 22, 2010 at 10:34 AM, wjp.vri...@quicknet.nl wrote: Hello FlightGear developers, In the FlightGear forum I stumbled upon a request from users, to enable head tracking in FlightGear (head tracking that is i.e. provided by Freetrack or TrackIR). Until now, I found no evidence that someone has embraced this request, so I would like to jump in... As you may know, the mentioned 'head trackers' have one great disadvantage: they require the user to wear a hat (or something similar) with Infrared LED's attached to it, to enable tracking. Recently I have made a head tracking program, based on the FaceAPI from SeeingMachines, which ONLY requires a simple web cam. By now, we only support the Freetrack-protocol (which is open-source) and are seriously testing it with ArmA 2 (actually, the first attempt gives really promising results). ... P.S.: The FaceAPI version I use, requires the software to be 'open source' (i.e. non-commercial). I am planning on publishing FaceTrackNoIR eventually, when beta-testing is done... Not to start a big flame, but their non-commercial terms are the complete opposite of open source. Also, in general, open source does not mean non-commercial. Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] landmass geometry shader rewrite
Hi, I hacked on the landmass geometry shader a bit. On my machine I got the frame rate to improve from 14 fps to 52 fps using the ufo at ksfo. This technique may be promising, although it could certainly stand some new textures. Anyone playing with geometry shaders in the terrain (and also models) should follow the example of landmass-g.vert and landmass.geom. Let me know if I broke anything in the graphical appearance, or if any OpenGL problems are introduced. Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Effects on OSX
On Thu, Apr 22, 2010 at 8:47 PM, HB-GRAL flightg...@sablonier.ch wrote: HB-GRAL schrieb: Frederic Bouvier schrieb: This is an OSG warning. Unfortunately, polygons were forgotten by the people who wrote the tangent space generator. I posted something about it on the OSG list but got no response. If we want to make it disappear, I presume we'll have to do it ourself -Fred Just to add a note about performance vs. quality: All effects activated and quality = 4.0 ERROR: Implementation limit of 40 varying components exceeded, linked shaders use 4 too many varying component(s). -Y. Ooops. Sorry, looks like this comes from todays landmass files from Tim. What platform. I was wondering if there were too many interpolated parameters. I can see how to eliminate 3 (the binormal); gotta think hard about the fourth :) Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Effects on OSX
On Wed, Apr 21, 2010 at 11:06 PM, Frederic Bouvier fredfgf...@free.frwrote: - Martin Spott a écrit : HB-GRAL wrote: BTW: Warning: TangentSpaceGenerator: unknown primitive mode 9 does not go away (from all this bumpspec.eff) but I guess this is not related to my card. Is it? I'm getting tons of this all the time with an NVidia driver on Linux/AMD64. I suspect the people involved are aware of it (since it's already been mentioned here) and it doesn't hurt - so I didn't complain ;-) This is an OSG warning. Unfortunately, polygons were forgotten by the people who wrote the tangent space generator. I posted something about it on the OSG list but got no response. If we want to make it disappear, I presume we'll have to do it ourself It would be best to get the polygons out of the loaded geometry. The INDEX_MESH optimizer that was recently added to OSG will do this. Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gnu linker question (don't optimize unused variables)
On Thu, Apr 15, 2010 at 10:59 PM, Torsten Dreyer tors...@t3r.de wrote:
Hi,
this is a question for the gnu linker geek:
I am trying to add gnucap to FlightGear as posted before. It compiles
cleanly
and links fine, but there is one issue. Gnucap uses commands which are
implemented in separate files. These commands get registered into a global
command registry. Here is a code snipped for the clear command:
class CMD_CLEAR : public CMD {
public:
void do_it(CS, CARD_LIST* Scope) {
// .. do something fancy here
}
} p0;
DISPATCHERCMD::INSTALL d0(command_dispatcher, clear, p0);
The class CMD_CLEAR implements the CMD interface which requires the do_it()
function.
The DISPATCHER template contains a INSTALL class, it's constructor performs
the registration into the registry. In theory, when the INSTALL class is
instantiated as d0, the actions in the constructor are performed.
Unfortunately, this does not happen when linked against FlightGear.
I tried to rename d0 into something more uniqe and grep'ed the created
object
and library for the variable which were found there, but not in the fgfs
executable. This lead me to the conclusion, that the linker optimizes the
unused variable from the executable.
It's not optimizing the variable, it's optimizing the entire .o file out of
the linkage, as nothing external is explicitly using any of the symbols in
the .o. This is a major weakness of the registration pattern when statically
linking.
Is there any magic switch to pass to the g++ linker telling him not to
optimize unused variables, preferably for a certain set of files or a
single
library?
No. Either build gnucap as a shared library or add some dummy references to
symbols in the file(s) that are referenced, perhaps indirectly, by code
outside of the library.
Tim
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New reelase(?) (Was: User selectable quality level for effects)
The major objective of having a master branch in my gitoreous repo is to make the release process less onerous from the source code point of view. Master is lagging a bit behind CVS at the moment, but that is actually part of the plan. It seems like preparing the data tree for a release is still an all-weekend affair... Tim On Mon, Apr 12, 2010 at 8:14 AM, Durk Talsma d.tal...@xs4all.nl wrote: On Monday 12 April 2010 04:19:55 am Pete Morgan wrote: DO NOT WAKE up the webmaster and BFDL. One release A year MUCH MORE than enough, decided upon At WILL and RELEASED AT WILL by ME FYI, I am currently FlightGear's release manager. Last year, there's been an approximate 2-3 month lead-up period for the new release, including intense communication between approximately 5-8 people directly involved in the build process. This resulted in 4 release candidates, and many, many last minute bug-fixes before we finally decided that the simulator was good enough. As much as we would like to d more frequent releases, lack of man power has been a serious issue holding us back most of the time. Apparently, since you are not satisfied with the procedure, I am open to your motivated suggestions as to how the procedure can be improved. :-) Cheers, Durk -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] English Electric Lightning no longer runs
Alan, What graphics hardware are you running on? Turning off shaders should get you going for the moment. Then we'll figure out how to conditionalize the shader code for drivers that don't support gl_FrontFacing. Tim On Thu, Mar 25, 2010 at 4:33 PM, Alan Teeder ajtee...@v-twin.org.uk wrote: I have rolled CVS back to 1 Feb, except for SGClipGroup.cxx and .hxx. These are the current ones to match with the SVN Osg. I have not rolled back Flightgear data as this takes for ever. Unfortunately Flightgear still crashes when I open up the Lightning´s engines. Perhaps the fault is within Osg. Alan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Linker problems
On Thu, Mar 25, 2010 at 8:58 PM, Roland Haeder r.hae...@gmx.de wrote: Not yet solved: libMain.a(main.o): In function `osg::Referenced::unref() const': /usr/local/include/osg/Referenced:194: undefined reference to `osg::Referenced::signalObserversAndDelete(bool, bool, bool) const' And many more of them. OSG is checked out from tag 2.9.7: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.9.7 Please assist. :) It looks like your OSG libraries are out of sync with your header files. You might need to run ldconfig. Tim Roland On Tue, 2010-03-09 at 19:57 +0100, Roland Haeder wrote: Hi all, I still have linker problems. I use the following compiler and linker: - GCC 4.4.3-3 (Debian Unstable) - GNU ld (GNU Binutils for Debian) 2.20 I still got tons of these messages: --- libMain.a(main.o): In function `osg::Referenced::unref() const': /usr/local/include/osg/Referenced:194: undefined reference to `osg::Referenced::signalObserversAndDelete(bool, bool, bool) const' --- OSG is 2.9.7 can compiles without errors (no special options specified). SimGear is recent CVS (updated some minutes ago) and compiles: ./configure --with-jpeg-factory --prefix=/opt/ --with-osg=/usr/local FlightGear is also updated some minutes ago and compiles but does not link. ./configure --with-osg=/usr/local --with-eventinput --with-logging --enable-osgviewer --enable-sp-fdms --prefix=/opt/ --datarootdir=/home/quix0r/fgfs/fgfs-base/data/ I use these special environment variables: -- declare -x CC=ccache gcc declare -x CXX=ccache g++ declare -x CXXFLAGS=-g -O0 -- As I found out with the help from Jester (strace), the linker seems to take the right lib but cannot link it. I already tried GCC 4.3.x but doesn't help. :( Please help me here. :) Regards, Roland [spam killed... :(] -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Linker problems
On Thu, Mar 25, 2010 at 9:56 PM, Roland Haeder r.hae...@gmx.de wrote: Hi Tim, It looks like your OSG libraries are out of sync with your header files. You might need to run ldconfig. Tim here is the full output of ldconfig -v: http://www.pastebin.org/123487 But it still outputs the same messages. :( Your ldconfig output shows that your libraries are all from OSG 2.8.2... but the error message suggests that your headers are from OSG SVN. Tim Roland -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
On Wed, Mar 24, 2010 at 2:53 PM, Gene Buckle ge...@deltasoft.com wrote: On Wed, 24 Mar 2010, Martin Spott wrote: Gene Buckle wrote: On Wed, 24 Mar 2010, Frederic Bouvier wrote: Fred is that only in the CVS or also in 2.0. All working? This code is in 2.0.0. But as far as I know, the scenery tools are not ready, and can't generate airports from that format WED (World Editor) from X-Plane can. :) Please explain - do you mean WED can generate airports for FlightGear ? As far as I can tell, the airports that you create with WED are written out using the current apt.dat file format. I seem to recall that it's also an open source tool. g. I think the point is that the tools that build BTG files don't use the new format. Tim -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
On Wed, Mar 24, 2010 at 4:19 PM, Martin Spott martin.sp...@mgras.netwrote: Erik Hofman wrote: Tim Moore wrote: I think the point is that the tools that build BTG files don't use the new format. Well maybe, just maybe it can be modified to output to ac3d or something similar (or even btg format itself). Problem is that casting curved shapes into triangles, the way our Scenery is currently set up, results in a pretty high triangle count. A couple of months ago I've done a few tests: Compiling X-Plane's current layout of KSFO (being a prominent example), including all the yellow taxi lines, into a triangluated surface leads to approx. 50k triangles just for the pure airfield. Now add the effect which Ralf has been explaining on this page: http://www.custom-scenery.org/Triangle-Counts.272.0.html and we'll end up with a _much_ higher triangle count than we're used to. According to past experience with inserting OSM line data for the (major) roads I'd say that FlightGear is currently not ready for this representation of curved shapes - especially not for mainstream Scenery which is supposed to run on a wide range of hardware. No offense, but the hardware described on Ralf's page is not exactly cutting edge. For an example of a million poly mesh displayed on a reasonable 2 year old laptop (nvidia 8600M), see http://shiny-dynamics.blogspot.com/2010/03/vertex-cache-optimization-for-osg.html. Of course, this is a huge apples-to-oranges comparison, but it should give food for thought about why fg seems to choke on large numbers of polys in the scenery. While on this subject, do you scenery guys have any thoughts about different levels-of-detail in scenery tiles? Tim -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
