darknovismc wrote on Nov 26
th, 2019 at 7:32pm:
Oh, yes I think that's it !
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.