[Genma Saotome]

Another thought on this: I think there are many situations where all of the decisions are best left to the modeler... consider the simple example of two identically sized polys, one facing to the ground and the other to the sky -- a car roof vs floor for example. The modeler will know the ground facing face should have a much shorter LOD than the sky facing one because it's far less likely to be seen at any distance other than rather close up.

Another example is what I call a run thru: You have symmetrical features on opposite sides of something... F3 portholes for instance. It's cheaper (poly-wise) to run thru the locomotive body those faces of the porthole that are at right angles to the body... they simply pop out the other side to be used by the porthole over there. That makes the face rather large but only a small percentage of it is visible outside of the carbody -- it's the GPU that does the culling, not the modeler.

Could the software figure out these conditions? Do they occur frequently enough to do the work to figure them out? I have my doubts.

What would be nice is a spreadsheet page that would have columns of screen resolutions and rows of inches (or cm) with the data in the array showing at what distance from the camera that distance for that screen resolution falls below 1 pixel. IOW, model for 1980x1020, have a 4 inch wide face, run your fingers across the array and see at n meters it disappears.

I seem to recall James posted a formula to calculate that... I should go search for it... see what I can do with it.

[wacampbell]

Genma Saotome, on 03 October 2013 - 09:22 AM, said:

Another example is what I call a run thru: You have symmetrical features on opposite sides of something... F3 portholes for instance. It's cheaper (poly-wise) to run thru the locomotive body those faces of the porthole that are at right angles to the body... they simply pop out the other side to be used by the porthole over there. That makes the face rather large but only a small percentage of it is visible outside of the carbody -- it's the GPU that does the culling, not the modeler.

I see this a lot but its economy is questionable. First you have to guarantee that the "run thru" is rendered after the "body". Failing to do so results in the pixel shader running for all the hidden pixels on the "run thru", looking up the texture, computing color, lighting and shadows. Those pixels will only later be overwritten when the body is rendered. When there is a high ratio of hidden to visible pixels this can have a huge impact on performance relative to just adding the necessary vertices to eliminate the hidden pixels. If you do find a way to get the "run thru" to render last, the gains are still questionable as much of the pixel processor still has to be run just to determine if the pixel is hidden, although it could save the texture lookup and lighting calculations. Just an FYI ...

[alkomv]

Genma Saotome, on 03 October 2013 - 09:22 AM, said:

Another thought on this: I think there are many situations where all of the decisions are best left to the modeler... consider the simple example of two identically sized polys, one facing to the ground and the other to the sky -- a car roof vs floor for example. The modeler will know the ground facing face should have a much shorter LOD than the sky facing one because it's far less likely to be seen at any distance other than rather close up.

Another example is what I call a run thru: You have symmetrical features on opposite sides of something... F3 portholes for instance. It's cheaper (poly-wise) to run thru the locomotive body those faces of the porthole that are at right angles to the body... they simply pop out the other side to be used by the porthole over there. That makes the face rather large but only a small percentage of it is visible outside of the carbody -- it's the GPU that does the culling, not the modeler.

Could the software figure out these conditions? Do they occur frequently enough to do the work to figure them out? I have my doubts.

What would be nice is a spreadsheet page that would have columns of screen resolutions and rows of inches (or cm) with the data in the array showing at what distance from the camera that distance for that screen resolution falls below 1 pixel. IOW, model for 1980x1020, have a 4 inch wide face, run your fingers across the array and see at n meters it disappears.

I seem to recall James posted a formula to calculate that... I should go search for it... see what I can do with it.

Just the bold bit.

I've also been told that for game models this not much use, the porthole windows on the SOU Tobacco car I'm playing with are just a separate mesh, I can drop them as part of the LOD

[Genma Saotome]

wacampbell, on 03 October 2013 - 10:14 AM, said:

I see this a lot but its economy is questionable. First you have to guarantee that the "run thru" is rendered after the "body". Failing to do so results in the pixel shader running for all the hidden pixels on the "run thru", looking up the texture, computing color, lighting and shadows. Those pixels will only later be overwritten when the body is rendered. When there is a high ratio of hidden to visible pixels this can have a huge impact on performance relative to just adding the necessary vertices to eliminate the hidden pixels. If you do find a way to get the "run thru" to render last, the gains are still questionable as much of the pixel processor still has to be run just to determine if the pixel is hidden, although it could save the texture lookup and lighting calculations. Just an FYI ...

Wayne, where does the pixel shader do its work, CPU or GPU? Is there a way to measure the load? I ask as I do a lot of run thru's in models for urban architecture...factories, lofts, offices, skyscrapers... most have 2 symmetrical sides, many have 4. Doing run-thru's cuts the poly cost of 3d geometry on both sides... removing them and going with a manifold model would be a 50% increase of polys for every item so changed. Added up that can represent a lot of polys.

[Genma Saotome]

ADMIN EDIT

Thread split off from ESD_Complex at this point in time.

[wacampbell]

Genma Saotome, on 04 October 2013 - 11:59 AM, said:

Wayne, where does the pixel shader do its work, CPU or GPU? Is there a way to measure the load? I ask as I do a lot of run thru's in models for urban architecture...factories, lofts, offices, skyscrapers... most have 2 symmetrical sides, many have 4. Doing run-thru's cuts the poly cost of 3d geometry on both sides... removing them and going with a manifold model would be a 50% increase of polys for every item so changed. Added up that can represent a lot of polys.

The pixel shader is run entirely in the GPU. The other key shader is the vertex shader - also in the GPU - which runs for each vertex on your object. So your method cuts the vertex shader load in half, but increases the pixel shader load by many hundreds or possibly thousands ( ie the ratio of hidden to visible pixels ). How that plays out in terms of FPS impact is difficult to predict. Most GPU's have many more pixel shader processors than vertex shader processors so to some extent, vertices are more expensive than pixels. So saving vertices is generally a good idea. But when the tradeoff is potentially 100's of times more pixels, than the gains are lost. Careful testing is the only sure proof, and of course different video cards would respond differently. if as an artist you are looking for some guidance, I would say perhaps 10:1 - ie if the hidden pixel count ( or face area ) is 10 x the visible pixel count, it would negate a 50% gain in vertices.

[Genma Saotome]

Out of curiosity I decided to see what differences might be present in Open Rails with a model containing many poly run-thru's vs. the same model, edited, with all of them removed.

The test environment:
Inside the route editor I drove the camera out to a completely blank tile and placed 1 instance of the model in question -- it's a large warehouse, 42000 square foot footprint, 6 floors having many 3d features in place such as wall pilasters (they look like support posts along the extrior wall), window and door insets, window frames, window sills. As built this is a high poly model, even with utilization of the run thrus. Shapeviewer reports it as:




I rotated 90d to the right and moved to the next tile where I placed 60 instances of the same model. I then saved RE, launched Open Rails and from the start location of the Activity rolled the camera out to the solo building and from there out the end of the world (there be Dragons beyond) and screenshot the OR data at that point:

The lack of work to do is evidenced by the high fps and the ultra low primitive count.



I pulled the camera back from the edge a bit to capture a little bit of terrain, just to see what changes:




A bit more for more terrain:




I then pulled the camera back to where the building was placed and screen shot that:





Rolling right I moved the camera over to where the 60 were placed and did a save. Rerunning OR using the resume command I took this screenshot:

My purpose in doing a save & restore was to ensure a like environment to compare with the revised model as in doing that a resume was necessary.

I then edited the model and removed all of the run thrus. Of note, all of the horizontal faces used faces sized at 42000 square feet. For each of those I retained 15 inches around the outer edge and removed everything else -- a 41000 square foot reduction, all of which had previously been hidden inside the walls. The revised model, in Shapeview now shows this (an increase of about a 1200 polys:




After changing the model name in the .w files I fired up OR again and resumed, as before, taking this screenshot of the modified building:




Examining the data I see an increase in fps of 2 for the no run thrus model, no difference in the number of primitives (expected), and an increase of 1 in objects being managed (unexpected and not explained).

So what does it mean? I'm not sure. Might the slight increase in fps be accounted for by the extra polys? Perhaps. What is not evident is any performance difference that I can see that is tied to the work the pixel shader is doing... the surface area of the run-thru model is vastly greater, at least a million square feet in area. I am aware the run thrus can occasional lead to an usual illumination of faces appearing out of a building on the far side of the sun... it's subtle but present. I dis not look closely to see what differences, of any, the revised model might have.

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

**edited to correct image sequence and verbal clarity.

[wacampbell]

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

Examining the data I see an reduction in fps of 2 (run thrus vs. no run thrus), no difference in the number of primitives (expected), and an increase of 1 in objects being managed (unexpected and not explained).

This is pretty good work and clearly refutes any negative impact from the run thrus. My theoretical knowledge is lacking somewhere ( many places probably ) Sorry for misleading you - ... carry on ...

[Genma Saotome]

wacampbell, on 04 October 2013 - 04:12 PM, said:

My theoretical knowledge is lacking somewhere ( many places probably ) Sorry for misleading you - ... carry on ...

Not in the least Wayne. Had you not mentioned it I'd have never done the test. We still are lacking in a good understanding of what is really going on... is the drop in fps due to polys... a change in what the vertex shader has to do... something else we're not even considering? I dunno (I'm just always looking for better fps).

[alkomv]

wacampbell, on 04 October 2013 - 03:54 PM, said:

The pixel shader is run entirely in the GPU. The other key shader is the vertex shader - also in the GPU - which runs for each vertex on your object. So your method cuts the vertex shader load in half, but increases the pixel shader load by many hundreds or possibly thousands ( ie the ratio of hidden to visible pixels ). How that plays out in terms of FPS impact is difficult to predict. Most GPU's have many more pixel shader processors than vertex shader processors so to some extent, vertices are more expensive than pixels. So saving vertices is generally a good idea. But when the tradeoff is potentially 100's of times more pixels, than the gains are lost. Careful testing is the only sure proof, and of course different video cards would respond differently. if as an artist you are looking for some guidance, I would say perhaps 10:1 - ie if the hidden pixel count ( or face area ) is 10 x the visible pixel count, it would negate a 50% gain in vertices.

A question, how do smoothing groups i.e. number of same, affect the both the pixel and in particular vertex shader in OR [ MSTS ? ]

Thanks