Question 3D, D3D9Client, Orulex

[shacharm]

Hi!
Couldn't find a straight answer in the forums
with Orulex, 3d up close on the moon, 3d looks good. From far away, it looks really bad though. when using D3D9Client remotely it looks really good
but I couldn't figure out if the D3D9Client makes the terrain 3D and no just a flat image?
Thanx in advance!

 

[Ripley]

Actually D3D9 itself doesn't have built-in terrain capabilities.
Jarmonik has plans to add it, but in the future.

 

[shacharm]

thanks for the quick reply
is there a way to retrieve the height, as in
h = DTM(lat, lng) ?



**in orulex there's ORUGetElevByVec(), which I used as follows to receive height above ground



double getHeightAboveTerrain(double lat, double lon)
{

double terrainElevation;
VECTOR3 gposSurfPoint, gposMoon;
oapiGetGlobalPos(theMoon, &gposMoon);
oapiEquToGlobal(theMoon, lon, lat, oapiGetSize(theMoon), &gposSurfPoint);
gposSurfPoint -= gposMoon;
terrainElevation = ORUGetElevByVec(v32v4(gposSurfPoint));
return (double)(terrainElevation - oapiGetSize(theMoon));
}

---------- Post added 09-18-12 at 07:00 AM ---------- Previous post was 09-17-12 at 09:13 AM ----------

Actually I started using the D3D11Client, is there kind of function there? (get height out of lat,lng)?

 

[Ripley]

...I don't even understand your question

Try asking directly in D3D11 subforum.
http://orbiter-forum.com/showthread.php?t=25040

 

[shacharm]

thanks, I will
my question was if there's a way to retrieve surface height as a function of latitude and longitude..

 

[Quick_Nick]

I'm almost certain that D3D9 currently has nothing to do with 3D terrain. (and surely the same for D3D11)

 

[Ripley]

Right about D3D9 (without the "almost").

Wrong about D3D11
http://www.orbiter-forum.com/showthread.php?p=365614&postcount=574

 

[jarmonik]

my question was if there's a way to retrieve surface height as a function of latitude and longitude..

No, there is no such function in the Orbiter. However, there is a small chance that a next version might have. (or might not)

D3D9Client doesn't provide 3D terrain because there is no collision detection from the Orbiters side and therefore 3D terrain isn't that good if you can't land on it. I will start my work with a 3D terrain when I receive a confirmation from Martin that a proper surface collision detection will be provided.

 

[asmi]

No, there is no such function in the Orbiter. However, there is a small chance that a next version might have. (or might not)

D3D9Client doesn't provide 3D terrain because there is no collision detection from the Orbiters side and therefore 3D terrain isn't that good if you can't land on it. I will start my work with a 3D terrain when I receive a confirmation from Martin that a proper surface collision detection will be provided.

Well I'm in the same boat with you here (in regards of physics), besides I really badly suck in mechanics to implement proper physics

But I've got a feeling that Martin is super-busy with some other stuff, so unless someone from community will bother to implement such a library, we will be slated for waiting for a very long time...

 

[jarmonik]

Well I'm in the same boat with you here (in regards of physics), besides I really badly suck in mechanics to implement proper physics
But I've got a feeling that Martin is super-busy with some other stuff, so unless someone from community will bother to implement such a library, we will be slated for waiting for a very long time...

I suppose a resonable work-a-round to provide a surface collision is to add a new callback function into a client.

clbkGetSurface(VECTOR3 vessel_pos_in, double &radius_out, VECTOR3 &normal_out, int idx=-1)

Orbiter would pass a vessel position vector to this callback function and would receive a planet radius and surface normal vector. Orbiter could still assume the surface to be flat (a plane). However, having an ability to change the orientation and altitude of this plane would make the surface collisions reasonable and shouldn't be too difficult to implement.

EDIT: idx would be the index of touchdown point if used.

 

[asmi]

I suppose a resonable work-a-round to provide a surface collision is to add a new callback function into a client.

clbkGetSurface(VECTOR3 vessel_pos_in, double &radius_out, VECTOR3 &normal_out)

Orbiter would pass a vessel position vector to this callback function and would receive a planet radius and surface normal vector. Orbiter could still assume the surface to be flat (a plane). However, having an ability to change the orientation and altitude of this plane would make the surface collisions reasonable and shouldn't be too difficult to implement.

This approach will be too coarse - at very minimum we need to return heights and normals for touchdown points. Since Martin has already told that he has implemented collision meshes, this mey very well turn into a big bottleneck - remember we're talking about calling potentially a lot of virtual methods.
The second, more subtle issue is there might be multiple normals for a point if surface function is not smooth - and it will have discontinues due to very nature of sampling unless we take specific care to smooth it out - imagine a point on the very peak of the hill - shall the normal point to the +x, or maybe -x, +z or -z?

P.S. I recall that we've already had this discussion some time in the past, hadn't we?

 

[jarmonik]

