Does atmospheric fog work right? Does occlusion culling work with reflection pass?
Currently performance hit is unacceptable. Even with 25% screen percentage our reflection cost around 35-40% of frame. Lot of this cost is from dynamic shadows that could be skipped. It would also be neat to allow user to set Material level for reflection pass. I could skip stuff like POM, detail maps, color variations, all under water etc.
It also seems that reflection pass use a lot more draw calls that normal pass. I don’t have exact numbers but it was like 60-65% of all draw calls. Not sure about reason.
Another question is how occlusion culling is implemented for planar reflection actor. Sometimes reflection pass is rendered even when I look right to the ground way above reflection plane.
Even with some rough edges I really like this . Our water is now almost perfect.
This planar reflection remind me of UDK. very handy stuff.good job epic u guys is the best.! however, When i try it something not right with the reflection. and tips from epic? and how to make the reflection quality better. please see the pic below
TQ
it affecting other object is bad.
Depends on whether it is actually approved for integration, and done during that timeframe. My point was that if you want a clip plane in a scene capture 2d, no reason to wait for us to decide to support it, you can modify the source.
It’s ok to allocate render targets at runtime, but bad to do so every frame. FPlanarReflectionRenderTarget is caching the render target so that it does not get reallocated every frame.
Atmospheric fog is not completely correct, because fog will be picked up underneath the water plane. I haven’t done enough tests to know how big of an this is in practice. It’s probably not solveable either, due to the precomputation implementation of atmosphere.
Occlusion culling does work with the reflection pass (objects in the reflection pass occlude each other).
The performance cost of a planar reflection is completely dependent on what’s in your scene. In other words - you control it. Scenes with a lot of triangles and meshes in particular will be heavy because those costs are unaffected by the planar reflection’s
ScreenPercentage.
Yep we need controls for what features are rendered. Material quality level is a good idea. LOD controls will be important too.
The planar reflection pass is using a different camera position and angle so you can’t compare it directly to the main view - it sees different things.
There is occlusion culling on the planar reflection component - the whole reflection pass is skipped when it is invisible. It really only kicks in for localized components like a mirror. There’s a limitation in the occlusion system where if the camera near plane intersects the bounds of a component, that component is always visible. That will cause the planar reflection for water to continue rendering when you are above it and you look up. That’s something we could improve.
So I have implemented a little plugin which can resize a rendertarget at runtime and also update the SceneCapture2d component in editor to the reflected viewport camera position (so that it can be previewed in editor).
There is no way getting around the fact that the clip plane needs to be enabled via modifying engine source though, I will be submitting a pull request soon.
The clip plane can potentially be used for other things as well btw, like portals!.. so it’s definitely something that the SceneCapture2d component needs to have.
Initial tests show up to ~10% performance improvement compared to the regular planar reflection actor! that is with the default SceneCapture2D show flags… a significant improvement can be achieved by disabling various features like dynamic shadows.
The downside of course is that you have to implement the reflection in the material side manually to account for fresnel, normal distortion, roughness etc. but at least you have full control to do whatever you want with the render target.
On that subject, do you guys have any advice in how to go about implementing roughness? I’m currently experimenting with blurring the texture but it seems expensive and not exactly “physically correct”
Hopefully I will end up with a couple of material functions to do all those things as simple as plug and play.
Yeah the whole “blur for roughness” thing is only going to get you relatively bad looking results unless you have enough resolution, not too mention “physically incorrect” as it were. Still, if you really must have it, you’re not going to do much better (or worse) than your initial test right there.
To avoid leaks you should test visibility of sample and weight by that for blurring. Actually this should be done for distortion too. If ray from distorted sample towards eye is not visible from camera(depth buffer test) then it potentially cause visible leaks. This can be seen if you are in cave then distorted samples can reflect sky even that camera is fully inside the cave.
That sounds like a great optimization
I would kindly request to keep in mind to also add these in the SceneCapture component (when and if this ever gets implemented of course).
If at least Epic makes scenecapture class extendable, removing it from minimal API, you could implement this without rebuilding full source code or waiting for a pull request to be merged.
From what Lincoln says in this post it could be very soon.
That’s what I think too. That’s why it could be so useful.
Absolutely. On my side, I found that the most significant improvement is by disabling “deffered lighting”.
What would be the workflow with a clipping plane enabled in the scenecapture actor? For example, in the screenshot you posted, do you still use a planar reflection (actor or component) or a scenecapture actor located under the floor by blueprint stuff? How does it work?
About roughness: your screenshot looks good to me, even if not perfectly physically correct (but anyway nothing really is in real-time graphics. When you play a game, the point is only: does it look good or not?).
By “frosting” reflections a little bit with a normal map (very small tiling voronoi cracks texture for example) and fading reflections as they go deeper “under” the ground by postprocess material stuff, it could be pretty good imo. However, frosting blurred reflections is necessary on a rough surface.
TK gave me a copy and I’ve been testing it out for the past few days. Basically with the code changes adding in the clip plane you can create an actor (he’s done this in a plugin) that captures a render target, which is then usedin a material. With that done, it looks and acts nearly identical to a Planar Reflection actor, but has so much more control. You don’t need the PlanarReflection actor, just a blueprint based off the custom scene capture actor in the plugin, which can be as complex or simple as you want.
The intended use was for an ocean simulation (we’re both working on the community ocean sim project), but he made sure it works great for just about anything. You can adjust the quality in multiple ways, such as reducing the resolution of the RenderTarget to improve performance. The 10% improvement is with a 1080p RenderTarget. With a 720p RenderTarget the performance gain becomes 30% or more, but the quality difference is very minor. For something like a mirror you’d want full resolution, but for something like an ocean where the reflection shouldn’t be perfect in the first place due to surface distortion breaking it up, it’s a huge savings.
The main reason this is such a big deal for us is that it only gets applied to the surface(s) you want it applied to, and you can exclude any actors you don’t want reflected. It makes this much more useful than the current PlanarReflection actor for our use case.
Really looking forward to having this added to source. It’s also very lean on code changes (+24 lines that only run if the clip plane is enabled). He did a great job, it’s really impressive along with the plugin.
No unfortunately. I’m using it as a component currently in my project, the component is pretty much identical to the Actor. Anything like landscape or objects in the water receive the reflection if they are within the Distance From Plane start/end. Even materials that are fully rough will get reflections currently, which is being fixed, but not having the control to specify what receives the reflection makes it almost unusable in our case.
Ok. In fact, when testing, I didn’t even check this. I only tested on opaque meshes and thought that, obviously, for translucents, what’s in the water wouldn’t receive the reflections.
Planar reflection actor should have automatic culling when camera is wrong side of plane. I am doing this at blueprint when camera is underwater but I can’t see reason why this would be bad idea to do in engine in general.
I am having a similar that is affecting my whole scene. I am at a dead end and I cannot respect the deadline.
Since I have lots of mirrors I upgraded to 4.12 so that I can use planar reflections in my project. They work well on vertical surfaces. On horizontal surfaces I prefer not to use it since of the problems you mentioned.
However I am now stuck with weird reflections on all horizontal surfaces. Please check my attachments.
Skylight, Postprocessing all disabled
I have deleted all horizontal planar reflection actors. No result.
I have disabled the planar reflections from the rendering options restarted the project and rebuild all shaders. Reflections remain.
[SOLVED] For future reference - I had a planar reflection in one of the door blueprints that somehow corrupted the whole scene even thought the planar reflections were disabled. Sorry for the spam but I lost all week on this one. Maybe it helps others.
I miss the UDK version of reflect actor , any plans to bring back the render to texture for the planner reflect like in udk?! It feels very limiting as it is now, without being able to have a way to access the reflection inside the material. I would like to be able to have the flexability of render to texture.
that is with the default SceneCapture2D show flags… a significant improvement can be achieved by disabling various features like dynamic shadows.
(when and if this ever gets implemented of course).
