(1.12.5) (Kopernicus) VertexHeightOblateAdvanced 1.1.2 - Easy oblate bodies

[Lt_Duckweed]

VertexHeightOblateAdvanced

VertexHeightOblateAdvanced is a custom PQS Mod intended for use by planet modders to enable easy creation of oblate bodies via a simple PQS Mod, rather than via a heightmap. Additionally, when in the SOI of a body implmenting VertexHeightOblateAdvanced, two new camera modes will be added to the camera rotation after FREE mode to better support non-spherical bodies.

Planet pack developers implementing VertexHeightOblateAdvanced are encouraged to bundle it with their mod, for the convenience of users.

Examples

• PointEqupotential

Spoiler

• UniformEquipotential Low

Spoiler

• UniformEquipotential Low

Spoiler

• UniformEquipotential High

Spoiler

• UniformEquipotential High

Spoiler

Download

• Github
• SpaceDock

Installation and Use

• Install ALL listed dependencies, following the links below
• Download and extract the VertexHeightOblateAdvanced zip file
• Place the GameData folder into your KSP directory
• Once installed, simply add a VertexHeightOblateAdvanced node to the Mods node in your body's PQS node
• Using the following Google Sheet, find appropriate periods for your body to get the desired oblateness, based on body surface gravity and radius.

Camera modes:

• SURFACE NORMAL
  • Functions like FREE camera mode, but with the vertical axis aligned perpendicular to the shape defined by the VertexHeightOblateAdvanced instance. This eliminates the "uphill effect" that oblate bodies have.
  • Lerps to FREE camera mode when greater than 10% of the body radius above the maximum oblate height.
• GRAVITY NORMAL
  • Functions like FREE camera mode, but with the vertical axis aligned with the local apparent gravity vector, taking into account the effects of rotation. Surfaces that look flat and level are actually flat and level relative to gravity.
  • Lerps to FREE camera mode when greater than 10% of the body radius above the maximum oblate height.

Parameters and expected values:

• oblateMode: overall controller for type of generation used
  • Values: (PointEquipotential, UniformEquipotential, Blend, CustomEllipsoid)
    • PointEquipotential: Generates a point mass equipotential
    • UniformEquipotential: Generates a uniform density equipotential, either a Maclaurin spheroid or Jacobi ellipsoid deppending on energyMode and period
    • Blend: Multiply a PointEquipotential by a CustomEllipsoid
    • CustomEllipsoid: Generate an ellipsoid based on a, b, and c axis values
• energyMode :
  • Used with: oblateMode (UniformEquipotential)
  • Values: (Low, High)
    • Low: For the given period, generate using the low oblateness branch. Always generates a Maclaurin spheroid
    • High: For the given period, generate using the high oblateness branch. Generates either a Maclaurin spheroid or Jacobi ellipsoid based on period
• mass: Mass of the body as set in the Properties node. Optional if  geeASL is provided.
  • Used with: oblateMode (PointEquipotential, UniformEquipotential, Blend)
  • Value: (greater than 0)
• geeASL: Surface gravity of the body as set in the Properties node. Ignored if mass mass is provided.
  • Used with: oblateMode (PointEquipotential, UniformEquipotential, Blend)
  • Value: (greater than 0)
• period: Rotational period of the body as set in the Properties node.
  • Used with: oblateMode (PointEquipotential, UniformEquipotential, Blend)
  • Value: (greater than 0)
• a: The primariy equatorial axis as a ratio of body radius.
  • Used with: oblateMode (Blend, CustomEllipsoid)
  • Value: (1 to infinity)
• b: The secondary equatorial axis as a ratio of body radius.
  • Used with: oblateMode (Blend, CustomEllipsoid)
  • Value: (1 to infinity)
• c: The polar axis as a ratio of body radius.
  • Used with: oblateMode (Blend, CustomEllipsoid)
  • Value: (1 to infinity)

Requirements

• ModuleManager
• Kopernicus

FAQ

• Q. I'm not a planet modder? Do I need this?
• A. You do not need to install it manually yourself, but if you found this in you GameData, it is because a planet pack you have/had needs/needed it and so it was either included with the mod or auto installed through CKAN

