Meshing Question Planet meshes

[iamtheari]

Hi everyone. This is my first post on this forum, although I was semi-active at various times on the M6 boards back when I spent too much time Orbiting.

I am getting interested in making meshes and such, and one thing that's outside my realm of experience is how planets work. I know that it's been asked before (here, for instance) about how to define a non-spherical planet. I've read a bit and here's what I know.

The version of a planet that gets rendered to the screen depends on the planet's size on the user's screen. If it's going to show up as a single pixel, it's not rendered with full cloud layers and such, but if it's going to take up the entire screen then you get the full Monty.

Planet configuration files have a Max Resolution setting. If it's 0, then a textured mesh is always used to render the planet.

Planets that are not rendered as a textured mesh or single colored pixel are rendered by showing the appropriate pieces of the spherical surfaces of those planets with the appropriate pieces of texture. The size of the spherical pieces and the textures rendered on them depend on the planet's size on the screen. This is the selector for level 8, level 11, level 14, etc. textures.

Is all that right so far?

What I definitely do not know is how a person can properly make a very large non-spherical planet. Or, for that matter, a mostly spherical planet with some parts of the surface built as meshes when you get close enough. For instance, mountains. Are they doable without a single mega-mesh for an entire planet?

I'm curious to learn more, so please don't be shy about telling me anything, no matter how basic or how advanced it is. Thanks!

 

[Rtyh-12]

Answer

What I definitely do not know is how a person can properly make a very large non-spherical planet. Or, for that matter, a mostly spherical planet with some parts of the surface built as meshes when you get close enough. For instance, mountains. Are they doable without a single mega-mesh for an entire planet?

