It’s looking like a pretty good update to me!
Thank you Mr. Bunner, for fixing the 3 scenarios of properly emitting include errors to avoid crashes in your commit: .com/EpicGames/UnrealEngine/commit/e7d9ccd8f8b52ef4260591f6deee75c13a9f687a
Good news is that we were able to migrate all our HLSL code to “/Engine/beyond/” virtual path and get them fully working. We are working on an ambitious video compositing system called Essence that handles chroma keying to relighting to denoising, striving to match Hollywood quality in realtime. So far so good, and we hope to share demos with you soon.
There are a couple of remaining issues. I have not seen a commit addressing the empty Project/Shaders (next to Source directory) crashing the Editor at startup. Since now, full file paths to #includes are officially disallowed, the Shaders directory at Project and Plugin locations are the only proper methods to develop and distribute shader code. Also as another minor issue, the missing include files are silently ignored.
Is it possible the Shaders directory crash is due to the required PostConfigInit for the project module? Would PostConfigInit interfere with HotLoad?
We rely on fast development iterations to sculpt the features and quality of our code, and using #includes in Material Custom Expressions was for that very reason. We have not been able to get the RECOMPILESHADERS CHANGED command to pick up changes to #includes in Custom Expressions yet. Recompiling all the materials with custom #includes in MaterialTemplate.ush would be too slow. The missing Hotload in the Plugins system was another deterrent.
One more good news is Separate Translucency is now working in 4.17, as it was disabled in 4.16.
Mega Huge. Thank you! This is going to help me a lot
Why is a FRichCurve UPROPERTY suddenly no longer supported by blueprints in 4.17?
Worked fine up until 4.16, now it’s “Error: Type ‘FRichCurve’ is not supported by blueprint”
Hello, can you please show as any simple demo how to make VR mixed reality videos? Any info would be very helpful
- Spectator screens are now supported on the Oculus and HTC Vive.
This. Does this mean cooking collisions on a different thread? If not, what does that mean exactly?
In case anyone wasn’t aware, there’s also now support for PCSS shadows from directional lights.
r.shadow.filteringmethod 1 produces results as so…
Also, shadow biasing seems to have been heavily improved, point and spotlights have perfect shadows with as low as 0.01 bias in most situations now, which means no more peter panning or acne all over the place - they don’t use the new filter yet though, but I’m sure that’ll change once this feature becomes finalised.
Will there be ToString and FromString Blueprint functions for FPrimaryAssetId before 4.17 launch? Seems like a critical piece that missing from the BP support that exists in C++
That is great indeed!
Directional lights are still all messed up. Why would they improve point lights first …?
This is again pushed back to 4.18: Unreal Engine Issues and Bug Tracker (UE-43093)
It’s hitting us with a solid 60 FPS drop at the moment.
Basepass cost goes incredibly high when using various meshes with Grass Tool.
This change really should’ve been highlighted in the new features list. The difference is astounding even without PCSS.
Can you please post a picture without PCSS? Preferably on the other thread.
I get fuzzy,flickering shadows with **r.shadow.FilteringMethod 1
**
Are you using TAA? It’s kinda required I guess, I noticed some issues but not nearly as bad as that.
Well, point lights had absolutely horrendous issues without even being very close to parallel with surfaces, but I think they need to sort out directional lights and in general remove the horrendous “blending” which happens closest to the shadow casters, it’s just ugly and doesn’t fix a problem that should never have existed had the biasing been implemented properly in the first place.
Added a MakeDynamicAdditive node to animBlueprints.
Sounds intriguing dude, what does it do?
Hi everyone.
Just a reminder that if you believe you have identified a bug with the 4.17 Preview, please create a bug report on the UE4 Answerhub.
Thanks
As part of the blueprint data exposure cleanups we now properly inform users that they are making use of types that are not exposed as BlueprintTypes. This may mean that some errors in places where types that were previously being made use of without being marked as BlueprintType no longer work. We can certainly consider exposing these types, but in general something like FRichCurve has none of its properties exposed to Blueprints, so it would require a pass across the class to make sure that an appropriate API was available.
If you want to the type BlueprintType in your local build you should be able to continue using it, but I would be interested in the context that you are using them and how you would expect them to work from blueprints?
