the package came out in like 2019
#Engine Discussion
normal agate
in the super early preview
and only hit 1.0 in the current LTS
it's a new physics engine written specifically for ECS
slate sapphire
Ahhh 🤷♂️ I haven't used Unity professionally since about 2014
Regardless, floating point applies to all physics integration at all time
normal agate
sure, but for a game like KSP, you don't really care about physics outside of a couple km around your active vessel
slate sapphire
That's just not true at all and not how simulation works in general
normal agate
not sure what you mean by that
KSP literally despawns the physical objects outside of 2 km
slate sapphire
Error is accumulative
There are so many hacks in KSP around this fundamental issue to get anything stable and consistent
normal agate
yes, but that's why I mentioned that Unity.Physics is a much better solution
because it's stateless
so by definition you can't get accumulative error
at least not in the same way as when you're caching
slate sapphire
😔 All simulation accumulates error over time, it is mathematically impossible not to
indigo mason
That's just not true at all and not how simulation works in general
KSP estimates the orbits based on the orbital paremeters I'm pretty sure. You cant get accumulative error.
slate sapphire
And how are orbital parameters derived? 🙃
indigo mason
I guess using mathematical systems like this in my python planet sim:
def update_orbital_elements_from_state_vectors(self):
if self.parent is None:
return
mu = G * self.parent.mass
r = self.pos - self.parent.pos
v = self.vel - self.parent.vel
h = np.cross(r, v)
k = np.array([0, 0, 1])
N = np.cross(k, h)
e_vector = (np.cross(v, h) - mu * r / np.linalg.norm(r)) / mu
self.eccentricity = np.linalg.norm(e_vector)
self.semi_major_axis = (np.linalg.norm(h)**2) / (mu * (1 - self.eccentricity**2))
h_norm = np.linalg.norm(h)
N_norm = np.linalg.norm(N)
self.inclination = np.arccos(h[2] / h_norm)
if N_norm != 0:
self.longitude_of_ascending_node = np.arccos(N[0] / N_norm)
self.argument_of_periapsis = np.arccos(np.dot(N, e_vector) / (N_norm * self.eccentricity))
else:
# Orbit is planar. The notion of ascending node is meaningless.
# You could choose to define argument of periapsis directly in this case.
self.longitude_of_ascending_node = 0
#self.argument_of_periapsis = np.arctan2(e_vector[1], e_vector[0])
self.argument_of_periapsis = 0 def update_orbital_elements_from_state_vectors(self):
if self.parent is None:
return
mu = G * self.parent.mass
r = self.pos - self.parent.pos
v = self.vel - self.parent.vel
h = np.cross(r, v)
k = np.array([0, 0, 1])
N = np.cross(k, h)
e_vector = (np.cross(v, h) - mu * r / np.linalg.norm(r)) / mu
self.eccentricity = np.linalg.norm(e_vector)
self.semi_major_axis = (np.linalg.norm(h)**2) / (mu * (1 - self.eccentricity**2))
h_norm = np.linalg.norm(h)
N_norm = np.linalg.norm(N)
self.inclination = np.arccos(h[2] / h_norm)
But I might be wrong
It doesn't need anything else than the position and velocity and stuff
slate sapphire
So position and velocity magically can't accumulate error? 🤔
indigo mason
Ok, you're probably right
slate sapphire
I know I'm right, I've been doing this for 15 years 🤣
indigo mason
Nice
slate sapphire
64-bit true double precision still accumulates a tiny bit of error, it is just so little compared to floating point that it is probably not an issue in a game, but actually is for astronomy over very long periods of time
When you have to rebase the world origin every 20km with potentially variable frame rate and main thread locks the scope of the problem quickly gets out of hand
The way KSP1 does orbits in itself is a hack around this problem and not how they would have done it otherwise
indigo mason
Hmm that sounds about right
What do you propose as a solution then?
So not Unity?
slate sapphire
My recommendation has consistently been to prototype out micro projects in both engines and prove which is better
indigo mason
Sounds good
slate sapphire
Unreal also has some fundamental issues, but at this scale they are far fewer and less critical, and having source makes every problem a matter of skill
If you run into issues with Unity, as hundreds of games have found out after years of production, well good luck finding a stable work around 🤷♂️
normal agate
while it's definitely better to be able to see the whole source code on GitHub as a whole, you can still look at the C# source of Unity's DLLs, and even modify it to your needs with Mono.Cecil at runtime if you really do need it (we have done that to some extent when modding KSP2)
inferior to having the actual source, of course, but it works
the biggest hurdle is then the native calls it makes
but those are just used for the most low-level stuff, usually
and either way, maintaining and updating a fork of a game engine is a bit beyond our scope
indigo mason
A custom engine would be so cool but yeaa, its not possible rn
slate sapphire
He means changes to engine source, like modifying the physics engine
slate sapphire
That's not a custom engine
pine valve
A custom engine would be so cool but yeaa, its not possible rn
Could still have floating point errors, unless you were to design a logmertitc nesting strategy (and even then it woudl have errors but significantly less unless you were at the far end of the log curve, which honestly would be the bounds of your "system" before taking a step over to the next).
indigo mason
That's not a custom engine
Yea, I know. It was just a though that popped up. Not related to what munix said
slate sapphire
It actually isn't that bad if the changes are limited. You can usually make changes to Unreal Engine and still be able to upgrade to a later version without issues. It is when you start to re-write huge chunks of the engine that constantly upgrading becomes no longer feasible
indigo mason
Could still have floating point errors, unless you were to design a logmertitc n...
Definitely true
Idk what it is but somehow a custom engine would feel more free'er. But we definitely don't have resources for that
pine valve
Idk what it is but somehow a custom engine would feel more free'er. But we defin...
No we don't...
indigo mason
Lets just use my old very interesting attempt to learn C++ do some basic graphics stuff as a base 
The file structure is perfectly ok with not flaws whatsoever
pine valve
The file structure is perfectly ok with not flaws whatsoever
Honestly likely better than my initial Godot test...
Which I just figured out that 1/2 the stuff I found doesn't work on the engine version I picked (i have to roll back to 4.2.2 grumble).
indigo mason
Oh yea, its more like the code stucture and stuff
Like the render stuff is very weirdly structured and stuff
pine valve
I'm still leaning towards Unreal but I love the OS concept of Godot, as I worry what else might be down the line.
PS. A new Voxel engine has been announced which doesn't just use voxels... (well it uses voxels but they don't have to be "Squares") not that I think this should be a voxel game...
slate sapphire
I'm still leaning towards Unreal but I love the OS concept of Godot, as I worry ...
Voxels aren't cubes, that's just one method of rendering them
There are mods for minecraft called that change the rendering algorithm to be smooth
vale mortar
Space engineers uses voxels for example
pine valve
Voxels aren't cubes, that's just one method of rendering them
true, its just a 3D grid pattern.
velvet quiver
How many responses though
I hate voxels, they are so heavy
Easy to work with conceptually, but their data requirements are kinda crazy
You guys should just use the Rage3 engine :p
On the topic of physics and floating point issues the problem is literally unsolvable
Its fundamental to the way digital computers work, the lack of precision introduces error over time and it just can't be stopped
You can mitigate and occasionally limit its impact
And while you can increase precision by having more frequent time steps, you quickly hit a computational limit, and then things start to slow down
Unity.Physics is definitely far and away a better physics solution that will have less issues than classical unity physics, but it doesn't remove that problem
Of course their choice in naming is absolutely stupid and very confusing, unity.physics was written on the unity jobs system which takes advantage of simd, the fact that its stateless doesn't make it more accurate but it does make it deterministic, which is good for networking
Its a solution written by the Havok Physics team for unity, in addition to the nee Havok Physics for Unity solution which is stateful
pine valve
How many responses though
pine valve
I hate voxels, they are so heavy
I'm not a fan of voxels (as an art form) except when you consider destructive landscapes as apparently they can handle that better (but at a performance cost of course).
slate sapphire
Its fundamental to the way digital computers work, the lack of precision introdu...
Yep, it is a problem throughout engineering, which is why dead reckoning was developed
Unreal double precision LWC solves this problem out to extreme distances, so we are rebasing for each planet, and using dead reckoning for networking, but that's a whole other topic.
Variable time step (dt) is also a major issue when the render and physics threads are separate, which we just encountered when trying to calculate acceleration from velocity on the main thread because the physics doesn't expose a method to get acceleration.
This is just one of the issues you'll encounter regardless of engine, Unity, Unreal, CryEngine, etc, there is no escaping it.
Unreal LWC does mitigate the accumulation of error over time to such a degree that we don't think it will ever be a major issue, and our networking is client authoritative so it is only the networking that will need to deal with it.
Not easy problems to solve though.
opaque bane
So position and velocity magically can't accumulate error? 🤔
No because orbits are not integrated, they are solved analytically.
slate sapphire
No because orbits are not integrated, they are solved analytically.
Which is a hack / work around and why they are so janky in both KSP1 and 2 🙃
vale mortar
Which is a hack / work around and why they are so janky in both KSP1 and 2 🙃
How is it a hack to solve orbits analytically
opaque bane
Which is a hack / work around and why they are so janky in both KSP1 and 2 🙃
That sentence doesn't make any sense. I feel you're more interested in being right than having a constructive conversation. Good night 🙂
slate sapphire
Displaying orbits in the way KSP does can make sense in some cases, but why would you want to have your orbital mechanics solved in that way? The answer is you don't and the entire physics system in KSP1 is a series of hacks on top of hacks on top of hacks to work around issues they encountered during development.
People can defend those design decisions and technical tradeoffs all they want, but the truth is that KSP physics, orbital mechanics and everything to do with spacecraft is so deep in tech debt it is incredible it works at all and took years to get working
Anyone who played and followed development in the early days will know how broken it was for years, KSP2 EA in comparison was very polished
The orbital mechanics is fundamentally flawed, it is hard to point to one particular cause or design decision that is the cause of this, as it is the totality of the system
Like it or not, KSP2 was effectively doomed the day the devs were forced to use that codebase 🤷♂️
elder yoke
Is the issue the swapping between on and off rails? Because an analytical solution seems ideal, at least for stuff not in focus. You don’t even need to simulate it, just store the orbital elements and solve it for the current time when you look at it again.
slate sapphire
I truly don't think there is a "the issue", again it is the totality of the design and the tradeoffs they had to make. In that specific case I think it makes sense from a visualization and user experience perspective, how maneuvers are performed from the user's perspective, but you loose so much by doing this on the physics side, which is made evident by janky orbits in KSP1 to this day
It is true that it is not possible even with double precision to always use the same frame of reference and expect good results, you'll have to convert between inertial and non-inertial frames at some point
indigo mason
Btw, I know a theoretical physicist who might be able to help us with the orbits. She is not super good at programming but does ok and could probably give some feedback.
meager aurora
(On Topic, but related to a message somewhere earlier in the chain that I can't seem to find lol), if we did decide to go with UE5, and if we did decide to modify the source code(heavily or lightly), we shouldn't try and stay up to date with the current UE5 version through out development, unless there is some huge performance boost or massive bug fix. Its kind of the same with Unity, you pick a version (usually a LTS before stability reasons), and you don't upgrade throughout development, unless it seems utterly neccesary.
So versioning issues with our modified code and any future versions of the engine just wouldn't be a problem until we are see fit to upgrade
but i also agree that for the moment, people should just start coming up with small proof of concepts in any engine, and we'll see what gets the most progress
pine valve
Stupidly Helpful video on GDScript in GoDot (assuming you understand how to program in Pascal-based syntax format labeling).
grave notch
but i also agree that for the moment, people should just start coming up with sm...
I think this is just the best thing to do atm
There's clearly disagreement on which engine we should use and, quite frankly, we won't be resolving them without making prototypes
brisk pebble
There's clearly disagreement on which engine we should use and, quite frankly, w...
There isnt disagreement
Its already been decided that a prototype will be made in Unreal and Unity
grave notch
Alright, so what are we waiting for? 😄
brisk pebble
Well, Munix is very sick
Theres also no design document yet, thats a higher priority
grave notch
Well, Munix is very sick
Oh no, I missed that 😦 hope he gets well soon
brisk pebble
Yeah me too
grave notch
Theres also no design document yet, thats a higher priority
What I'm thinking is: for the prototypes, how detailed of a design doc do we really need? We know already we're gonna need basic planets, orbital mechanics and basic craft flight controls. Is that enough to make a proof of concept?
brisk pebble
I think it is, although a design document is important for various reasons
For one, it serves to let people know what the project is
Which is rather important seeing as about half the people here seem to think its a KSP clone
grave notch
Yeah I agree
brisk pebble
I dont blame them though, theres way too many conversations that happened prior to try to read through, even you weren't aware of the status of the engine decision. Thats why a design document needs to exist
grave notch
Tbf, I also didn't keep up with everything because there's been a lot of talks (which isn't a bad thing, I just don't have the time to follow it all)
brisk pebble
yeah, even I missed plenty of stuff, despite being here day 1 and this being basically the only server I check
Progress is underway though I can assure you that. I know Munix and Cheese fully intend to work on the design document as soon as hes not too sick to.
grave notch
Alright, sounds good
meager aurora
With or without a design doc i think tech demos can already be worked on atm. Maybe someone wants to prototype the stateless physics of Unity.Physics(this is the package Unity.Physics, not the default Unity Physics engine). Maybe someone wants to test out new building methods, or implement Harvesters wobbly vehicle solution, maybe someone wants to work on planet rendering from inspace to surface
brisk pebble
Someone could make one if they insisted sure, but the project leads are preoccupied with the design document
meager aurora
Thats what i mean
We as the community should start making prototypes and gaining experience with these systems, and testing out the other engines
Then once the project leads are ready and able to start, we've got this huge collection of prototypes and public feedback on what people like, and what is the most doable
brisk pebble
The project leads are going to be the main people actually programming the thing, so to some extent, its specifically important they work with the two engines to see which is suitable between them, and the design document is not going to take that long
meager aurora
Oh i was under the impression that this was a community driven and developed project? And potentially open sourced or source available.
grave notch
It is, but usually there's a handful of people that do the vast majority of work
brisk pebble
Its an open source project with community contribution
A project of this scope isnt going to be made by people coming in and dropping out doing work here and there, so it cannot just be pure community driven
Although a great deal of the work will come from the community, you need people who are actually coordinating it and pushing it along all the time, hence the project leads
Time will tell who else is committed to the project
meager aurora
that's fair, I knew that only a fraction of all the people interested in the project where actually going to contribute, but I still think its valuable for anyone that has an interest, and wants to do some research a prototyping, to do so and then publish their results. The quality of that research will be all over the place lmao, but i still think it could be valuable for others. I know I will probably start prototyping some aero and stress physics stuff in my off time.
and I've also seen the death of a hanful of community projects once the assumed leads of the project go silent or need to step back from the project(not saying that that will happen here though)
brisk pebble
It's unlikely that the project will even have stress physics
So youd kinda be wasting your time there
meager aurora
not really a waste. Its a subject i'm interested in
but why would the project not have stress?
brisk pebble
Because its not necessary for the gameplay loop
meager aurora
or at least not even attempt it?
thats arguable i'd say. building, trying, and failing for various reasons is part of the original KSP gameplay loop, and if we're trying to make anything like those games then I'd say it potentially is a part of this projects loop. Now to be fair we have no idea what the gameplay loop actually is rn, but thats also what this time is for, experimenting, prototyping, and just trying shit. Throwing stuff on the wall to see what sticks. We don't have to commit to everything thats built, and I am certain that not everything thats made will get used, thats just the nature of projects
brisk pebble
We do know what the gameplay loop is
and this game isnt trying to be KSP
This is why the design document needs to exist lol
The gameplay is mostly involved in colony/resource management, with space sim aspects built into the gameplay
I dont mean to discourage people from doing what they want to do, but when it comes to this project specifically, the greatest priority right now is coordinating efforts and getting everyone on the same page, and that comes with a design document
If everyone goes off and does their own thing, the project wont get anywhere meaningful imo
meager aurora
and this game isnt trying to be KSP
i did specifically say that i know the game is different than ksp. But it does feel like its trying to capture some of its essence, thats why i used it in my statment.
meager aurora
If everyone goes off and does their own thing, the project wont get anywhere mea...
yeah, but currently we are really disjointed and have little leadership, cause the leads are preoocupied, which is ok. I just think its a good idea to use some of this energy people have for something constructive while we wait. and once the leadership is back, and plans are being made we can regroup and figure out where to go
brisk pebble
I don't think its a bad idea to work on your own things in the engines being discussed with related things to get a hang of them in the meantime
They could end up being useful as well
But the actual prototypes for the game need to wait until things are more organized
meager aurora
oh sure, i'm talking about tech demos and proof of conepts thats all
normal agate
For what it's worth, I think this can be started basically anytime: #🟡game-general message
It's mostly independent on the actual game design
grave notch
Gotcha
normal agate
And I'm feeling a lot better today so I'll get to work on the design side of things right away
haughty compass
I'm gonna try and learn some code and see if I can help.
haughty compass
(To be more accurate I'm going to download Unreal Engine 5 and screw around with it, I do know a little bit about coding already)
slate sapphire
(To be more accurate I'm going to download Unreal Engine 5 and screw around with...
I would recommend 5.3.2 because 5.4 is still a little unstable after some major changes
normal agate
I'd say that we should just go with the newest version since it's not like we'll be locked into it anytime soon, anyway
for that same reason we were using Unity 6 beta
slate sapphire
You shouldn't be locked into it for a prototype
slate sapphire
5.5 would probably be a good "target version" for locking into, as it will have all of the RHI parallelization and performance but be more stable
5.4 is just super unstable right now in some very specific areas, so I recommend using 5.3.2 for prototying, especially for anyone new to the engine
normal agate
but I also don't think generally we need to lock into any specific versions "forever", look at KSP, the original game started development in 2011 and now runs on Unity 2019.4, and KSP2 was released with 2020.3 and got upgraded to 2022.3 with no issues
slate sapphire
Biggest mistake is staying with one version for a long time if you ever plan to upgrade, that tech debt will compile and it will be harder to make the switch
normal agate
yeah, I would definitely be for more regular engine updates
slate sapphire
UE5 has actually been pretty good in terms of that since EA/Preview builds, but there are some "miss versions", like 5.1.0 which was completely and totally broken
brisk pebble
And I'm feeling a lot better today so I'll get to work on the design side of thi...
Glad you’re feeling better
slate sapphire
Epic have an odd development cadence with UE5, it is almost like every other major version is kind of broken, then stabilizes, so I never even attempt to upgrade until the first stability version.
For example 5.0.3 was great, 5.1.x was broken, but 5.2 was stable, and then 5.3.0 was broken but 5.3.2 is great now
normal agate
heh
with Unity it's usually a bit simpler
they have xxxx.1, xxxx.2 as the "experimental" builds where they introduce features, and then xxxx.3 (earlier xxxx.4) as the LTS where they focus on getting it all stable
not sure if or how that will change with Unity 6, we'll see
slate sapphire
UE does that too, they are called Preview builds and will be available in the launcher several weeks before the 5.X.0 version
grave notch
they have xxxx.1, xxxx.2 as the "experimental" builds where they introduce featu...
- unity hasn't really had any major stability issues for years now, at least in my experience
slate sapphire
You can always grab the very latest daily build from GitHub
normal agate
UE does that too, they are called Preview builds and will be available in the la...
yeah, I think the time scale is just very different
slate sapphire
Unreal's hit or miss stability is actually feature, their development velocity is very very high, higher than any other engine, and Epic is not afraid of regression or stability issues, so you kind of have to expect and plan for that, and test new versions / listen to what others in the community are saying
normal agate
since each of the minor versions stays around for ~half a year
yeah, very different development philosophy
grave notch
that... doesn't really sound like a feature to me tbh
haughty compass
alright, github client downloaded, trying to find the keys to my old account, UE5.3.2 downloading
slate sapphire
that... doesn't really sound like a feature to me tbh
It very much is, looking back at only the past year of UE5 development they have accomplished more than most engines have in multiple years, some in nearly a decade (cough cough CryEngine), and that comes with a certain level of instability
I have worked with people who simply ignore Epic's development and stick with a single version for 6-12 months, then you miss all the experimental features and instability, it is up to you how much you want to test or see new features
normal agate
Glad you’re feeling better
I lied a bit though, in the end I ended up fixing some work stuff and I'm just getting to the game stuff
but I am getting there
😆
grave notch
opinions may differ on this, but i want a stable tool above all else, i don't need a million new features every year, especially when it brings instability with it
slate sapphire
opinions may differ on this, but i *want a stable tool above all else*, i don't ...
My point was, stability or more specifically lack there of is up to YOU
Don't like the instability and don't need experimental features? Stick with a stable patch for 6-12 months
normal agate
yeah, I would agree there, you're free to stick with a version you know is stable
slate sapphire
Yep, and most do, but some like myself have been on (almost) every version since 5.0.0 and hasn't massively hindered me
normal agate
(e.g. the equivalent of only using Unity's xxxx.3 builds - it's just that they have a special designated number to tell you that they're stable, unlike Unreal)
slate sapphire
5.1.X though, that was a bad time 😄
That probably is the biggest difference for sure
Just, don't "trust" any 5.X.0 patch and you're fine
Subsequent 5.X.X are almost always out a few weeks later to fix showstoppers
grave notch
Just, don't "trust" any 5.X.0 patch and you're fine
that might explain why my experience with 5.0.0 was so bad
gonna need to give it another shot at some point
slate sapphire
Well, I mean 5.0.0 was totally experimental, almost every feature
5.0.3 was the most stable version until 5.3.2
5.0 EA was actually more stable than 5.0.0 release, then they dumped a ton of new features in is why it was so broken
grave notch
i just assumed that it was stable because it went out of beta
slate sapphire
That's probably the biggest change in development philosophy when working in Epic's engine pipeline, took me a year to learn and no one warned me
Just don't assume 5.X.0 is stable and you're all good
pine valve
I have worked with people who simply ignore Epic's development and stick with a ...
Given this is volunteering, I would strongly suggest you don’t apply any additional effort on people unless there is a solid reason to upgrade (new feature or clear performance improvement) and only then do it if you have enough buy-in from people to update the code base.
slate sapphire
Given this is volunteering, I would strongly suggest you don’t apply any additio...
Usually that is performed by a single person anyway until it is stable
Team just updates to latest on the repo after it is stable and maybe some minor issues after that
This is why unit and smoke tests are so important to build in 😉
The difference there is if a project falls behind several years on the engine side, it could take months to update, instead of a few days
If you plan to ever update it is better to stay up to date
pine valve
Well I think I understand how Godot works (still need to figure out how to recompile the engine to add double precision as a 5th variable option).
I’m 95% sure you guys are going to go with unreal so I’m trying to crash course learn C++ and Blueprint code basics and syntax.
slate sapphire
Wait are they? 🤔
I didn't assume that at all honestly
I'm glad they are considering Unreal and Unity prototypes at all, but if making an assumption I figure the institutional bias toward Unity would be very hard to get past
slate sapphire
Ohh I missed that
grave notch
and i will be quite frank, DOTS is, from my point of view, exactly what we need
brisk pebble
Wait are they? 🤔
I think Unreal engine is generally seen as likely the better solution now, although both will still be prototyped
grave notch
but i'm open to be convinced otherwise
slate sapphire
Has anyone determined anything about the legality of open source in Unity? That's something I have absolutely zero understanding of
grave notch
what exactly do you mean with legality? the whole runtime fee shenanigans?
slate sapphire
No, I figured the runtime fee wouldn't apply here, otherwise Unity wouldn't be an option at all
I mean more in terms of what license an open source project built on Unity would need to have
grave notch
basically TL;DR: for revenue under 100k / year, no restrictions at all
as far as i'm aware
and we're not gonna be having any revenue
haughty compass
alright, 5.3.2 is a bit too hefty to willingly use my hotspot to do, will have to wait until I get home to get it loaded on
slate sapphire
alright, 5.3.2 is a bit too hefty to willingly use my hotspot to do, will have t...
Btw you don't need debugging symbols for general purpose C++ in UE, that is like 100GB on disk iir
normal agate
I don't think licensing will be an issue, their official open project is licensed Apache 2.0
haughty compass
Btw you don't need debugging symbols for general purpose C++ in UE, that is lik...
yikes, that's uh, more space than I have on this thing lol
sounding like a desktop project and remoting in
when I wanna be mobile
slate sapphire
My 5.3 Engine is 44.7 GB on disk
Once you install, you'll use the dropdown here
Go to Options
And disable all other platforms (even if you plan to support Linux later)
haughty compass
oh no, never mind I misunderstood what you were saying
slate sapphire
And symbols for debugging is ~80 GB, only your lead developer will need that
Highly recommend keeping Templates and Feature Packs
haughty compass
yeah I only had the defaults selected, like that picture there.
velvet quiver
Just want to chime in and say, if you're going to be mobile on engine versions, you should update often to keep change costs minimal, but that can sometimes be challenging when highly used apis are affected
haughty compass
just have a build whose existence is purely for integrating new engine updates and seeing what they break
slate sapphire
Yep, it really is the best way to go. It will waste a day or two of your lead dev's time every 2-6 months, but could save months later if you don't
normal agate
exuse me how does this thing have 80 GB of debugging symbols 
velvet quiver
If you want to see how messy it can get, get really familiar with the thunderkit code base
I have polyfils for uitk to make cross version support easier, lots of preprocessor directives, etc.
The polyfil is largely because unity 2018 only had a very incomplete prototype version of uitk
normal agate
well, it was a package even in 2020.3
velvet quiver
It was in the UnityExxxx.Experimental.UIElement namespace
normal agate
or was that only for the runtime?
velvet quiver
It was editor only
normal agate
the package I mean
velvet quiver
There was no package, I was remembering it backwards, and therr was no runtime support at all
A lot of stuff was a lot worse tbf
normal agate
no yeah all I'm saying is that in 2020.3, we had to download a preview package to use UITK, so presumably that was for the runtime features
velvet quiver
2018 tk has a ton of custom implementations and work around for missing features.
Anyways the point is, you can get a sense of how much changes over major versions even in a case where the contact surface is fairly minimal
Tk has to keep support for all versions so it becomes much more visible
normal agate
specifically in Unity, just don't touch experimental/preview packages whenever you can avoid it
is a good rule
velvet quiver
Oh I'm notorious lol
normal agate
😆
velvet quiver
Living on the bleeding edge is fun (for me, this isn't sarcasm lol)
For a project with real goals its obvious a bad idea
Downside for using unreal, you don't get to use ThunderKit :p
I promise this is ~not~ a biased opinion.
normal agate
well, when you can just download the source project of the game, ThunderKit is a bit redundant even with Unity 😆
velvet quiver
Haha, fair point
A unity dev once asked me if tk had any use for developers
I feel lile the answer is yes, but honestly I dont have a clue
haughty compass
so, what is DOTS
normal agate
it's a framework for a data-oriented design architecture, basically it's a combination of 3 main features: Burst (to compile C# into more performant native code), Jobs (a parallelization system) and ECS (entity-component-system, basically a data-oriented programming pattern)
haughty compass
I see, and I take it that, since this is the only reason Unity's still in consideration, this poses some significant advantage over Unreal 5
grave notch
it's biggest advantage is that it allows the game to utilize all available CPU cores with barely any effort required by the programmer
haughty compass
that's... considerable
grave notch
also the data oriented architecture is very CPU cache friendly, reducing stalls caused by the CPU needing to fetch data from RAM
normal agate
well, Unreal has its own ECS-like system (Mass Entities), already compiles to native code (since it's C++) and parallelization in the form of Tasks
so I would say that the two are pretty even when it comes to this
haughty compass
and from what I gather, UE5's advantages are in the physics engine
normal agate
well, I wouldn't say specifically physics engine, the one Unity has for ECS is also good, but the biggest advantage of Unreal is that it supports doubles for world positioning and physics, unlike Unity which only has single-precision floats support
meaning you don't have to do as much origin rebasing
haughty compass
doubles are kinda necessary unless we want to hack together our own SOI stuff like the KSP team did
(I mean, we'll still have to)
(just less)
normal agate
yeah, it would just make it simpler, not make it completely unnecessary
pine valve
And I'm on the side testing Godot with Jolt physics and seeing about adding double percision into the engine... not sure there is an ESC system but... its OS and a lot of people have neat workaround for things.
haughty compass
always neat to test things
grave notch
godot was talked about a lot early on but it's lack of a DOTS equivalent was kinda why we ruled it out in the first place
normal agate
well, not exactly
ECS is not a requirement, it is just a tool we need in Unity because otherwise Unity is very slow
(since it uses Mono)
Unreal compiles to native code and Godot runs on modern .NET, meaning almost as fast as native
there were other bigger issues with Godot than the lack of ECS
it has some very questionable C# support issues, the editor is not nearly as mature, and there isn't as much support for it as there is for the two commercial engines
haughty compass
basically if we ever get to the point of making, like, a sequel, it might be in the running then since it'll have matured, I take it?
(then again, UE and Unity will have done the same unless Unity and Epic explode in a literal fashion in the meantime)
normal agate
I mean... I can't see why you would ever make a sequel rather than just improve the existing game
since we won't get extra sales money from making a second game
haughty compass
if you're just improving the existing game you wouldn't switch engines
velvet quiver
well, I wouldn't say specifically physics engine, the one Unity has for ECS is a...
Doesn't unity entities allow double precision transforms?
haughty compass
that's why I used it as an example
normal agate
if you're just improving the existing game you wouldn't switch engines
yeah, and I don't expect we ever will
grave notch
if you're just improving the existing game you wouldn't switch engines
there's no need to switch engine if you have a solid core
grave notch
Doesn't unity entities allow double precision transforms?
with custom code, yeah
the transform system is open source, you can modify it if you want
same with the dots physics engine
normal agate
Doesn't unity entities allow double precision transforms?
pretty sure it doesn't yet
haughty compass
what's double vs single precision? is there a such thing as triple (or higher) precision?
normal agate
I remember reading a thread where they suggested that since ECS has a much more decoupled architecture, you could go ahead and write your own drop-in replacement for the transforms system though
grave notch
what's double vs single precision? is there a such thing as *triple* (or higher)...
double is 64 bit, single is 32 bit
and no, there's nothing above double precision
yet
grave notch
I remember reading a thread where they suggested that since ECS has a much more ...
yes, considering almost all of DOTS is written in C# and the source is freely available, you can fill in any gap you want
it's more about if you think it's worth doing or not
pine valve
ah, right, so 'no' on the higher precision question
I mean... you can... but your performance is going to get cut in half...
velvet quiver
Therrs big int and big decimal in c# but yeah its costly
Even the move from 32 to 64 is costly
haughty compass
worth it though, as modern computers can handle the switch
velvet quiver
Its part of why a lot of people just builds frameworks that cope with the precision issues differently
When dealing with extreme distance, you'll have to regardless
normal agate
from what I've read on this topic, on modern CPUs, float and double operations are both handled natively at the same speed, the only issue is that since doubles are, well, double the size, memory speed becomes a bottleneck
velvet quiver
So even with double. You'll be building some kind of reference frame thing anyway
Imo Reference frames exist in reality because calculations using float for the master sim was too expensive and thats why time dilation is real! Fight me!
normal agate
So even with double. You'll be building some kind of reference frame thing anywa...
definitely, though it could be greatly simplified by not having to rebase like every 2 km, but rather only on SOI change, for example
brisk pebble
Being able to build the reference frame around SOIs rather than having to move it every 5km sounds a lot more convenient though
Munix said what I was gonna say first..
velvet quiver
Imo Reference frames exist in reality because calculations using float for the m...
By proxy, time doesn't pass for photons simply to save on computation costs
pine valve
from what I've read on this topic, on modern CPUs, float and double operations a...
Depends on the chip architecture in the CPU / GPU. Example, I have a 64bit AMD CPU. If someone is using a 32bit CPU it takes twice the time to process a double.
normal agate
I don't think anyone is using a 32-bit CPU for gaming these days
velvet quiver
I think a lot of 32bit support for hardware has been phased out
normal agate
64-bit CPUs have been around for like 25 years, so no wonder
pine valve
I think a lot of 32bit support for hardware has been phased out
end of next year is the end of support for 32bit
velvet quiver
Depends on the chip architecture in the CPU / GPU. Example, I have a 64bit AMD C...
Just gotta do all the physics on the gpu using compute (no lie, ive been toying with this idea)
normal agate
Unity.PhysiGs
haughty compass
I mean, that's not an awful idea
but at that point you're running a solid like, 5/6ths of the game on someone's GPU
would be an interesting set of sysreqs
"CPU: Pentium 4 or higher"
"GPU: RTX 3080 or better, RX 7800XT or better"
pine valve
"CPU: Pentium 4 or higher"
"GPU: RTX 3080 or better, RX 7800XT or better"
Dam, I'm only at 3070 😦
@slate sapphire is writing a masterclass on setting up an Unreal project in https://discord.com/channels/1078696971088433153/1246165293185765509
haughty compass
Dam, I'm only at 3070 😦
RX 6800 for me
cold spade
but at that point you're running a solid like, 5/6ths of the game on someone's G...
Then move some processing to cpu? There is a lot of things that trade cpu time for gpu time
haughty compass
Twiner said all the physics
cold spade
Twiner said *all* the physics
Not talking abt physics
haughty compass
I am
which is why I said like 5/6ths of the heaviest compute portions of the game would be on the GPU if you did that
cold spade
Rendering would be faster with no overdraw
haughty compass
because beyond graphics and physics there isn't a hell of a lot going on beyond that
cold spade
Rendering would be faster with no overdraw
And cpu could be used for sending only geometry that is rendered on the gpu
slate sapphire
Rendering would be faster with no overdraw
Zero overdraw?! 👀 What holy grail do you speak of?
slate sapphire
<@220534568988442625> is writing a masterclass on setting up an Unreal project i...
Yep, done for now! I will add additional resources later, especially for getting started with C++, but that should be a good quick start guide instead of a (checks notes) 4-6 hour beginner video tutorial on youtube! 🥹
Anyone getting going feel free to @mention me and ask any questions!
https://discord.com/channels/1078696971088433153/1246165293185765509
That actual step by step guide I posted will give anyone a great point of reference for quickly creating the right project, projects settings, and a few things about the editor
grave notch
ideally someone should make an equivalent for unity (and any other engine that may be prototyped with)
slate sapphire
Sadly the only other engine I think could have had potential for large worlds is UNIGINE, but it never went anywhere and the engine and devs were horrible to work with in my experience
And CryEngine is all but 💀
RIP CryingEngine
If anyone doesn't believe CryEngine is dead, please visit this link for more information: https://docs.cryengine.com/
brisk pebble
Tbh, I havent heard a single mention of anybody using CryEngine in a long time
normal agate
yeah, same
grave notch
yeah i don't think anyone is gonna argue against cryengine being dead
slate sapphire
Their community still seems very convinced it is the next great engine, meanwhile no one has been able access documentation for 6 months
And the only engine version you can download is CE5.7 LTS 😭
UNIGINE.... exists... I guess?
https://unigine.com/
normal agate
Stride seems pretty well positioned to get very good
slate sapphire
UNIGINE.... exists... I guess?
https://unigine.com/
I won't call it an outright scam, but I had full access to UNIGINE SIM SDK and nothing they show off was possible out of the box
slate sapphire
Stride seems pretty well positioned to get very good
I don't know much about Stride, have you used it?
normal agate
not personally, just evaluated it for a bit as a possibility for the project (at first we were kinda picking between Stride, Godot and Unity as the best available C# engines)
slate sapphire
How's it compare to Godot feature/maturity wise?
Looks like more mature C# support
normal agate
imo it's much closer to Unity when it comes to maturity of 3D rendering, but there were some things that weren't great, and the editor is definitely the worst out of the three
slate sapphire
imo it's much closer to Unity when it comes to maturity of 3D rendering, but the...
Oh yeah that's a big one
Nothing publicly available can really compete with Unreal and Unity in terms of editor these days
normal agate
yeah
slate sapphire
It is hard for me to want to use other engines because of their editor and tools honestly. I would for a full time job, but not for a hobby.
haughty compass
alright, Unreal downloaded and installed, gonna fire it up and see if this thing can deal with it or if I really will need to remote to my desktop
slate sapphire
alright, Unreal downloaded and installed, gonna fire it up and see if this thing...
Here's my little quick start guide if you like: https://discord.com/channels/1078696971088433153/1246165293185765509
slate sapphire
That's actually impressive
normal agate
meanwhile my 5th gen barely handles Rider 😭
haughty compass
but I do art and such on the Surface while at work
slate sapphire
Hey, developing on low end hardware forces you to optimize! 🧠
haughty compass
I think mine's a Pro 8
it was 400 bucks cheaper than the 9 and now the new stuff is out and makes both look like toys :V
anyhow, I think I should also look into dusting off my Blender skills as I feel like that might be helpful
normal agate
yeah but compared to the money I paid for my model back in 2017, they got so fucking expensive
😠
I've been looking into upgrading
but I'm not about to pay almost double
haughty compass
you can probably get a 9 for like half price
and, yeah, like Uriah said, doing dev work on low end hardware could help us a lot
if whatever we make runs (however badly) on a Surface, then we're doing good
normal agate
lmao that is true
if you want extra challenge, do it on a Surface Pro X
(ARM with x64 emulation)
slate sapphire
I literally test on a laptop all the time, who cares about benchmarks on a high end PC, put that shit on a stick of gum and see how it runs for low spec 🤓
haughty compass
Pro X has, like, an actual graphics card and actual heat-management stuff built into it because it's a 'real' laptop tho :V
I have an Alienware but it's almost a decade old and I can't actually access the File Explorer on it any more
(computer seriously just hangs)
(if I reimage it it'll probably be fine)
slate sapphire
Surface Laptops are probably the best on the market, I guess I shouldn't be surprised by their small form factor being able to run UE5 editor 🤷♂️
normal agate
Pro X has, like, an actual graphics card and actual heat-management stuff built ...
are you sure about that? the Adreno GPU it has is like in bottom 2% of benchmarks
(talking about Pro X vs. Pro 10)
haughty compass
hm, lemme check the pro site
slate sapphire
I don't have one, but I convinced my fiancee to get one after breaking multiple laptops and she loves it
normal agate
it's more of a long battery life over performance model imo
slate sapphire
Battery life and build quality
normal agate
I absolutely love mine, though the years have not been kind to it
it is after all 7 years old
slate sapphire
First thing I did was made her get a sleeve 😁
haughty compass
ah, I was thinking about the Surface Studio
normal agate
definitely wouldn't mind having that one
ideally, something with the convenience and touch screen quality of a Surface Pro, and with the performance of my gaming laptop 😂
ruby furnace
so what's happening here ? UE5 is being considered?
haughty compass
yep
me realizing my tablet could run the editor has morphed into a discussion on that topic
haughty compass
double-precision floats for our physics engine as a pro
lets us have fewer SOIs to consider
honestly, tbh, from what I've gathered here they're roughly equal and it's a matter of personal preference
(outside of the double precision)
ruby furnace
And what about compared to the Unity DOTS?
haughty compass
it sounds like DOTS lets us make better use of multithreading than UE5 does out of the box?
grave notch
unreal has a similar system called mass, but looking at the docs i wasn't really sure if it is good or not
grave notch
it *sounds* like DOTS lets us make better use of multithreading than UE5 does ou...
if we don't use unreal mass, that's definitely the case. unity DOTS scales extremely well and is (IMO) pretty easy to work with
normal agate
the biggest reason to use DOTS in Unity is sim performance, while in Unreal that generally shouldn't be as much of an issue
so we don't strictly need to use an ECS architecture in Unreal
grave notch
well, if we don't, we're back to single threaded sim, which is a big part of why KSP runs so poorly
normal agate
not really, multithreading has nothing to do with ECS
you can still multithread regular code
grave notch
that's true, but as far as i'm aware if you use unreal without it it appears to run the logic on the main thread (correct me if i'm wrong)
normal agate
ECS just generally guides you more naturally towards the structure
grave notch
of course we can multithread it anyways, but that probably requires extra effort
normal agate
Unity Jobs vs Unreal Tasks seem like basically the same systems
async, prerequisites/dependencies, nested jobs/tasks, etc.
at least from reading the docs, it seems like it's very similar to Jobs
slate sapphire
DOTS multithreading isn't like you don't need to care about it, but it is slightly easier than Unreal to do so
Either way multithreading requires a certain level of understanding of what your code is doing, DOTS will be slightly easier, Unreal will be slightly more performant
pine valve
This is what I expect to get at my “First attempt at Shaders” LOL 😂
slate sapphire
This is what I expect to get at my “First attempt at Shaders” LOL 😂
Pixel shader, vertex shader, or.... fragment shader? 👀
pine valve
Pixel shader, vertex shader, or.... fragment shader? 👀
Camouflage Hide for when I do serious nature photography.
And I don’t know anything about shaders yet, I watched 1 video about cell/toon/anime shading and was like “what? What… what!” So I think I need to read up more on exactly what a shader is and is applied.
pine valve
Last time I made a proper game was 300,000 lines of code looking like this… and my peak drawing skills.
(Yes I’m also holding 3lbs of paper of design documents for various games I wanted to make from sci-fi to fantasy.)
So comparison to today these game engines each look easy.
normal agate
oh wow, that's a cool find 😆
pine valve
oh wow, that's a cool find 😆
Yeah I have species, stats, ships, etc. Only a bit of code but these days with the tools in the engines I could probably remake the game in like a week.
I remember my sprite project I did at the last minute looks a lot like the « dodge enemies » games in how to use an engine tutorial. When I made mine no one else knew how to do those games and not have the computer crash/slowdown if you had more then like 50 sprites being rendered at one time.
Basically you had to dodge a bunch of fat dancing penguins which were animation tree character I developed for a dance game the month earilier. Anyways, nostalgia lane but I knew I kept a large binder in storage on it (tossed like 4 way back when along with a lot of lines of code).
Anyways… thought I’d share as you guys might find it interesting. Before game engines existed I had to bind my own alphanumeric key bindings to game effects.
velvet quiver
Last time I made a proper game was 300,000 lines of code looking like this… and ...
The infinite creativity that burdens all developers