Add properties for a thick ring #201
Conversation
|
These texture tiling changes also allow traditional rings to add "horizontal" detailing, since the full texture is now applied as an area rather than just one linear sample; here's JoolRings after a "tiles = 5" line is added:
|
- Add rotationPeriod property - Use it to update the transform
|
Added per-ring rotation period configuration in latest commit to support rotation speeds other than 0 and parent-matching. |
|
@HebaruSan Question (may seem off-topic): would it be possible to also take a look at adding a "LAN-locking" feature? Currently, if you have rings with inclinations other than 0 degrees, they get different LAN values each time you launch KSP (meaning that you cannot have nice Uranus rings...) |
|
Yes, the angle property denotes the inclination of the ring in degrees, 0 being perpendicular to the planets rotational axis. |
|
@PhineasFreak , are you sure about the problem with the LAN? I found this post on the forum which seems to suggest that inclined rings have already been done this way, and that the problem isn't that the LAN can change, but that you can't change it in the Kopernicus cfg files. Adding a setting for LAN would be straightforward, if that's what's needed. |
|
@HebaruSan I may be wrong about the LAN but i did find a post by the user OhioBob that describes the problem exactly: It is an old post but i am not sure if anyone ever took a look at it. My idea was that the ring would stay locked so that it will never end up being half in the dark and half in the light side of the body (much like how ISS always has the cupola facing the surface of the Earth). I will post some reference screenshots of Uranus later when i will have access to my workstation. |
|
Thanks for that link! I was able to observe the issue with the JoolRings example by changing Laythe's inclination and using its orbit as a reference plane. Indeed, the ring's LAN does jump around from one restart to the next, and I now have the screenshots to prove it. (Of course, figuring out why is another question entirely...) |
- Add longitudeOfAscendingNode property - Make lockRotation property consistently fix ring to same orientation
|
A fix for the LAN issue is now available in #204, and I've merged it into this PR as well to avoid future conflicts. (I also deleted some of my replies here that were no longer useful.) |
Since there's no z-buffering, ring faces need to render in the correct order, and previously the inner and outer faces were interleaved, which allowed inner faces to be drawn on top of outer. Now all inner faces will always be drawn before all outer faces, which produces the correct rendering for overlaps. (You can only see overlaps if you're outside the ring, and only if an inner face overlaps an outer. Since you're outside the ring, the outer face must be closer to you than the inner face.)
Fix to #201: Z-ordering problem with thick rings
This patch extends Ring and RingLoader:
The changes are designed to be backwards compatible; existing planets will not be changed unless they are modified to support the new features (tested with JoolRings from KopernicusExamples). Also hoped to be future compatible with features like ring-on-ring shadows and a solid landable terrain surface.
Intended for visualizing classic fictional megastructures, for example:
(I'll be releasing the config for that screenshot as a separate mod if this patch is merged.)