Feature Request: EntityGroup()
Blitz3D Forums/Blitz3D Programming/Feature Request: EntityGroup()
| ||
| There's probably a good reason why we can't have this or else we would have it already, but if you don't ask you don't get and at least I've taken the trouble to find a way of organising it. What I'm talking about is an end to having to mess around with this silly surface limitation Blitz has. Now I haven't done any programming with DX, but as I understand it, you render objects individually, and reset the texture state ( there's probably a real term for this ) between rendering objects with different textures. But for whatever reason, Blitz resets the texture state every single time, whether it needs to or not. So what I'm suggesting is to have entity groups. Every entity defaults to zero for compatibility, but can also be assigned an entity group. Then when you call RenderWorld, Blitz goes through the groups, only resetting texture state between groups. So if I have ten cubes with share a brush ( and therefore texture ) I can give them all an EntityGroup() of 2 and they are all rendered without the texture state change. Then Blitz resets the texture state and goes onto group 3 and so on and so forth. With the default of zero, it shouldn't break any code, and if people assign two objects with different brushes to the same entity group, it's their own stupid fault if their sky has the same texture as the ground. It wouldn't break or crash, and the problem would be obvious to them and easy to fix. |
| ||
| i'm surprised it doesn't at least sort by brush when rendering. i guess because each object can potentially have a different brush, as they are created "on the fly" for each object, that sorting would not really give much of an advantage. if i had my way, you'd have to create a brush for every different visual property. a little more work, but it really speeds things up when you've got 200 or 300 objects with the same brush, and you only need to set the visual properties once for all of them. sad thing is that none of this will ever happen. |
| ||
| if i had my way, you'd have to create a brush for every different visual property. a little more work, but it really speeds things up when you've got 200 or 300 objects with the same brush, and you only need to set the visual properties once for all of them. That was my first thought. Then I thought, well Mark would have to keep track of the brushes in code, and maybe there's a reason he can't or doesn't want to, so I came up with the idea of us doing it manually. If Mark would prefer to enforce upon us the use of brushes and handle it that way, I'd be perfectly happy with that instead. But this faffing about with surfaces is a joke. |
| ||
| The problem is, entities can and do consist of more than one brush/material set up, even within b3d. So it would really have to be a case of Surface Group. I mean take your average character. 1 texture for head, 1 for body etc, no real way to sort by entity. It's certainly possible though, batches in vivid are essentially this, you can add surfaces/entities/shared surfaces and it sorts the surface list internally and renders by material(I.e whatever order/entities the surface are in, if they're copied..only 1 change required to render them all) And, considering it speeds up your average scene by about 50% it can be vital. I'd say b3d doesn't have it because to actually sort these lists isn't THAT fast. Throw in a dynamic scene and it would be a nightmare, when based around a single scene list as b3d is. So..the bmax engine he's planning will be ideal probably, but not b3d in it's current state. |
| ||
| Fair point about multiple surfaces per entity, that would have to go if you changed it, and that would break code, so that's no good. The sorting question is the one I was trying to avoid. If there was a way for us to manually pick which objects were rendered when, it wouldn't be an issue for Mark to take care of internally. Perhaps a RenderEntity() command so we can render just what we want in the order we want? Something needs to be done. Single surface workarounds are fun and challenging to code, but they're not the answer for every situation. |
| ||
| Render_Entity alone wouldn't give any advantages, unless mark also added control when texture locking. How I did it was, simply create a batch type, each batch element = pointer to surface and a pointer to the entity it's being referenced from. Now, you just sort by surface, and still retain per-entity attribs. Basically, for each batchObj if bat\surf<>lastSurf Locksurface:lastSurf=bat\surf lockEntity bat\ent renderSurface bat\surf next And you sort before hand. a cooler way, which I'll probably implement in vivid having just thought of it, is for each surface, generate a 8/12 byte buffer, each 4bytes = texture handle int, and generate a CRC from that. Now for each surface, you have a single unique int for it's texture set up. But since it's a crc, you can do cool things, like sort by any data value you'd like. Say you wanted to share surface locks that share texture binds AND a entity name. Insert the entity name into the buffer, then the texture look ups, then generate the crc for each one. Right, i'm off to implement that in vivid..hands off mark ;) |
| ||
| "The problem is, entities can and do consist of more than one brush/material set up, even within b3d" then you'd just change the sorting from per-entity to per-surface, right before rendering. call some kind of a "buffer" function on each surface, which would stick it into a dynamic array at the correct position.. then render the dynamic array. not sure how fast it'd be, but i've been thinking about doing that in my engine to see. unfortunately i won't have time to try it until christmas.. |
| ||
| Almost anything can be done when performance isn't taken into account. But compared to seperate pre-sorted(and post-sort sorted by adding to already existing 'runs') methods, you're going to be hitting the cpu hard. probably hard enough to render any gains useless. I suppose mark could rewrite it internally, and just sort when a entity is added. but i can't see him doing something that would cripple dynamic entity speed(I.e imagine particles. hundreds being added/removed per min) again leads back to having seperate render lists. |
| ||
| that's true. and that's something i'll have to think about for my engine ;) do an insert sort on load/create/brush change, but have another mode for objects that are always changing their surfaces. i think distinguishing between static and dynamic objects in my engine would help immensely. |
| ||
| One way you could it now(I assume you're using blitz3d? If you're writing your own engine in the true sense of the word, ignore this advice :) ) is to create a header pivot for static/non-static. I.e ShowEntity Static_Parent HideEntity NonStatic_Parent |
| ||
| i am actually writing my own engine in C++ with the DX SDK, but it's got a blitz-like heirarchy system :) though it'd probably be better to make static and dynamic objects separate classes. |
   |