Yes. I'm still trying to get my head around git though
Cheers,
Sam.
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.
our wiki wrote:Development status
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.
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.
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.
kyokoyama wrote in Wed Mar 21, 2012 7: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 7: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?
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();
} );
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?
Users browsing this forum: dg-505 and 9 guests