somewhat related, you can turn off LOD with the console command "mlmode 0"

Unreal 227 has a feature called "no clip rendering". Would this meet your requirements?

darknovismc wrote on Nov 26^th, 2019 at 7:32pm:


It is not. I think what you are refering to is backfaces beeing culled in software already before lighting while The SupportsNoClipRender in 227 affects only stages after lighting.

This may help with the issue to some degree, but it certainly won't solve it, as normals on UE1 meshes are entirly crappity smacked up and requires massive amount of mesh cleanup (though i certainly won't mind, and actually want to work on that for stock UT resources). Also there is the issue that twosided faces are turned towars the viewer before normals are calculated, which will cause an additional flickering. Problem on vertex lighting is that one only knows whether it's a backface or frontface during polygon rendering, so one would need to calculate vertex lighting for front and back and pass that on, etc. But thats probably not gonna happen for the software lighting, as this would likely get to prohibitive expansive.

However copying the SupportsNoClipRender from Unreal 227 makes no sense at all. The only effect this option has is to disable software clipping of vertices on the edges of the screen. This software clipping was only ever needed by SoftDrv which would crash otherwise. Any hardware based rendered plain ignores the outside parts, or rather does perform the exact same clipping in hardware. This software clipping will also result in invalid normals on the newly created vertices btw.

So this should be skiped automatically if not SoftDrv/SpanBased rendering. The only thing where the SupportsNoClipRender would have had made a difference is clipping on the near plane of the SceneNode. This near clipping is not implemented in the RenDevs, but can be implemented virtually for free in hardware based RenderDevice. However, software near plane clipping is done regardless of the SupportsNoClipRender. In fact the whole software clipping is again fully performed as soon as there is a near plane with scenenode recursion.

However in stock implementation of Render there is a direct or indirect (over ComputeRenderSize) SetSceneNode call is missing to inform RenderDevices about the updated clipping plane. The same is true when using Canvas.DrawPortal (or at the end of it). After one does add these, one could just drop any of this cpu clipping code inside Render and just implement the near plane clipping. Actually shaves off a lot of pointless math. In general all but the near plane clipping (which may need to be implemented in rendevs) should really be just moved to rot in SoftDrv.

Either way, the SetSceneNode calls should really be added to Render.Render and Engine.Canvas.

/edit:
LOD also screws heavily with your normals, so thats certainly also not any good if you try doing tesselation.

/edit2:
I would appreciate it, if you would stop claiming HDR support. The Render Devices only get LDR precalculated lighting data of the Render and even the the attenuation of the light sources itself is LDR in the first place. It's LDR tonemapping in the end. Just call it tonemapping and I'm fine with the name.

/edit3:
Maybe it would work instead of software culling (solid) backfaces, one might just skip lighting on these vertices. This should probably be work fine with all rendevs (maybe not SoftDrv...) as long as it's limited to solid faces. Typically one can make the lighting itsself quite easy to be the by far biggest performance issue, so it shouldn't be a performance issue in practive I guess.

Afaik RenDevs typically perform no backface culling, and I'm not entire sure that Mirrors may not actually scew with the orientation as well (at least it certainly did for stock ue regarding fattening). So my line of thought is those additional faces can savely be provided, because they always will get occluded. However this would not be guaranteed for masked, translucent, etc. But there is still plenty room left on URenderDevice, so one may be able to just redesignate  such behaviour.

Regarding HDR, even if you lets say consider that light might gets to ecRGB value of like 2 (depending on how you intepret the input data), that would be like 5x the intensity over clipping. For HDR this would start to be somehwere around 1000x-10000x the linear intensity, so a couple of magnitudes difference, where you can't use your normalized integer buffers anymore.

However another question is, what would be preferable for you on how normals are calculated? Currently each faces is weighted the same, which well isn't that optimal, as it heavily relies on the geometry. However it is quite cheap to weight by angle on the vertex by using a taylor expansion of acos. I think it improves visual quality somehwat. Any thoughts on that, in particular wrt tesselation?

Hi, I am working with Smirftsch on porting the renderer for Unreal patch 227i.
Disabling software viewport clipping does help a lot with tessellation artifacts.
Unfortunately I am not able to test if disabling backface culling helps as patch 227i sends backface culled meshes.
Han, have you already tried to disable backface culling in patch 469 and test it on multiple renderers ?

Saw this:


I kinda suspect it was done using your RenDev. This certainly looks like a legit implementation for the Fatness option.

My until now plan for handling Fatness was to start using a second set of vectors seperate from Normals for extrusion. So one can generate them differently, like set them to 0, if the vertex is part of a (conceptionally) smoothing group split, to fix meshes breaking apart in those cases, and otherwise just my naive idea would to like sum up normalized (angle weighted) normals of the triangles using that vertex. Afterwards this is divided by the sum of the weights.

But yeah, certainly need to rethink how that would interact with tess.

Just chiming in and saying it would be awesome if we can figure out how to better support the new renderer in the upcoming patch as currently visculling issues seem to kill the what this renderer is trying to do on the tessellation side of things. A real shame because I can see this doing for UT99 what Truform did for a lot of games back in the day.