Board index FlightGear Development Aircraft

Jabiru J-170 (DEVELOPMENT)

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

Re: Jabiru J-170 (DEVELOPMENT)

Postby Figaro » Tue Mar 20, 2012 5:45 am

Yes. I'm still trying to get my head around git though :lol:

Cheers,
Sam.
User avatar
Figaro
 
Posts: 1262
Joined: Fri Feb 25, 2011 9:23 pm
Callsign: 4L-FIG
OS: Elementary 5.0 Juno

Re: Jabiru J-170 (DEVELOPMENT)

Postby redneck » Tue Mar 20, 2012 12:55 pm

For those looking at the issue I have with the tutorial, I had a weird exit condition. One of them was for vertical speed in FPS to be greater than -100. I was thinking in FPM at the time. I fixed that to -0.6.

EDIT: Sam, if Omega's being too lazy (again) to help you out with Git, I should be able to help. Just get on Skype when you're ready, and I'll walk you through it.
Call Signs: redneck, ATCredn (unspecified freq atc)
FGFSCopilot
FGFSCopilotATCEdition
System Specs
Model: Alienware M15x, OS: Windows 7 Professional 64-bit, RAM: 3 GB, CPU: Intel i3 quad core at 2.4 GHz, GPU: Nvidea GeForce GTX 460M 1.5 GB GDDR5
redneck
 
Posts: 3630
Joined: Mon Feb 02, 2009 2:17 am
Location: Pennsylvania, USA
Version: 240

Re: Jabiru J-170 (DEVELOPMENT)

Postby Hooray » Tue Mar 20, 2012 5:44 pm

omega95 wrote:Btw, if Rembrandt is coming out pretty soon, we should just stop work on the synthetic vision... I'm making a Nasal+XML version cuz I know it's gunna take a while for anything from C++ to be ready and fully distributed.


Yes, a Nasal/XML version will obviously require less integration work, and you won't have to wait for some core developer to review and commit your code hopefully prior to the next feature freeze.

However, I am not sure if/how a C++ instrument would be affected by Rembrandt (i.e. deferred rendering) and why the Nasal-based approach would possibly be inferior?
Actually, Fred mentioned that some hard-coded "glass" instruments are still causing problems (see the devel list or the Rembrandt wiki page), so I would think that a Nasal/XML-based instrument is currently more future-proof actually.

As can be seen by the backlog of patches waiting to be reviewed and committed to git, you are actually much safer by not depending on core developers reviewing and committing your C++ code. On the other hand, there's a fair share of code to be reused for the synthetic vision, most of the od_gauge stuff would be relevant, as well as Zan's property-driven texture cameras. Obviously, the C++ code would be more performant, but you would need to find someone willing to review the code and basically "adopt" the patches so that they can be used in the upcoming FG release.

Regarding the next release, quoting the wiki:

our wiki wrote:ImageDevelopment statusImage
Traffic light green.png Current status: OPEN
Next status: frozen (89 days from now)
Next release: 2.8.0 (150 days from now)
See release plan for details.


Regarding Rembrandt: According to the devel list, the idea is to start integrating Fred's work as soon as possible (i.e. NOW), so yes, they are aiming for the upcoming release, but everybody seems to realize that this could turn out to be too ambitious, so they are also prepared to postpone "FlightGear Rembrandt (aka FG Shadows)" if necessary - that's basically the consensus among core developers:

http://www.mail-archive.com/flightgear- ... 36381.html
The first question is whether this is something that we want in the
2.8.0 release. We have just over 130 days until the next code freeze,
which isn't a huge amount of time. OTOH, that's as much time as we're
ever going to have between releases :) So, the question becomes where
it can be release-ready in 130 days, or it needs to wait until the
following release.

If we want it in 2.8.0, then it needs to be in the "next" branch ASAP.
That's the only way to ensure that every developer is working with
it. The danger of leaving it in a separate branch is that developers
can just ignore it. My recollection of the OSG work was that it was
only when it became part of the main cvs code that people really
started filling in the feature gaps compared with plib.

Given that we have 400+ aircraft that need to be updated, I think we
also need clear documentation (on the wiki?) describing the steps you
outline above, and in particular how to register the transparent
surfaces. That probably needs to be in place before the code goes
into "next".

IMO we should bite the bullet and get it into "next" this week if
possible. There's obviously some risk to our 6 month release
schedules that we'll just have to accept.



http://www.mail-archive.com/flightgear- ... 36404.html
Personally I would think adding Project Rembrandt will call for
FlightGear version 3.0. So if it is added I would create two branches,
version 3.0 and version 2.7 in which the later is switched to bug fixes
only.

