Board index FlightGear Development Aircraft

F-20 development

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

Re: F-20 development

Postby Flying toaster » Thu Dec 01, 2016 4:56 pm

vanosten wrote in Thu Dec 01, 2016 4:22 pm:Why not FGAddon?

Not yet ... I want the thing as complete as possible before committing it to FGAddon ...
It is not production status as it stands
But feel free to send feedback on the development versions ;)
Flying toaster
 
Posts: 353
Joined: Wed Nov 29, 2006 6:25 am
Location: Toulouse France

Re: F-20 development

Postby wkitty42 » Thu Dec 01, 2016 6:17 pm

FGAddon would be the best as the craft would be able to be downloaded and used most easily...

of course, if you really want to distribute via an archive like zip, dropbox also works... it is similar to google drive and other cloud storage services...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 6133
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: F-20 development

Postby Josh_grtuxteam » Fri Dec 02, 2016 2:20 pm

Hi, Flying toaster

Since i got some issues with granting for right access to fgaddon, i am using sourceforge, which is to me perfect.
They are serious.
I am not flooded with spam.
The support is perfect.

I do use SVN and i create a zip file once a week.
So anyone interested can have access and download.

@wkitty42 for sure for the end user fgaddon would be better, however for the "developper" there is not any difference
my link https://sourceforge.net/projects/grtuxsimfg/


Cheers

Josh
User avatar
Josh_grtuxteam
 
Posts: 107
Joined: Mon Oct 17, 2016 2:58 pm
Location: France
Version: lastStable
OS: Linux OpenSUSE

Re: F-20 development

Postby Thorsten » Fri Dec 02, 2016 3:48 pm

There's different development philosophies.

Many people prefer to make versions available early to everyone, even with things manifestly not ready. The advantage is feedback, the disadvantage is being drowned in irrelevant feedback and having to commit plenty of time for support. Another advantage is that this may attract people to join the development, which turns into a disadvantage if you don't really want that.

Others prefer to make versions available to some limited community such as to gather feedback without creating support issues.

Yet others prefer to finish the job, then make it available.

As far as I can see, these are all legitimate. I'm perfectly certain Enrique knows how FGAddon works and makes his choices according to his best judgement - and that's all there is to say. I've had a great time with the F-20 as well as the X-15, and I'd love to see them on FGAddon - when the developer is ready to put them there.

And Josh - please note that your planes can go to FGAddon if you'd like to see them there even if you don't have commit access. There's several ways in which a trusted committer could handle that for you while you remain 100% anonymous to everyone else - it's your call basically.
Thorsten
 
Posts: 11467
Joined: Mon Nov 02, 2009 8:33 am

Re: F-20 development

Postby wkitty42 » Fri Dec 02, 2016 11:18 pm

if i'm not mistaken, someone on the dev list did exactly offer that service to josh, too... i don't know if it was just missed or misunderstood but...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 6133
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: F-20 development

Postby Flying toaster » Sun Dec 04, 2016 8:20 am

Fiddling with integral lighting:

Image

Now on to C++ hacking ;)
Flying toaster
 
Posts: 353
Joined: Wed Nov 29, 2006 6:25 am
Location: Toulouse France

Re: F-20 development

Postby abassign » Sun Dec 04, 2016 8:47 am

Flying toaster wrote in Sun Dec 04, 2016 8:20 am:Fiddling with integral lighting:
Now on to C++ hacking ;)


Nice effect :D
Why C++ ?
abassign
 
Posts: 831
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: F-20 development

Postby Flying toaster » Sun Dec 04, 2016 9:07 am

abassign wrote in Sun Dec 04, 2016 8:47 am:
Nice effect :D
Why C++ ?


Thanks !
And the answer is, because of flood lights, which are a pain to implement as light maps given my texture mapping habits ;)
Flying toaster
 
Posts: 353
Joined: Wed Nov 29, 2006 6:25 am
Location: Toulouse France

