Figured I would chime in with a +1 for Epic to implement plugin support for modifying the rendering engine. I have serious doubts about my skills as a github user and getting everything to play nicely. This would also be a huge benefit for the ArcViz crowd that may or may not be programmers. Going from AutoCAD / Inventor to UE4, and then needing to learn about github branch management and compiling? No thanks!
I dont believe packaging works at this time for my build, I know there are a couple of pull requests on the main NVIDIA branch for fixing packaging with HairWorks, so maybe imlpementing that would allow packaging for all techs to work (maybe not). Each tech might have its own reasons for packaging failing. At this time I have no plans to look at that, as my version of the engine is still in constant flux, once it settles down and I have all the features I want, then I will take some time to look at it, but that is still a while away.
I am happy to accept any pull requests from anyone who may be looking at fixing packaging.
FWIW I randomly had this happen in an editor session as well, and I figured out it was caused by the specular filtering by playing with the post process settings. Can’t explain why it wasn’t happening in the 4.7 build, or why it only seemed to be happening to me, but disabling specular filtering in the post process settings avoids the problem for me. It’s on by default, which seems unnecessary when specular jittering is off by default.
You’re looking for DoScreenSpaceReflections in ScreenSpaceReflections.cpp. If VXGI specular is enabled, then it just returns false. IMO it would be better if you could enable both without changing the source code, but the VXGI branch defaults should probably change SSR to default to disabled.
If you enable VXGI+SSR, you probably also want to change ReflectionEnvironmentShaders.usf so it blends SSR with the VXGI specular.
You probably also want to lower the max roughness that SSR will be done for so it only uses it for smooth surfaces. For me, SSR+VXGI fixes more artifacts than it adds:
It’s probably possible to fix SSR artifacts like the false reflection underneath the sphere by making it more conservative about what it considers a hit, since VXGI can fill in for situations where SSR doesn’t have enough information.
Hi Simon, are there any news with Flex and the stuttering and adding surface emitters to blueprints issues?
Indeed this looks like a bounds issue. The FlexFluidSurface component gets the bounds from the connected emitter instances. I haven’t been able to reproduce the issue. If you haven’t already, could you try to turn off the surface rendering, and re-enable the particle rendering to see whether it happens in the exact same setup otherwise?
I believe that the problem lies with the flex fluid surface since rendering flex particles (balls) works fine. I have noticed that when I was testing the fluid surface I was at +35286 on Z-axis in my level, and when I moved the flex fluid surface emitter to 0 on Z-axis there where no stuttering at all.
Weird. I downloaded your branch again and recompiled just to make sure but no dice. When I create a procedural foliage volume it says it’s a flex actor. The entire procedural foliage tab is missing so no simulate button either.
On the Epic 4.8 branch this of course works fine. I’m clueless as to what gives.
I’m using OceanShader with UE4.8 integrate with Nividia GameWork. I’m stuck in the same problem with ‘FVertexFactoryInterpolantsVSToDS’ error in material editor.
I’m not clear how to fix the issue due to Flex fluid vertex. Could you please clarify more?
It seems the change didnt make it through to my 4.8 branch, but in the function ShouldCache of the FFlexFluidSurfaceVertexFactory in Engine/Source/Runtime/Engine/Private/PhysicsEngine/FlexFluidSurfaceComponent.cpp you need to change “return true;” to
We’re working on the individual branches right now, I’m looking at the FleX upgrade today (with more changes on the FleX side, including support for a new kind of soft-bodies); the VXGI team has the upgrade done and we’re planning to push it by next week. The other branches should follow reasonably quickly. Regarding an all-in-one-branch, I don’t have an official ETA.
I was wondering if shader compiling with vxgi still taking few minutes to complete, like before? I would like to try to use this tech in production, but shader compilation times seem to be a major drag as of now. Also, if that’s still the case, will it be addressed in the future?
Another question is - how soon do you think it will take for HBAO+ to make to the official branch (in 4.9 maybe?), as per my tests it works perfectly in its current state.