Board index FlightGear Media

Flightgear on foot

Screenshots, videos, sound recording etc. taken in/with FlightGear.

Flightgear on foot

Postby Thorsten » Sun Apr 06, 2014 6:41 pm

I've cooked up this plan to use FG/ the walker to write something like an action adventure scenario, involving a number of flight and other challenges - for instance finding a crashed plane in the mountains, landing a helicopter close to it and then use the walker to investigate, or flying at night secretly and low to a yacht off the coast, meeting people at certain locations to gain information, or having to cope with a sabotaged plane and a failing engine... with the adventure taking over time and weather settings, and a pricetag for every hour you use a certain plane,...

So, today I did some experiments just walking around, having a look how the scene looks like close up from the ground, and... it's fairly okay actually:

That's Propriano airport, Amelia between some parked planes:

Image

Approaching Bonifacio:

Image

Exploring the old town on foot:

Image

Patch of forest nearby:

Image

Suddenly door animations make a lot more sense:

Image

Enroute into the mountains:

Image

Monte Giovanni, not quite the top, but near:

Image

Ground texture resolution is actually good enough:

Image

Amelia's trusted heli parked in the scenery (taking off from sloped ground is a bitch...)

Image

And walking around parked planes in Ajaccio:

Image

So, I guess I'm just going to start on the adventure then and see what happens. I could use a 3d modeler aboard, so if anyone likes the idea... let me know!
Thorsten
 
Posts: 10840
Joined: Mon Nov 02, 2009 8:33 am

Re: Flightgear on foot

Postby Hooray » Sun Apr 06, 2014 7:18 pm

Thorsten wrote in Sun Apr 06, 2014 6:41 pm:I've cooked up this plan to use FG/ the walker to write something like an action adventure scenario, involving a number of flight and other challenges - for instance finding a crashed plane in the mountains, landing a helicopter close to it and then use the walker to investigate, or flying at night secretly and low to a yacht off the coast, meeting people at certain locations to gain information, or having to cope with a sabotaged plane and a failing engine... with the adventure taking over time and weather settings, and a pricetag for every hour you use a certain plane,...

So, today I did some experiments just walking around, having a look how the scene looks like close up from it


Something like that should be ideally using Stuart's XML-configurable tutorial system (implemented entirely in Nasal), and extended where necessary: http://wiki.flightgear.org/Tutorials
Recently, Marius_A demonstrated what's possible in his "helicopter missions" thread:

Subject: "Mission" for helicopters
Marius_A wrote:Creating "mission" for helicopters.
Currently studying the available tools (Tutorials, GUI, 3D modelling).

Preliminary results:


So it would probably be a good idea to team up with people interested in doing similar stuff, such as Marius_A, but also quite a few other folks:
Subject: Missions
k33bz wrote:At the same time I first started messing around with FGFS I tried out Flight Simulator. To be honest, there was not much difference between the two, at least IMO. Only thing I saw that was there in FS that is not in FGFS is missions. I would love to see missions here in FGFS. Flying just for kicks and flying for Virtual Airliners is all good, but I would like something else to do besides these two things.


You may also want to get in touch with chriscalef: Subject: Flightgear and Unity3D

As you were probably expecting, I'd suggest to create a wiki article dedicated to this, and then add a "call for help" to the newsletter. I can help with Nasal things, and I am sure there are some folks around here, who are into texturing and 3D modeling, who'd love to see "missions" or "adventures" in FlightGear. I am personally not overly interested in "FPS"-style adventures, but I don't mind coming up with the infrastructure required to pull something like that off via Nasal/tutorials
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Flightgear on foot

Postby Thorsten » Mon Apr 07, 2014 5:50 am

Well, obviously I don't need anything on the Nasal side - writing an event managing structure is a matter of 20 minutes at most :-) I specifically asked for a 3d modeler since I'm not particularly good in that department.
Thorsten
 
Posts: 10840
Joined: Mon Nov 02, 2009 8:33 am

Re: Flightgear on foot

Postby DFaber » Mon Apr 07, 2014 6:24 am

