CopyEntity question
Blitz3D Forums/Blitz3D Programming/CopyEntity question
| ||
| Does anyone know how this works? I thought that, if something was part of a surface, it was rendered? Now, if you copyentity something, it becomes part of the surface. Well, not really, because it's vertices are the same as the copies. BUT, you can apply different textures to every single different copy. Now, taking this into account, that means each copy must have it's own brush surely? Now, i was under the impression, every texture basically equalled a surface. So, whats going on here? |
| ||
| It seems that multiple surfaces in blitz, even if identicle, are still rendered as seperate surfaces. This means that CopyEntity will still increase the surface count (although I could be wrong). The main advantage of CopyEntity is better loading speed, and far less memory usage. If you want to minimize surfaces, the only way (as far as I know) is to manually set up the surfaces (or use AddMesh to combine meshes and surfaces into a single mesh) Edit: After further investigation, it appears that using CopyEntity rather than CopyMesh not only loads faster, but renders faster as well. |
| ||
| The thing is, if you move one of the vertices of any of the copied entities, all the copies get affected, so it must be using the one surface. But, if that's so, then, what about my first post? |
| ||
| As I see it, copied entities share meshes and surface brushes. I would hope this means that all copied entities are rendered in sequence, thus reducing the need for a state change, since they will all be using the same surfaces brushes, initially. However, I guess if you then assign a different texture to a copied entity, it is then given it's own brush, and so no longer references the original entity's brush, but still references it's mesh. Not sure how blitz handles things when this happens, as if all copied entities are simply rendered in sequence, there will be a state change required when rendering the one assigned a new texture, and then another state change to revert back to render the remaining copied entities. Hmm, dunno really - just thinking out loud. :) |
| ||
| Yep, i get what your saying. Would nice to hear officially how this works, if someone at BRL isn't busy :o) |
| ||
| This means that CopyEntity will still increase the surface count (although I could be wrong). So far as I can tell, you're wrong. Compare the surface handle of one copied entity to another and you will find them equal. Contrast this with those of a copied mesh. This is how I'm keeping the surface count down in Ice-Teroids without resorting to manual vertex manipulation. EDIT: Also, the surface handle remains equal even if you apply different textures to each copied entity: |
| ||
| Sledge: Well, of course the "surface" is a shared (which is why modification affects all entities) - that doesn't prove much since blitz could still make state changes individually for each entity. So, I tried a performance test to see whether CopyEntity meshes or CopyMesh meshes are faster, and the results are: Copied meshes: 20 fps for 2000 cubes Copied entities: 45 fps for 2000 cubes (>2x faster!) Obviously I've underestimated the power of CopyEntity. It looks as though you were right and I was wrong - CopyEntity must optimize surfaces (or state changes) in some way or another or else there wouldn't be the speed boost :) |
| ||
| Yeah, it's very strange how it works. Seems as if there is more going on behind the scenes than you first think. |
| ||
| Sledge: Well, of course the "surface" is a shared (which is why modification affects all entities) - that doesn't prove much Hooray! Welcome to the net, Sledge, where we will say that CopyEntity must carry a surface overhead, wait until you show us that it doesn't, then - aha! - say OF COURSE NOT YOU IDIOT! :D So okay, this is obviously some sort of byzantine test. So I'll bite: What it proves is that you can build a nice single surface sprite/particle system (copies can be scaled, oriented and retextured individually, remember) without having to fiddle and faff around with vertices manually... that might not mean much to you, but I bet it means quite a bit to those who went and wrote complex fiddly SS systems on the opposite assumption! I tried a performance test to see whether CopyEntity meshes or CopyMesh meshes are faster Sorry, I thought the fact that it is faster was implicit in my previous post. More surfaces = less speed in B3D, and CopyMesh = more surfaces whereas CopyEntity doesn't. I don't know anything about these "state changes" - I just know that less poly's and less surfaces equals happy. |
| ||
| I believe copyentity creates brushes though, because a single surface particle engine is a good bit faster than a copyentity one. |
| ||
| I believe copyentity creates brushes though, because a single surface particle engine is a good bit faster than a copyentity one. Agreed - you're still trading speed for ease of use, but it's a really nice balance. Dare to define a template quadmesh and you can get a big ol' speed increase without having to do everything manually. I should really check and see if applying different frames of an animtexture to the copies (rather than individual textures) has any effect on the brush overhead. Not sure what to expect on that one. |
| ||
| I don't know anything about these "state changes" I was reffering to render state changes. Try searching for "Direct3D Render States", or read this. Basically, render state changes are relatively expensive operations. More surfaces = less speed in B3D, and CopyMesh = more surfaces whereas CopyEntity doesn't. I don't know anything about these "state changes" My initial point was that, even though copied entities share the same surface, Blitz still might still make render state changes between entities (in which case, sharing surfaces between entities do NOT improve speed) - but I later disproved my "theory" with a simple performance test. Hooray! Welcome to the net, Sledge, where we will say that CopyEntity must carry a surface overhead, wait until you show us that it doesn't, then - aha! - say OF COURSE NOT YOU IDIOT! :D I don't think I understand. I'm sorry if it seemed like I said "OF COURSE NOT YOU IDIOT!" or anything, but I really meant my post to say "I'm sorry - I was wrong about CopyEntity(), you were right." |
| ||
| I'm sorry if... I appreciate you posting that, but I was more amused than anything - it's so easy to post at cross-purposes that I never get narked unless someone is obviously trying to be deliberately 'orrid (note smiley). Blitz still might still make render state changes between entities (in which case, sharing surfaces between entities do NOT improve speed) Yeah, to be fair I should've explicitly stated that I'd tested this and found it to be faster. It didn't occur to me that you might not equate a reduced surface count to a blanket increase in performance... it's a kinda brute fact of the Blitz world. Dunno about the technicalities/witchcraft though. |
| ||
| I appreciate you posting that, but I was more amused than anything - it's so easy to post at cross-purposes that I never get narked unless someone is obviously trying to be deliberately 'orrid (note smiley). Please do not misunderstand me. I'm not sure how you're interpreting what I said, but I wasn't being sarcastic or anything. (btw, that smiley was my way of saying that I'm grateful you pointed my error out - nothing more, nothing less - I certainly wasn't "trying to be deliberately 'orrid"). If you still find my apology "amusing", well, then I suppose there's nothing more I can say. |
| ||
| I should really check and see if applying different frames of an animtexture to the copies (rather than individual textures) has any effect on the brush overhead. Not sure what to expect on that one. I get the same performance with copyentity + applying an anim texture to 150 objects that I do without texturing at all ... this is good news :) |
| ||
| The thing is, there must be a change. For all copied entities to share the same surface when rendering seems unlikey, as you can copyentity, until the combined vertex count far exceeds the 32K vertex limit. |
| ||
| Please do not misunderstand me. I'm not sure how you're interpreting what I said, but I wasn't being sarcastic or anything. (btw, that smiley was my way of saying that I'm grateful you pointed my error out - nothing more, nothing less - I certainly wasn't "trying to be deliberately 'orrid"). If you still find my apology "amusing", well, then I suppose there's nothing more I can say. Lord above - this is exactly what I'm talking about. Pesky electronic (mis)communication! Quickly then: - MY smiley, I was referring to. MINE. Not YOURS. You're reading a criticism where there ain't one. - I did not - NOT! - say you were being deliberately 'orrid. I said I only get narked on forums when people are deliberately 'orrid, thinking that you would realise that this must mean that I am not - NOT! - narked at you (because you clearly weren't being deliberately 'orrid... anyone can see that). You're reading a criticism where there ain't one. - I did not - NOT! - say I found your apology amusing. I found the fact that we were having a misunderstanding amusing because it's so hopelessly typical on net forums for wires to get crossed. In fact I specifically said I appreciated your apology. You're reading a criticism where there ain't... oh, you get the picture. Forum posts constitute a running dialogue - you can't take each post in that dialogue as an isolated unit and expect it to make any sense. Read our posts, yours and mine, as a running conversation and you'll soon realise that I'm not pulling you to pieces at all. Geez! |
| ||
| Oh, ok. Now I can see what you mean by "amusing" (which my misunderstanding definitely is :) ) |
| ||
| dunno exakt how it works but on my computer is loadentity much faster as copyentity .... |
   |