Space Shuttle

[Philosopher]

Well, since tank tracks are repetitious, I think it would be easier to use a modulo number to animate them, such that one track never fully replaces the next - they essentially would just stay in the same vicinity as they started in. Thus for the tracks wrapping around the wheel, you would only need a rotation animation; for those running along the top, just a translation animation, etc. That way, only a handful of track elements would need both types of animation (with interpolation).

[Johan G]

Good thinking.

[legoboyvdlp]

There is a panzer somewhere for FlightGear... I think it has moving tracks. Nice work on the launchpad.

[japreja]

Panzer thread link http://forum.flightgear.org/viewtopic.php?f=4&t=9693 too bad jack retired in 2011. This has been sitting for a while but the tracks do roll nicely in next nightly

Thanks for the hint legoboyvdlp

[Thorsten]

I think it would be safe to join together the major parts that will never move and use them for KTTS Scenery

You can submit this to scenemodels yourself, it's a web interface to do it - I can't do this any more directly than you can, I could just include it in the Shuttle repo

(actually, I've been thinking of placing it with the Shuttle in case you launch from other locations, but I couldn't make it work, and it's probably too hacky anyway, so I think the pads should be installed at Kennedy and Vandenberg).

[Hooray]

http://wiki.flightgear.org/Space_Shuttle_Avionics


http://sourceforge.net/p/flightgear/fga ... al/map.nas

Code: Select all

graph.removeAllChildren();


What is the performance like for people with older computers ?
(if in doubt, wrap the whole thing in a debug.benchmark() call):

Code: Select all

debug.benchmark(
  graph.removeAllChildren();
);


I am asking, because according to the repository, this is still using the removeAllChildren() approach to update/prune elements non-selectively, despite this being known for being particularly inefficient:

Subject: How to display Airport Chart?

I would suggest to avoid the 'remove all children' logic, which is obviously unfriendly to the Canvas.

A recommended workaround being cached (=reused) points and using parametric curves instead of connected line segments:

Using Canvas for visualizing orbital flights (cont'd PM)

looking good - what is performance like, I am asking because of the removeAllChildren() approach you're using for clearing/redrawing each track (i.e. no caching/reuse of existing points), do you notice any impact on frame rate/spacing while updating ?

Using Canvas for visualizing orbital flights (cont'd PM)

As a first step, I have edited the Canvas Snippets article to demonstrate how to draw quadratic/cubic curves (this should help lower the total number of Canvas path elements needed, because you're currently using a high number of line segments for approximating the curve):

http://wiki.flightgear.org/Canvas_Snipp ... enVG_Paths





Once this is working, I would consider creating an array (=Nasal vector) of path objects and simply update (translate, hide/show) those instead of using removeAllChildren() - so instead of invoking removeAllChildren(), you'd merely hide(), update()/transform() and show() the corresponding path elements

Using Canvas for visualizing orbital flights (cont'd PM)

right, sorry for not being clear about it: I was referring to the reusing previously created point objects (as in the property tree), by merely changing their x/y positions - and simply hiding those not needed (using the .hide() method) - which means that you'd basically only have the allocation overhead once (i.e. during initialization).
The other obvious optimization is using a cubic/qudratic curve instead of hundreds of line segments (as I mentioned previously).

Basically, the idea is to have as little property I/O as possible - in terms of total property updates, but also total number of individual properties vs. "parametric" updates that don't create as much I/O (see the property browser to inspect how many nodes are created/removed during each update). In that sense, removeAllChildren() works analogous to delete() or free() in C/C++, whereas createChild("...") works like new/malloc - so you'd want to minimize those, and ideally use a data structure/drawing type that is appropriate (e.g. using a parametric curve instead of tons of line segments to approximate a curve)

TheTom posted these, and a few other, optimization suggestions in the original "fgplot" thread, including Nasal/Canvas code snippets.
You can use systime() and/or debug.benchmark() to see how much of a difference this makes for this particular use-case.

[Thorsten]

What is the performance like for people with older computers ?

Don't know, don't care at this point.

There's ~90% of the avionics still not done at all, getting all workable is priority now, making it efficient is something that can be done later if it is a problem.

[Richard]

What is the performance like for people with older computers ?

Don't know, don't care at this point.

There's ~90% of the avionics still not done at all, getting all workable is priority now, making it efficient is something that can be done later if it is a problem.

Whilst I appreciate the point being raised that it may not be the best way (as I didn't previously know this) I'm going to have to completely agree with Thorsten, premature optimisation is the cause of many a failed project.

[Hooray]

I am quite aware of that and agree with it, but there's a certain point of "proliferation" where it makes sense to revisit certain techniques - simply because other code is likely to have the same structure. For instance, look at the extra500, which is using similar techniques all over the place. And at some point, changing things later on becomes a ton of work.

So being aware of potential issues is a good thing either way- especially if, like you say, more avionics need to be developed - which may thus be likely to "share" certain approaches.

But again, I was asking if it is a problem or not - I haven't tested anything related to the space shuttle, and I am also unlikely to really notice it given my own hardware specs.

[Thorsten]

I am quite aware of that and agree with it, but there's a certain point of "proliferation" where it makes sense to revisit certain techniques - simply because other code is likely to have the same structure.

The code is right now not optimized (in more than one way - the whole discussion becomes moot when you realize we never really need to re-draw the lines unless the page changes, so talking about what's the most efficient way of updating a plot we can simply leave drawn is not the most productive thing), I am well aware of this and will deal with it in due time. Right now I want to get systems operational and free of basic errors, then we can test the cross-dependences for different off-nominal scenarios and fix the bugs there, and then it's optimization time.

[japreja]

I forget if I already asked before, but can we workout a list of completed and uncompleted systems, including a list of texturing/modeling(3d) work and who is doing what if at all possible? Regarding the cockpit if we can narrow it down to panels? maybe a todo checklist in the artwork folder?

I found a fairly easy way to texture them from scratch and put the labels to the switches according to the crew ops manual. I just tested it out in blender and gimp and it seems like it will take a few hours per panel. The only problem is ... to get clear text each panels texture would be 2048x2048 to start with, after they are all done we can figure out a way to make them smaller and join them if needed. Each compressed(90%) png will be around 100-200kb. If we bust this out over the next few days it could free up some time from others working on this to help with the systems. I just don't want to start doing it without asking because I don't want to step on anyone elses work. I don't know if this will allow for back-lighting or if it does not matter.

I did this with the original cockpit mesh but can do it just as easily with the current one in Artwork. This is Panel.R2 with the Velcro and Firehole hidden. I accidentally applied the texture to everything on the panel but the different objects UV verts can be moved to a more appropriate color or not unwrapped at all to use a material color instead. I just did it the quickest way to test it out. The "START" and "STOP" text here is 10px, GPC is 12px, and the rest is 20px. The lines are 2px in gimp which is actually 4px for some reason but looks ok.

[legoboyvdlp]

Beautiful, really clear, easy to read.
Good job.

[Richard]

I forget if I already asked before, but can we workout a list of completed and uncompleted systems, including a list of texturing/modeling(3d) work and who is doing what if at all possible? Regarding the cockpit if we can narrow it down to panels? maybe a todo checklist in the artwork folder?

I've remapped and textured L1, L2, F5, F6, F7, C1, C2, F8, R1, R2



I'm currently using a 4096x4096 texture map for all of these and using photographs to get the text. The text is a bit blurry.



As I'm doing this I'm tidying up the mesh; you can see on the landing gear that the main panel is now just one face, whereas the one next to it is quite triangulated. I've also been separating out the switches and removing the unnecessary parts of the mesh for them (most of the original switches sit on a thin box which I don't think we need.

I'm not tied to doing it this way - it's just my opinion that the naturalness and imperfections from the photographs look better and that redrawing the text looks too perfect; it's quite a slow process using the photographs - and it took me a long time (almost a full week of experimentation) to come up with the scheme that I'm now using.

as you can see in this image of L1 it's sort of ok, but I just noticed that there are some overly light and dark bits on the texture



I'll be pushing these commits shortly as I've really got to try and get the PFD done - so at this point if you wanted to do some of the texturing that'd be great.

What I was planning to do next was to get the switches, guards and screws to look better by having less 'flat' colours for these. What I've done before is to take a flat painted metal surface (I used the side of a white Land Rover 110) and to colour this and then use that. If I lived near the Air Force museum I'd pop over there with a camera, tripod and lights and take some nice square photos of each panel and use these as that is what I got Gene to do on the F-15 and I think it looks better this way. But I'm not near there so that's not an option and instead I'm using panoramas (which have lots of geometry issues to resolve).

http://www.nationalmuseum.af.mil/Visit/ ... it360.aspx
http://www.nmusafvirtualtour.com/media/ ... 0View.html
http://www.nmusafvirtualtour.com/media/ ... 0View.html
http://gigapan.com/gigapans/102753


--Richard

[Thorsten]

Speaking of the mesh, one of the big mysteries I've been encountering: With nothing around (no scenery, no earthview), sitting in the cockpit, the worst framerate hit I get is looking straight down to the floor. There doesn't seem to be anything vertex-rich down there, or is it?

[Richard]

It depends on how close you are and the field of view. Most of the vertices are in the panels; but the pedals have got a fair few. I'll pull the numbers out of OSGStats later to see what the counts are; but it'd be useful if you do a screenshot with full OSGStats showing where the worst hit is.