Thorsten wrote in Sun Apr 06, 2014 6:41 pm:So, I guess I'm just going to start on the adventure then and see what happens. I could use a 3d modeler aboard, so if anyone likes the idea... let me know!


Obviously I'm interested :-) I gathered some experience while doing the Halloween Adventure (http://forum.flightgear.org/viewtopic.php?f=6&t=21160&p=196570&hilit=Halloween#p192523 ).
Apart from that I'm planning to add interactive NPC (Non-Player- ) Characters to the Walker. What exactly do you need to get modelled?

Greetings
Detlef Faber
FlightGear Development:
http://flightgear-de.net

German FlightGear Forum
http://forum.flightgear-de.net
DFaber
 
Posts: 687
Joined: Fri Dec 01, 2006 7:51 pm
Location: Aachen, Germany
Version: GIT
OS: Linux

Re: Flightgear on foot

Postby Hooray » Mon Apr 07, 2014 11:59 am

Thorsten wrote in Mon Apr 07, 2014 5:50 am:Well, obviously I don't need anything on the Nasal side - writing an event managing structure is a matter of 20 minutes at most :-) I specifically asked for a 3d modeler since I'm not particularly good in that department.


right, I know that you know how to implement such things, but maybe you don't necessarily know how to extend Stuart's existing code accordingly ? And that's something that I can help with.
I'd *really* prefer people not to come up with non-generic scripting-space frameworks for such things, because those building blocks would be useful for the tutorial system itself - so it would be much better to simply extend it where necessary - so that people can use such infrastructure regardless of their particular project.

"event managing structures" are all over the place in hundreds of scripts in FlightGear, including local weather, flug's bombable, the f14, fox2.nas or MapStructure/NavDisplay. The main point being that we should come up with generic code for such purposes rather than having people always re-invent the wheel.
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Flightgear on foot

Postby Thorsten » Mon Apr 07, 2014 3:22 pm

Apart from that I'm planning to add interactive NPC (Non-Player- ) Characters to the Walker. What exactly do you need to get modelled?


Interactive NPCs would be just perfect - a few criminal types, a shepherd, an airplane mechanic,... Otherwise a crashed single engine plane, and a luxury yacht with a helipad. I'm going to utilize the Corsica custom scenery for starters - that has lots of interesting static models already.

"event managing structures" are all over the place in hundreds of scripts in FlightGear, including local weather, flug's bombable, the f14, fox2.nas or MapStructure/NavDisplay. The main point being that we should come up with generic code for such purposes rather than having people always re-invent the wheel.


Well, we don't re-invent the wheel, we target specific code to specific purposes. Managing branching and merging forks of an adventure story has rather different demands than finding out whether your airplane is inside a thermal which moves around with the wind. Which are in turn different from working through an aircraft checklist.

So while they all fall under the header of 'event managing', what's under the hood must look rather different, because the problem is different. Attacking this by general purpose code is making that general purpose code needlessly cumbersome and slow.
Thorsten
 
Posts: 10840
Joined: Mon Nov 02, 2009 8:33 am

Re: Flightgear on foot

Postby Hooray » Mon Apr 07, 2014 3:35 pm

for the sake of the effort, I am not going to respond here anymore ...
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Flightgear on foot

Postby LesterBoffo » Mon Apr 07, 2014 4:25 pm

Thorsten wrote in Mon Apr 07, 2014 5:50 am:Well, obviously I don't need anything on the Nasal side - writing an event managing structure is a matter of 20 minutes at most :-) I specifically asked for a 3d modeler since I'm not particularly good in that department.


Well I'm somewhat skilled with vertexes and surfaces, but the pathway to getting them in FG is a bit, 'adventurous''.

Are those buildings the new autogen stuff? They're pretty much what I had in mind when I suggested ways of making crowded, older, European urban scenery.

The new trees are looking really good, can mere mortals get to try these out before the release?
User avatar
LesterBoffo
 
Posts: 2104
Joined: Sun Oct 02, 2011 4:02 pm
Location: Western USA
Callsign: LesBof
Version: 2016.1
OS: WinXP 32 bit

