Visual and Structural Improvements

EvESpirit

New member
Joined
Jul 10, 2025
Messages
5
Reaction score
19
Points
3
Location
A comfy chair
Hello there.

[Personal paragraph]
O-F isn't my home in this community, at least not since I became a part of it, as I spend most of my time on the Discord as well as in DMs with various people. Given that I have no history here on the forum at all, I figured I might as well introduce myself to people who might not know me.

So! I've been developing cool things for over a decade now. My main focus for most of that decade was game development, game engines and tooling. But my interests go far beyond that. I've previously dipped my toes into things like x86 kernels (a project that is still very much ongoing, I'm just taking a victory nap after a massive feature shower), custom processor/architecture design, DRM, analysis tools (mainly pertaining to things like the Steam market), reviving abandoned FOSS projects, webapps, and cool thingimabobs of all sorts really (such as a near-SOTA star formation simulator!). Other than development, I'm quite keen (and able!) on things like amateur rocketry, chemistry, gardening, cooking, mechanical engineering and others. I love to generalize problems until they feel like yesterday's news, as you can probably tell. Sometimes, I'm able to use that to great effect, others, it just makes me more confused. Which one will it be today? Nobody knows! Either way, pleased to meet you, if we hadn't met before.

[/Personal paragraph]

I would like to use this post, besides as an introduction, to show off some of the cool things I've been working on over the last couple of months, for those of you who don't keep up with the GitHub.

Rocks!
The Rocks PR started off quite innocently as a "wait, why don't we still have anything on the planetary surfaces. we should at least have rocks or something, right?". This has since evolved into a vast technical effort of implementing a scattering system (and fix the myriad of issues with it that came up along the way), design and create the actual physical assets for the scatter (mesh files and textures), and generalizing the problem enough to be able to accourately represent any scatter type on any surface. Since many of the actual assets are still work in progress since I'm juggling multiple things both within and out of Orbiter, this for now isn't really quite visible. But under the hood, it's really quite extensive - we have support for a new type of quadtree that globally defines the physical density of scatter (perfect for any real-life data gathered and compiled by scientific papers, as opposed to just code-guessing or pure artistic authorship), a feature that will, before O26 drops, also support definitions for scatter size distributions as well as another channel for "geological unit" definitions (where data is available) - this means spawning different assets based on the general "biome" area - for example, on the Moon, you expect jagged, unweathered anorthosite so surround fresh impact sites, but vesicular basalt in the lunar maria. The system is likewise generalized enough to support trees, shrubs and other Earthly foliage - pending assets. For Earth specifically, as you would imagine, we have immaculately precise data for all three planned channels. Just... not rocks, but greens. Cool nonetheless! Kindly ignore lunar rocks being on Mimas - like I mentioned, pending assets. Will look much cooler when done.
1781640278730.png1781640387165.png


Collisions!
As soon as the Rocks PR got going a little bit, I realized another innocent little detail "wait, Orbiter historically never had any collisions, except when vessels interact with planetary surfaces.". This statement was immediately followed by "oh no".
So I got to work. I ended up shipping this feature inside the Rocks PR (because I really suck at compartmentalizing). Not the best idea in retrospect, but I managed it eventually. That's the important part right? right??
The collisions started with a fully custom implementation, but as I ran into more and more issues that I wasn't able to solve, I once again deffered to work people much smarter than me have already done 50 years ago and copied their homework. The result is a fully featured reimplementation of the GJK + EPA algorithms coupled with a custom implementation (though, yes, the idea itself is once again derivative of previous work present in many-a-game-engine) of a slicing algorithm that intelligently forces convex colliders to hug the actual meshes much, much closer than they otherwise would. The results are really good in my opinion! Zero possibility of mesh interpenetration or unphysical force application (energy is always conserved) in any except the most extreme scenarios. This collision system is toggleable in three distinct buckets - Vessel-to-Vessel, Vessel-to-Base and Vessel-to-Scatter (Rocks are an immovable object. For performance reasons, of course.).
There is still some things that are left to be desired here - for example the collision mesh generated for the ISS is absolutely nuts, as compared to say, Mir, which is perfect. But anything else works really well. Below is sample footage from one of the validation runs. Not the newest code (as of writing this post) running here, but it's 99% of the way there.


Volumetric clouds!
Aha, gotcha! No hyperlink here - I haven't yet pushed this code anywhere given that I fixed the last major bug with this feature like half an hour ago. Nonetheless - I felt like one other thing that I was really missing was volumetric clouds, ideally coupled with things like sunshafts, volumetric fog, and other shenanigans. For now, I can only show off the clouds. Please note that the look of these clouds isn't finalized, just the technical part is - before this is ever merged, I plan to make it look much more realistic and much cleaner. I cannot promise it'll look like MSFS24 with Floyd's Epic Clouds, but that's definitely what I'm striving for. This is implemented via a shader and various other small modifications to the actual C++ code - ones that are completely dependant on the OVP D3D9 client, given that we sadly still don't have any public updates to the Vulkan client that's in the works. When the time comes that Vulkan is merged into the upstream repository, I'm gonna have to do this all over again - but I did it anyway, just to have a blueprint. And hey, who knows, with any luck, Vulkan will work it's magic and make the clouds look even better. Here's an early, pre-PR sneak peek:
1781641774715.png1781641796003.png1781641824202.png


Besides all of this, I'm also very slowly working on a new piece of software - an intuitive, engaging, and most importantly visual way to make raw rocket/spaceplane meshes into functioning Orbiter mods with one-click-export capability. This is by far the most unfinished thing, despite being started first (lol), because I appear to have slightly burnt out on it - and I realized that the community would probably appreciate all of the above far more than this piece of software. Still doing the soft jobs though, designing the user experience, the interface, and overall workflow for the tool itself to be truly great, and truly useful. No screenshots here, since the UI/UX is still a very very early prototype. For those of you morbidly curious enough, I once posted one in the Orbiter Discord server. Consider that an invitation :cheers: Come hang out with us!


That's all from me for today. Cheers and have a great day everyone.
 
Last edited:
Hi EvESpririt, i'm very interested in mesh collisions and deformations. For collisions, it's obvious that boxes will suffice. But for deformations, it will be a bit more difficult.
Can't wait to try this!

Thanks anyway for the good news and your work.
Hi, I'm glad you like it. Unfortunately deformations aren't currently supported, and I'm unsure if they ever will be. At the moment, collisions are fully elastic - like billiards balls. Creating a system that supports inelastic collisions on arbitrary meshes would tank the framerate, require at least several more weeks of work, and would be very difficult to retrofit into the existing Orbiter architecture, because docking ports and several other systems of stock vessels would all have to be greatly enhanced in order to make this work properly. If you crave inelastic collisions, I'm sure you know about Beam.NG. While not a game where you can fly into space, it'll give you what you're looking for, and you can mod rockets into it - there's just nowhere to fly lol.
 
I think deformations should better be left to the vessel in question. No problem with a middleware to make this easier than the basic Orbiter API. But unless you have a basic concept how to describe the structure of a vessel, you will just do funny mesh manipulations....
 
I think deformations should better be left to the vessel in question. No problem with a middleware to make this easier than the basic Orbiter API. But unless you have a basic concept how to describe the structure of a vessel, you will just do funny mesh manipulations....
Yes, absolutely. I was definitely thinking of a more generalized mesh deformation system that would be knocking off what Beam.NG is doing. An interesting technical challenge, but one that ultimately in my opinion hasn't got a point in Orbiter. The "failure" part is the one that's actually an interesting topic, as opposed to general mesh deformation.
 
Yes, absolutely. I was definitely thinking of a more generalized mesh deformation system that would be knocking off what Beam.NG is doing. An interesting technical challenge, but one that ultimately in my opinion hasn't got a point in Orbiter. The "failure" part is the one that's actually an interesting topic, as opposed to general mesh deformation.

Yes, but I think in first iteration, it would already be a major improvement to have fitting event callbacks on the lowest level. Same for example also about the nominal 2016 landing gear implementation, which still happens without much developer control.

And then you can let the vessel decide. The mesh deformations in the old 688i submarine sim were also pretty unrealistic and rather goofy, but they made clear that the target is really destroyed and didn't look too bad from far away (and with late 1990s 3D graphics).

And yes, the failure aspect is what this feature request for deformations is likely really about. Even a shrinking health bar would be a good enough outcome after a collision, even today - if you need that much game in Orbiter. But for station building and especially halfway realistic looking EVAs , a too generic collision and deformation implementation would be bad.
 
Hi, I'm glad you like it. Unfortunately deformations aren't currently supported, and I'm unsure if they ever will be. At the moment, collisions are fully elastic - like billiards balls. Creating a system that supports inelastic collisions on arbitrary meshes would tank the framerate, require at least several more weeks of work, and would be very difficult to retrofit into the existing Orbiter architecture, because docking ports and several other systems of stock vessels would all have to be greatly enhanced in order to make this work properly. If you crave inelastic collisions, I'm sure you know about Beam.NG. While not a game where you can fly into space, it'll give you what you're looking for, and you can mod rockets into it - there's just nowhere to fly lol.
Okay, I admit I cheated... ;)
 
