The Face and Face2 Commands

At the risk of wandering off topic, Face2 will have absolutely no affect on the speed of rendering a model.

The things that affect rendering speed are as follows:
* Number of vertices
* Number of unique textures in the model
* Texture size
* Transparency / alpha

leezer3 wrote:At the risk of wandering off topic, Face2 will have absolutely no affect on the speed of rendering a model.

The things that affect rendering speed are as follows:
* Number of vertices
* Number of unique textures in the model
* Texture size
* Transparency / alpha

Ok thanks for clearing this up.

Then I think I know exactly what I’ve done wrong with the interior fitting of the 168. Might be too many textures, I’ll have to do a little bit of remodelling

Has this been changed, Chris? I've been told many times that Face2 hits performance and is generally bad.

leezer3 wrote:At the risk of wandering off topic, Face2 will have absolutely no affect on the speed of rendering a model.

The things that affect rendering speed are as follows:
* Number of vertices
* Number of unique textures in the model
* Texture size
* Transparency / alpha

Well I did check that out by making the same thing in Face only and Face2 and found no change in frame rates.

The rest I am guilty of using a lot!

Quork wrote:Has this been changed, Chris? I've been told many times that Face2 hits performance and is generally bad.

That's the same as putting an overlay on a model 0.005 from what it's overlaying to stop them fighting each other!

I could say were things like that came from, but I better not.

Deleted

Quork wrote:Has this been changed, Chris? I've been told many times that Face2 hits performance and is generally bad.

No, never in the life of openBVE at least.
Can't speak for BVE2 / BVE4, but all Face2 really does is toggle an openGL flag.

I'll admit I'm guilty of the overlay trick mind.

Will split this thread once home from work if it's not been done already, as we're seriously O/T now.

Movingmillion wrote:What exactly is the difference between face and face2? I'm not really sure.

Face2 is visible from both directions, Face is only visble when viewing from the clockwise direction.

More specifically, Face2 turns off Backface Culling in openGL when drawing a Face.

leezer3 wrote:At the risk of wandering off topic, Face2 will have absolutely no affect on the speed of rendering a model.

The things that affect rendering speed are as follows:
* Number of vertices
* Number of unique textures in the model
* Texture size
* Transparency / alpha

So, if you were to have a larger that usual texture for an entire exterior, (say, 2048x1024) but only one, would you expect better performance (less textures) or worse (larger texture)?

thehoviskid wrote:So, if you were to have a larger that usual texture for an entire exterior, (say, 2048x1024) but only one, would you expect better performance (less textures) or worse (larger texture)?

Bigger texture = more memory needed from your GPU. It has to load the entire thing to work with it. As long as the number of vertices is the same, the computing part should not be affected that much.

In general:
Texture size -> GPU memory consumption.
Texture count -> Both memory and computing impact.
Number of Vertices (faces) -> computing demands.

Deleted

thehoviskid wrote:

leezer3 wrote:At the risk of wandering off topic, Face2 will have absolutely no affect on the speed of rendering a model.

The things that affect rendering speed are as follows:
* Number of vertices
* Number of unique textures in the model
* Texture size
* Transparency / alpha

So, if you were to have a larger that usual texture for an entire exterior, (say, 2048x1024) but only one, would you expect better performance (less textures) or worse (larger texture)?

It's more complex than Dexter's statement above.

Your texture example takes account of the following factors:
* Total texture size in GPU memory (Width x Height x 32 bits per pixel); Note that this is different to the on-disk size.
* Number of switches between textures. In general, if multiple faces within a model share the same texture, they can be batched into a single draw call, whereas others cannot.

As you combine more textures into the whole, you add more draw calls to the batch, and so the speedup from this will be exponential based upon the number of combined textures.
This has to be balanced against the cost of loading the larger texture into memory.
In real terms, assuming the single texture is less than or equal to the size of the combined ones, it will be marginally faster, but whether or not this is actually noticable depends on the size of the model and number of textures it replaces.

Updating the vertices is a *much* slower operation.

Ah. So a good way to save frames and performance is to have smaller, but more textures?

The number of textures needed will depend on the item(s) being produced. It's a balancing act of detail vs. performance. It is incumbent on the developer to keep the bitmap count to the lowest number and the bitmap size to the lowest resolution - all compatible with ending up with sufficient visual detail.
Always ask yourself, as you start coding yet another mesh, "Is this necessary?"
(I find train interiors frequently beguile makers into add a lot of needless stuff - just because you CAN doesn't equate to because you SHOULD  )
And often, a smaller texture will work just as well as that big one you thought you needed. Novices should try substituting reduced scale copies and running it to see any difference.

So with sensible coding there's not a massive difference between the two, and it should be a case of swings and roundabouts?  

I suppose there's two opposite-end-of-the-spectrum cases- Steve tends to use smaller bits of mesh with their own texture, but putting that all onto one larger texture (like a set of stickers) and referencing the bit of that texture by coordinates would wipe out any gain, by virtue of being a larger texture?  

To make any sort of noticeable gain, would you have to combine both the textures (easy) into one image and the code for the object (far from easy) into a single mesh, set of face, and texture coordinates rather than one file with separate meshes in it?  But one or the other isn't going to make a staggering difference?

Now, that would be tricky to get your head around spatially!

leezer wrote:
It's more complex than Dexter's statement above.

I was referring to side as in height and width, not the file size. Probably should have gone for the word "dimensions".