Re: Flightgear on foot

Postby Thorsten » Mon Apr 07, 2014 4:53 pm

Are those buildings the new autogen stuff?


No - the custom Corsica scenery has plenty of static models - especially the old town cores, watchtowers along the coast, every airport modeled - so it's sort of an ideal playground to test something like walking through the scenery.

I suppose they could be adapted to autogen easy enough though...

The new trees are looking really good, can mere mortals get to try these out before the release?


It's just different texture sheets - I think you can simply grab them from the repository, it should allow to download individual files.

Well I'm somewhat skilled with vertexes and surfaces, but the pathway to getting them in FG is a bit, 'adventurous''.


Not sure what you mean - I'm mainly thinking of Nasal-spawned models here.

for the sake of the effort, I am not going to respond here anymore ...


*shrugs* I'm doing this in an experimental mood - just to play around and explore options, see where it leads, what it may inspire. You're thinking of a formalized project and concrete benefits, which would basically kill the spirit of the whole thing for me. I'm not really interested in working in any pre-defined structure, because then I can no longer explore where I want.

So maybe I go off a bad direction, maybe not, maybe I find something really interesting and useful - that's called research :-) But yeah, I guess you'll have to live with my goals being different from yours here...
Thorsten
 
Posts: 10840
Joined: Mon Nov 02, 2009 8:33 am

Re: Flightgear on foot

Postby LesterBoffo » Mon Apr 07, 2014 5:08 pm

Well I'm not a programmer, so creating Nasal is out, but I can do modded scenery, and new models up to a point, I think human figures are something that Detlef does better.
User avatar
LesterBoffo
 
Posts: 2104
Joined: Sun Oct 02, 2011 4:02 pm
Location: Western USA
Callsign: LesBof
Version: 2016.1
OS: WinXP 32 bit

Re: Flightgear on foot

Postby Hooray » Wed Apr 09, 2014 3:27 pm

Thorsten wrote:Managing branching and merging forks of an adventure story has rather different demands than finding out whether your airplane is inside a thermal which moves around with the wind. Which are in turn different from working through an aircraft checklist.

So while they all fall under the header of 'event managing', what's under the hood must look rather different, because the problem is different. Attacking this by general purpose code is making that general purpose code needlessly cumbersome and slow.


https://en.wikipedia.org/wiki/Finite-state_machine

(and yes, we do have state machine support in SimGear, and we can create trivial state machines using Nasal vectors/hashes, or even PropertyList XML)

There's nothing inherently "slow" about generic code, especially not FSMs.

To a generic state machine class, it doesn't matter at all, if you are going through "checklists", "tutorial stages", "missions/adventures" or even custom avionics systems.

Remember how I suggested to look into octrees/quadtrees for spatial searches when you were optimizing LW/AW ? I did so, because those techniques are an industry standard, that you seemed to be unaware of - so I was trying to be helpful, and I am still trying to be helpful by pointing out things that may not necessarily be obvious (according to your own comments).

Obviously, we can spend all day long doing "research", while completely disregarding existing solutions to trivial problems, using terms like "event management structures" for ultimately non-maintainable and non-generic spaghetti code, that nobody else is going to use or adopt :D
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Flightgear on foot

Postby Thorsten » Wed Apr 09, 2014 5:19 pm

There's nothing inherently "slow" about generic code, especially not FSMs.


There sure is. GLSL where there's a high performance footprint is the prime example. Adapting code to use specific properties (for instance making use of the fact that a water surface is flat and hence has a trivial normal, or that a terrain normal will always be upward pointing for the FG mesh, or similar things) outperforms generic code by a factor two or more. But the specific optimization only works for the specific example.

Nasal event management may have so low an overall performance footprint that the details really don't matter, but the general principle is sound.

Remember how I suggested to look into octrees/quadtrees for spatial searches when you were optimizing LW/AW ? I did so, because those techniques are an industry standard, that you seemed to be unaware of


