Re: [Flightgear-devel] Rating System Redux (was Re: Flightgear-devel Digest, Vol 61, Issue 12)

[Hal V. Engel]

On Monday, May 30, 2011 12:47:41 PM Stuart Buchanan wrote:
> >> I don't have a good answer for the other items. Some are nice-to-haves
> >> that enrich
> >> the simulation experience but don't impact simulation of flight
> >> itself, but others
> >> (such as a co-pilot) are more important for multi-crew aircraft.
> > 
> > Call them all "advanced features". That could be a/the criterion for
> > "advanced production"
> 
> I'm not sure. The "Advanced production" bar is already very high - two 5s
> and two 4s.
> 
> I'm not sure if any aircraft will actually gain it!

I would expect that at this point only a few aircraft out there are close to 
or are "advanced production" quality.  It is a very high standard and any 
aircraft that is that far along should really stand out.  I would expect that 
most of the most advanced current models only need perhaps 1 or 2 points to 
get there but adding points when the models are that far along is a lot of 
work.   But I would be surprised if there were more than a handful of aircraft 
that were far enough along to only need 1 or 2 points to become "advanced 
production".  I think I agree with Stuart that having some things called 
"advanced features" does not add much if anything to the system particularly 
when we have so many models that are missing many basic things.

An example of one that is close but needs more work is the p51d-jsbsim model.  
It only needs to improve the external model (add livery support to go from a 3 
to a 4) to get to "production" status and then add one more point in cockpit, 
external model or systems would make it "advanced production".

Currently it has the following ratings:

 
 5
 4
 3
 4
  

The 3D modeling stuff is not my strong suit but I do have new more accurate 3D 
models for the fuselage and wing (including flaps and aileraons) for the P-51D 
that I created a while back.  I have also more accurately modeled the cooling 
inlet passages and the oil and coolant radiators so that these will look 
correct (once textured) when looking into the cooling inlet.   I need to uvmap 
all of this stuff now and this is where I get stuck as I can't figure out how 
to 
do this so that the resulting uvmaps can be used to create livery support.  
Having a nice user friendly uvmap for the fugelage and wings is more or less 
nessary to move ahead with libery support I think.  

For Systems adding emergency gear release support, oxygen system support, full 
cooling system support, VHF radio support,  rear warning radar support, IFF 
support and some missing electrical system stuff would increase this to a 5.   
The 3D models for the controls for all of these systems are already in the 
cockpit.

One comment about systems.  For the P-51 series there are two cooling doors 
that are used to control cooling airflow.  One for the engine coolant and one 
for the oil cooler.  JSBSim has support for the coolant door controls but not 
for the oil cooler door controls.  I have the automatic coolant door stuff 
modeled but not the automatic oil cooler stuff because of this.  I also need to 
add manual overides for these at some point (the controls are in the cockpit 
but currently only allow for automatic control).  What I am getting at is that 
some systems can not be fully modeled because of limitations in the FDM being 
used and aircraft authors should rate these as complete systems if they have 
modeled everything that is possible with the existing FDM support. 

For Cockpit adding the fuselage fuel tank and guage, a few missing placards, 
the arm rest, the map bag and improved texturing would pretty much get it a 5.

For some aircraft it may never be possible to get the FDM rating high enough 
to get more than a 2 or 3 simply because the data needed to do that is not 
available.  These aircraft will never be able to get beyond an "early 
production" status unless the author finds a source for the needed information. 
   

Hal
--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Rating System Redux (was Re: Flightgear-devel Digest, Vol 61, Issue 12)

[Stuart Buchanan]