Licensing

• VertexHeightOblateAdvanced is licensed under the MIT License

Edited May 18 by Lt_Duckweed

[Clonos]

nice work!!

[Whirligig Girl]

oh that's excellent. maybe i'll be able to put this into Whirligig World if i get back to it. I've been wanting to make Mesbin properly level ever sense i first released it. (I just haven't been interested in planet modding for the past year or so, since running Planet Jam 2)

Edited January 11 by Whirligig Girl

[Whirligig Girl]

woe. lenticular mesbin be upon ye.

https://github.com/GregroxMun/Whirligig-World/tree/VertexHeightOblateAdvanced

[Thatguywholikesionengines]

lenticular mesbin now lives in my nightmares thank you

[CashnipLeaf]

On 1/11/2024 at 8:12 PM, Whirligig Girl said:

woe. lenticular mesbin be upon ye.

https://github.com/GregroxMun/Whirligig-World/tree/VertexHeightOblateAdvanced

Just when I thought Mesbin was cursed enough as is. /lh

[Emma_4623]

Hey, trying out your mod to spice up RSS, but my planet won't go oblat. it stays round. Any tips to fix this? Anyway, great work I love it

[Lt_Duckweed]

Can you post the config for the planet so I can take a look?

Since it tries to be as realistic as feasible on shape, if a planet isn't rotating all that fast it won't change the shape much at all.  It's possible that is the issue here.

As an example, if the Earth was had a period of 6 hours, or 4x faster than it does now, it would only have a Equatorial to Polar axis ratio of 1.07, which is going to be hard to notice to the naked eye.

[Emma_4623]

14 hours ago, Lt_Duckweed said:

Can you post the config for the planet so I can take a look?

Since it tries to be as realistic as feasible on shape, if a planet isn't rotating all that fast it won't change the shape much at all.  It's possible that is the issue here.

As an example, if the Earth was had a period of 6 hours, or 4x faster than it does now, it would only have a Equatorial to Polar axis ratio of 1.07, which is going to be hard to notice to the naked eye.

Sure, 
                VertexHeightOblateAdvanced
                {
                    oblateMode = UniformEquipotential
                    energyMode = High
                    radius = 980000
                    geeASL = 0.06
                    period = 14040
                    enabled = True
                    order = 25
                }        

[Lt_Duckweed]

On 1/15/2024 at 4:03 AM, Emma_4623 said:

Sure, 
                VertexHeightOblateAdvanced
                {
                    oblateMode = UniformEquipotential
                    energyMode = High
                    radius = 980000
                    geeASL = 0.06
                    period = 14040
                    enabled = True
                    order = 25
                }        

Is this body meant to represent Haumea perchance?  When replicating a existing body with a known shape, it would be easiest to use CustomEllipsoid mode, so you can set the a, b, and c parameters equal to the known real values.

Additionally, when using UniformEquipotential or PointEquipotential, the radius and geeASL you input must match the values for the poles.  For Haumea this would be something like 525km radius, and a geeASL of around 0.095

Unfortunately this still gives a shortest possible period under the Uniform model that is longer than the actual real period of Haumea.  This is because in reality, Haumea is probably not uniform in density but is denser towards the core, and thus would have a shorter period than what the model would predict.  In such a case it is supposed to clamp to an oblate value that is within the bounds of the model, but seems like this edge behavior may have a bug I need to fix.

All that said, assuming this is indeed Haumea, my recommendation would be to use the polar radius and gravity, and try using CustomEllipsoid to manually set the a,b, and c values (c should be 1, a should be a bit over 2, and b should be around 1.6).

Edited January 18 by Lt_Duckweed

[Emma_4623]

On 1/15/2024 at 8:08 PM, Lt_Duckweed said:

Is this body meant to represent Haumea perchance?  When replicating a existing body with a known shape, it would be easiest to use CustomEllipsoid mode, so you can set the a, b, and c parameters equal to the known real values.

Additionally, when using UniformEquipotential or PointEquipotential, the radius and geeASL you input must match the values for the poles.  For Haumea this would be something like 525km radius, and a geeASL of around 0.095