Re: F-20 development

Postby wlbragg » Sun Dec 04, 2016 10:15 am

Flying toaster wrote in Sun Dec 04, 2016 9:07 am:because of flood lights, which are a pain to implement as light maps given my texture mapping habits ;)

Yeah, that can really put a damper on creating a nice light map!
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
wlbragg
 
Posts: 5218
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: F-20 development

Postby Flying toaster » Sun Dec 04, 2016 6:42 pm

I am in a proof of concept stage.
Basically to make my shader work I need the aircraft transform matrix accessible from GLSL.
These are the modifications I have made, and it seems to work somewhat:

1/ Declare a uniform in acmodel.hxx
Code: Select all
osg::ref_ptr<osg::Uniform> _aircraft_model_matrix_uniform;

2/ Initialise the Uniform in acmodel.cxx FGAircraftModel::init
Code: Select all
_aircraft_model_matrix_uniform = new osg::Uniform("aircraft_model_matrix", new osg::Matrixd());

3/ Update periodically the uniform acmodel.cxx FGAircraftModel::update
Code: Select all
 
   //Update the model matrix for the aircraft and export it as a uniform
   osg::MatrixList matrices = _aircraft->getSceneGraph()->getWorldMatrices(_aircraft->getSceneGraph());
   //extract from matrix list
   if (matrices.size() != 0)
   {
   // std::vector<osg::Camera*> cameras;
   // globals->get_renderer()->getViewer()->getCameras(cameras);
    _aircraft_model_matrix_uniform->set(matrices[0]);
    osg::StateSet* current_state_set = _aircraft->getSceneGraph()->getStateSet();
    if (current_state_set) current_state_set->addUniform (_aircraft_model_matrix_uniform);   
  }

I feel the fetch of state_set and addition of Uniform may be completely a waste of resources (the rest of the code may be too :oops: ), but I did so to be on the safe side. Any idea to make this better ?

Once you have this matrix, using the osg_ViewMatrix, you can take an aircraft coordinate and direction vector (the light position) to do your lighting computations...
Actually I had the thing working on a very simple diffuse shading shader. So that should do the trick.
Modifying the ALS-ultra shader is kind of hairier ...
Flying toaster
 
Posts: 353
Joined: Wed Nov 29, 2006 6:25 am
Location: Toulouse France

Re: F-20 development

Postby Thorsten » Mon Dec 05, 2016 6:36 am

I guess I'm confused.

You have a light source at given position in aircraft model coordinates. You have the aircraft mesh (including, say, an elevon), in aircraft model coordinates. If the elevon would not move, you could compute all in aircraft model coordinates.

Now the elevon does move and gets a matrix describing that movement from the animation. As a result, going from model to view coordinates is different for aircraft and light vs. elevon, i.e. gl_ModelViewMatrix (elevon) != gl_ModelViewMatrix (light). Which is why the elevon would receive different light once it moves.

What you'd like to have when running the shader over the elevon is how the light position would look like in elevon view coordinates. So which of these matrices did you expose, and how does it solve the problem?

Any idea to make this better ?


Not really - I have tinkered some with the C++ side of things, but mainly I work with GLSL, so I don't really consider myself very knowledgeable for setting up rendering.

Conceptually, the question is a bit - to which effects does this matrix get exposed? It runs into the old multiple light source problem that once the shader has the capability of rendering n light sources, it's going to use the resources for n even if you have just 1, so for best performance you ought to use different shaders dependent on the number of light sources (that is one of the main appeals of deferred rendering).

Modifying the ALS-ultra shader is kind of hairier ...


Not really - you just look where gl_LightSource[0] is used, and you add your lines below there.
Thorsten
 
Posts: 11467
Joined: Mon Nov 02, 2009 8:33 am

Re: F-20 development

Postby Flying toaster » Mon Dec 05, 2016 11:58 am

Thorsten wrote in Mon Dec 05, 2016 6:36 am:I guess I'm confused.