On Thu, May 26, 2011 at 8:30 PM, Vivian Meazza wrote:
> Stuart
>
>>
>> > Thanks for addressing the points that were hammered out over on the IRC
>> > channel. I think the modified system could work. Just a few points
>> remain:
>> >
>> > There is no penalty for including systems, such as an AP, where none
>> existed
>> > on the original.
>>
>> There's not an explicit penalty. but I think Hal has addressed this in
>> the notes
>> for the System criteria:
>>
>> "Ignore systems not present on the aircraft IRL. If the real aircraft
>> doesn't have
>> a system (e.g. autopilot), the FG model shouldn't have either and if
>> all systems
>> in the real aircraft are modeled then it scores a 5 even if it is a
>> very simple aircraft. "
>>
>> I'm not sure how much of a problem this is.  If someone chooses not to
>> disable the
>> generic autopilot for a vintage aircraft, it will have no effect on
>> pilots who choose
>> to fly realistically (they simply won't use it). If the system is
>> exposed in the cockpit,
>> then it is covered by the rating for accuracy of cockpit - a KAP140 in
>> the Sopwith
>> Camel would obviously not be worth a 4 or 5 cockpit rating.
>
>
> That is correct - but it doesn't follow from the criteria quoted above.

I've added "No unrealistic systems" to the System-3 rating criteria, with
an exception for autopilot. I've also attempted to provide some useful
guidance notes.

>> We're talking here about the difference between a 4 or 5 External
>> Model rating, where
>> we're trying to differentiate between a good external model and one that
>> is as
>> realistic as possible.
>>
>> I think we should differentiate between them if possible, but I'm
>> struggling to think
>> up some objective criteria. Photo-realistic? model resolution of 5cm?
>>
>> Perhaps we end up providing subjective criteria, or some additional
>> guidance
>> in this case?
>
> I think guidance - livery shouldn't be a criterion for realism, but it might
> form part of it. Realism is the goal.

I've modified the rating and guidance as follows:

# 4: Accurate 3D model with animated control surfaces, gear, prop,
livery support (if applicable).
# 5: Highly accurate 3D model (down to minor components such as
control rods), with animated control surfaces, gear, prop, livery
support, tyre smoke, shader effects.

"Objectively differentiating between a 4 and a 5 is very difficult. As
a guideline, a "5" model is as realistic as possible given the
available rendering technology. "

>> I don't have a good answer for the other items. Some are nice-to-haves
>> that enrich
>> the simulation experience but don't impact simulation of flight
>> itself, but others
>> (such as a co-pilot) are more important for multi-crew aircraft.
>
> Call them all "advanced features". That could be a/the criterion for
> "advanced production"

I'm not sure. The "Advanced production" bar is already very high - two 5s and
two 4s.

I'm not sure if any aircraft will actually gain it!

>> Of course, we're trusting that aircraft developers are going to apply the
>> rating
>> criteria accurately to the best of their ability.
>
> Yes - I think perhaps a bit of spot-checking to keep us all honest?

Assuming this gets widely adopted, I think it'll be self-policing. Users
are going to notice if an aircraft falls below the general criteria.

>> > Oh and, finally finally - the model with the highest score might be so
>> good
>> > that the framerate means that it can only be used on high-end systems or
>> > away from detailed airports. This limitation should be noted somewhere.
>>
>> I don't have a good answer to that. Does that become criteria for a "5" in
>> External Model? I think this ends up back as something subjective.
>
>
> I think we need some form of bench-mark - perhaps the default model at KSFO
> with certain (all?) features enabled. The aircraft to be rated scores a %
> framerate above or below this norm? Thinking aloud here a bit. Perhaps
> that's a bit too fancy.

I think that's going to vary so much between graphics systems, plus I'm not
sure that graphics degradation is linear - it always seems to fall off a cliff
for me :)

>> If enough people rate their aircraft and we can use it to provide a better
>> download page for the upcoming release, it will succeed.
>>
>
> Let's hope - some aircraft developers have an awful lot of aircraft to rate.

Given his standardized workflow, I think Helijah will be able to apply pretty
much the same rating to most of his new models, and retrospectively fit his
existing aircraft as well.

Hal V. Engel wrote:
>> Hadn't thought about that at all. I've added it to the criteria for a
>
>> "4" rating.
>
> I would treat these as just another system. I think the systems catigory is
> a difficult one because of how much difference there is between very simple
> aircraft (think sailplane) and a very complex one (think Concorde). This
> makes it very difficult to have a rating system that results in similar
> scores for aircraft that have 

Re: [Flightgear-devel] - Open Radar development

[ThorstenB]

On 28.05.2011 04:47, Marcel Fernandez wrote:
> Other question I have is where can I find documentation about multi
> playerprotocol. I saw that the documentation I found  in flight gear
> wiki has some differences with the one found in flightgear multiplayer
> server page(fgms.sourceforge.net ).

The wiki description doesn't look to bad. But if in doubt, it's best to 
consult fgfs sources for actual implementation. The multiplayer 
implementation isn't really a beautiful part of our sources, but the 
actual encoder isn't too complex. Have a look at 
FGMultiplayMgr::SendMyPosition in
http://www.gitorious.org/fg/flightgear/blobs/next/src/MultiPlayer/multiplaymgr.cxx