Unfortunately this still gives a shortest possible period under the Uniform model that is shorter than the actual real period of Haumea.  This is because in reality, Haumea is probably not uniform in density but is denser towards the core, and thus would have a shorter period than what the model would predict.  In such a case it is supposed to clamp to an oblate value that is within the bounds of the model, but seems like this edge behavior may have a bug I need to fix.

All that said, assuming this is indeed Haumea, my recommendation would be to use the polar radius and gravity, and try using CustomEllipsoid to manually set the a,b, and c values (c should be 1, a should be a bit over 2, and b should be around 1.6), alternately.

Thank you very much, and yes im trying to make Haumea
I will try  using CustomEllipsoid, thx 

[Lt_Duckweed]

VertexHeightOblateAdvanced 1.1.0

What's new:

• When in the SOI of a body implementing VertexHeightOblateAdvanced, two new camera modes will be added to the camera rotation after FREE mode to better support non-spherical bodies.
  • SURFACE NORMAL
    • Functions like FREE camera mode, but with the vertical axis aligned perpendicular to the shape defined by the VertexHeightOblateAdvanced instance. This eliminates the "uphill effect" that oblate bodies have.
    • Lerps to FREE camera mode when greater than 10% of the body radius above the maximum oblate height.
  • GRAVITY NORMAL
    • Functions like FREE camera mode, but with the vertical axis aligned with the local apparent gravity vector, taking into account the effects of rotation. Surfaces that look flat and level are actually flat and level relative to gravity.
    • Lerps to FREE camera mode when greater than 10% of the body radius above the maximum oblate height.

Download

• Github
• SpaceDock

Edited January 25 by Lt_Duckweed

[MCWither_Storm]

This makes me want to play KSP again.

[LucalisIndustries]

can this be used for oblate sphere of influences?

[Lt_Duckweed]

11 hours ago, LucalisIndustries said:

can this be used for oblate sphere of influences?

unfortunately no

And oblate SOI would be cool but also difficult to implement in code.

[Alpha_star]

On 1/12/2024 at 12:12 PM, Whirligig Girl said:

woe. lenticular mesbin be upon ye.

https://github.com/GregroxMun/Whirligig-World/tree/VertexHeightOblateAdvanced

Finally! do we get a scientifically mesklin mesbin in the game. It would be very cool if you can get the atmosphere done right too, I just can't wait play my mission of gravity soon. PS,Is this picture before or after the update?

[Whirligig Girl]

1 hour ago, Alpha_star said:

Finally! do we get a scientifically mesklin mesbin in the game. It would be very cool if you can get the atmosphere done right too, I just can't wait play my mission of gravity soon. PS,Is this picture before or after the update?

the image attached uses VertexHeightOblateAdvanced.

the shape i ended up going with (visible in the end of the whirligig world thread) is wider than this, to match mesbin's original dimensions so gameplay remains the same; but the slopes should be gentler now even though it's not using the pure equipotential.

Atmospheric oblateness is still impossible at the moment. If Atmospheric oblateness does become a thing it will probably require Whirligig World go through something of a paradigm shift or major update (or, and no promises, a sequel) to accomodate. It's something I've always wanted to do, but it's always been this far off future thing.

Atmospheric oblateness would require both physics and visuals be changed to accomodate not just ellipsoidal shapes, but all the shapes possible with VertexHeightOblateAdvanced.

And for a proper Mesklin analogue we also need oceans! which means ocean heightmaps with proper physics for buoyancy and collision on oblate worlds.

[CashnipLeaf]

3 hours ago, Whirligig Girl said:

Atmospheric oblateness would require both physics and visuals be changed to accomodate not just ellipsoidal shapes, but all the shapes possible with VertexHeightOblateAdvanced.

On the physics side of things, oblate atmospheres might be possible with some ModularFlightIntegrator tomfoolery. I don't yet know about the visual side of things. (tho one could probably poke blackrack to see if he has any thoughts on that)

Edited January 28 by CashnipLeaf

[Whirligig Girl]

12 hours ago, CashnipLeaf said:

On the physics side of things, oblate atmospheres might be possible with some ModularFlightIntegrator tomfoolery. I don't yet know about the visual side of things. (tho one could probably poke blackrack to see if he has any thoughts on that)

