Request for disabling Mesh Culling in Patch 469

[darknovismc]

Hello everyone !
I have a request for coders who are developing patch 469 to add an option in UnrealTournament.ini file to disable model geometry culling by software on the engine side.
This would drastically improve models quality which are being Tessellated by the new Unreal DirectX11 Renderer.It would remove holes inside geometry and disappearing backfaces.
Here is the link:
https://www.moddb.com/mods/unreal-direc ... une-and-dx
It would also get rid of artifacts like moving vertices ("mesh morphing") seen for instance in minigun model.
By mesh culling I mean backface culling and frustrum intersecting geometry culling for models which are send to be drawn in DrawGouraudPolygon( FSceneNode* Frame, FTextureInfo& Info, FTransTexture** Pts, int NumPts, DWORD PolyFlags, FSpanBuffer* Span ) function call.
Could you please do this for our community ?

[[]KAOS[]Casey]

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

[darknovismc]

No, unfortunately it's not about mesh level of detail at all.
Unreal engine sends meshses culled to the renserer from it's beginning.
Mesh software culling was implemented by Tim Sweeney himself.
Download the renderer to see the problem or allow me to talk to Anth or Smirtfisch.

[anth]

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

[darknovismc]

Oh, yes I think that's it !
I mean if it affects models like weapons,players,decorations, etc. It doesn't have to affect BSP(drawComplexSurface) geometry.
Please could you implement it in UT patch 469 and add this as an option to UnrealTournament.in i(it might be disabled by default).
So the players can disable software mesh clipping to get full quality on DX11 tessellated meshes.

[han]

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.

[darknovismc]

Hi, I'm pleased that someone with comprehensive knowledge of Unreal Tournament source code replied !
I would like to have both clipping on the edges of the screen and backface clipping (before calculating lightning) disabled.
These two software algorithms cause major problems with tessellated meshes.
Concerning two-sided faces engine could send only one face as it is doing it now (they have poly-flag PF_TwoSided).
Unreal meshes have on average several hundreds of polygons and there are only handful of them on rendered scene so I think we could also apply lighting to backfaces as it would not hit performance much.
Disabling clipping should work automatically on any hardware Renderer as you say, maybe it will even increase fps.
/rep1:LOD screws a little bit with tessellation but you have a good point I will add an option to lower or disable it.
/rep2:In HDR algorithm I perform tonemapping, light adaptation and bloom on 16-bit per channel color maps to get best color gradients.
As human eye adapts to bright light sources I render them dimmer - isn't HDR supposed to work that way..
/rep3:Yes, please could you try to disable backface culling and see the results on different renderers.
It's interesting how does it affect framerate and if you would be able not to cull PF_TwoSided faces.
Best regards,
MN.

[han]

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?

[darknovismc]

I think that actually mesh normals aren't used in any renderer when drawing models.Only here I use them for tessellation.
Have no idea if changing weighting normals by vertex angle would improve or worsen mesh quality.
This option could be configurable(in ini or command) to test against all meshes.I'm using Phong tessellation in the domain shader.

[darknovismc]

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 ?

[han]

Han, have you already tried to disable backface culling in patch 469 and test it on multiple renderers ?

I have not, but my idea for Render.Render's meshrendering as of a few weeks ago, was more in line of adding some utpgrendevclass which will alsways gets used. If needed a buildin utpgrendevproxy class would be used to remap to old rendev where needed. The utpgrendev could provide an wrapper implementation using only the drawgouroundpolygon api. This wrapper could be overriden if desired, after all these like currently 200 lines of codes which are free in hardware kinda also perform backface culling.

I kinda started to develop such interface/while rewriting/cleaning up/refactoring mesh rendering code for my opengldrv. Kinda idea is that i to some degree first focus on what could also be done with proxies in Render.Render for legacy renderdevices, so that could be put into Render.Render.

Proxies could also be used to like transcode BC7 textures into P8, so legacy devices could unpack them to RGBA8 for use on hardware which supports BC7.

Kinda have a lot of ideas, pretty busy with working on them.

[han]

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.

[darknovismc]

I understand you are implementing newer renderer class which URenderDevice inherits from. I guess it will have additional features while preserving compatibility with older render devices.
This model is from DeusEx. Some models get fatter and other get thinner ( like some barrells in Unreal Gold). I think it depends on mesh geometry and normals.
Disabling mesh culling should stop models from breaking apart .Have you tried weighting by normal angles ? How does this mesh look like with it ?

[AFreakinProblem]

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.

[massale1]

sounds good

[anth]

We're working on an extended renderer interface that will allow you to receive mesh data much earlier (i.e., before culling, enviromapping, etc.). XOpenGLDrv will be using the new interface in the next beta build (which should land some time this week).

[darknovismc]

Thanks for the information once again.
I hope you will release public headers for patch 469 after releasing the patch itself.
I also hope that the old renderers will still work as you promised. It should be achieved with some function overloading for old vs new renderers.