P.S. I recall that we've already had this discussion some time in the past, hadn't we?

No, we haven't discussed about this. But I did find the "Orbiter Dynamics News" thread and there was a lot of discussion about this. But I am not aware of any other thread about this subject.

This approach will be too coarse - at very minimum we need to return heights and normals for touchdown points. Since Martin has already told that he has implemented collision meshes, this mey very well turn into a big bottleneck - remember we're talking about calling potentially a lot of virtual methods.
The second, more subtle issue is there might be multiple normals for a point if surface function is not smooth - and it will have discontinues due to very nature of sampling unless we take specific care to smooth it out - imagine a point on the very peak of the hill - shall the normal point to the +x, or maybe -x, +z or -z?

Yes, you are right about it, it's coarse. But my point is that it's better than nothing and it would be pretty simple to implement from Orbiter's side and in that case the orbiter would compute the collisions between a collision mesh and a plane.

But, of course, if the Orbiter must call a function like that for every vertex in a collision mesh then it might become a performance problem. Difficult to say without exact details. EDIT: There shouldn't be any problems if the vertex count is no more than 100

 

[asmi]

Yes, you are right about it, it's coarse. But my point is that it's better than nothing and it would be pretty simple to implement from Orbiter's side and in that case the orbiter would compute the collisions between a collision mesh and a plane.

But, of course, if the Orbiter must call a function like that for every vertex in a collision mesh then it might become a performance problem. Difficult to say without exact details. EDIT: There shouldn't be any problems if the vertex count is no more than 100

The problem with that is once we have something like this implemented - we effectively have two heights - one is "planetary altitude" that is effectively height above "sea level", and "true altitude" which is altitute from that specific point on surface to the vessel. This will screw up all autopilots, and some other pretty useful MFDs. So there is more than just collision response here - and I guess that is exactly why Martin is reluctant to implement anything like that...

 

[jarmonik]

The problem with that is once we have something like this implemented - we effectively have two heights - one is "planetary altitude" that is effectively height above "sea level", and "true altitude" which is altitute from that specific point on surface to the vessel. This will screw up all autopilots, and some other pretty useful MFDs. So there is more than just collision response here - and I guess that is exactly why Martin is reluctant to implement anything like that...

Yes, that's one of the biggest reasons why I haven't been so much interested about the 3D terrain. I belive I have said that it would fundamentally break everything about one and half years ago. But it's up-to Martin what he desides to do. There could be a check box in a visual effect tab to enable 3D terrain features. But every add-on would need to be remade to support a 3D terrain by replacing some function calls with an other one. And probably some more... I don't know exactly.

There are a few work-a-rounds to fit a reasonable 3D terain into the Orbiter even if Martin would deside not-to implement it. But it's a complicated issue since there are more than just a terrain and multible heights involved in it. Currently the D3D9Client project is pretty much on hold and I am waiting.

 

[shacharm]

well, this turned out to be a really useful discussion actually.

Well, as I said Orulex had ORUGetElevByVec()
As was mentioned, the D3D11 does provide 3D height and actually, as I've set it up, I can see the 3D structure already.

Browsing the D3D11 source code shows there are references to ground height. My idea is just to recompile it and to use the orbitersdk to get extract the heights.
If and when finished, I guess I'll upload a branch to the D3D11 repository, if this interests anyone.


now I've got to ask, as it appears in google earth too.
what does sea level height means on the moon?

 

[asmi]

well, this turned out to be a really useful discussion actually.

Well, as I said Orulex had ORUGetElevByVec()
As was mentioned, the D3D11 does provide 3D height and actually, as I've set it up, I can see the 3D structure already.

Browsing the D3D11 source code shows there are references to ground height. My idea is just to recompile it and to use the orbitersdk to get extract the heights.
If and when finished, I guess I'll upload a branch to the D3D11 repository, if this interests anyone.

I still don't quite understand what are you trying to achieve. There are pretty precise heightmaps for D3D11Client that contain an actual geographical data, but for now this data is internal to the client since Orbiter doesn't support it.

now I've got to ask, as it appears in google earth too.
what does sea level height means on the moon?

The same thing it means for Earth - it's an agreed-to point of reference.

 

[kamaz]

what does sea level height means on the moon?

Reference sphere with some pre-agreed radius, usually about 1737km.

The exact radius depends on the dataset being used. Kaguya datasets use R=1737.4km and LRO uses 1737km.

 

[BruceJohnJennerLawso]

Reference sphere with some pre-agreed radius, usually about 1737km.

The exact radius depends on the dataset being used. Kaguya datasets use R=1737.4km and LRO uses 1737km.

Is it set at our best guess of the lowest point on the moon, or closer to an average of it?

 

[asmi]

Is it set at our best guess of the lowest point on the moon, or closer to an average of it?

It's a mean radius: [ame="http://en.wikipedia.org/wiki/Moon"]Moon - Wikipedia, the free encyclopedia[/ame]