Even a shrinking health bar would be a good enough outcome after a collision, even today - if you need that much game in Orbiter.
I never thought about it, but it would be a really nice option during landing, docking, reentry in atmoshpere. Even without visual deformations.
 
I never thought about it, but it would be a really nice option during landing, docking, reentry in atmoshpere. Even without visual deformations.

I want to do something like that in my next project, but with indirect indications of damage, like for example gases leaking out of the systems or the landing gear getting permanently damaged by a too hard landing. But if I can find a reuseable architecture for deformation and similar damage effects, I maybe include this in a later 2.x update. It is perfectly in-character for the main actor of the project, but right now it exceeds my skills.

The old purple cardboard folder with sketches and concept drawings is still growing every other day.
 
Yes, absolutely. I was definitely thinking of a more generalized mesh deformation system that would be knocking off what Beam.NG is doing. An interesting technical challenge, but one that ultimately in my opinion hasn't got a point in Orbiter. The "failure" part is the one that's actually an interesting topic, as opposed to general mesh deformation.
What's interesting is the "I think that," and not "why not try?" It costs nothing but code.
 
What's interesting is the "I think that," and not "why not try?" It costs nothing but code.
I said that because it's an incredibly difficult piece of engineering. You ask "why not try" - I explained my opinion on why I think it's not worth trying. If you want to submit your own patches to Orbiter to make this happen, I'd love that. I personally don't have the time nor drive to make that happen. Besides, even within this single thread we have established that everyone has a slightly different idea about what ought to be done. I have no interest in reconciling those viewpoints. I'm just happy to breathe some new life into a game I love.
 