cheers,
Thorsten

--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Segfault with OSG multi threading

[ThorstenB]

On 30.05.2011 19:25, Stefan Seifert wrote:
> The segfault happens when the main loop thread tries to
> access GL information. I know next to nothing about openGL programming but I
> seem to recall that it's not allowed to access the same GL context in 
> different
> threads. So how is this supposed to work?

Well, wouldn't surprise me to find more related multi-threading issues. 
Not sure how long OSG itself supports it, but I guess it wasn't a major 
priority at the time when FG was adapted to OSG. And I'm sure more fixes 
will be necessary to safely support it.
The particular source lines also have an "//OSGFIXME" comment - another 
hint that work was left behind.
Try replacing the calls to SGIsOpenGLExtensionSupported - they provide 
constant information anyway. It'd be enough to check 
version/capabilities once during init and then use constant data at 
run-time. Try if that helps. Patches welcome :).

cheers,
Thorsten

--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Segfault with OSG multi threading

[Stefan Seifert]

On Friday 13 May 2011 11:03:24 Anders Gidenstam wrote:

> Presumably it will also increase the risk of triggering any race condition
> and/or unsynchronized data access bugs that may be lurking in the code.
> There are some known ones (e.g. during the creation of a particle
> system) but there could easily be more.
> 
> In this case you should investigate the arguments and locals in the
> different stack frames to see if you can see something looking bad.

Stack looks quite fine and it does not feel like a race condition to me. It's 
100% reproducable and always in the same place and adding a sleep here and 
there does not change anything. Well everything looks fine except for the big 
picture. There are two threads running. One running OSG rendering stuff and the 
other FG's main loop. The segfault happens when the main loop thread tries to 
access GL information. I know next to nothing about openGL programming but I 
seem to recall that it's not allowed to access the same GL context in different 
threads. So how is this supposed to work?

(gdb) thread apply all bt

Thread 2 (Thread 0x7fffec712700 (LWP 15449)):
#0  0x77bcd38c in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#1  0x73a4021d in OpenThreads::Condition::wait(OpenThreads::Mutex*) () 
from /usr/local/lib64/libOpenThreads.so.12
#2  0x74dc2d3b in osgViewer::Renderer::ThreadSafeQueue::takeFront() () 
from /usr/local/lib64/libosgViewer.so.76
#3  0x74dc3506 in osgViewer::Renderer::draw() () from 
/usr/local/lib64/libosgViewer.so.76
#4  0x73de291e in osg::GraphicsContext::runOperations() () from 
/usr/local/lib64/libosg.so.76
#5  0x73e3693a in osg::OperationThread::run() () from 
/usr/local/lib64/libosg.so.76
#6  0x73de4a88 in osg::GraphicsThread::run() () from 
/usr/local/lib64/libosg.so.76
#7  0x73a3fd90 in OpenThreads::ThreadPrivateActions::StartThread(void*) 
() from /usr/local/lib64/libOpenThreads.so.12
#8  0x77bc8a3f in start_thread () from /lib64/libpthread.so.0
#9  0x7328267d in clone () from /lib64/libc.so.6
#10 0x in ?? ()

Thread 1 (Thread 0x77fa7760 (LWP 15446)):
#0  glGetString () at glapi_x86-64.S:9877
#1  0x00abe70a in SGIsOpenGLExtensionSupported (extName=0xbe7cda 
"GL_ARB_texture_env_combine") at extensions.cxx:64
#2  0x009687cc in SGCloudLayer::rebuild (this=0x7fffe31785b0) at 
cloud.cxx:389
#3  0x00967d0b in SGCloudLayer::SGCloudLayer (this=0x7fffe31785b0, 
tex_path=...) at cloud.cxx:210
#4  0x004357c4 in fgIdleFunction () at main.cxx:424
#5  0x004a1d8e in fgOSMainLoop () at fg_os_osgviewer.cxx:284
#6  0x00436903 in fgMainInit (argc=1, argv=0x7fffdbd8) at 
main.cxx:659
#7  0x00433899 in main (argc=1, argv=0x7fffdbd8) at 
bootstrap.cxx:243

Cheers,
Stefan

--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel