F-20 development

[Flying toaster]

I guess what I was looking for was whether it would cause bad blood. I don't know your opinion on the subject is, I just got the impression thats its not something you were interested in putting time into.

Don't worry, no bad blood, I have played mil sims before and still own DCS and Il-2. It's just I don't want the thing to be turned into a procedure trainer for god knows who. To me this F-20 is merely a high performance aerobatic aircraft, and I added loadouts for the "what if" side of it. I make a difference between shooting pixels and dropping flaming steel splinters on civilians (or poor enrolled sobs who have nothing to do with the quarrel at hand).
So it's OK for you to do what you want of it (open source man) but I will stop short of providing that kind of simulation.

Hope it clarifies

Cheers

Enrique

[swampthing]

Loud and clear.

Thanks

[Flying toaster]

Bumping up the question, yet again... Is it normal that the aircraft transformation matrix is the identity matrix , i.e. the aircraft is the root of the scenegraph ?
If it is so, why is it that the modelview matrix is different for the osg view matrix in GLSL ?

Thanks for any pointers

Enrique

[Thorsten]

I honestly don't know the answer (never had to deal with this part of the code) - maybe Stuart knows this, he's been more busy with the C++ side of rendering.

But it would make some sense (after all, the aircraft is the least moving element from the user perspective). If that's what we're indeed doing, it'd simplify things somewhat...

[Flying toaster]

Now THIS is really weird...
The lighting I get is correct if I compare the absolute position of the light in AC reference frame against the vertex position provided as an input to the shader !


(never mind the color, I just implemented a test shader for light position computation)
As you can see in the shots above, the light is correctly computed after animation (look at the knob) ... Which would indicate that the vertex is given to the shader, after application of the transformation matrix (i.e. scenegraph traversal up/down to aircraft coordinates)... Quite unexpected but quite convenient too ...
That would mean that any fixed coordinate in aircraft reference frame can be fed as world coordinates to the shader program...
I still think it is a bit quirky to take benefit of this situation, but it does seem to work. If anybody can explain the principle behind it, that would be enlightening

Cheers

Enrique

[abassign]

Now THIS is really weird...

My mind is open ... I'm curious to understand it seems very interesting!

[Thorsten]

indicate that the vertex is given to the shader, after application of the transformation matrix (i.e. scenegraph traversal up/down to aircraft coordinates)... Quite unexpected but quite convenient too ...

I probably mixed something up before because I feel confused now (did I mention that I always hated coordinate transformations?), but here it goes:

The vertex that's given to the shader (gl_Vertex) is always in aircraft coordinates (as in your *.ac model). That's also true for any child-models you include - if an instrument is modeled in its own coordinate frame, than this is what gl_Vertex contains.

ALL transformations relative to the camera point, regardless of whether they're caused by eye movement, by submodel include offsets or by rotation, translation or scale tags or by plane movement and attitude change for models not attached to the plane - all these end up in gl_ModelViewMatrix.

So before applying gl_ModelViewMatrix you do not have a continuous coordinate system across your plane between itself and child models - only after applying it you have.

So referring to your statement above, to the best of my knowledge no vertex ever is given to the renderer after the application of any matrix - the vertex shader gets the raw vertex and the matrix and decides upon how to apply it by itself.

[Flying toaster]

So before applying gl_ModelViewMatrix you do not have a continuous coordinate system across your plane between itself and child models - only after applying it you have.

So referring to your statement above, to the best of my knowledge no vertex ever is given to the renderer after the application of any matrix - the vertex shader gets the raw vertex and the matrix and decides upon how to apply it by itself.

As much as I would agree with you on a theoretical point of view, I get the images you see above with the following piece of code :
vertex shader

Code: Select all

varying vec4 ecPosition;
varying vec4 transformed_position;
varying vec3 normal;


void main()
{   
   transformed_position = vec4 (-3.65, 0.7, 0.5, 0.0);   
   normal = normalize(gl_NormalMatrix * gl_Normal);
    ecPosition =  gl_Vertex;
    gl_Position = ftransform();
}


fragment shader

Code: Select all

varying vec3 normal;
varying vec4 transformed_position;
varying vec4 ecPosition;

void main()
{
   vec3 n = vec3 (1.0, 0.0, 0.0);
   vec3 lightDir = vec3 (-1.0, 1.0, 0.0);;
   float NdotL = 0.5;
   float Ndot2 =  0.0;
   vec4 color = vec4 (0.0, 0.0, 0.0, 1.0);
   float att, dist;
   
    n = normalize(normal);
   
    lightDir = vec3 (transformed_position - ecPosition);
     
    dist = length(lightDir);
    NdotL = max(dot(n, normalize(lightDir)),0.0);
    Ndot2 = dot (normalize(lightDir), normalize(vec3 (0.2, 0.2, 1.0)));

    if (NdotL > 0.0)
   {   
        att = 2.0 / (dist * dist) * exp (-1/(Ndot2*Ndot2*Ndot2*Ndot2*Ndot2*Ndot2*Ndot2*Ndot2*Ndot2*Ndot2*Ndot2));
        color += att * (vec4(1.0, 0.0, 0.5, 1.0) * NdotL);
    }
    gl_FragColor = color;
   
}


As you can see I do all the computation in the original (not transformed by the modelview matrix) reference frame. And the images are still correct after application of the transformation (the rightmost knob rotation).
Hence my surprise !

[Thorsten]

Code: Select all

   normal = normalize(gl_NormalMatrix * gl_Normal);

This supplies the normal in eye coordinates to the fragment shader.

Code: Select all

    lightDir = vec3 (transformed_position - ecPosition);

Despite the name, this establishes the light direction in model coordinate space.

Code: Select all

 n = normalize(normal);
(..)
NdotL = max(dot(n, normalize(lightDir)),0.0);

This forms a dot product between an eye space vector and a model space vector - if this gives reasonable results, it's by mere accident.

[Flying toaster]

This forms a dot product between an eye space vector and a model space vector - if this gives reasonable results, it's by mere accident.

You are definitely right... That being said, I remove the glNormalMatrix... And it gives exactly the same result... This is getting weirder every time

[Necolatis]

I noticed the blackout values are set to 8.5-11 G.

That will work for older FG versions, but you probably want to update that for FG 2017.1+, as blackout now works differently.

You can see the details here: http://wiki.flightgear.org/Howto:Add_bl ... t_settings

[J Maverick 16]

Any updates on the subject? I've downloaded it per chance today and got really in love with it. Congrats to all the developers that worked for it really.
Regards, Mav

[Flying toaster]

I have been developping a good 99% of it. Right now I am working on the comms system. Is there an operating UHF radio system around ?
Also I have put the non rembrandt lighting system way on the backburner. It is possible to do forward rendering lighting in shaders but OSG obfuscates a bit too much the rendering process for me to do that in the short term.
Next step is to have the ECS and Rembrandt lights working.

Cheers

Enrique

[Thorsten]

.

It is possible to do forward rendering lighting in shaders but OSG obfuscates a bit too much the rendering process for me to do that in the short term.

The Compositor will do that in the short to mid-term (and Rembrandt will be discontinued once the compositor is in place).

[Flying toaster]

Progress on lights