You can do it, for example putting a mountain mesh around Brighton Beach, (I think it has already been done:[ame="http://orbithangar.com/searchid.php?ID=2949"]http://orbithangar.com/searchid.php?ID=2949[/ame]). It makes it look far more realistic. It also exists on Mars, at Olympus Mons or Vallis Dao. Wideawake International also has some mountains on Ascension Island.

By the way, there is also a HUGE mesh of the entire moon, but it has problems, for example Brighton Beach is an few hundred meters under the surface...

Planet configuration files have a Max Resolution setting. If it's 0, then a textured mesh is always used to render the planet.

No idea about that, sorry, I can't give you more details, except the following from the Phobos.cfg file:

; === Visualisation Parameters ===
AlbedoRGB = 0.37 0.36 0.39
MaxPatchResolution = 0           ; use explicit mesh

so I guess you're right.

Apart from that, no idea. I hope this helped.:thumbup:

 

[orb]

You can make highly detailed global terrain for mostly spherical (large moons, planetoids) planets with [ame="http://www.orbithangar.com/searchid.php?ID=2686"]Orulex_Land_Gen-v1.2[/ame] and Orulex for Orbiter 2010 and it's also a part of OGLAClient used with Orbiter_NG.

Orulex doesn't slow down the simulation much, because non-spherical high level terrain meshes are generated only for the current field of view, near the surface. It's like level 9-14 textures, that are used only for a part of planet that is currently in field of view. You can provide heightmaps for Orulex/OGLA that will be used for rendering those meshes.

Only for a local terrain, and the rest of planet spherical, you can use meshes placed at bases, like in mentioned by Rtyh-12 add-on that places a mountain mesh around Brighton Beach.

For highly non-spherical (small) bodies, like some moons or planetoids, you do what you already said, so a mesh for that body, and MaxPatchResolution set to 0.

 

[iamtheari]

Can anyone explain exactly how MaxPatchResolution works when it's not set to 0?

 

[orb]

MaxPatchResolution is the maximum texture level for a body. If you set it to 1, the maximum texture level will be also 1 for that body, and no higher resolution level will be used, even if it's present in the .tex file. The number of faces of the mesh of that planet's surface also depends on the texture level. For example if you set "MaxPatchResolution = 1" for Earth, you'll notice it's no longer visually a sphere but a polygon. If you set it to 10, but you have level 14 textures, the maximum level used in the simulation will be only 10. MaxPatchResolution is used to limit the maximum level of texture for planets/moons. Meshes are only used for those bodies when MaxPatchResolution is set to 0.

 

[iamtheari]

Is 0 a special case or is it just the way things work because it's 0? In other words, does 0 signify "just use a mesh" and any other number signify "never use a planetary surface mesh"?

Mostly what I'm getting at is this: Do you have to choose between a meshed planetary surface with MaxPatchResolution = 0 versus a spherical surface with the only surface features being the land/water mask and surface base mesh objects, or can you have a spherical planet with some sections done as surface meshes?

 

[orb]

0 signify "just use a mesh" and any other number signify "never use a planetary surface mesh"

^ This ^, but I'd rather interpret it as: 0 - "don't use planetary textures applied to sphere, and instead use a mesh that defines its own texture", other numbers - "use planetary textures applied to sphere, but with no higher texture level than specified".

Mostly what I'm getting at is this: Do you have to choose between a meshed planetary surface with MaxPatchResolution = 0 versus a spherical surface with the only surface features being the land/water mask and surface base mesh objects, or can you have a spherical planet with some sections done as surface meshes?

I have already written how to make a spherical planets with some parts using mesh for terrain. I think it should be clear.

 

[iamtheari]

I'll read it in more detail and see how well I understand it. Knowing that 0 is a special case for that variable will help substantially, I think, in my general understanding of Orbiter.

 

[iamtheari]

Okay. So my understanding is that planets, in the base Orbiter program, are either textured meshes with a maximum texture resolution set to 0 (such as Phobos) or spherical surfaces, divided (automatically? pre-calculated?) by Orbiter into small pieces. Orbiter calculates which "level" to render a planet at based on the angular size of the planet on the user's screen. That level determines both the number (and thus size) of pieces and the size of the textures that are wrapped on them.

Surface bases are an entirely different creature and are rendered as meshes on a planet's spherical surface.

Is that understanding fairly complete or at least accurate for the small amount of information it contains?

 

[orb]

You got the first part right.

Surface bases alone aren't meshes. If you use surface tiles in bases, they are rendered on the sphere of planet. The objects that can be placed in bases can be meshes - either predefined Orbiter meshes, as hangars, blocks, etc. or user created meshes read from .msh files. You can for example make a part of terrain in .msh file, and place it in the base by using MESH entry in object list.

Whether bases are mapped to planet's sphere is determined by MapObjectsToSphere flag in the base configuration file, but larger user defined meshes need to be curved properly to planet's surface even if you use this flag, otherwise edges of it will be floating, as also meshes placed far from the center of base will be more inclined, because only the center (0,0,0) point of the mesh is mapped to sphere.

 

[iamtheari]

What exactly does MapObjectsToSphere do? Both on and off, that is--what does it mean?

 

[Tommy]

If set to false, all meshes will be mapped to a plane. For small bases this is OK, but on larger bases meshes far enough from the center (origin) will appear to hang above the ground due to the curvature of the Earth.

If set to true, meshes are mapped to a sphere (size of sphere determined by planets radius). This corrects the "hanging in air" issue. However, while this corrects the location of the mesh, it doesn't change the rotation of the mesh. Meshes will always be rotationally aligned with the origin, so as Xyon mentioned, meshes far from the center will appear to be tilted toward the center. However, this is only really noticeable on very large bases. The work-around for that, of course, is to plan ahead and have the meshes "pre-rotated" depending on the direction and distance from the origin.

I don't recall how this option affects things like runways, but I seem to recall that it affects L-Pads, so they shouldn't be placed to far from the base's origin.

 

[Xyon]

so as Xyon mentioned, meshes far from the center will appear to be tilted toward the center...

Hmm? I said what now? This is my first post in here.

 

[Tommy]

Hmm? I said what now? This is my first post in here.

Opps!

I meant Orb.

Clearly, I need more coffee!

 

[Xyon]

There's never a time when one needs less coffee.

:unjack:

 

[orb]

I don't recall how this option affects things like runways, but I seem to recall that it affects L-Pads, so they shouldn't be placed to far from the base's origin.

At least in Orbiter 2010, stock Orbiter objects, like BLOCK, HANGARs, TANK, and RUNWAY are mapped to sphere with appropriate rotation of the mesh to planet's curvature, and RUNWAYs are mapped to sphere fully (neither of ends will float in air, nor center will be below sea/ground level).

LPADs are rotated appropriately with planet's curvature, but their Y position isn't decreased even if MapObjectsToSphere is TRUE. For Earth, you need to make Y for example -250 meters if LPAD is placed 56 km from the center of base (40000 -250 40000).

SOLARPLANT, though it's rotated with planet's curvature, it isn't mapped to sphere in Y coordinate, but there's a small bug that moves only its panels up or down if you change the Y manually to make it placed on the ground (the towers will still be floating).

Objects like RUNWAYLIGHTS, BEACONLIGHTS, TRAIN1, TRAIN2 are not mapped to sphere at all, and you need to calculate their END1 and END2's Y coordinates manually, but for either of these objects long enough, centers of them will be below ground level if ends are placed on the ground.