it's all i've ever wanted. i would make such a cool planet if i had working oblate atmospheres. (and uh. oceans. the planet would be possible but way less cool without oceans.)

[Lt_Duckweed]

VertexHeightOblateAdvanced 1.1.1

What's new:

• Fix for NullReferenceException and broken camera when in the SOI of a body without a PQS (Stars and Gas Giants)

Download

• Github
• SpaceDock

[Iapetus7342]

On 1/12/2024 at 4:12 AM, Whirligig Girl said:

woe. lenticular mesbin be upon ye.

https://github.com/GregroxMun/Whirligig-World/tree/VertexHeightOblateAdvanced

OH MAN
OH GOD OH MAN
OH GOD OH MAN
OH GOD OH MAN
OH GOD

[Lt_Duckweed]

VertexHeightOblateAdvanced 1.1.2

What's new:

• Fix for VertextHeightOblateAdvanced using terrain altitude instead of radius for deformity calculations.  VHOA should now behave consistently independent of load order when used alongside other PQS mods.
• radius parameter depreciated, radius is now directly inherited from parent PQS.

Download

• Github
• SpaceDock

Edited May 18 by Lt_Duckweed

[Lt_Duckweed]

VertexHeightOblateAdvanced 1.1.3

What's new:

• Tweak folder structure to fix mod load order conflict

Download

• Github
• SpaceDock

[UncleMateo]

Hello.  I am putting together a planet pack right now, and I use this mod as a dependency to help squish one of my planetoids into a more exotic shape.  Unfortunately, as of the last Kopernicus update a week or two ago, something broke.  Kopernicus continuously failed to load, the log was unhelpful.  Through careful process of elimination, I found that the mod causing the problem was either my mod specifically, this mod, or both.  In fact, I now believe it was both.  Both problems were relating to mod loading order, I believe.  I am not 100% sure the cause of this issue, but I suspect it has something to do with Harmony loading after DuckweedUtils which breaks the load order for Kopernicus and causes it and any mod loaded after it to fail.  This did not happen in the previous Kopernicus version, rolling back fixes it.  I'm somewhat of an amateur when it comes to modding, perhaps, but I was able to solve both load order issues by simply renaming the folders of the mods in question.  The relevant solution for this mod was to rename "000_DuckweedUtils" to "001_DuckweedUtils", which allowed everything to load successfully.  When I bundle your mod with mine as a dependency, I hope you wont mind if I retain this naming scheme for the folder.

I wanted to post this issue here in case others had found themselves having any issue with this mod and Kopernicus after its newest update.   Anyways thanks again for this great mod.  Hope this information is useful.

Edited June 18 by UncleMateo
[My unrelated sidenote was about a fix for a custom parallax config problem that turned out to not be fixed after all

[Lt_Duckweed]

8 hours ago, UncleMateo said:

Hello.  I am putting together a planet pack right now, and I use this mod as a dependency to help squish one of my planetoids into a more exotic shape.  Unfortunately, as of the last Kopernicus update a week or two ago, something broke.  Kopernicus continuously failed to load, the log was unhelpful.  Through careful process of elimination, I found that the mod causing the problem was either my mod specifically, this mod, or both.  In fact, I now believe it was both.  Both problems were relating to mod loading order, I believe.  I am not 100% sure the cause of this issue, but I suspect it has something to do with Harmony loading after DuckweedUtils which breaks the load order for Kopernicus and causes it and any mod loaded after it to fail.  This did not happen in the previous Kopernicus version, rolling back fixes it.  I'm somewhat of an amateur when it comes to modding, perhaps, but I was able to solve both load order issues by simply renaming the folders of the mods in question.  The relevant solution for this mod was to rename "000_DuckweedUtils" to "001_DuckweedUtils", which allowed everything to load successfully.  When I bundle your mod with mine as a dependency, I hope you wont mind if I retain this naming scheme for the folder.

I wanted to post this issue here in case others had found themselves having any issue with this mod and Kopernicus after its newest update.   Anyways thanks again for this great mod.  Hope this information is useful.

As of the latest version, the folder should be 001_DuckweedUtils anyways, so you are all good there.