Re: [Flightgear-devel] sound questions
On 24.03.2012 00:29, syd adams wrote: I,ve noticed for awhile that sounds seem to cut off at the reference-distance rather than max-dist. Is there a new way to do the sound files that Ive missed or is this a bug ? It is nice that sounds actually stop now , but I must be doing something wrong .I've been attempting to fix all my sound files but things aren't working as expected. Erik should be able to give authoritative answers on sound, but AFAIK we're using the inverse distance clamped model for attenuation of all sounds. There's a graph showing how gain vs distance works in this mode - see this OpenAL spec (section 3.4.2): http://connect.creativelabs.com/openal/Documentation/OpenAL%201.1%20Specification.pdf Additionally, FG 2.6 introduced a new range check to free sound resources completely above maximum distance. That's a check that FG is doing itself - not done by openAL (so not shown in the openAL spec). So, how it should work altogether for FG is: Volume is clamped to a maximum below reference distance. Volume is attenuated above reference distance. Sounds are completely cut off above maximum distance (since 2.6). If you think it's not behaving as described, it's probably best if you gave an example. cheers, Thorsten -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery loading cleanup
Hi, I had a busy week, so sorry for the delay. On Saturday, March 17, 2012 10:07:07 Anders Gidenstam wrote: I have not had time to consider the proposal carefully, but I agree that the ocean tiles are problematic in the old (old) scheme if you have object directories with overlapping objects rather than jaust additional objects. I have not tested the new changes at all yet. At first, is the current state something you can currently work with? It should stop opening stg files once a base object is hit. While the (old) new behaviour is as Martin expects it is not what most that has read Docs/README.scenery would expect (I'd think). However, I would not consider Docs/README.scenery a normative source (i.e. not how it should be but rather how it was) - but Martin's expectation (as far as I know about it) is also not the behaviour I'd like or want. I agree with that. The aim to clean up technically the scenegraph lead me to this area and looking at the implementation I found plenty of stuff that was dangling from the osg switch I think - so the old source could not considerred normative either. I feared that it did much more than it should do. So, I was looking for documentation and somebody who knows about that. What I did at first sounded plausible somehow but missed your needs for your workflow. IOW I can well see the need for reading from more than one directory for your workflow. In the old old scheme entries in the path could point to just terrain or just object trees in addition to full scenery directories containing both Terrain, Objects and (more recently) Airports and Models subdirectories. Both those options are useless with the stop-at-once behaviour (you get either terrain and no objects or just objects). Could a working middle way be to merge objects from path entries containing only the Objects (and maybe Models) tree encountered before the first full scenery directory for the tile in question? That way an ocean tile in a full scenery directory would terminate the search. (How to decide that a scenery directory is full, that is, considered to contain both terrain and objects for a particular tile, may need more thinking). Yes, all boils down to this question. So currently full means 'I have found a BASE_OBJECT'. Which is something that will not happen for sea tiles. So one of the proposals was to be able to explicitly generate sea tiles by putting them into the BASE_OBJECT line. That does not mean that every sea tile must be explicitly triggered, but a sea tile *could* in this model be explicitly triggered to get a propper termination point. This can happen by a id.seatile metafile or an other keyword in the stg file for example. Similar questions most likely arise for the files in the Airports and Models directories, and for terrain only scenery directories (but there soft links to the desired Objects, Models and Airports directories may help to turn a terrain only directory into a full scenery directory). E.g. for ground net development I would like to be able to have a local Airports directory (containing just the files I'm working on) that would be searched before the one in the full (e.g. terrasync) scenery directory. I don't know exactly what happens currently for the Airports directory. But yes I see. This must work the same than the scenery object search as the stg/btg files need to match with the taxiway descriptions. But that means that finding the matching groundnetwork files must also follow the same complex stg file algorithm. Or even more, this one also needs to look *into* the stg files to scan for an OBJECT_BASE line and take the files from the matching Airports directory beside? Do you think it is possible to define 'full' scenery by the plain presence of a Terrain/id1/id2/id3.stg file in the Terrain subdirectory? This would at least reduce the need to look *into* the stg files to barely looking for the existence of an stg file to see where to stop? For the sea tiles this would mean that those tiles with object need a terminating Terrain/... file, sea tiles without dont need anything as it is today. This question is motivated by the scenegraph structure we currently generate. I can imagine improovements to scenery paging with this kind of change. What I want to try is not put individual model files into own level of detail nodes or paged nodes, but put all models in one tile into a single paged osg node. This node is then paged in later/paged out earlier than the bare Terrain node that we need even for far tiles. If I try to do the same with the current semantics, I need to execute the same search sequence by opening the stg files multiple times. Not sure yet I gain something here, but willing to ask if this is at least possible. Ideas? Comments? Thanks Mathias -- This SF email is sponsosred by: Try Windows Azure free for 90
Re: [Flightgear-devel] scenery loading cleanup
On 24 Mar 2012, at 08:54, Mathias Fröhlich wrote: This question is motivated by the scenegraph structure we currently generate. I can imagine improovements to scenery paging with this kind of change. What I want to try is not put individual model files into own level of detail nodes or paged nodes, but put all models in one tile into a single paged osg node. This node is then paged in later/paged out earlier than the bare Terrain node that we need even for far tiles. Tangental, but, yes please! This and a few other similar options, like generating a low-detail terrain node 'automatically' for distant tiles, were some ideas I considered last year to allow further draw distances. James -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG
Hi, On Wednesday, March 21, 2012 13:29:52 Renk Thorsten wrote: Mathias, maybe it's just me - but I have a serious problem understanding what you write. I have greatest respect for what you do, and I've seen some amazing things like the factor 50 speed increase of the geodinfo() call, but most of the time I have no idea what you're talking about. The above is symptomatic. I agree that I am mostly very short. But this really is due to the lack of time to do all step by step. Where I start explaning at that point where I believe that it starts to get non trivial for others. So obviously I do not hit that point ... Martin mentions you trying to integrate space-view into Flightgear. I've tried to google space view, but that returns mainly image collections and some company websites. So I have no idea what it is. As a result, I ask you to comment, because I want to know what you're trying to do and how it compares with what I do. Your anwers starts with reference to how to do scattering integrals outside the atmosphere. It assumes I know all the rest (how Earth is modelled, how scattering integrals are done inside the atmosphere, ...) and would just be interested in the technical detail how to do it from space. You then continue under the assumption that I had asked a highly technical question, detailing rendering with fog and scattering separated into the last step. So what am I doing: I load a scenegraph model of the whole earth that, using apropriate osg methods, aims toward a scalable scenegraph that is still able to display high level of details once you are close to ground. This is just a scenegraph object that is rendered. There is a whole lot of stuff contained there to make that scalable, but for rendering this could just be considered seperately then. Take this and combine it with some technique that simplifies the skydome which is only used today as a proxy geometry to get rendered pixels for the sky shaders. And as such a way to high real existing dome/sphere that needs to be rescaled and repositioned. You need to take care of this geometry for the near/far clipping planes. All that could just be replaced by a simple fixed screen aligned quad that has way less geometry and provides the same effect of providing fragments for the scattering/sky shaders. Once you have realised that scattering/sky is just the same than fog for objects, it is clear that you want to do both in the same way/code. Which simply leads to what I am talking about: Put that into a compositing step where you combine the stuff that you get from rendered objects with the scattering integrals. When you do this in a compsiting step, you get a lot of possibilities to implement say shafts in the atmosphere where scattering happens differently in directly lit areas than in inderectly lit ones. Appart from that being a technology enabler for really nice visuals, you can then omit ugly fog computations from the models. You can seperate different stuff into different modules and untangle dependencies, which is good in its own. This is to a high degree really what Fred is working on, just with a different detail in its usage. And in an other sense not that sophisticated than freds approach for the material properties of the objects. That's all you need. I typically prepare a lot of things that are usually sensible and helpful for its own but with such a final goal in mind. Once all is set up in place I just need to grab into the black hat and pull out a white rabbit - in this case this could be space flight. Totally independent of your request, but only realizing stuff that is helpfull for its own and fitting together into some bigger picture. Does this help? Mathias-- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery loading cleanup
Hi, On Saturday, March 24, 2012 09:29:41 James Turner wrote: Tangental, but, yes please! This and a few other similar options, like generating a low-detail terrain node 'automatically' for distant tiles, were some ideas I considered last year to allow further draw distances. Yes, the spt loader does this currently. but the lower level of details still lacks altitude information. And the basic texture is just the croase whole world texture even in the mid lod case. That's what I currently use for developing a seperate hla viewer that can be attached to any hla object. I can currently safely sit on top of the ogel generated on the sphere in san diego flying over LOWI. Works fine here :) So, short, I have never described the spt loader, but it is able to provide a scalable whole world paged scenery. This is similar to google earth or osg's marble or the like. The scenegraph is done with a quadtree/octree structure that in the end fits our tile structure of stg files. That should be fast to cull. We have currently three levels of detail one of which with the recently added earth texture and croaser tiles. One in between that still uses the same texture but should use a set of higher detailed ones in the future. and the third level then contains the stg files. So what needs to be done here is provide a set of earth textures for the mid level of detail together with may be associated altitude textures for both lod's. Then extend the croase ground tile implementation either in a vertex shader or in static load time geometry generation to make use of the altitude information. This could in a next step replace the high detailed btg/stg tiles for far away tiles. And this should build the ground work for seriously enable using really high detailed btg files but still being scalable. All that would then need a lot of tuning and improovements the high detail scenery so that paging happens smooth. Well, I for myself do not plan to work on this in the near future but this could just be a sketch of how this could be extended probably somehow easy. Whoever wants to work on that please stay in touch with me, as I already have a lot of hooks in place. Greetings Mathias -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 2D panel breakage
As part of some work on cleaning up picking and mouse-interaction in the OSG scene, I recently converted 2D and 2.5D panels to be picked via the 'normal' hit-testing mechanism. Unfortunately this has broken some panels, due to some latent bad behaviour: http://files.goneabitbursar.com/fg/concorde-panels.png The cyan rectangle is the panel's official boundary (of the 'logical' 1024x768 panel) - as you can see, panel authors have placed actions and layers outside this area, presumably because it 'just worked'. I've broken it 'just working', but will code up a fix in the next couple of days. I'll also commit the code to show the 2.5D panel boundaries in 'hotspots' mode, not that it really matters. In the meantime, if you find other aircraft (besides the Concorde) where 2.5 panel hotspots aren't working, let me know so I can test them. Regards, James -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] sound questions
Thanks for the explanation , that helped. I thought the volume was reduced to half at reference-distance , but after more experiments discovered that the volume IS cutting off at max-dist , but the reference distances were excessive , so it turns out to be my misunderstanding and old sound configurations. Thanks ! Syd -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] sound questions
Am 24.03.2012 15:39, schrieb syd adams: I thought the volume was reduced to half at reference-distance That's actually what README.xmlsound still says - but I don't think that's right (it's not halved, but clamped at it's maximum at ref-dist). Maybe the description matched a pre-OpenAL implementation of our sound module and needs an update? Erik? cheers, Thorsten -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Rendering Failure
Good afternoon, I recently downloaded FG2.6.0.1, and tried to start it up on a Vista SP1 that was able to run all previous versions and a developer's snapshot from last November without problems. However, I tried to fly the UFO with 2.6, and the terrain appears to be corrupt. Please refer to the YouTube video I uploaded at youtube.com/watch?v=BPPRn265IoUhttp://www.youtube.com/watch?v=BPPRn265IoUfeature=player_embedded to see what I mean. I tried to look for precedents in the Forums and posted a topic on this, but I haven't been able to get any answers. Could I get some advice or redirection to try fixing this problem? Thank you. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Next Meeting #fg_scenery
Hi, the next meeting is planned for Monday, 26.3. at 16:00 UTC or 4 PM UTC. Don't forget about the DST starting tonight in many countries :) Hope to see many of you. Chris -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Change in failures.nas
Hi everyone. Thanks for the awesome sim you all make.
I'd like to understand something that seems to affect only me.
As you can see in the forum [0] after a recent fgdata update I couldn't use
one plane because it checked against a property in failure-manager part of the
tree, that was not appering for me. Once I understood more or less what was
happening I reverted a part of the commit [1] only in the failures.nas file
and it worked again.
This is what I reverted manually in my install:
--
diff --git a/Nasal/failures.nas b/Nasal/failures.nas
index ccf6f79..23cb738 100644
--- a/Nasal/failures.nas
+++ b/Nasal/failures.nas
@@ -177,12 +177,12 @@ var setAllMCBF = func(mcbf) {
}
}
-
# Initialization, called once Nasal and the FDM are loaded properly.
-_setlistener(/sim/signals/fdm-initialized, func {
+var fdm_init_listener = _setlistener(/sim/signals/fdm-initialized-once,
func {
+removelistener(fdm_init_listener); # uninstall, so we're only called once
srand();
-# Engines are added dynamically because there may be an arbritary number
+# Engines are added dynamically because there may be an arbitrary number
var i = 1;
foreach (var e; props.globals.getNode(/engines).getChildren(engine))
{
breakHash[e.getPath()] = { type: type.MTBF, failure: fail.ENGINE,
desc : Engine ~ i };
--
What could be the problem?
Thanks, Eugenio.
[0]
http://www.flightgear.org/forums/viewtopic.php?f=4t=13296p=153965#p153945
[1]
https://gitorious.org/fg/fgdata/commit/f1e4c6503643587a933e742fcfc15cb5af127802
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
