Re: [Flightgear-devel] Properly rendering terrain data from FlightGear using OpenGL

[Samuel C. <sam...@gm...>]

On Thu, 3 Sep 2020 20:48:52 +0100
James Turner <ja...@fl...> wrote:

> > On 3 Sep 2020, at 17:49, Samuel CUELLA <sam...@gm...>
> > wrote:
> > 
> > Now how could I render a terrain tile like if I was flying over it
> > at say the center, a given altitude with 0 roll (parallel to the
> > earth), 0 pitch (parallel to the earth) and heading north ? I
> > couldn't find how FlightGear is doing it.
> > 
> > The code I have to translate lat,lon alt to X,Y,Z (ECEF) seems to
> > work (I get the right tile) but then I'm struggling with how
> > position the "camera" to render the tile as if I was flying as said
> > earlier.  
> 
> Look at places that use SGQuat::fromLonLatRad,
> SGQuat::fromYawPitchRollDeg and so on in the code, this should help.
> 

I've started there, then given up and used DSTO–TN–0640 PDF by Don Koks 
which gave me some kind of results.

I'm going to start again there. I've re-read the code in
simgear/tgdb/obj.cxx where it loads btgs files. What fg does is:
a) Create hlOr SGQuat (Local Horizon?) from the tile bounding sphere
center, AND a rotation of 180 on Z (line 76):

SGQuatd hlOr = SGQuatd::fromLonLat(geodPos)*SGQuatd::fromEulerDeg(0,
0, 180);

Does this second rotation of 180 about Z has anything to do with
converting ECEF(Z up) axis to OpenGL (Z near/far)?

b) Apply that to all nodes and normals.

--Previously I had stopped there and I think that was why I didn't get
too far with this.--

c) Create a matrix (lines 106-107) that represent a translation to the
tile gbs center and a rotation by that hlOr quat:

// The toplevel transform for that tile.
osg::MatrixTransform* transform = new osg::MatrixTransform;
transform->setName(path);
transform->setMatrix(osg::Matrix::rotate(toOsg(hlOr))*
                     osg::Matrix::translate(toOsg(center)));
 
I understand that I need to apply this first (when working with that
tile ofc) to be at roll/pitch/yaw = 0
and alt = gbs_center.alt and then appy the SGQuat given by
SGQuat::fromYawPitchRoll to get the correct attitude I want. Is that
correct? What about the altitude then?

> It does assume you are familiar with quaternions to express
> rotations, unfortunately.
Well, I guess I will have to work on that too. 

> 
> As noted elsewhere, you absolutely have to work in doubles in the
> intermediate matrices for sufficient precision, and you need to build
> a view matrix with the camera+world offset combined, so that your
> final view transformation (which becomes your uniform) does not push
> the floats into unstable territory. Once you have your combined view
> matrix as doubles in the CPU, you can work in floats on the GPU side,
> at least for standard rendering. (You might still need more than
> floats for various lighting / depth techniques, depending on the view
> range you want, but that’s a problem for later)

That really is interesting. I wasn't aware of doubles being mandatory
and I thought I could get away with floats. It might be the cause of the
shaking I experience. Unfortunately the math lib I work with (cglm)
only support floats. I'll have to find a way to do without it but I will
definitively give a try at using doubles everywhere to see if this
eliminates the shaking.

> 
> Kind regards,
> James
> 
> _______________________________________________
> Flightgear-devel mailing list
> Fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel