[captain_bazza]

May I suggest you look at the interior of the model and see if the reverse side, or inner facing polys are visible. If so then the modeling prog' hasn't culled these, hence a lot of invisible polys may be rendered anyway.

Cheers Bazza

[rdamurphy]

Back in the days of yore, before modern GPU's, a computer game had to draw each and every poly on the screen. It would start with those farthest away, and draw towards you, hopefully rendering the correct ones as it went along, to create your screen.

Then, graphics card manufactures figured out that they could save a lot of clock cycles by simply NOT drawing any pixels that weren't visible, because they were hidden, or pointed at a direction at right angles to the camera.

Which works well... Until you put two polys through each other, say, at right angles, like, as you mentioned, a "run through" pilaster. Now, the GPU has to draw the polys because they are visible, well, a small part of them are, and it has to figure out where in the z-buffer to put them, and then draw the correct polys over top of them. This is multipass rendering, which also helps to draw the shadows in the scene.

Having the pilasters on the outside of the building - completely - means one pass per surface, the wall, the pilaster. When you run them through the building to "save polys" what you're doing is requiring the GPU to sort the polys, drawing the interior portion of the run-through and then the wall, then the exterior, or two passes per surface.

Are you saving GPU time by having less polys? No, because the ones on the opposite side of the building aren't rendered anyway, since they're entirely not visible, or facing away and invisible to begin with. There are two methods of Occlusion Culling known as Occlusion Query and Early-Z Rejection.

Basically, anything that isn't visible, occluded, is simply ignored and not rendered at all. Early-Z is a bit more complicated, since the GPU starts the rasterization process, but as soon as it decides it's not visible, it rejects the poly, and at that point, saves the GPU work and memory by not loading the texture.

Ah, but those run through polys can't be rejected because they are partially visible, and do have to be rendered, and then z-buffered over. If you had "extra polys" on the back side of the building, they're rejected by the GPU's occlusion culling, and the geometry isn't even loaded.

So, it's not surprising at all that you saw a slight rise in FPS, because by using more polys you're reducing the workload on the GPU.

Please, I'm not an "expert" on graphics cards, so don't take this as gospel, someone like James can probably explain it an awful lot better than I can, but it is a pretty basic explanation of why you're getting the results you are.

Robert

[James Ross]

 Genma Saotome, on 04 October 2013 - 04:06 PM, said:

Anybody else able to draw any conclusions from all of this?

Unfortunately, as Wayne has noted, it is a very complex pipeline of work going on rendering models, so it's pretty tricky to come to any conclusions from the data we have. The 12.4ms down to 12.1ms frame times do indicate something was running quicker without the run-throughs, so it's possible that for this model on this graphics card the extra vertices are quicker than the extra pixels.

The problem is that the cost of individual vertices or pixels is basically unmeasurable, and can vary between GPU architecture/model.

So, I think it basically comes down to a judgement call from the modeller; my advice would be that, if the run-throughs have an area that is significant relative to the whole model, consider not doing the run-through. I don't think we can do better than that.

[rdamurphy]

James, according to NVidia, larger numbers of small polys are best for Occlusion Culling, large polys tend to slow down the process.

Robert

[wacampbell]

 rdamurphy, on 05 October 2013 - 02:01 AM, said:

James, according to NVidia, larger numbers of small polys are best for Occlusion Culling, large polys tend to slow down the process.

Just to clarify, Open Rails does not use Occlusion Culling. Its a CPU intensive technique with marginal benefits on modern hardware. Open Rails uses Distance Culling, Frustrum Culling, Backface Culling, and for the shaders that allow it, Early Z Culling. Note that the latter depends on draw order of the polygons, where hidden pixels won't be culled if their pixels are drawn before the occluding poly's ( ie its not hugely effective ).

[Genma Saotome]

I need to add a clarification as I did do an edit in my post:

Model with run-thrus shows a fps of 79.
Model w/o run thrus shows a fps of 81.

So removing them shows a very slight increase in performance.