Do u think it’s a good thing, (when using a bsp tree to sort polygons), to class the poly by texture and only render them when you have enough poly with the same texture??
I am saying that bc loading texture in memory is very slow, so if someone as an idea…
Do not use the bsp for face sorting but use it instead for visibility culling. Sort your geometry by textures… hope this help.
Why not use it for both? As I walk the bsp tree I chain the visible faces to their texture, and then after having finished walking the tree, I just render each chain of faces. This results in glBindTexture2D being called just once for each texture used in a given frame. Transparent polys however go into a single seperate array, which then gets depth sorted and regrouped before being rendered.
I have actually a question about ‘Texture sorting’. I have done a class that renders the polys it gets by texture and it works fairly well (about 7M triangles per seconds accepted by a classic GeForce). But now I’ve to deal with lightmapped triangles, so even if the ‘classic’ texture doesn’t change for a list of faces, the lightmap will be different for each. So the idea I had is to put lightmaps in one or more big textures (the best seems to have one lightmaps texture for each ‘normal’ texture), but I’m not sure it is the best way.
Anyone having suggestions ?
Cool!! That’s exactly the technique I use!!
I also render the chain frequently to avoid giving too much polys to my 3d card.
But the question is : doing this, I have to enable the stncil buffer, which could be avoid, using the bsp… Do u think it’s good ?? (I think, since 3d cards are used)
hehe tu speak tres bien english… t’aurais pas du reste en France pendant l’ete (private joke)
but your question is VERY interesting, and I agree with you.
I think the problem will be to deal with textures of different sizes (hopfully, a rabbit will probably put the texture in a correct way, so that you don’t loose space in your big texture)