• Welcome to PiBoSo Official Forum. Please login or sign up.
 
March 29, 2024, 02:01:14 PM

News:

GP Bikes beta21c available! :)


Sudden framerate drop

Started by h106frp, May 25, 2020, 09:11:30 PM

Previous topic - Next topic

h106frp

May 25, 2020, 09:11:30 PM Last Edit: May 25, 2020, 11:58:28 PM by h106frp
On my Mallory Park model, at one point on the track I get a very sudden frame rate drop. I have tried all sort of changes to model and texture but nothing really explains the very sudden hit. At the point in question you navigate a hairpin (Shaws) and go from looking outward towards the primeter of the model to directly towards the centre of the model but the bulk of the model should still be obscured by the following crest.

The video explains the issue and my observation - as the camera rotates towards the normal hairpin view (tall stone kerb) you see the large frame rate hit, panning left or right which would move the view back towards looking to the model perimeter raises the framerate even though some more detailed models and textures are revealed and towards LOD0.

The interesting thing is that elevating the camera point toward the model centre so that a very large increase in model content is revealed has virtually no impact on frame rate - I would have expected it to drop considerably. Rotating toward the perimeter and the frame rate increases again. Lowering the camera back down and the frame rate stays largelly constant as if the ammount of detail being rendered has not changed at all.

Looking straight up and down has the expected result as yo look away from any model content and suggests that it is not a possible skydome issue.

This is a non-listed video; Frame rate indicator top right

Any idea as to what sort of horror I have created that would cause this issue? I have noticed similar frame rate hit behaviour with other track models and again it does not agree with waht you would expect given the the viewable content.

Thank you.

Is it possible in debug options to indicate real time tris rendered and texture volume rendered in the current view?

javiliyors

Have you tried converting the circuit by removing all the objects and including them little by little to see where the problem is?  It could also be that these objects are complex or with many polys.  It worked like that for me in some circuits.  But I think it could be also a problem of the graphic engine of the game.

h106frp

Been through all that but nothing that explains the switch like frame drop.
 In the vid you can observe that we do not appear to have sufficient culling of the distant objects in the distant infield area when the camera goes up and down, and as far as I understand scene rendering this should not be the case.

matty0l215

May 25, 2020, 11:10:37 PM #3 Last Edit: May 25, 2020, 11:12:32 PM by matty0l215
Now call me stupid but the frame rate increase happens when you pan away from either the inside curb wall on the apex of the turn/when you no longer render what would be the transition from the trkasph to trkgras surface also on the apex?
Or when there seems to be a very long uniterupted view distance

Just an observation.
For faster responses, please visit the discord server- HERE

h106frp

May 25, 2020, 11:54:42 PM #4 Last Edit: May 26, 2020, 12:05:33 AM by h106frp
But on the approach to the apex you run along the same tall kerb/track and it sits happily at 150 fps. Maybe not clear in this vid as when you are lapping but the switch drop occurs when the camera shifts to looking toward the infield, so on the bike it would be just after the apex so it seems to be camera orientation (view) thats important. Its also completely repeatable.

Frame rate change with view distance around the track generally is about what you might expect considering what is in view at any time. It just this point where the view camera goes from generally looking out from the centre of the model to looking in toward the centre where it suddenly drops and its much lower than from the top of devils elbow wher you pretty much see the entire track, paddock and panorama all at once.

The other thing thats a bit odd is having the 1P or 3P detailed bike also in the frame barely affects the frame rate at this point - you would think rendering these as well would make quite a difference. Its as if we already have a significant overhead to process.

h106frp

@Matty, Just did a check and even if I push the camera right up to the kerb wall so that I have nothing in the local view other than what would maybe be a single textured geometry plane it only goes to 100fps. So I can draw the bike, rider, and all the detail of Shaws hairpin at a cost of only 20fps compared to drawing a single 4 vertex plane?

Hawk

May 26, 2020, 11:09:57 AM #6 Last Edit: May 26, 2020, 11:16:24 AM by Hawk
I'm probably way of mark here, but looks to me like a painter having x-ray eyes(able to see everything into the distance even though his view in reality is blocked by close objects) and painting everything he sees from the deepest to the nearest z point therefore painting over things it's already rendered that cannot be seen as the z point gets closer to the camera, you know? As though the routine for culling what cannot be see isn't working correctly before finally rending the camera scene?

Either that or maybe it's just a case of the work the scene culling routine is doing to sort out what is viewable and what is not is using a lot of resources which is cutting down the frame rates at that point with there being a lot of objects to sort and cull in the background there?

PS: I know this sounds silly, but I wonder if the graphics engine is sorting with it's own software routine to sort and cull the scene or is in actual fact using the graphics card hardware to sort the scene?

h106frp

I agree, it does appear the Z culling is not functioning as required. As far as I know its a library type call to he graphics driver to sort out the object that will actually be rendered to scene. It would be very useful to have the debug info on the scene size displayed in real time.

PiBoSo

Quote from: h106frp on May 26, 2020, 06:34:20 PMI agree, it does appear the Z culling is not functioning as required. As far as I know its a library type call to he graphics driver to sort out the object that will actually be rendered to scene. It would be very useful to have the debug info on the scene size displayed in real time.

Please note that at the moment the graphics engine doesn't perform early z-culling.
"La perfezione non è il nostro obiettivo, è la nostra tendenza".

h106frp

Thank you for the confirmation, I had pretty much confirmed this by riding the circuit in reverse and having a considerably worse frame rate than riding it in the normal direction.

I guess any track that reverses within the draw distance is a bit of a non-starter at the moment as you are going to have a very high rendering load.

javiliyors

Quote from: h106frp on May 29, 2020, 02:05:23 PMThank you for the confirmation, I had pretty much confirmed this by riding the circuit in reverse and having a considerably worse frame rate than riding it in the normal direction.

I guess any track that reverses within the draw distance is a bit of a non-starter at the moment as you are going to have a very high rendering load.

I advise you to locate the objects that can make that drop fps, I have noticed that there are simple objects that the graphic engine of the game doesn't process well. I have been removing objects until I found the object that made this problem.


I had this problem with the scaffolding that was on the main line



QuoteBEFORE DELETE: https://vimeo.com/431045568
AFTER DELETE: https://vimeo.com/431045576

h106frp

We did get to the bottom of this and it was confirmed by Piboso - the lack of Z culling in the engine means that you need to examine your track with x-ray glasses, basically anything that aligns with the FOV even if you cannot see it in-game gets drawn.

For Mallory it makes the hairpin impossible to fix as from that FOV if you remove the hill you would see nearly the entire track - clipping a few objects will not make any difference in this case.

Strangely this makes very long meandering tracks very efficient in GPB but small tracks that turn back on themselves very inefficient.

Vini

The game has no Z culling?? Now it all makes sense.