[Flightgear-devel] KSFO/KOAK custom scenery issues
I noticed some wrong paths or naming here with custom scenery of KSFO/KOAK with non-existing .ac Models (or wrong names) and missing textures (?). It’s custom scenery I know, but I think it is also default scenery, isn’t it? output -- Could not find at least one of the following objects for animation: terminal_2 Could not find at least one of the following objects for animation: terminal_2 osgDB ac3d reader: could not parse texture coords while reading object Mesh1 Component_1_1 M setting to (0,0) osgDB ac3d reader: could not parse texture coords while reading object Mesh2 Component_1_2 M setting to (0,0) osgDB ac3d reader: could not parse texture coords while reading object Mesh3 Component_1_3 M setting to (0,0) osgDB ac3d reader: could not parse texture coords while reading object Mesh4 Component_1_4 M setting to (0,0) osgDB ac3d reader: could not parse texture coords while reading object Mesh5 Component_1_5 M setting to (0,0) osgDB ac3d reader: could not parse texture coords while reading object Mesh6 Component_1_6 M setting to (0,0) osgDB ac3d reader: could not parse texture coords while reading object Mesh7 Component_1_7 M setting to (0,0) Cheers, Yves -- 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
[Flightgear-devel] Fuel: Nasal errors
Hi Nasal I get an error in /Nasal/fuel.nas with current fgdata git: Nasal runtime error: non-objects have no members at pathtomyinstallation/fgdata/Nasal/fuel.nas, line 46 called from: pathtomyinstallation/fgdata/Nasal/fuel.nas, line 63 I started 737-100 but think this error is not related to the model ? Cheers, Yves -- 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
[Flightgear-devel] 737-100: Fuselagereflect in /Generic ?
Hi 737-100 devs and reflect effects directory maintainers With 737-100 I get a illegal renderbin draw error. This comes from Fuselagereflect.eff (which is not part of 737-100 distribution), the effect is in /Aircraft/Generic/Effects. There I see that Fuselagereflect calls default Effects/reflect and then this one has a path to imageAircraft/737-300/Models/Effects/733LH.ReflectionMap3.png/image. Smoke over my head. Cheers, Yves -- 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] Fuel: Nasal errors
On 27.03.2011 13:48, HB-GRAL wrote: I get an error in /Nasal/fuel.nas with current fgdata git: Time to update fg/next. You're probably missing this commit: http://www.gitorious.org/fg/flightgear/commit/0114fd962e7450b080e580fe67414ca43cd99bd7 cheers, Thorsten -- 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] Stuttering at 1 Hz rate
For the time being, we'll have to live with this. We should just be aware, that introducing too complex data structures and too heavy/complex computations in Nasal isn't a good idea. Even when their average execution time looks ok, they will eventually trigger noticeable frame rate jitters. The larger the data structures get, the longer the jitter. The more heavy the computation gets, the more often the garbage collector has to run, the more often the jitter happens... That seems to be very system dependent. I am running extensive Nasal computations, but I get the hardest framerate hits from the shaders - I can't use the terrain effect at all since it cuts my framerate from 70 to 10 if I fly over the wrong terrain type - way more troublesome than a short drop from 70 to ~55 when Nasal cleans up. So, it's still good to implement heavy stuff and common instruments in our FG core (C++), and use Nasal mainly for aircraft-specific animations etc. Though that may not be the direction our project is heading to right now... Since I don't follow the 'rule' by coding 10.000+ lines in Nasal, I suppose that is partially thrown into my direction. From where I stand, there are good reasons to use Nasal - first of all the userbase which regularly compiles their own code is small, whereas people do install addon packages - so I get a lot more feedback and test results. Second that one usually can't really crash the whole system from Nasal. Third, it's very easy to quickly try something and very maintenance-friendly. Fourth, you can actually start developing something without knowing how the core code ties together - which I suppose takes a lot of time to learn. And so on. The argument against that is essentially that C++ is faster than Nasal - which, everything else being equal, is certainly correct. But highly specialized Nasal code written for a particular problem outperforms general purpose C++ code - I've given several examples in the past. If someone were e.g. to add movement to Nasal spawned models by adding a velocity property, I'm not sure it would outperform my Nasal quadtree-sorted adaptive range code which priorizes movement for things actually inside the field of view. Of course, if you'd hard-code that specialized algorithm, it would be faster than the Nasal version - but then you couldn't apply it to other problems any more. But if people feel that things inside e.g. the Local Weather package (or somewhere else) should be ported from Nasal to C++ - by all means do so, don't just complain :-) You have the Nasal code available, I for one am entirely willing to explain to anyone who wants to hard-code something what certain things do and how things tie together - I'm just not going to do it myself. Cheers, * Thorsten -- 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] Fuel: Nasal errors
Am 27.03.11 14:16, schrieb ThorstenB: On 27.03.2011 13:48, HB-GRAL wrote: I get an error in /Nasal/fuel.nas with current fgdata git: Time to update fg/next. You're probably missing this commit: http://www.gitorious.org/fg/flightgear/commit/0114fd962e7450b080e580fe67414ca43cd99bd7 cheers, Thorsten Autsch, thanks Thorsten. -- 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] 737-100: Fuselagereflect in /Generic ?
Hi, With 737-100 I get a illegal renderbin draw error. This comes from Fuselagereflect.eff (which is not part of 737-100 distribution), the effect is in /Aircraft/Generic/Effects. There I see that Fuselagereflect calls default Effects/reflect and then this one has a path to imageAircraft/737-300/Models/Effects/733LH.ReflectionMap3.png/image. Smoke over my head. Cheers, Yves I'm not quite sure, but so much as I know that was helijah's idea, as he fits every single aircraft with this shader. The 733LH.reflectionMap2.png was once created by Vivian and used on the 733 to give an example how this shader is working and how it can be jused. It would be much better that a gneric ReflectionMap is made and used here. That should prevent illegal renderbin draw errors. Heiko -- 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] KSFO/KOAK custom scenery issues
HB-GRAL wrote: osgDB ac3d reader: could not parse texture coords while reading object Mesh1 Component_1_1 M setting to (0,0) These relate to the KSFO_DomesticGarage.ac model. Everything's fine when I'm loading the model in 'osgviewer', therefore I suspect some obscure special handling in FlightGear. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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] Stuttering at 1 Hz rate
On Sun, Mar 27, 2011 at 1:17 PM, Thorsten Renk wrote: But if people feel that things inside e.g. the Local Weather package (or somewhere else) should be ported from Nasal to C++ - by all means do so, don't just complain :-) You have the Nasal code available, I for one am entirely willing to explain to anyone who wants to hard-code something what certain things do and how things tie together - I'm just not going to do it myself. FYI I'm currently looking at adding support for creating a 3D shader cloud using Nasal, to bypass the need to have XML wrappers etc. I'm hoping that this can off-load some of the low level quad-tree work you currently have to do. This might allow us to either conver the Local Weather package to C code, or alternatively (and more likely?) move all Global Weather management code into Nasal so we can integrate them together properly. We should discuss exactly what API makes most sense for this. -Stuart -- 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] Stuttering at 1 Hz rate
Hi,
here's a few more comments/hints/warnings on Nasal and simulation
performance in general.
First of all: it's not meant _against_ anybody. It's great to have a
tiny scripting engine in FG. It's great to have an option for custom
extensions. And we're certainly seeing very nice examples (absolutely
including ThorstenIR's local weather, since he brought that up).
I'm just making a point here that the Nasal engine does have
performance issues, which we should be aware of and care about.
When evaluating simulation performance, don't get fooled by the frame
rate. What's really important to us is the worst case frame latency.
Even if the system is producing a huge average of 100 frames per
second, it can still look absolutely crappy, if only a single frame
took more than 20-30ms, since that's immediately visible to the human
eye (note to self: add a worst case latency indicator). So, we're
building a real-time system here, and 20-30ms is our timing
constraint.
Nasal needs to run a garbage collection every now and then. This means
an extra delay, and may become noticeable, if it causes a frame to
violate the timing constraint. _When_ and _where_ in the Nasal code
the g/c triggers, is almost random, so you cannot attribute the g/c
delay to the point where it happened.
The effect depends on two properties: (1) how long does it take, and
(2) how often does it happen. These issues are triggered by different
properties of the code. If we can keep the delay below the limit,
everything is perfect. If we cannot, than we should at least reduce
its frequency. One stutter per minute may be acceptable. Once every
second looks absolutely intolerable (though you may still get a funky
100fps indication!).
1. The length of the delay depends on the number of references the
garbage collector needs to traverse: variables (data), but also
functions, which are just like variables in Nasal, e.g.
var myVariable = 42;
var myFunction = func()...
It doesn't depend on the size of a particular function or basic
variable though. The garbage collector needs to look and follow every
single reference to find out what's still in use. The delay is
proportional to the number of elements which were
loaded/initialized/created in Nasal. It hardly depends on the
length/complexity/frequency of Nasal computation though, since the
average number of references usually won't change too much.
I have instrumented the Nasal g/c to show the number of references
caused by generic Nasal scripts and by different aircraft (subtracting
the references caused by generic scripts) with current GIT:
39128 all generic stuff (i.e. fgdata/Nasal...)
3475 UFO
4788 c172p
6007 SenecaII
8283 B777-200ER
19270 F14
86122 Concorde
So, for most aircraft, the a/c specific Nasal is negligible. Time
consumed by garbage collection almost depends on generic stuff alone
(40K of references traversed in each run). Only some complex aircraft
significantly influence the g/c performance themselves, e.g. the
Concorde. It's ok if advanced models require advanced CPUs. But it's
not so nice with generic stuff, since it affects everyone and every
aircraft.
Currently, we load all fgdata/Nasal/*.nas at startup. Whether the code
is ever used or not, or a particular feature is disabled, doesn't
matter much. It's loaded and initialized, increases the number of
references, thus delays the g/c.
For the test above, I had _disabled_ multiplayer/wildfire/target
tracking/local weather/redout. The numbers hardly change when enabling
features though.
Since the local weather topic was mentioned: yes, it's large, but only
responsible for about 11K of references, so about 1/4 of current
generic Nasal stuff (when disabled).
2) The g/c frequency mainly depends on how much stuff is done in
Nasal, including the number of timers and the timer frequencies. So,
in contrast to (1), this very much depends on enabled features, and
strongly on specific aircraft (see Robert's email on frequency).
I also added instrumentation here to see how our generic stuff is
doing. There's several timers which run at full frame rate, even when
the related feature is disabled:
fgdata/Nasal/mp_broadcast.nas:146
fgdata/Nasal/redout.nas:93
fgdata/Nasal/wildfire.nas:506
fgdata/Nasal/track_target.nas:194
Even when they're almost doing nothing, it'd still help if they were
stopped or at least slowed down, when the related feature was
disabled. They affect garbage collection since a lot of (useless)
contexts are created and need to be cleared at some point - hence
triggering the g/c more often than necessary.
Typically many of our Nasal timer handlers look like this:
myTimer = func() {
if (getprop(/foo/feature/enabled))
{
...
}
settimer(myTimer, 0.0); // run again in next update loop
}
This would already improve things (20-100 times fewer contexts being
created/removed):
myTimer = func() {
if (getprop(/foo/feature/enabled))
{
...
Re: [Flightgear-devel] 737-100: Fuselagereflect in /Generic ?
Am 27.03.11 14:59, schrieb Heiko Schulz: It would be much better that a gneric ReflectionMap is made and used here. That should prevent illegal renderbin draw errors. Heiko Just to add: Looks like the illegal renderbin draw has other reasons. Besides this very interesting file/directory/self-and-outer-inheriting structure unfortunately the reflect shader is not working anymore for OSX 10.6.6/ATI 5750/OSG 2.9.9 at the moment (with recent sg/fg/fgdata). -Yves -- 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] 737-100: Fuselagereflect in /Generic ?
Heiko wrote: With 737-100 I get a illegal renderbin draw error. This comes from Fuselagereflect.eff (which is not part of 737-100 distribution), the effect is in /Aircraft/Generic/Effects. There I see that Fuselagereflect calls default Effects/reflect and then this one has a path to imageAircraft/737-300/Models/Effects/733LH.ReflectionMap3.png/image. Smoke over my head. Cheers, Yves I'm not quite sure, but so much as I know that was helijah's idea, as he fits every single aircraft with this shader. The 733LH.reflectionMap2.png was once created by Vivian and used on the 733 to give an example how this shader is working and how it can be jused. It would be much better that a gneric ReflectionMap is made and used here. That should prevent illegal renderbin draw errors. If the reflection map path is incorrect you should see only this error message: no image file, maybe the reader did not set the filename attribute, using white for type '2d' on '', in /technique[9]/pass[0]/texture-unit[4] If you are seeing another error message, please update your data (some potential errors were removed recently). If the errors persist then please file an issue report. The reflection map is intended to vary reflection across an object. I would be amazed if one size fits all. I wouldn't have expected it to be a good candidate for the generic folder. Oddly enough I have been working on the shader today. The reflection map can be used to give quite nice effects: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV-Reflect-Map.png Vivian -- 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
