Announcement

Collapse
No announcement yet.

Unreal Engine 4.25 Preview

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    I noticed in 4.25 a new error started happening.

    Can't use hidden enum values as parameter defaults.

    And game trace channels are marked as hidden.

    What are we supposed to do in 4.25 and on for default params for game trace channels?

    Code:
        ECC_GameTraceChannel1 UMETA(Hidden),
        ECC_GameTraceChannel2 UMETA(Hidden),
        ECC_GameTraceChannel3 UMETA(Hidden),
        ECC_GameTraceChannel4 UMETA(Hidden),
        ECC_GameTraceChannel5 UMETA(Hidden),
    Right now in 4.24, it actually works fine. My custom collision channels configured within the engine appear as enum values. And when I try to call a C++ function with this default param from Blueprint, the default param is correctly set to the custom collision profile.


    Code:
    UFUNCTION(BlueprintCallable, BlueprintNativeEvent, Category = "Damage", meta = (WorldContext = "WorldContextObject"))
        bool ApplyRadialDamage(const UObject* WorldContextObject,
            float DamageMultiplier,
            float RadiusMultiplier,
            const FVector& Origin,
            AActor* DamageCauser,
            AController* InstigatedByController,
            ECollisionChannel DamagePreventionChannel = /*FCollisionConstants::Instance.DamageIgnoreNonSolidTraceChannel*/ ECC_GameTraceChannel2) const;
    https://imgur.com/a/lbI6hyc
    Last edited by illYay; 04-19-2020, 02:51 AM.

    Comment


      what is maximum jdk version that we can use with ue4 4.25 ?
      first time i use jdk 14 and i cant export my android project with this version
      now i am using 1.8.0_77 and 4.25 work correctly with this version

      https://www.unrealengine.com/en-US/t...al-engine-4-25
      this page does not have information about jdk in 4.25
      Last edited by Farshid; 04-19-2020, 08:30 AM.

      Comment


        Project link for lightmass problem https://www.dropbox.com/s/4nm7guahegywr0k/Demo.zip?dl=0

        More dark spots as you increase lightmap resolution. DanielW

        Last edited by Maximum-Dev; 04-19-2020, 08:42 AM.
        Artstation
        Join the support channel
        Gumroad Store

        Comment


          I reported the skylight slider being unusable as a bug but was told it was by design. Moving the slider one pixel increases the value from 0 to 47.(same thing on the directional light moves it from 0 to 0.71)
          https://i.imgur.com/8VOOKRL.mp4
          Just curious if anyone has actually used the skylight intensity slider in recent versions instead of typing in numbers.

          Comment


            Using 4.25 preview 7. I have tried to compile for Android, armv7 builds fine. But arm64 I continually get the following errors and the build fails for both APK and AAB. I tried on a different PC with same issue.

            UATHelper: Packaging (Android (ETC2)): [5/7] MyProject-arm64.so
            UATHelper: Packaging (Android (ETC2)): ld.lld: error: undefined symbol: FMemory::Malloc(unsigned long long, unsigned int)
            UATHelper: Packaging (Android (ETC2)): >>> referenced by MyProject.cpp:4 (C:/unreal/MyProject/Intermediate/Source\MyProject.cpp:4)
            UATHelper: Packaging (Android (ETC2)): >>> C:/unreal/MyProject/Intermediate/Build/Android/UE4/Development/MyProject/MyProject.cppa8.ooperator new(unsigned long))

            UATHelper: Packaging (Android (ETC2)): ld.lld: error: undefined symbol: FMemory::Free(void*)
            UATHelper: Packaging (Android (ETC2)): >>> referenced by MyProject.cpp:4 (C:/unreal/MyProject/Intermediate/Source\MyProject.cpp:4)
            UATHelper: Packaging (Android (ETC2)): >>> C:/unreal/MyProject/Intermediate/Build/Android/UE4/Development/MyProject/MyProject.cppa8.ooperator delete(void*))

            Comment


              Originally posted by pop-eye View Post
              Using 4.25 preview 7. I have tried to compile for Android, armv7 builds fine. But arm64 I continually get the following errors and the build fails for both APK and AAB. I tried on a different PC with same issue.

              UATHelper: Packaging (Android (ETC2)): [5/7] MyProject-arm64.so
              UATHelper: Packaging (Android (ETC2)): ld.lld: error: undefined symbol: FMemory::Malloc(unsigned long long, unsigned int)
              UATHelper: Packaging (Android (ETC2)): >>> referenced by MyProject.cpp:4 (C:/unreal/MyProject/Intermediate/Source\MyProject.cpp:4)
              UATHelper: Packaging (Android (ETC2)): >>> C:/unreal/MyProject/Intermediate/Build/Android/UE4/Development/MyProject/MyProject.cppa8.ooperator new(unsigned long))

              UATHelper: Packaging (Android (ETC2)): ld.lld: error: undefined symbol: FMemory::Free(void*)
              UATHelper: Packaging (Android (ETC2)): >>> referenced by MyProject.cpp:4 (C:/unreal/MyProject/Intermediate/Source\MyProject.cpp:4)
              UATHelper: Packaging (Android (ETC2)): >>> C:/unreal/MyProject/Intermediate/Build/Android/UE4/Development/MyProject/MyProject.cppa8.ooperator delete(void*))
              this won't be fixed until the release of 4.25. the engine is undergoing a HUGE change and everything is broken. but maybe in 3 years they will stop adding features and
              fix the bugs. WE PRAY FOR THAT DAY.
              Matt Walton: Programmer and owner for WireLiteSoft Games.

              Comment


                Originally posted by frostic View Post
                fix the bugs. WE PRAY FOR THAT DAY.
                But... preview releases are all about testing and bug fixing, so everyone would get a stabilized engine once the final release happens.
                4.25 has 7 preview releases already, almost 2 months focused mostly on bug fixing and tweaking features. Tons of fixes every day. If GitHub mirrors changelists live some fixes committed during weekends, probably some people are crunching to make things done. And they are slowed down by working remotely.

                It feels weird to read statements like "not enough bug fixes" in this topic which is all about bug fixes.

                Or reading suggestions "stop adding features, fix bugs only". The problem is, if they wouldn't add features, that means engineers would go work elsewhere - why keep hundreds of programmers in the company if only a few needed to fix critical bugs? - and engine development would practically stop. There wouldn't be even the next engine version to support new/updated platforms, no features you need to stay competitive. And bugs would be still there.

                [edited upon mod request - fixed so it wouldn't feel like offending anyone]
                Last edited by Moth Doctor; 04-23-2020, 08:21 AM.

                Comment


                  Moth Doctor
                  Originally posted by Moth Doctor View Post
                  That's so annoying, such complaining... Preview releases are all about testing and bug fixing
                  Fine, but in fairness to frostic, your posts also get a bit tiring sometimes tbh (always taking the superior high-ground / coming off sounding preachy). Look... Its frustrating that Epic no longer offer a roadmap where they clearly state release goals (to those w/o UDN at least). Meantime, there's legitimate demand for a stable build. Examples:1 2 3 4... It hurts everyone with this mushrooming of users (only started a couple of years ago as Epic became more corporate)... Just sayin...

                  Comment


                    I think we all get a little negative. It’s just because we love Unreal and are so passionate about it that when things don’t work like they say they do, or do work one version only to be broken the next, it is really disappointing. The main problem is not that preview releases have bugs, but that these bugs introduced in previews often stay for several full release versions, if they get fixed at all (I’m looking at you Landscape Physical Materials).

                    And make no mistake, we are happy to have new features and want to use them. But often we can’t because systems we’ve spent 100+ hours working on sometimes break when we upgrade. I wrote an entire blueprint only save system, was about to put it on the marketplace, only to have it broken in the next release. So now I have to decide whether to rip that out and use a different system, or forgo new features that are really cool. And that’s not a fun decision.

                    Comment


                      Originally posted by EntrpriseCustomr View Post
                      Moth Doctor
                      Look... Its frustrating that Epic no longer offer a roadmap where they clearly state release goals (to those w/o UDN at least).
                      Sure, but I can't see how this is related to my comment or comments above?
                      I was complaining on complaining in this Preview topic, not on all threads and everything. And now you're preaching me on that

                      I can take that I'm "sounding preachy", but sometimes people here expect miracles. They demand miracles, full stability of codebase with 2-3 million lines of code

                      My opinion is: there's simple reason for the lack of roadmap is that... Epic simply is unable to guarantee a given system/feature/fix would be delivered in the promised timeframe. Or if it would fulfill expectations.
                      - Unity tried it hard, and couldn't deliver "production-ready" systems on schedule. This backfired, devs often complain about "ready" features that aren't ready.
                      - A lot of software houses don't announce precise details of future product revisions before features are implemented, i.e. Houdini, Quixel.
                      - Epic actually tries to communicate things. They simply can't give you exact date i.e. "when Chaos would be production-ready" because they simply don't know. Creating new features/systems usually don't meet "time exceptions". This is true even if developing features for a small game...
                      - When they still had a clunky roadmap (it was very working well), people were just repeating questions "why X is still not implemented" and Epic couldn't properly reply - they didn't know the answer or couldn't announce things like "hey, we started working on our own physics system, but we don't know when this will be ready, maybe 2 years, maybe 3 years".
                      - UDN doesn't provide an exact roadmap. Sometimes you'd get "current estimations", but nothing you can truly rely on.

                      So... yes... I'd love an awesome roadmap with precise release goals and dates. I do try to adjust my development to engine development.
                      - Just I don't see how this would be possible? Without actually delaying most of the release goals.
                      - It's extremely important for my projects to have all these new features and system refactorings. So I don't share enthusiasm to say "stop adding features, fix all the bugs". Especially if added in the Preview topic.


                      Originally posted by EntrpriseCustomr View Post
                      Meantime, there's legitimate demand for a stable build. Examples:1 2 3 4... It hurts everyone with this mushrooming of users (only started a couple of years ago as Epic became more corporate)... Just sayin...
                      The thing is, you present this like "people demand a stable build", but "Epic doesn't care". It creates notion that "they don't care, don't fix things". Or more things would be fixed in an audio system if they wouldn't work on raytracing. Or similar claims

                      Please, take into account the fact my perspective. I started a gamedev career by working with in-house engines. I was happy if editor didn't crash 20 times a day or somebody actually had time to properly implement tools without running to another task.

                      Overall quality and stability of Unreal Engine 4 are amazing, brand new standards.
                      - Compared to most in-house engines designed to support only single game type, impossible to use tools if its programmer didn't come to your desk and explain everything in detail, there was never time for engine documentation.
                      - It's superb if compared to Unity where devs often mention a long list of things that stop working. Or they had to revert the project to the older system or engine version.
                      - If somebody demands 100% stability from such huge software, he never gonna get it. We're quite close to this 100% however. There are hundreds of modules updated with every version, and it's not like people complain about the big amount of them...

                      Let's take one of the issues mentioned in your link:
                      "Audio on Xbox One broken if updated a project, required massive rework and research"
                      Yes, because they switched to the new audio engine by default. Nobody rushed it. They spend 2 years on maintaining the old engine (very time-consuming since old implementation wasn't multiplatform, often they had fix things multiple times, for every single platform) and that slowed down introducing the new, properly designed audio mixer. Audio team spent a lot of time to make a new engine as compatible as possible with the old one. Obviously, it's not 100% compatible, some things need to be reworked.
                      - Now if you take such comment above without proper context/explanation... It gives impression that things broke for no reason! Epic failed and ignored the serious issue! Which simply isn't true.
                      But we don't even know the context... does the author use the new audio engine? If not forced, it could switch back to the old engine? Does the author is aware that switching to a brand new system (entirely different code) cannot be painless?

                      Another post states "Turning UE4 into more or less useless and not reliable at this point." That isn't exactly true for the general engine community. Could it be better? Sure, but these posts are often over-dramatic. Like the entire engine got "less useless".

                      Meanwhile, I do keep updating the project to every new version. Often waiting longer (weeks) before the upgrade. Yes, I can't consider the first final release as stable enough. If not compiling the engine from source, it's often better to wait until the first patch.
                      I'm always preparing to encounter major issues that would need to be immediately fixed. I don't issue "demands for stability". Yeah, I had to deal with some bugs with almost every engine release. Still, an incredibly small price for getting all these new features, improvements and work of hundreds of engineers. A dream for an indie developer.

                      Call me "taking the superior high-ground", but I gonna defend the opinion that UE4 is an extremely stable engine compared to all other ones and given the speed of engine development.

                      What they could do and should do is to release patches more frequently. Why couldn't they release a patch every week or two? It would improve a lot if given project uses launcher build of the engine
                      Last edited by Moth Doctor; 04-21-2020, 05:42 PM.

                      Comment


                        Originally posted by Nerdsbeware View Post
                        And make no mistake, we are happy to have new features and want to use them. But often we can’t because systems we’ve spent 100+ hours working on sometimes break when we upgrade. I wrote an entire blueprint only save system, was about to put it on the marketplace, only to have it broken in the next release. So now I have to decide whether to rip that out and use a different system, or forgo new features that are really cool. And that’s not a fun decision.
                        Yeah, I understand your pain. There's one of the reasons I follow all information, browse GitHub submits - to minimize such issues.
                        It happened often while we're porting the game to early UE4 that rendering programmer implemented missing things. And actually Epic implemented it in their way such a version later

                        Another thing they could improve is to communicate core engine changes. It's black box, shortly listed in release notes without explanation.
                        Last edited by Moth Doctor; 04-21-2020, 11:58 AM.

                        Comment


                          Originally posted by Moth Doctor View Post

                          Sure, but I can't see how this is related to my comment or comments above?
                          I was complaining on complaining in this Preview topic, not on all threads and everything. And now you're preaching me on that

                          I can take that I'm "sounding preachy", but sometimes people here expect miracles. They demand miracles, full stability of codebase with 2-3 million lines of code

                          My opinion is: there's simple reason for the lack of roadmap is that... Epic simply is unable to guarantee a given system/feature/fix would be delivered in the promised timeframe. Or if it would fulfill expectations.
                          - Unity tried it hard, and couldn't deliver "production-ready" systems on schedule. This backfired, devs often complain about "ready" features that aren't ready.
                          - A lot of software houses don't announce precise details of future product revisions before features are implemented, i.e. Houdini, Quixel.
                          - Epic actually tries to communicate things. They simply can't give you exact date i.e. "when Chaos would be production-ready" because they simply don't know. Creating new features/systems usually don't meet "time exceptions". This is true even if developing features for a small game...
                          - When they still had a clunky roadmap (it was very working well), people were just repeating questions "why X is still not implemented" and Epic couldn't properly reply - they didn't know the answer or couldn't announce things like "hey, we started working on our own physics system, but we don't know when this will be ready, maybe 2 years, maybe 3 years".
                          - UDN doesn't provide an exact roadmap. Sometimes you'd get "current estimations", but nothing you can truly rely on.

                          So... yes... I'd love an awesome roadmap with precise release goals and dates. I do try to adjust my development to engine development.
                          - Just I don't see how this would be possible? Without actually delaying most of the release goals.
                          - It's extremely important for my projects to have all these new features and system refactorings. So I don't share enthusiasm to say "stop adding features, fix all the bugs". Especially if added in the Preview topic.




                          The thing is, you present this like "people demand a stable build", but "Epic doesn't care". It creates notion that "they don't care, don't fix things". Or more things would be fixed in an audio system if they wouldn't work on raytracing. Or similar claims

                          Please, take into account the fact my perspective. I started a gamedev career by working with in-house engines. I was happy if editor didn't crash 20 times a day or somebody actually had time to properly implement tools without running to another task.

                          Overall quality and stability of Unreal Engine 4 are amazing, brand new standards.
                          - Compared to most in-house engines designed to support only single game type, impossible to use tools if its programmer didn't come to your desk and explain everything in detail, there was never time for engine documentation.
                          - It's superb if compared to Unity where devs often mention a long list of things that stop working. Or they had to revert the project to the older system or engine version.
                          - If somebody demands 100% stability from such huge software, he never gonna get it. We're quite close to this 100% however. There are hundreds of modules updated with every version, and it's not like people complain about the big amount of them...

                          Let's take one of the issues mentioned in your link:
                          "Audio on Xbox One broken if updated a project, required massive rework and research"
                          Yes, because they switched to the new audio engine by default. Nobody rushed it. They spend 2 years on maintaining the old engine (very time-consuming since old implementation wasn't multiplatform, often they had fix things multiple times, for every single platform) and that slowed down introducing the new, properly designed audio mixer. Audio team spent a lot of time to make a new engine as compatible as possible with the old one. Obviously, it's not 100% compatible, some things need to be reworked.
                          - Now if you take such comment above without proper context/explanation... It gives impression that things broke for no reason! Epic failed and ignored the serious issue! Which simply isn't true.
                          But we don't even know the context... does the author use the new audio engine? If not forced, it could switch back to the old engine? Does the author is aware that switching to a brand new system (entirely different code) cannot be painless?

                          Another post states "Turning UE4 into more or less useless and not reliable at this point." That isn't exactly true for the general engine community. Could it be better? Sure, but these posts are often over-dramatic. Like the entire engine got "less useless".

                          Meanwhile, I do keep updating the project to every new version. Often waiting longer (weeks) before the upgrade. Yes, I can't consider the first final release as stable enough. If not compiling the engine from source, it's often better to wait until the first patch.
                          I'm always preparing to encounter major issues that would need to be immediately fixed. I don't issue "demands for stability". Yeah, I had to deal with some bugs with almost every engine release. Still, an incredibly small price for getting all these new features, improvements and work of hundreds of engineers. A dream for an indie developer.

                          Call me "taking the superior high-ground", but I gonna defend the opinion that UE4 is an extremely stable engine compared to all other ones and given the speed of engine development.

                          What they could do and should do is to release patches more frequently. Why couldn't they release a patch every week or two? It would improve a lot if given project uses launcher build of the engine
                          The lighting is vastly underwhelming compared to Unity, but I suppose thats being fixed to some degree or not. My main project is not in Unity, but what I do have there, the lighting in general is good, and where overlaps occur, its gorgous.I guess Unity has had more time to hone things. I can waste hours on lighting and still not have it right its a giant mess of a subject. Wondering if 4.25 will fix any of that && adding world comp where my world resides adds even more stress as rotating light to one angle looks good in area X, yet area Y looks washed out, horrible, and my system ( most of our systems I imagine_) are weary to handle raytracing in totality. I wish.

                          But yes, overall, UE4 while spotty 2d is much easier to dev in 3d as Unity makes you make so much ,giving you little out of box, but move, but then they focus a lot on profit/store for most things.

                          I guess I see the two engines similar for various reasons, but in Unity I often get weird errors for the dumbest reasons, like editor theme, tons of errors often just for script differences changing engine, there I think Unity falls hard. I never see that in UE4 , tho I'm not sure its a 1 to1 comparison.

                          Lighting is the biggest headache , even in Unity its not prize.

                          " They demand miracles, full stability of codebase with 2-3 million lines of code
                          "

                          I personally find programming at that level utterly amazing, so I don't personally prefer to put labels on them, of what they can and can't do within a given length of code

                          No matter, opinions vary always will, but honestly , complaining about someone else complaining is a double negative and those aren't helping to create a conducive atmosphere IMHO OFC .

                          Anyway game dev is hard , because making good looking games that run well using all features ,components, IS hard short of someone having tons of experience, even then when isn't it at least time consuming when can be seen as hard

                          Making games can be very stressful depending on who we are and our experiences, so...
                          Last edited by neighborlee; 04-22-2020, 12:08 AM.
                          Solo but Seismic - feel free to apply
                          https://neighborlee1.wixsite.com/theheartseed

                          Comment


                            Moth Doctor
                            Originally posted by Moth Doctor View Post
                            Call me "taking the superior high-ground", but I gonna defend the opinion that UE4 is an extremely stable engine compared to all other ones and given the speed of engine development....
                            No one is saying the engine is always unstable. For many 4.10 / 4.18 were incredibly stable. It would just be nice if Epic could focus on kicking out a stable build occasionally, or an LTS version as suggested by KristofMorva in a link above.

                            Originally posted by Moth Doctor View Post
                            I can take that I'm "sounding preachy", but sometimes people here expect miracles. They demand miracles, full stability of codebase with 2-3 million lines of code .... - If somebody demands 100% stability from such huge software, he never gonna get it.
                            Epic could focus on a stability pass every 5-10 versions though. They did before... Every other tech firm with a large code-base has the same challenge. 4.19-4.25 are reminiscent of pre-4.10 versions, where the engine was not fun to work with... I have to believe there are target Enterprise users out there who also want to see a more stable build occasionally.

                            Originally posted by Moth Doctor View Post
                            What they could do and should do is to release patches more frequently. Why couldn't they release a patch every week or two? It would improve a lot if given project uses launcher build of the engine
                            Ah finally, at the very end of the wall of text there's an admission that engine stability could be improved through increased patching... Chatting with you feels like debating with a politician kjustynski (your later edits sharpening the text / adding more razor wire didn't go unnoticed)... Nice work El Presidente... ;p

                            Comment


                              It wouldn't be a satisfying reply if personal "touch" wouldn't be added again, right?

                              Originally posted by EntrpriseCustomr View Post
                              Moth Doctor
                              I have to believe there are target Enterprise users out there who also want to see a more stable build occasionally.
                              I admit that's a perspective I rarely "consider". This brings Houdini to my mind, where you have even nightly builds released frequently. I guess that's the highest standard of support you can get for "creative" software while it doesn't require putting a lot of resources into LTS.
                              Maybe it wouldn't be feasible for Epic to release such builds all the time, but important hotfix could be delivered just the same day it was submitted to the release branch.

                              It would require a very little from engineers (they do already fix many remaining critical issues quickly after release) and changes nothing for those compiling engine for them (which even small indie studio do, it's easy and "natural" thing to do). But I see now how this could improve things for those who just want to use tools, not patch them themselves

                              PS IMHO such notes directly from you are much better for conversation than simply linking to forum posts which tends to sound very dramatic, while extremely vague. No information on system specs (there's a good reason why support technician would ask for DxDiag or another information dump while analyzing performance issue), no information on enabled features and plugins (especially these marked as early access or experimental).
                              Sometimes all you need to is update GPU drivers, often is a very specific thing in your project that's needs to be fixed and updated. And evidence such as "I stay with UE 4.xx, it was last stable build" is quite anecdotical, you can't check if newer versions are less stable for you if you don't actively use them...
                              I could post another "anecdotical evidence": for me, early versions of UE4 were the least stable because of unsolved issues with circular references between blueprints and a lot of similar issues of new engine generation. Now what? Everyone could post his experience with the engine versions and it could be very different...


                              Originally posted by neighborlee View Post
                              I personally find programming at that level utterly amazing, so I don't personally prefer to put labels on them, of what they can and can't do within a given length of code
                              Yeah, measuring software complexity by counting lines of code isn't the best idea, generally. It was just to quickly give an impression of engineering effort we're dealing with

                              Originally posted by neighborlee View Post
                              No matter, opinions vary always will, but honestly , complaining about someone else complaining is a double negative and those aren't helping to create a conducive atmosphere IMHO OFC .
                              Tru that. Next time I'll try to go in different directions like "don't panic, it's just Preview, a lot of critical issues already fixed". Thanks for accenting word "negative", it makes me review my wording

                              Comment


                                Originally posted by EntrpriseCustomr View Post
                                Moth Doctor

                                Meantime, there's legitimate demand for a stable build. It hurts everyone with this mushrooming of users (only started a couple of years ago as Epic became more corporate)... Just sayin...
                                Great discussion. I agree with the above statement wholeheartedly. On the plus side it's been really great to see so many bugs fixed in each preview of 4.25, and not just things in the newer "9----"... range like usual, but a few older ones going back to the 7's and 8's. Definitely a step in the right direction and I hope they keep at it. I love using this engine, and discover cool new things about it every day, but the growing backlog of bugs is extremely frustrating to deal with.

                                I wish they would just spend six months doing nothing but going through that backlog, fixing them up, and getting a really stable build going. I submitted one bug over a year ago, which Epic reproduced, and which should have been a relatively easy fix for them, with no obvious chain of dependencies, but no one has looked at it since. Also there are some great features that have been around for 3+ years but are still somewhat broken and haven't received any love since being added.

                                The "upgrade roulette" is the hardest part to deal with though. Each new version might fix something important that's been broken for awhile, but then it winds up breaking something else, or several things, that are essential. Sometimes these bugs can be worked around with some hacky changes to the engine but most of the time they can't. Back in the 4.12 to 4.21 days these newly broken things would be quickly addressed in hotfixes, which was very reassuring, but now they often sit there for multiple full releases, or never get fixed at all. I do pay very close attention to the updates, but it's pretty hard to check every single thing you use, or think you might use, for perfect functionality in all possible conditions before upgrading.

                                Examples off the top of my head that have prevented me from upgrading...

                                4.22 broke early Z-pass and sphere traces
                                4.23 fixed z-pass, broke something else I can't remember atm
                                4.24 fixed sphere traces, broke landscape physical materials (oy!), other broken thing still broken
                                4.25.... holds breath.... well, holds breath for 4.25.1 anyway.

                                Fingers crossed.
                                Last edited by Ramasurinen; 04-22-2020, 09:01 PM.

                                Comment

                                Working...
                                X