- Well I finally licked it, the clipping works great now, in 16 and 32
bpp mode, on 2d and 3d panels.
- I tried glScissors, didnt work because clipping was done in screen
co-ordinates.
- Stencil buffer methods worked great for 2d panel, but messed up 3d
panels,(depth buffer problems I think), and only worked in 32 bpp mode.
- I then tried clip planes , and so far it appears to work with no
problem, and no framerate drop like I had with the stencil buffer
method...
I'm attaching the panel.cxx file for testing...
* Use "const string&" rather than "string" in function calls when appropriate.
* Use "const Point3D&" instead of "Pint3D" in function calls when appropriate.
* Improved course calculation in calc_gc_course_dist()
* Safer thread handling code.
Vassilii Khachaturov:
Dont use "const Point3D&" for return types unless you're absolutely sure.
Erik Hofman:
* Use SGD_(2)PI(_[24]) as defined in simgear/constants.h rather than
calculating it by hand every time.
- replay.cxx :
corrected a bug, now reinitialize the recording data when replay is
deactivated
- fgclouds.cxx :
cloud layers and weather condition are saved when choosing a weather scenario,
added a new scenario 'none' so we can switch back to standard flightgear
weather
- navradio.cxx :
force a search() on init to initialize some variables, preventing a nearly
infinite loop when delta-time == 0 on the first update()
- electrical.cxx :
uninitialized variable in apply_load() for FG_EXTERNAL supplier
- panel.cxx, panelnode.cxx :
added a property "depth-test" for 2.5D panels so that they update the depth
buffer and are no more visible from the outside of the aircraft when the
aircraft uses textures without an alpha channel
- panel.cxx :
moved the computation of the instruments diffuse color outside the
texturelayer code since this is constant during a frame, this is a big speedup
for 2D panels
The "switch" layer type now takes any number of child layers, and will
use the first child that has a condition that evaluates to 'true' (no
condition is automatically true). Previously, it could take only two
children, controlled by a boolean property.
I've updated the instrument modulator code to allow tricks like the one
described by Andy. It is now possible to define <min>, <max> and
<modulator> in one layer and if <min> and/or <max> ore within the range
of the <modulator> tag, their value will be honoured.
So, if you define
<layer>
<min>0</min>
<max>50</max>
<modulator>100</modulator>
</layer>
The value will stay at 50, until the modulator forces it back to 0.
Ensure that if a condition for a panel mouse binding fails, other
bindings for the same area will have a chance to run.
Add a repeatable flag for panel mouse bindings (defaults to true).
I wrote:
> I can confirm this. Layers on the 2D panels (but oddly, only the 2D
> panels) aren't drawing over the background with the current ATI
> drivers.
OK, this turns out to be a trivial fix, although I still think it's a
driver bug. There are two calls to glPolygonOffset in the panel
rendering code (shared by both 2D and 3D panels). One is called
per-layer, and sets up a layer-specific offset. The other is called
for drawing the background textures, to lift them off of any
underlying cockpit geometry.
I was using different "factor" values for each, incorrectly. Patch
attached. It was affecting only 2D panels because the 3D ones don't
use background images.
Problem is, by my reading of the specification the bug should have had
the effect of pushing the background texture *farther* behind the
instruments, instead of pulling it on top of them. Either I'm reading
the spec incorrectly or ATI has inverted the sense of the factor
argument. Dunno, I'll submit a bug report to them and see what
happens.
> Jim Wilson wrote:
> > How hard would it be to have a property that toggles hotspot
> > visibility? It'd be nice to be able to turn it on and have yellow
> > rectangles show up on the hotspots...
>
> That's not a bad idea.
It's actually an astoundingly good idea, and implementable over lunch
to boot. :)
Try the attached patch, which predicates the boxes on the
/sim/panel-hotspots property. I mapped a toggle event on this to a
spare joystick button, and had fun. :)
[dpm: bound to Ctrl-C]
avoid having the 2D instruments obscure 3D objects in front of them):
It's related to depth buffer precision. On my Geforce cards (2MX and
3), it never happens with the 24 bit depth buffer you get by default
at 32bpp. At 16bpp, it picks a slimmer depth buffer (probably 16 bit)
and the texture layers bleed through.
The code is using a pretty big argument to glPolygonOffset, and I've
never investigated how small it can be. If someone has a little time
the next time they see this issue, try changing the value of
POFF_UNITS at the top of Cockpit/panel.cxx. Decrease it until the
textures *just* start to interfere with each other, and post the value
that works for you.
The biggest and coolest patch adds mouse sensitivity to the 3D
cockpits, so we can finally work the radios. This ended up requiring
significant modifications outside of the 3D cockpit code. Stuff folks
will want to look at:
+ The list of all "3D" cockpits is stored statically in the
panelnode.cxx file. This is clumsy, and won't migrate well to a
multiple-aircraft feature. Really, there should be a per-model list
of 3D panels, but I couldn't find a clean place to put this. The
only handle you get back after parsing a model is a generic ssg
node, to which I obviously can't add panel-specific methods.
+ The aircraft model is parsed *very* early in the initialization
order. Earlier, in fact, than the static list of allowable command
bindings is built in fgInitCommands(). This is bad, as it means
that mouse bindings on the instruments can't work yet. I moved the
call to fgInitCommands, but someone should look carefully to see
that I picked the right place. There's a lot of initialization
code, and I got a little lost in there... :)
+ I added yet another "update" hook to the fgRenderFrame routine to
hook the updates for the 3D panels. This is only required for
"mouse press delay", and it's a fairly clumsy mechanism based on
frame rate instead of real time. There appears to be delay handling
already in place in the Input stuff, and there's a discussion going
on about different mouse behavior right now. Maybe this is a good
time to unify these two (now three) approaches?
really see anything different in the day, but as day turns to night the
panel smoothly darkens and the lighting component becomes visible.
Lights are wired to electrical system so if you kill power, you lose the
lights.
+ The panel(s) are now an first-class SSG node inside the aircraft
scene graph. There's a little code added to model.cxx to handle the
parsing, but most of the changes are inside the new FGPanelNode
class (Model/panelnode.[ch]xx).
+ The old FGPanel source changed a lot, but mostly cosmetically. The
virtual-cockpit code moved out into FGPanelNode, and the core
rendering has been abstracted into a draw() method that doesn't try
to set any OpenGL state. I also replaced the old inter-layer offset
code with glPolygonOffset, as calculating the right Z values is hard
across the funky modelview matrix I need to use. The older virtual
panel code got away with it by disabling depth test, thus the "panel
draws on top of yoke" bug. PolygonOffset is really the appropriate
solution for this sort of task anyway.
+ The /sim/virtual-cockpit property is no more. The 2D panels are
still specified in the -set.xml file, but 3D panels are part of the
model file.
+ You can have as many 3D panels as you like.
Problems:
+ The mouse support isn't ready yet, so the 3D panels still aren't
interactive. Soon to come.
+ Being part of the same scene graph as the model, the 3D panels now
"jitter" in exactly the same way. While this makes the jitter of
the attitude gyro less noticeable, it's still *very* noticeable and
annoying. I looked hard for this, and am at this point convinced
that the problem is with the two orientation computations. We have
one in FGLocation that is used by the model code, and one in
FGViewer that is used at the top of the scene graph. My suspicion
is that they don't agree exactly, so the final orientation matrix is
the right answer plus the difference. I did rule out the FDMs
though. None of them show more than about 0.0001 degree of
orientation change between frames for a stopped aircraft. That's
within an order of magnitude of what you'd expect for the
orientation change due to the rotation of the earth (which we don't
model -- I cite it only as evidence of how small this is); far, far
less than one pixel on the screen.
[and later]
OK, this is fixed by the attached panel.cxx file. What's happened is
that the winding order for the text layer's polygons is wrong, so I
reverse it before drawing. That's largely a hatchet job to make
things work for now, though. We should figure out why the winding
order is wrong for only text layers and fix it. I checked the plib
sources -- they're definitely doing things CCW, as is all the rest of
the panel code.
Odd. I'm also not sure why the 2D panel doesn't care (it works in
both winding orders). But this will allow you to check in working
code, anyway. There's a big comment to this effect in there.
- changed FGSubsystem::update(int) to
FGSubsystem::update(delta_time_sec); the argument is now delta time
in seconds rather than milliseconds
- added FGSubsystem::suspend(), FGSubsystem::suspend(bool),
FGSubsystem::resume(), and FGSubsystem::is_suspended(), all with
default implementations; is_suspended takes account of the master
freeze as well as the subsystem's individual suspended state
- the FDMs now use the delta time argument the same as the rest of
FlightGear; formerly, main.cxx made a special case and passed a
multiloop argument
- FDMs now calculate multiloop internally instead of relying on
main.cxx
There are probably some problems -- I've done basic testing with the
major FDMs and subsystems, but we'll probably need a few weeks to
sniff out bugs.