What's interesting is the "I think that," and not "why not try?" It costs nothing but code.

And code is damn expensive.

Creating the code is cheap, maintaining it is the real price. It stays cheap if you make a prototype for yourself and then don't care if it doesn't work after a single weekend. But if it should last for more than a year (or on somebody elses computer), yeah, that's a lot of commitment.
 
I said that because it's an incredibly difficult piece of engineering. You ask "why not try" - I explained my opinion on why I think it's not worth trying. If you want to submit your own patches to Orbiter to make this happen, I'd love that. I personally don't have the time nor drive to make that happen. Besides, even within this single thread we have established that everyone has a slightly different idea about what ought to be done. I have no interest in reconciling those viewpoints. I'm just happy to breathe some new life into a game I love.
I agree, I appreciatIe your honesty and your work, and I completely understand your point of view.
It's up to you to decide how things will proceed.
You hold all the cards.
 
And code is damn expensive.

Creating the code is cheap, maintaining it is the real price. It stays cheap if you make a prototype for yourself and then don't care if it doesn't work after a single weekend. But if it should last for more than a year (or on somebody elses computer), yeah, that's a lot of commitment.
I agree with the principle, but doing something for others is more important than money.
 
I agree with the principle, but doing something for others is more important than money.

I agree, under the condition that I have more money than I need. :cheers: ;)

Still I know that thankfulness is a very fleeting currency and doesn't last long. Soon you will only have obligations and the anger of the people you will disappoint.
 
Back
Top