Re: [Flightgear-devel] A collection of questions
Thanks Fred, this pretty much addresses all my questions. > Light objects are built in simgear/scene/tgdb/pt_lights.cxx > There effect is built in C++ in the getLightEffect function. It is not > configurable as it is now. Ideally, this function should be replaced > by a lookup in the material file to find a configurable effect. > But I didn't thought about the implications of doing so. Okay, then I'm not going crazy and can't really address this from the effect/shader side without touching the core. Could I request implementing a lookup as a non-urgent feature request? This is needed to get true low visibility scenes rendered properly, but I think not among the most pressing problems. > Precipitations use the OSG particle effect. I don't thing it is something > configurable as the shader is coded in OSG C++ code. Maybe this is > something we should try rewriting in order to make the lighting > different. The implementation of the effect is in > simgear/environment/precipitation.cxx Well... maybe let's just leave it as it is - personally I am not much bothered by the precipitation lighting, and this sounds like a non-trivial issue to fix. > Problem : it consumes GPU memory even if the technique requiring > the extra attributes is not selected Hm, I see Can a geometry shader potentially compute the curvature and pass it on? I mean, having a triangle with adjacency info must be good for something like this, right? Stuart: > I don't think there's a sensible way to generate additional trees at > 50-100m. With the changes described above, the overall memory > occupancy of trees should go down, so perhaps it won't matter as much? I was thinking fern, grass, undergrowth,... - these would have a density ~100 times higher than trees, so even just storing the coordinate point if it is created at tile creation time would be a major drain, and the whole thing would only remain manageable if really only the close vicinity is stored - which means it needs to be created on the fly as you approach an area. * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of questions
Hi Thorsten, > De: "Renk Thorsten" > > > If I may bother everyone again - here's my current list of open > questions. Any help or pointers would be appreciated: > > > * Where do the runway and taxiway lights enter the rendering scheme? > They need to be fogged consistently with the rest of the scene, but > I do not know where to set this - which effect are they using? > > Context: In low visibility scenes, lights remain visible to large > distances because they go to the default fog color rather than the > atmospheric light scattering fog color. > > See http://users.jyu.fi/~trenk/pics/catIIIb.jpg Light objects are built in simgear/scene/tgdb/pt_lights.cxx There effect is built in C++ in the getLightEffect function. It is not configurable as it is now. Ideally, this function should be replaced by a lookup in the material file to find a configurable effect. But I didn't thought about the implications of doing so. > * Where does precipitation enter the rendering scheme? > > Context: I have received the suggestion to change the lighting of > rain and snow to agree better with the environment lighting - but I > don't know where the lighting for precipitation is defined in the > first place. > > See > http://www.flightgear.org/forums/viewtopic.php?f=69&t=7358&start=555#p176734 Precipitations use the OSG particle effect. I don't thing it is something configurable as the shader is coded in OSG C++ code. Maybe this is something we should try rewriting in order to make the lighting different. The implementation of the effect is in simgear/environment/precipitation.cxx > * Why are the runway and taxiway designation signs using the terrain > shader? Can (should) this be changed? > > Context: The terrain ubershader at high detail assumes that vertical > surfaces need to be rock. If a sign is rendered by the terrain > shader, the shader consequently makes the sign vanish and replaces > it with rock unless the rock texture is explicitly set to 'off'. > This could be hacked around by just setting it off for every sign, > but I am thinking that a better solution would be to render these > objects with a model shader because the features of a terrain shader > do not really make sense in this context. > > See http://www.flightgear.org/forums/viewtopic.php?f=47&t=18999 No idea. Certainly a shortcoming. > > * Can we generate more vertex attributes than tangents, normals and > binormals? For instance, can we do components of the curvature? > > Context: Lots of vegetation patterns in nature are 'on the valley > floors' or 'along a ridge'. In order to tag those with shader > effects, one would need curvature. For instance, valley floors are > defined by normal pointing upward and positive curvature, the ridges > are defined by normal pointing upward and negative curvature. This > would allow much more natural distributions of overlay patterns. Problem : it consumes GPU memory even if the technique requiring the extra attributes is not selected > * How difficult would it be to expand the tree generating system to a > multi-tier system in which we can in addition generate a circle of > vegetation in the range of ~50-100 m for high resolution scenes > landing off airfields? Do we generate the memory load from trees at > tile loading time, or at tree loading time? > > Context: Would be very cool to have ;-) > > * Just how are the LOD ranges defined in the view menu used? I am > genuinely confused, I understand that LOD bare sets the terrain, but > that's the limit. Does anyone know? These properties were introduced by me back in 2004 when I began to populate the SFO area with static buildings. I originally provided 2 or 3 versions of the geometry in the same model selected by a range animation. > Thanks in advance for any help with these! Regards, -Fred -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of questions
> I suspect they are just using the default terrain effect, if anything. > They are generated from the C-code when the tile it loaded (IIRC > simgear/scene/tgdb/obj.cxx though I'm not at my FG computer to check) > > If you want any changes I'd be happy to make them, though I'd expect > it's the sort of change that you could make yourself with a little > digging :). I guess the only way to fog/light these things correctly is to hand them to the right shader, but I only know how to do this for things which appear in effect files or which use one of the specified effects. I can certainly pick it up from there, but I had the impression that lights do not use terrain default, because I would have expected that to work consistent with the rest. Among other things, they would for instance get snow-covered or dirt-modified if they would use the terrain shader. So I think what I would need is the lights referencing some effect file if they're currently not sorted anywhere. > FYI, I've got a list as long as my arm of FG things to do, and have > struggled to find any time to spend on FG for the last month. Please no hurry - I'm just trying to get my mid-term plans together. > I would think it would be straightforward to do this, but I don't know > the perf/capacity impact of doing so. Probably on par with generating both tangents and binormals - it's down to looking up adjacent normals and computing how different their dot product with the local 'up' direction is. This shouldn't be outrageously expensive to do, but it would throw in some more non-local topology into the shaders. Thanks, * Thorsten -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of questions
On 8 Apr 2013, at 09:57, Stuart Buchanan wrote: >> * Just how are the LOD ranges defined in the view menu used? I am genuinely >> confused, I understand that LOD bare sets the terrain, but that's the limit. >> Does anyone know? > > To my embarrassment, I don't know how they are used, except to say > that they aren't used for tree, random buildings, and (probably) > random objects. > That's probably a bug. I would say the whole LOD management needs to be reviewed and tweaked to get a bit more control, a (hopefully) simpler UI, plus the 'auto-LOD' I've suggested before. It's on my medium-term ToDo list, but definitely not short-term. If you find nasty things in the area of LOD, I would suggest recording / reporting them, but judge for yourself if it's worth investing time in making changes around the periphery. (Of course if anyone wants to really dive into that area I would be delighted, but best to sync up with Mathias about his SPT work, before writing any code). For Stuart's specific example, there probably needs to be top-level (per-tile) LOD which parents *all* the objects (static, shared, and random veg/buildings), and probably a shared quad-tree of LOD nodes (again for all kinds of objects) instead of the current scheme where each class of object has its own independent quad-tree (or doesn't). With some unified control over the ranges and bias for such a scheme (and maybe larger static objects are tagged and go higher up the quad-tree, so are visible further away than vegetation), this ought to be usable with a 'bias' control, and no tweaking of ranges at all (in the UI). If anyone wished to look at doing that, I'm sure Stuart and myself could point them in the right direction. (Or I'll get to it 'at some point') Regards, James -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of questions
On Mon, Apr 8, 2013 at 8:04 AM, Renk Thorsten wrote: > If I may bother everyone again - here's my current list of open questions. > Any help or pointers would be appreciated: Things have been remarkably quiet the last couple of weeks - good to have something to discuss :) > * Where do the runway and taxiway lights enter the rendering scheme? They > need to be fogged consistently with the rest of the scene, but I do not know > where to set this - which effect are they using? I suspect they are just using the default terrain effect, if anything. They are generated from the C-code when the tile it loaded (IIRC simgear/scene/tgdb/obj.cxx though I'm not at my FG computer to check) If you want any changes I'd be happy to make them, though I'd expect it's the sort of change that you could make yourself with a little digging :). FYI, I've got a list as long as my arm of FG things to do, and have struggled to find any time to spend on FG for the last month. Off the top of my head I've got the following things on my plate right now: - Improve Basic Weather integration with Atmospheric shaders. Thorsten's provided soem documentation of the properties to be set, and I need to either write some property rules for Basic Weather or modify the C-code. - Review Vivian's changes to the Weather dialog (this is not to mean I don't think Vivian's work is a step forward, I just need to think about it a bit) - Modify trees so that there's no need to change the texture set under atmospheric light shading. This is almost complete and means that trees above the snow-line are snow-covered, and deciduous trees in autumn/winter lose their leaves - Further improvements to AA refueling - support drogue/probe positions - Move the loading of trees/buildings from the tile loading into a deferred LoD node so that they only get generated when the user gets closer to them. This should improve tile loading times and memory occupancy. Of course, it's nice to have so many interesting tasks to work on, but if anyone is looking for some work to do and would like to take one one of the tasks, they'd be very welcome :) > * Where does precipitation enter the rendering scheme? It'll be somewhere in the C code. I'll have a root around for it and let you know. > * Why are the runway and taxiway designation signs using the terrain shader? > Can (should) this be changed? Yup, I'm sure this can be changed :) I'll take a look if no-one beats me too it. > See http://www.flightgear.org/forums/viewtopic.php?f=47&t=18999 > > * Can we generate more vertex attributes than tangents, normals and > binormals? For instance, can we do components of the curvature? I would think it would be straightforward to do this, but I don't know the perf/capacity impact of doing so. > * How difficult would it be to expand the tree generating system to a > multi-tier system in which we can in addition generate a circle of vegetation > in the range of ~50-100 m for high resolution scenes landing off airfields? > Do we generate the memory load from trees at tile loading time, or at tree > loading time? Currently we generate all the trees at tile loading time, and then use LoD to control how many are displayed. So the memory cost of incurred at tile load time. As mentioned above, I'd like to change this so that tree generation is deferred into the LoD node. Mathias has shown how this can be done, and I need to extend his work. I don't think there's a sensible way to generate additional trees at 50-100m. With the changes described above, the overall memory occupancy of trees should go down, so perhaps it won't matter as much? > * Just how are the LOD ranges defined in the view menu used? I am genuinely > confused, I understand that LOD bare sets the terrain, but that's the limit. > Does anyone know? To my embarrassment, I don't know how they are used, except to say that they aren't used for tree, random buildings, and (probably) random objects. That's probably a bug. -Stuart -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] A collection of questions
If I may bother everyone again - here's my current list of open questions. Any help or pointers would be appreciated: * Where do the runway and taxiway lights enter the rendering scheme? They need to be fogged consistently with the rest of the scene, but I do not know where to set this - which effect are they using? Context: In low visibility scenes, lights remain visible to large distances because they go to the default fog color rather than the atmospheric light scattering fog color. See http://users.jyu.fi/~trenk/pics/catIIIb.jpg * Where does precipitation enter the rendering scheme? Context: I have received the suggestion to change the lighting of rain and snow to agree better with the environment lighting - but I don't know where the lighting for precipitation is defined in the first place. See http://www.flightgear.org/forums/viewtopic.php?f=69&t=7358&start=555#p176734 * Why are the runway and taxiway designation signs using the terrain shader? Can (should) this be changed? Context: The terrain ubershader at high detail assumes that vertical surfaces need to be rock. If a sign is rendered by the terrain shader, the shader consequently makes the sign vanish and replaces it with rock unless the rock texture is explicitly set to 'off'. This could be hacked around by just setting it off for every sign, but I am thinking that a better solution would be to render these objects with a model shader because the features of a terrain shader do not really make sense in this context. See http://www.flightgear.org/forums/viewtopic.php?f=47&t=18999 * Can we generate more vertex attributes than tangents, normals and binormals? For instance, can we do components of the curvature? Context: Lots of vegetation patterns in nature are 'on the valley floors' or 'along a ridge'. In order to tag those with shader effects, one would need curvature. For instance, valley floors are defined by normal pointing upward and positive curvature, the ridges are defined by normal pointing upward and negative curvature. This would allow much more natural distributions of overlay patterns. * How difficult would it be to expand the tree generating system to a multi-tier system in which we can in addition generate a circle of vegetation in the range of ~50-100 m for high resolution scenes landing off airfields? Do we generate the memory load from trees at tile loading time, or at tree loading time? Context: Would be very cool to have ;-) * Just how are the LOD ranges defined in the view menu used? I am genuinely confused, I understand that LOD bare sets the terrain, but that's the limit. Does anyone know? Thanks in advance for any help with these! * Thorsten -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
