Does CopyEntity create a new surface per instance?
Blitz3D Forums/Blitz3D Programming/Does CopyEntity create a new surface per instance?
| ||
| The reason for my question is that I'm building an outdoor environment and trying to figure out if it would be better to copyentity my tree and building models, or create all instances as a unique meshes and then combine the surfaces. |
| ||
| I'm pretty sure copy entity creates now surfaces. |
| ||
| It's much better to combine them into meshes. I've tested this. |
| ||
| Copyentity doesn't create new surfaces. It just copies the mesh pointer. If you for example deform the mesh of a copied entity, all other entitys copied will also deform. |
| ||
| That's true, however you still get a speed hit the same as if each entity was a seperate mesh. |
| ||
| I would think the speed hit would depend on the GPU and how it handled it. It would also depend on if you wished to selectively show certain entities. If you combined all it all into one mesh the more tris you add to the mesh the greater the speed hit. How many mesh additions/copied entities are you testing? |
| ||
| I am aiming to have about 10-15 base models for the buildings, and maybe 5 for trees. These will be used to create a settlement and the surrounding landscape. I was hoping that CopyEntity was the solution as I could then texture the copied entities differently from the templates thus increasing the apparent variety of models. SSwift, I am dissapointed at the results that you have found, but would you not get a comparable performance hit from not having unseen meshes culled? As LilPuppy pointed out, if I AddMesh something like 200 buildings and one is in view, then presumably they will all get rendered? |
| ||
| We've done much better by not using one mesh. Most of the time it's better to cull away the polygons and still have a good number of objects (I'm talking maybe 50 surfaces instead of 1). One benchmark I did using just spheres showed a FPS increase by rendering (only rendering, no collision or picks) spheres, but I think that the collision, pick, and possibly if you're using Sswift's own shadow system that having more entities is better. I know the shadow system likes to cull away whole entities that cannot be receivers and I think the collision and pick systems also make certain similar checks for possible colliders. As it is right now we're using a few meshes for visuals only, and then about 30 to 50 separate collision only (but not rendered, alpha=0) to use for picks and shadows. However, even before we used this method we tested a few large meshes with fewer surfaces Vs. many separate surfaces and by culling away entities behind the camera is was faster (although more erratic). |
| ||
| If you have say a forest you should use tree-groups as added meshes but not the entire forest as one mesh. If you split the forest in groups of the size of 10 or twenty trees per mesh you can save a lot of surfaces but will use culling of entities behind the camera nonetheless. If you have a function that can add all trees to one mesh then it might be simple to use such groups instead. |
| ||
| "SSwift, I am dissapointed at the results that you have found, but would you not get a comparable performance hit from not having unseen meshes culled?" Let me make a clarification. For each surface of each entity, regardless of whether you use copyentity or copymesh, you get a speed hit. However, you also get a speed hit for the number of polygons that are visible at once. There is a sweet-spot where selectively combining entities together and keeping them seperate gives you the best performance. I can't tell you where this sweet spot is, but I can tell you that it's likely to be vastly different from card to card. What I suggest is combinig entities which are close to eachother. The test that I did a while back was a test to see how many trees I could pack onto a terrain at once while still maintaining a framerate greater than 20fps. With individual entities, the number of trees I could have at once was very low. However, I discovered that I could make "clumps" of trees that were near eahtoher into a single mesh with a single surface, and in doing so I was able to get 100,000 trees onto my terrain at once. I may have been able to put even more if I worked at it some more to tweak the number of trees in each mesh. Of course I did not have 100,000 trees visible at once. I had a fraction of that visible at once. The point was that as you walked around this huge terrain lots of trees were always in view. Btw, I used entityautofade in my demo. I tried to do an octree, but I found it was very slow. I'm not sure why. It shouldn't have been. Oh and also, the groups of trees I used were like 50-100 trees in a group. That seemed to be the optimal number for a large fairly open terrain with trees that only went about a half mile into the distance. My trees were just two planes each though. WIth more detailed trees you'd have to use less obviously. |
| ||
| Yes, I think you are right about using smaller groups of combined meshes; I will have to experiment to find the correct number to include in each segment. The nice thing is that since I am dynamically generating my models and using uv's per poly to do texture tiling on the buildings, I can mix up the uv's to vary the tiles per building even though the whole group will be using only 1 "tilemap" texture. I would not be able to do it this way with copyentity as the mesh uv's could not be altered without affecting all copies. |
   |