Jump to content

runner78

Members
  • Posts

    118
  • Joined

  • Last visited

Posts posted by runner78

  1. 11 hours ago, Elfmaze said:

    What goes into the decision to stay with unity over unreal? 

    11 hours ago, Elfmaze said:

    I thought people used to say Unity was part of the limiting factor in the first game. Granted I know nothing about unity. But I assume it's been developing as fast as unreal on a parallel path.  Hopefully the new engine version doesn't have the same limitations.  

    One has to take into account that Unity is quite advanced in development since the beginning of KSP1. Some limitations do not exist anymore, and some limitations also arise from the inexperience of the developers.
    Unreal, however, is starting to get the problems unity used to have with its easy accessibility: many games with the same look. I just recently saw a video of an Unreal developer ranting about Unreal. More and more bad Unreal games are coming out. While it's easy to make "good-looking games" with unreal 5, that doesn't mean that this only applies to the trailers and that the game is then just bad or boring. he also ranting that unreal is becoming more and more complex and complicated with every update. I tried Unreal 5 times, apart from the huge installation size, between 40 and 110 GB depending on the components, I felt more comfortable with Unity.

  2. 43 minutes ago, minerbat said:

    is there a way to stop steam from auto-updating until i have finished my current mission that uses a kraken drive?

    You should also be able to set the version manually in the settings, according to SteamDB there is a public branch for the current version

  3. 1 hour ago, Gargamel said:

    Thats the beauty of time zones, the reference zone you pick is arbitrary.     As long as it’s specified which time zone they’re referencing, it doesn’t matter which one it is.  

    UTC is not a time zone but the world time to which all time zones are based.

  4. At the weekend I tried to create an experimental orbit scene in HDRP with realistic stars (HDRI skybox) but had quite a problem with the exposure, as soon as an object such as a planet was even slightly in sight, the whole scene was completely overexposed .

    However, I think that the move to HDRP is a bit late and maybe it should have been used from the start, or at least upgraded earlier in development since it's quite a hassle now.

  5. Unity's job system only has one worker thread per local CPU, and by the way it's a C++. The C# job system is just a wrapper over it.
    Unity also supports async/await, e.g. "async void Update()".
    For 2023.1, unity has also implemented its own Awaiter type that has less overhead and is then used for asyncone unity calls.

    9 hours ago, Lisias said:

    My point on my previous post. It can be useful when you have a lot of crafts scattered in the Universe, but managing colliders

    Only crafts within your vicinity will be loaded, at least the visual/part-physics. All others craft no longer play a role when it comes to local physics.

     

    10 hours ago, Lisias said:

    It's my understanding that in the same way the Unity's Update callbacks can be skipped under heavy load, so do the Burst jobs. At least, is what some posts on Unity forum is telling us.

    I've never heard of Update() or job being skipped. The thread is about burst not compiling a job, but that only means  the C# JIT is executed as a fallback. The job is always executed.

  6. 4 hours ago, Lisias said:

    Nope, I'm very up to date. See this thread (it is less than a year old). I'm talking about the GAME, not the engine.

    Additionally:

    If you create MonoBehaviour script and do things in any Fixed/Late/Update() function, this runs on main thread. Most of the Unity API's are not thread safe. Meaning you cannot create seperate thread and interact with the engine API's.
    Source (April 2022) 

    Yep, physics is generally not well suited for multithreading, unless you stop thinking serially and start to think "distributively".  Different crafts on different frames of reference don't interact with each other and, so, dont need to be simulated serially. Even two different crafts in the same frame of reference but not touching themselves can have their physics calculated in parallel - as long your data structures are tailored for that. Detecting collisions are still a problem, tough.

    The MonoBehavior message methods are called onthe main thread, but it does not mean that you have to calculate everything in it. You can just plan in LateUpdate() an job, and use the result in the Update() on the next frame.
    Many API from Unity now have job support, e.g. RaycastCommand.

    I do not know exactly to what extent the phsix multihiltering model is used in unity, but even if you calculate two vehicles separately, as soon as they are close to each other, they must be calculated together again so that the collision detection works.


    KSP2 actually uses the job system and burst, but it is still surprising why, for example, the fuel System case som problems, I assume that you can  the complete the work in jobs pro vessel/station, and is not dependent on Engine APIs.

  7. 3 hours ago, Lisias said:

    Unity games usually relies heaving on single core performance - Unity, or at least the part of Unity that KSP1 heavily relies on, is heavily built around a non threaded paradigm. As far as I know, the Unity's physics engine is not multi-thread capable - but this may be a weakness imposed by KSP1 itself, where all the Universe shares the same Frame of Reference at a given instant.

    I think you're not quite up to date, Unity itself uses a lot of multithreading on the engine side. Rendering uses its own thread, physics is actually multithreading so far i know. And with Unity's job system, a game developer can implement multithreading quite "easily" and is also used a lot internally by Unity.
    But physics is generally not particularly well suited for multithreading and has some limitation.

  8. 2 hours ago, K^2 said:

    But then you'll have to explain gravity, which is even harder. And before anyone suggests putting a chunk of neutron star or a tiny black hole in the center to generate the gravity, that would cause too much stress on the shell, causing it to collapse. So unless Ringworld Engineers have built Minmus out of scrith just to mess with Kerbals, I don't think that's going to work.

    By means of a tractor beam that attracts everything that comes close to create the illusion of gravity.

  9. On 7/18/2021 at 9:37 AM, The Aziz said:

    Besides, Unity editor isn't exactly resource friendly, I know from experience that after placing a bunch of light sources, flying around with recording software turned on wasn't what I'd call smooth.

    Editor or runtime? Game performance in the editor is always much slower than runtime build due to the editor overhead. There is also a difference whether the editor is in release mode or debug mode. For example, it makes no sense for level designers to run the editor in debug mode, this is only useful when debugging scripts.

  10. On 4/15/2021 at 10:50 PM, Dientus said:

    Well, do you think an icosphere would increase the need for processing power by much? It is using the Unity engine

    With mordern Unity (Jobs + Burst + new Mesh API) shouldn't be a problem on the CPU either. I saw an example, a coin animation at 60 fps (in the editor) when a new mesh was created every frame with over 100,000 quads.

  11. On 2/27/2021 at 6:17 PM, Alexoff said:

    After Dyson Sphere Program and No Mans Sky, it's hard to impress me with the graphics of the KSP 2 gameplay. But I'm sure K^2 is telling the truth and the game will rip the gaming industry apart, as T2 gives the studio a lot of money and time.

    After Dyson Sphere is also build with Unity, like KSP, but different art style.

    Valheim is also build with Unity and both Valheim and Dyson Sphere Program has an Hightmap based terrain deformation system.

  12. 21 minutes ago, K^2 said:

    I don't know if that's strictly a requirement, especially with Unity. You can easily catch up additional platforms to your leading one after the fact and then release in lockstep.

    It certainly depends on the game, but the menu and controls are often different. Genshin impact also uses asset bundles for ingame updates (events).
    But what you have to consider from the beginning is the performance, if the game should also be playable on low end devices, it is better to develop it for this right from the start.
    Genshin impact is, in my opinion, a good example that it succeeded, and the visually most beautiful anime-style game on the market.

×
×
  • Create New...