surface stuff

I am even more confused now about surfaces. i just for a laugh decided put a highish poly tree in my level(500 polys). Each leaf is a seperate poly. it looks cool, but I expected it to slow the frame rate right down. But no, its exactly the same. each poly is double sided BTW.
What is actually happening here.
Is blitz grouping the leaves in to one surface?
There is only one leaf texture shared.

I also put in another 5 trees using copy entity and again the fps is the same (38fps) which is cool.

Seems to me i could now afford to make ut2003 style trees without too much slowdown.

Surfaces can contain many different objects.
Look closely how 3d models are constructed to understand.

You have three vertices and using those three vertices, you can make a triangle.

You can make another 3 vertices and one more triangle. They might not be connected. But they are on the same mesh. The same surface.

When you understand this, you'll probably realise your tree is just one surface full of different triangles and meshes.

You modelling package will automatically create a new surface if you need to apply a different texture to a mesh internally.

But these DO use different surfaces. Both copyentity and copymesh create a new surface, however copyentity will share the memory of the original surface. Confused? don't be...

Just remember that each individual thing you can access using the entity commands *IS* another seperate surface. So if you can move a leaf, it IS a seperate surface, a child entity, perhaps.

So there are actually performance penalties, you're just nowhere near breaking them yet.

Each mesh contains a number of surfaces.
Each surface contains a number of vertices and triangles.

If all your leaves are in the same mesh, then unless you specifically created seperate surfaces for each, they all are likely contained in one surface which is textured with your leaf texture. If you have a seperate texture for bark, then each of your trees would have two surfaces. It would be better to combine both textures so that each tree only has one surface, and if you want to be daring, you can even combine trees that are near eachother into a single surface within a single mesh. You'll need to do this if you want to have a hundred trees visible at once.

But, if each leaf was a child of a parent 'tree' mesh and you loaded it using LoadAnimMesh() (for example if each leaf was individually animated), then each leaf *WOULD* have a different surface. However, on the same model loaded with LoadMesh() Blitz will internally combine the leaves into 1 surface for you.

Isn't Blitz great? :)

thats cool, i undeerstand now.I just tried doubling the poly count again, to round a 1000 and there is a slight performance hit when you get close to the tree, ie really close. i lose about 10fps, but otherwise the fps is about the same.

Ruz,

We did a project last year with lots of bojects, with lots and lots of textures.

We got to 14 on screen and the whole thing 'died a death!' suddenly.

We went back to the drawing board and instead of 20 textures each object now had 2-3, the result was suddenly we could have 26+ different objects (and copies) on screen - lovely!

Many separate textures + many separate surfaces = Blitz Killer.


IPete2.

I would tend to agree IPete2 , but Its a fact i hate doing low poly trees, its much more of a challenge. there are of course various ways to do them, each with their own drawbacks.I suppose what i am concerned wiht is what looks the best for this particular demo.
And at this point doing a more detailed tree seems more appropriate.
When I am more in the moood i will do a better low,low poly tree for general useage

Skitchy is right -but- If they use different textures, then LoadMesh will group them by as many different textures or surface properties. So LoadMesh isn't any guarantee it will be a single surface.

Thanks to all for explaining this all to me, very helpful

Long as it groups indentical textures ,then I am happy.
oh and thanks for the info guys, wheres my manners.