Yes - except that Stuart found a way to solve the same problem that's specific for the way clouds are implemented which works a factor 100 or so faster which is what we're using now. Which underscores the point that specific code is faster rather dramatically.

Obviously, we can spend all day long doing "research", while completely disregarding existing solutions to trivial problems, using terms like "event management structures" for ultimately non-maintainable and non-generic spaghetti code, that nobody else is going to use or adopt


Frankly, for a project which I want to do for my private enjoyment, I care about understanding the trivial problem, which means I need to work out the solution to it. And in order to understand when it works and what it does, I need to think things through rather than coding 'by the book' and merging pre-existing code blocks. ALS wouldn't exist and wouldn't run as fast as it does if I were content to code 'by the book' - it contains lots of code specifically adapted to the problem.

That's less true for Advanced Weather perhaps, although... going by the feedback I got from several people, there is simply no weather system of similar sophistication anywhere on the market, neither in FSX nor in X-plane nor as addon to any of those. So coding trivial things by the book hasn't delivered anything comparable, whereas my non-generic code did.

So I'd say there's something to be said for out of the box thinking and coding and trying new ways.
Thorsten
 
Posts: 10840
Joined: Mon Nov 02, 2009 8:33 am

Re: Flightgear on foot

Postby Hooray » Wed Apr 09, 2014 5:39 pm

you are making this a "black & white" issue once again - highlighting the merits of hand-crafted GLSL code over generic Nasal code is obviously not going to convince anybody who's even just a CS undergrad - those are very different runtime environments. The octree/quadtree argument also still holds true, because that's exactly the method internally used by OSG - it comes as no surprise that a native/C++ implementation outperforms the Nasal implementation - however, your Nasal implementation predated any C++ efforts in this department, i.e. took place at a time when nobody was even bothering implementing stuff specifically for AW, so I'd say it did serve a purpose. It's obviously unfortunate that the project is not more coordinate to avoid such redundant efforts, but that's the way it is - and as you can see, people trying to do something about it, are having a hard time convicing others to adopt certain approaches :lol:

The GLSL examples you mentioned are prime examples for the fact that algorithmic optimizations beat any micro-optimizations (including hand-crafted Nasal code) - but the whole discussion is kinda ridiculous in the context of simulating missions/adventures in FG, where you typically won't need the performance offered by GLSL (or even native C++ code), as you undoutedly know (and GLSL optimization passes are still fairly rudimentary too in comparison to sequential code).

The whole discussion was not about the "general principle" of generic code being slow - but rather about generic Nasal code not having to be inferior to hand-written "optimized" code given the current scope (MISSIONS/ADVENTURES). Coming up with "performance" as an excuse not to extend existing frameworks (namely Stuart's tutorial system) is not particularly compelling in this particular case :D

In fact, once you start using a generic framework (even just prototyped in scripting space) it can be replaced within minutes by using Nasal/C++ bindings. Something that is really difficult without using established programming techniques, like for example generalization (even just classes and objects).

So what you are basically saying is this: "I do not want to have to use/understand existing libraries/frameworks to play with these ideas", which is obviously fine - but it isn't much different from people coming here wanting to code a weather system in Nasal from scratch, and being told by you, that they /should/ preferably look at AW/LW - because that's exactly what it is doing. even if it may need to be extended for certain things ... :D

Remember those guys that wanted to develop a "combat/dog fighting" system for FlightGear, without wanting to use flug's bombable work ? Or the guy who wanted to do AI missiles without looking at xiii's work ? They didn't want to have _any_ advice, they would come up with arguments like improved flexibility, design, realism, performance (hello !) ... Deja Vu !

I take it that this is one of those cases where you are not easily convinced (i.e. where it may take anywhere from 18-24 months for the realization part to kick in...), but I think we can still help each other by focusing on areas where we do agree, rather than technicalities where we obviously disagree - because you always manage to turn every argument back into something that I never said, which makes you sound right again to the layman -- and I'd really prefer to spend my time differently, and I'm sure you do too :lol:
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Flightgear on foot

Postby Thorsten » Wed Apr 09, 2014 6:22 pm

you are making this a "black & white" issue once again


I don't think so. I didn't claim There's nothing inherently "slow" about generic code, especially not FSMs.

The octree/quadtree argument also still holds true, because that's exactly the method internally used by OSG - it comes as no surprise that a native/C++ implementation outperforms the Nasal implementation - however, your Nasal implementation predated any C++ efforts in this department, i.e. took place at a time when nobody was even bothering implementing stuff specifically for AW, so I'd say it did serve a purpose.


Please make sure you understand the issue before making an argument - we're not using any octree, either in Nasal or in OSG, to specifically focus on clouds in the visual field for movement, we're moving them by a global overall transform without any field of view searches.

but the whole discussion is kinda ridiculous in the context of simulating missions/adventures in FG, where you typically won't need the performance offered by GLSL


Again, you said There's nothing inherently "slow" about generic code, especially not FSMs. and I said Nasal event management may have so low an overall performance footprint that the details really don't matter, so if you find the discussion ridiculous, you should perhaps not have argued that generic code isn't inherently slow, which prompted the GLSL examples in the first place. Please don't push the discussion into a certain direction first to argue later that you find it ridiculous, I didn't say this is particularly relevant for Nasal event management, I said the opposite and you could have simply agreed and backed off your general statement (which is wrong in general, even if that doesn't particularly matter for the specific case).