If 3.0 turns out to require more time than expected (I probably know the
answer to that one) then there's always a really stable version 2.8
which can be released.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Jabiru J-170 (DEVELOPMENT)

Postby omega95 » Wed Mar 21, 2012 6:09 am

Just came across a problem.. We have a set (2D array?) or elevations and when you visualize them, they look like the red dots in the image. But then when you get a view, most of the scan lines won't even hit one of those points. That means you don't really get good distances. A solution might be to use a function to connect the dots and have the scan lines see those too.. like in the 2nd diagram. But then the problem is I don't really understand how we can do that. Any ideas? :?

Image
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Jabiru J-170 (DEVELOPMENT)

Postby kyokoyama » Wed Mar 21, 2012 6:16 am

(and just to chip in, what if there is a small spike between those dots that aren't captured in the scan?)
Look for "B-BIRD" "N127KY" or "AVA0004" -that's me.

Despite having over 1700 posts here, I am not even close to being the most skilled guy here... I'm just words and bad drawing, not experience. :P
kyokoyama
 
Posts: 1988
Joined: Sun May 03, 2009 2:16 am
Location: Earth
Callsign: B-BIRD, N127KY
Version: 2.12.1
OS: Windows Vista

Re: Jabiru J-170 (DEVELOPMENT)

Postby omega95 » Wed Mar 21, 2012 6:19 am

kyokoyama wrote in Wed Mar 21, 2012 6:16 am:(and just to chip in, what if there is a small spike between those dots that aren't captured in the scan?)


omega95 wrote in Wed Mar 21, 2012 6:09 am:A solution might be to use a function to connect the dots and have the scan lines see those too.. like in the 2nd diagram. But then the problem is I don't really understand how we can do that. Any ideas? :?
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Jabiru J-170 (DEVELOPMENT)

Postby omega95 » Wed Mar 21, 2012 6:47 am

Alright, I came up with a mathematical solution of doing that.. The diagram below (lol, I love GIMP :D ) should explain the whole thing. :wink:

Image

You can see that we don't bother doing any checking if the point is outside the box limits, now if it's inside, we check the angles it subtends to the 2 elevation points. If the angles are equal, we found out exactly where it touches the line the connects the 2 points. And there we go, use that as our distance to point. :D

Getting started on converting all the diagrams to nasal code. :)
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Jabiru J-170 (DEVELOPMENT)

Postby omega95 » Wed Mar 21, 2012 9:46 am

Alright, I used a nasal helper to create the animations for the display pixels on the SkyView-D1000 (61x50, slightly over 3 Mega Pixels :shock: ) and it just created 59904 lines of xml... Will this sorta thing cause lag? I also did a basic untested calculator/scanner to find the distances from eye point to the elevation points.. With such for-loops I don't think we can get away without lag, any ideas to make this better?

Code: Select all
var FT2NM = 0.000164578834;

#-----------------------GRADIENT TEXT-TRANSLATE VALUES-------------------------#
#
# Altitudes
var transparent = -50; # Area where you can see the skydome
var ceiling = 15000; # Service Ceiling
#
#------------------------------------------------------------------------------#

var projector = {
   init : func {
        me.UPDATE_INTERVAL = 0.05;
        me.loopid = 0;
       
        setprop("skyview-D1000/fov", math.pi / 4); # 45 degrees in radians
       
        me.reset();
       
   },
   update : func {
   
      # Run only when you have power in avionics
      
      if (jabiru.electric.outputs[0].serviceable) {
      
         var fov = getprop("skyview-D1000/fov") / 2;
         
         var pitch = getprop("/orientation/pitch-deg");
      
         var range = getprop("skyview-D1000/range");
         
         var altitude = getprop("/position/altitude-ft");
         
         var page = getprop("skyview-D1000/page");
         
         # Find maximum textranslate range
         
         var max_x_textranslate = math.sqrt(((range)*(ceiling * FT2NM)) + ((range)*(ceiling * FT2NM)));
         
         # Check the point intersections for 50 points in each of the 61 strips
         
         for (var strip = 1; strip <= 61; strip += 1) {
         
            for (var point = 1; point <= 50; point += 1) {
            
               # Convert the point to the angle from normal and add it to pitch
               
               # Using default screen size as 1 just to get sub-angles
               
               var view_center = 1 / math.tan(fov);
               
               var scr_pt_height = 0.04 * (point - 25); # 1/25 as the screen has 25 in each hemisphere
               
               ## NOTE - Doing all angular calculations in radians
               
               var scan_angle_base = RAD2DEG * math.atan2(view_center, scr_pt_height);
            
               var scan_angle_rad = scan_angle_base + pitch;
            
               # Find the max distance the scanner needs to check
               
               ## Max Scan Limit = Range / cos(scan_angle_deg)
               
               ## NOTE - Doing all distance calculations in nautical miles
               
               var scan_limit = range / math.cos(scan_angle_rad);
               
               # Scan all distances from 0 to the limit with an interval of range/150
               
               var dist_interval = range / 100; # Thats in a straight line, this changes according to angle but the difference won't be too much.
               
               for (var distance = 0; distance < scan_limit; distance += dist_interval) {
               
                  var found = 0;
                  
                  var prev_range = 0;
                  
                  var prev_index = 0;
               
                  # Create a virtual box with the 2 points b4 and after the scan point as opposite corners
                  
                  # Elevation points before and after (distance * cos(ange))
                  
                  var x_proj = distance * math.cos(scan_angle_rad);
                  
                  # 15 points, divided through the range | 15 as we have 15 elevation points
                  
                  var range_interval = range / 15; # Change this for different elevation points
                  
                  for (var n = 0; n < 15; n += 1) {
                  
                     if (x_proj >= n) {
                     
                        found = 1;
                        
                        prev_index = n;
                        
                        prev_range = n * range_interval;
                        
                     }
                  
                  }
                  
                  if (found == 1) {
                  
                     #----------------VIRTUAL BOX CORNERS---------------#
                  
                     pt1_x = prev_range;
                     
                     pt2_x = prev_range + range_interval;
                     
                     pt1_y = getprop("skyview-D1000/terrain/row[" ~ prev_index ~ "]/col[" ~ strip ~ "]/elevation-ft"); # elevation at prev index
                     
                     pt2_y = getprop("skyview-D1000/terrain/row[" ~ (prev_index + 1) ~ "]/col[" ~ strip ~ "]/elevation-ft"); # elevation at the next index
                     
                     #--------------------------------------------------#
                     
                     # Now, check if it's inside the box
                     
                     var point_height = altitude + (distance * math.sin(scan_angle_rad)); # This is also the entry height
                     
                     if (((point_height <= pt2_y) and (point_height >= pt1_y)) or ((point_height >= pt2_y) and (point_height <= pt1_y))) {
                     
                        var connect_angle = math.atan2(range_interval, (pt2_y - pt1_y) * FT2NM);
                     
                        var found_pt = 0;
                     
                        for ((var fine_dist = pt1_x; fine_dist <= pt2_x; fine_dist += (pt2_x - pt1_x) / 20) and (found_pt == 0)) {
                        
                        checkpt_x = fine_dist;
                        
                        checkpt_y = point_height + ((fine_dist - distance) * math.tan(scan_angle_rad));
                        
                        var subtend_angle = math.atan2((checkpt_x, pt1_x),(checkpt_y - pt1_y) * FT2NM);
                     
                           if ((math.abs(connect_angle - subtend_angle) <= 0.15) and (found_pt == 0)) {
                        
                              var sub_elevation = pt1_y + ((fine_dist - distance) * math.tan(connect_angle));
                        
                              setprop("skyview-D1000/display/strip[" ~ strip ~ "]/point[" ~ point ~ "]/altitude-ft", sub_elevation);
                              
                              var fine_proj = (fine_dist - distance) / math.cos(scan_angle_rad);
                              
                              var final_distance = distance + fine_proj;
                           
                              setprop("skyview-D1000/display/strip[" ~ strip ~ "]/point[" ~ point ~ "]/dist_textranslate", final_distance / max_x_textranslate);
                           
                              found_pt = 1;
                        
                           }
                     
                        }
                     
                     } # end of inside-box check
                     
                  } else {
                  
                     # If nothing's found, that means the next coming terrain is out of the scanner's range. So basically, we set the display altitude set the display to transparent.
                  
                     setprop("skyview-D1000/display/strip[" ~ strip ~ "]/point[" ~ point ~ "]/altitude-ft", transparent);
                  
                  } # end of found check function
               
               } # end of distance scan for-loop
            
            } # end of points for-loop
         
         } # end of strips for-loop
         
      } # end of power check function
      
   },
   reset : func {
        me.loopid += 1;
        me._loop_(me.loopid);
    },
   _loop_ : func(id) {
        id == me.loopid or return;
        me.update();
        settimer(func { me._loop_(id); }, me.UPDATE_INTERVAL);
    }

};

var get_elevation = func (lat, lon) {

   var info = geodinfo(lat, lon);
      if (info != nil) {var elevation = info[0] * 3.2808399;}
      else {var elevation = -1.0; }

   return elevation;

}

setlistener("sim/signals/fdm-initialized", func {
   projector.init();
} );
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Jabiru J-170 (DEVELOPMENT)

Postby omega95 » Wed Mar 21, 2012 10:36 am

Ohhkk, I just fixed a couple of errors and tried it.. WITHOUT the code, I lose frame-rate from like 25 to 15 (cuz of the number of polygons on the screen) and then when I try the code, the FlightGear gets stuck when I turn on the master. Basically, the for loops are really long and cause a LOT of lag. I suggest we stop this method and use C++. First, may I know WHY we have to wait for Rembrandt to do this? I mean, we just need to create a hard coded instrument which renders terrain camera view to texture using od_gauge.

If you can render terrain camera views to screen and render other stuff like a ground radar to texture, why can't we mix them and render a terrain camera view to texture?

Can some core programmers please help here? :|
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Jabiru J-170 (DEVELOPMENT)

Postby Figaro » Wed Mar 21, 2012 11:12 am

Probably better to take that question to the mailing lists.


Cheers,
Sam.
User avatar
Figaro
 
Posts: 1262
Joined: Fri Feb 25, 2011 9:23 pm
Callsign: 4L-FIG
OS: Elementary 5.0 Juno

Re: Jabiru J-170 (DEVELOPMENT)

Postby Icecode GL » Wed Mar 21, 2012 9:43 pm

This would be much more easier and efficient to do in C++. C++ allows you more control over the entire program, more low-level access. Nasal/XML is really high level though.

Rembrandt will only change (or that's what I understood) the way FG renders everything, switching to deferred rendering. That shouldn't change anything in the making of hard-coded instruments or rendering terrain to a texture I think. My little advice is to do it in C++, and let Nasal for simplier things. :)
Icecode GL
 
Posts: 529
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: Jabiru J-170 (DEVELOPMENT)

Postby Barambu2sa » Wed Mar 21, 2012 9:54 pm

Very nice.
I love realistic cockpits
Barambu2sa
 
Posts: 274
Joined: Tue Mar 25, 2008 4:49 pm

Re: Jabiru J-170 (DEVELOPMENT)

Postby Hooray » Fri Mar 23, 2012 4:51 pm

First, may I know WHY we have to wait for Rembrandt to do this? I mean, we just need to create a hard coded instrument which renders terrain camera view to texture using od_gauge.

If you can render terrain camera views to screen and render other stuff like a ground radar to texture, why can't we mix them and render a terrain camera view to texture?


Based on reading the forum, the mailing list and the wiki, the current issue is that MFDs are not yet fully integrated with Fred's Rembrandt work so that they don't show up properly in FG/Rembrandt. However, the underlying problem will need to be solved regardless of a new OD_GAUGE instrument or not. That aside, there shouldn't be any other issues actually. For more info you may want to get in touch with Fred.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Jabiru J-170 (DEVELOPMENT)

Postby F-JJTH » Fri Mar 23, 2012 9:43 pm

The current issue about MFD is caused by <emission> balise. The <emission> balise generate glow effect. The correction is in the todolist of Fred and the solution could avoid to modify MFD.

For example 787-8 and Rembrandt give :
Image
Image

Cheers,
Clément
Last edited by F-JJTH on Sat Mar 24, 2012 1:18 pm, edited 1 time in total.
User avatar
F-JJTH
 
Posts: 697
Joined: Fri Sep 09, 2011 11:02 am

Re: Jabiru J-170 (DEVELOPMENT)

Postby kyokoyama » Sat Mar 24, 2012 5:04 am

Awesome -the cockpit glows! :DDD

...To make the cockpit seem less awkwardly and unrealistically lighted, is it possible to identify screens and specific lightsources to only make certain parts glow in a certain luminosity level?
(in otherwords, could you make it so that the AP knobs don't glow, and the LEDs glow brighter than the VNAV button?)
Look for "B-BIRD" "N127KY" or "AVA0004" -that's me.

Despite having over 1700 posts here, I am not even close to being the most skilled guy here... I'm just words and bad drawing, not experience. :P
kyokoyama
 
Posts: 1988
Joined: Sun May 03, 2009 2:16 am
Location: Earth
Callsign: B-BIRD, N127KY
Version: 2.12.1
OS: Windows Vista

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: amue, YandexBot [Bot] and 3 guests