Culling nodes

[Ian]

I haven't really done any more work on near/far planes
I am fairly close to getting proper culling to work. Right now it successfully culls boxes that are inside the view frustum, it just doesn't work for boxes that traverse the view frustum.

Ie when testing points are inside the view frustum, if all points are outside, but the box straddles the view frustum, it gets culled, which is clearly wrong. I switched to using axis aligned bounding boxes as I thought it might make the maths easier.

I did some investigating regarding performance. Lower spec pcs should be getting a lot better frame rates when they are. The fact it renders when paused is quite useful for profiling. Basically the issue is still the CPU. If you use Nik's debugger and look at the meshes, the way they are split is entirely related to culling, and down at the lower leafs it's almost down to single polygons. But those polgyons can be polys from any mesh, ie using different textures, which means for batching, it's kind of worst case scenario for modern hardware lol. Actually it's not so bad for the GPU, but driver side for the CPU its expensive.

Anyway, hoping that if we cull half the geometry that is outside of the view we'll get a pretty reasonable speed up.

[Ian]

Well .. I've made some progress
It nearly works

Before culling


After


Everything seems to work perfectly, except the sky ! Frame rate difference is significant

[Bart]

Very cool! Perhaps at some point we can factor out the scene graph traversal and culling code so that both the new and legacy renderers can share it. Since it's API-agnostic, it should probably be placed into Src/Model3/Real3D.cpp, too.

[Ian]

Well,
assuming I can fix this sky
You can just copy and paste the code, it's not actually a lot

[Joaquim Gonçalves]

Well,
assuming I can fix this sky
You can just copy and paste the code, it's not actually a lot

You are freaking Jenius Ian
Can you fix the shadows of the player?
It will fix all games too.

[Shekel]

Everything seems to work perfectly, except the sky ! Frame rate difference is significant

Excellent. Look forward to finding out just how much. The black sky isn't that bad, either.

[Ian]

Well, in debug mode on my pc it roughly doubles the frame rate
But debug code is quite different to release code. On my pc I get a solid 60fps with release mode, so the speedup for me will be zero :p But assuming I can get this to work, it should give a reasonable speed up on lower end systems. It should cut down the time processing the nodes, and half the number of draw calls in most games. Due to the way the geometry is split, we have a very high number of draw calls for a low amount of geometry, which is expensive in the driver CPU side.

I think I know what's up with the sky. I made the boxes axis aligned by just transforming one point at the origin and adding the extents to it. But doing this any scaling in the model matrix gets ignored. I will go back and try oriented bounding boxes again and see if that fixes it.

[Bart]

You can test un-throttled speed with: -no-throttle -no-vsync
The second option is important.

[Joaquim Gonçalves]

You can test un-throttled speed with: -no-throttle -no-vsync
The second option is important.

What a difference between this options on and off.

[Ian]

I get something like 15-20fps speed up in harley
Not really that significant when its running at 160+ fps unconstrained :p

Be interesting to know if it makes a difference on lower end PCS with dual core CPU or something.

Think the bottle neck on my pc is basically emulating the powerpc. If i double the frequency to 100, the fps basically halves.