but it isn't much different from people coming here wanting to code a weather system in Nasal from scratch, and being told by you, that they /should/ preferably look at AW/LW - because that's exactly what it is doing. even if it may need to be extended for certain things ...


I don't usually say that. If asked specifically what support for X we have, I try to answer the question, but I have no opinion either way whether anyone interested in weather should use AW or not.

Remember those guys that wanted to develop a "combat/dog fighting" system for FlightGear, without wanting to use flug's bombable work ? Or the guy who wanted to do AI missiles without looking at xiii's work ? They didn't want to have _any_ advice, they would come up with arguments like improved flexibility, design, realism, performance (hello !) ... Deja Vu !


Obviously it's a decision to be made here, which, dependent on what you want to do and what your abilities and interests are can go either way. I have many issues with Simon, but T4T not contributing to bombable is not one of them.

I frankly don't know what the fuss is about - I made my decision to do things in a particular way, I even explained the why to you, but you seem to be unable to let it stand for some reason. You may even find it stupid (just like plenty of people found the idea to code weather in Nasal stupid, or as a fair number of people find ALS stupid) - which is fine with me. But don't continue this discussion like you can't let go of it and then blame me for continuing the discussion. Thanks.
Thorsten
 
Posts: 10840
Joined: Mon Nov 02, 2009 8:33 am

Re: Flightgear on foot

Postby Hooray » Wed Apr 09, 2014 6:39 pm

well, this is obviously not going to be constructive - I am now inclined to post links to prove you wrong, but that would include C++ code, which you normally don't look at (BTW: the point was NOT moving clouds, but rather selectively updating stuff within the current FOV)- so for the sake of the project (and this thread), I am going to leave it at that, please consider yourself the winner of this totally pointless debate.

PS: No, I was not referring to T4T or them /not/ contributing to bombable. For the record, I still don't have the impression that you actually understood what I was referring to when I suggested the use of a generic FSM component - and that indeed, it would not need to be any slower than your "hand-crafted" Nasal code (probably even faster than your nested conditionals). But maybe it takes others to explain to you the merits of using a FSM for such a standard problem. This time, it's not me who's going to take the time to explain things ... It's still beyond me, how you can come up with GLSL examples to demonstrate that generic Nasal code suffers from performance issues. The point was generalization, having a well-defined interface - and being able to replace it (if necessary) using a native implementation. Coming up with "performance" at a time when there's nothing even running in terms of code suggests "premature optimization" to me. And looking at all the Nasal code in fgdata, I prefer maintainable code over unmaintable code any day, as long as something is maintainable, things can be refactored still.
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Next

Return to Media

Who is online

Users browsing this forum: No registered users and 0 guests