You have a light source at given position in aircraft model coordinates. You have the aircraft mesh (including, say, an elevon), in aircraft model coordinates. If the elevon would not move, you could compute all in aircraft model coordinates.

Now the elevon does move and gets a matrix describing that movement from the animation. As a result, going from model to view coordinates is different for aircraft and light vs. elevon, i.e. gl_ModelViewMatrix (elevon) != gl_ModelViewMatrix (light). Which is why the elevon would receive different light once it moves.

What you'd like to have when running the shader over the elevon is how the light position would look like in elevon view coordinates. So which of these matrices did you expose, and how does it solve the problem?

What I want is the aircraft matrix, not the elevon matrix to place the light. Why ? Because most lights are on non moving parts of the airframe. That way I can define the location of the lights in model (airplane) coordinates. In vertex shader I transform the coordinates of this light in view coordinates (which I can't by using the default modelview matrix, which is attached to the elevon in your example), and in fragment shader, I can make the lighting computations with that view position.
That won't help you with other kind of lights. for your booster or a flare, you would want the light attached to that moving part. It would be feasible in C++ by having a registry of lights that are added according to the xml object file. But the modification of C++ is less straightforward, and I still have to prove that my limited mod works.

Thorsten wrote in Mon Dec 05, 2016 6:36 am:Conceptually, the question is a bit - to which effects does this matrix get exposed? It runs into the old multiple light source problem that once the shader has the capability of rendering n light sources, it's going to use the resources for n even if you have just 1, so for best performance you ought to use different shaders dependent on the number of light sources (that is one of the main appeals of deferred rendering).

Could not agree more, it still is a hack... But since ALS and deferred seem mutually exclusive and deferred has a serious performance hit (I wish I had time to fix that but ...) This method is still much less demanding in work compared to the lightmaps, and more flexible than the view fixed workaround implemented for the flashlight for instance.

Thorsten wrote in Mon Dec 05, 2016 6:36 am:Not really - you just look where gl_LightSource[0] is used, and you add your lines below there.

Will have a look, thanks !
Flying toaster
 
Posts: 353
Joined: Wed Nov 29, 2006 6:25 am
Location: Toulouse France

Re: F-20 development

Postby Flying toaster » Sun Dec 11, 2016 8:18 pm

Now the smoke generators work (activated through the jettison button
Image
Some more effects ... I am hesitating. Mipmap makes the texture ugly, but going to 4096 textures (easy) might be too much in terms of size and frame rate hit.
Image
And the complete F-20C cockpit (without floodlights yet)
Image
Quite a busy office
Flying toaster
 
Posts: 353
Joined: Wed Nov 29, 2006 6:25 am
Location: Toulouse France

Re: F-20 development

Postby Johan G » Mon Dec 12, 2016 6:38 pm

If you later on would need more data on the real Smokewinder generators there is a detailed manual on the bottom of the Sanders Smoke Technologies Smokewinder product page. A popular and nearly ubiquitous smoke generator.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5634
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: F-20 development

Postby Flying toaster » Mon Dec 12, 2016 6:53 pm

Johan G wrote in Mon Dec 12, 2016 6:38 pm:If you later on would need more data on the real Smokewinder generators there is a detailed manual on the bottom of the Sanders Smoke Technologies Smokewinder product page. A popular and nearly ubiquitous smoke generator.

Thanks for the heads up,
Actually I checked out that reference in doing the smokewinder. Quite a heavy thing to put on (heavier than the real sidewinder). For the time being mine does not consume its oil and neither does it run out of it. In future versions I might add that, plus a choice of colors (why not ?).
Also, as I do not intend to model the weapons systems (I even hesitate putting some loadouts on the coming release), you activate it by using selective jettison. And actually that should work on the real thing too ;)
Flying toaster
 
Posts: 353
Joined: Wed Nov 29, 2006 6:25 am
Location: Toulouse France

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: Applebot [Bot] and 5 guests