BSP brush entities

[hendu]

I'm making good progress on this, and I'd like to know which way the Irr devs would like the API to avoid unnecessary work.

I'd add two public methods to CQ3LevelMesh, getBrushEntity(u32 num) / getBrushEntity(IEntity *ent).
Would you like them to return a meshbuffer, a mesh, or a scene node? Is the name ok?



Background:

An entity is a point with properties. A brush entity is a brush with properties. With brush entities one can mark a door as a door, and then react to it in-game - make it swing open, collide with it, destroy it, and so on.

This necessitates they be separate scene nodes from the main world geometry. Then they may be individually handled from that point on.

Another plus that comes from this is the ability to mark transparent objects, and then have correct draw order, since they are no longer a part of the main world mesh.


I'd also like to submit an example that shows this in action, with a sample map. Since the numbers appear to be about difficulty, I propose it to be number 16.
It would load the sample map with collision, and have one door that opens and closes according to the player's distance from it.


edit: Added the entity call.

[CuteAlien]

You should maybe message user "burningwater" about this thread, as he writes the q3 stuff usually and I don't think he will notice about this otherwise. I don't know the format, are those brush entities additional data which are connected to the meshes or can they contain completely independent data? It sounds to me when reading this that they could be ISceneNodes (IBrushSceneNode?) when instanced, but seem to need a complete new structure when loaded (IBrush?).

[hendu]

I was leaning towards returning a mesh, and then the user can add a scene node as usual. Similar to getMesh(0).

The brush entities are normal entities, but contain a pointer to the faces in the model key. Currently irr draws them as a part of the world geometry.
The internal structure (IBrush?) need not be exposed, as they are a part of the BSP level. They'd get constructed to meshes on level load, but not drawn or returned until requested.

[hendu]

Done. Please excuse the made-in-5-minutes level, it should succeed in showing how to use this feature.



Patch against 1.7 and trunk posted here:
https://sourceforge.net/tracker/index.p ... tid=540678

That item also has an example showing the use of brush entities, and a one-liner patch to correct a warning. I didn't bother to respin the small patch for trunk, as it's only adding a zero, nor creating a separate item for that.


Anyone interested, please test. Comments welcome.

[CuteAlien]

Thanks. Did you try messaging burningwater about this? (I don't know anything about the BSP format and unfortunately your explanation still didn't clear things up for me enough to understand what brushes really are, sorry - will try learning about that when I find time). One minor thing I noticed on a quick-view (in a compile-pause) - you seem to avoid core::array, working instead with c-arrays.

[hendu]

- burning: yes, I sent him a PM a week ago; no response, but it moved out of my outbox, I assume this means it was read.
- brush: quake term for a mesh. There are internal nuances, but basically it means just a mesh.

There's no need for dynamic arrays in any of the use cases here, IMHO. Using them where not needed would just slow things down, and make the code harder to read and understand.

edit: It was also the existing style of the BSP loader.

[CuteAlien]

OK, well, as long as Thomas (burningwater) got at least informed I guess he won't complain if we change something if he doesn't react.
And yeah - I just checked other code and he also never used core::array but instead c-arrays for some reason and making it similar as existing code is always fine.

Ok, so brush is a mesh - you mentioned something above that they should not be drawn unless requested. And if I got you right then Irrlicht does that now, but that's not what you changing. So what is basically added is a way to identify a certain mesh by an index? Or what is that "num" a user can pass to getBrushEntity? From where do users get this number?

[hendu]

The "num" parameter comes from the entity, the function that takes an IEntity shows how to parse it.

Exposing the int interface to the user, in addition to the IEntity one, gives more flexibility - if you use other parameters from the entity and are parsing it yourself, no need to reparse it in the BSP code.

And if I got you right then Irrlicht does that now, but that's not what you changing.

Currently, Irrlicht lumps all geometry in the BSP into one, regardless if it's in parts or not. What these changes do is only lump the main level, and leave the marked models separate.

The marked models are not drawn or handled at all besides creating them; it's up to the user what to do with them.

So what is basically added is a way to identify a certain mesh by an index?

Yes. And that index is identified by class name and any custom parameters, basically sky's the limit.

[CuteAlien]

Ok, starting to get it (I read some more about bsp on the web). Patch also looks rather nice so far. You wrote " I didn't bother to respin the small patch for trunk" - but there is a patch for 1.8 in the bugtracker - did you do that after writing that or is this outdated in some way?
I can only add this to trunk - new features can't go into 1.7 anymore (only bugfixes get in there).

edit: Hm - one thing still irritating me somewhat. Why BrushEntity? From what I understand so far enties can point to brushes but brushes are not entities, but meshes (or just brushes...).
edit2: Ok - not identical to internal Q3 brush structure. But also not an entity I think - maybe BrushMeshes would be fitting?
edit3: A little hard for me to read that part right right now without applying the patch first, but if I got you right you do no longer display other models except model 0 (the world), right? I suppose there is a little bit a mess because we're using a meshloader here while it seems those files contain scenes so we should rather use a sceneloader interface probably (same problem we have in collada-loader). But lets ignore that for now - what I wonder is - now we only can access the brush-meshes, but no longer the normal model-meshes at all it seems. So if people filled their level with static-models those would no longer be displayed? I understand we should not display brush-data, but it's a little harder to tell about the usual faces. Or did I not understand you correct there? (there's solutions for this - just trying to understand the changes exactly for now...)

[hendu]

You wrote " I didn't bother to respin the small patch for trunk" - but there is a patch for 1.8 in the bugtracker - did you do that after writing that or is this outdated in some way?

That refers to the one-liner patch to correct a gcc warning, 0002-*. It could be considered a bugfix.

Why BrushEntity? From what I understand so far enties can point to brushes but brushes are not entities, but meshes (or just brushes...).

That's the name as known to mappers. It's how they are named in the editors and howtos.

Over the years there have been some requests here on the forums to support brush entities, too, with that name.

A little hard for me to read that part right right now without applying the patch first, but if I got you right you do no longer display other models except model 0 (the world), right? I suppose there is a little bit a mess because we're using a meshloader here while it seems those files contain scenes so we should rather use a sceneloader interface probably (same problem we have in collada-loader). But lets ignore that for now - what I wonder is - now we only can access the brush-meshes, but no longer the normal model-meshes at all it seems. So if people filled their level with static-models those would no longer be displayed? I understand we should not display brush-data, but it's a little harder to tell about the usual faces. Or did I not understand you correct there? (there's solutions for this - just trying to understand the changes exactly for now...)

If I understand you correctly, you mean misc_models, that is, md3/obj embedded to the map.
I'm not 100% sure whether they are contained as separate models, but if they are, then yes; they would no longer be drawn with the world geometry.

If this is the case, then they can be accessed via the misc_model entities. I see how this can be considered a regression in Irrlicht if a map previously used many such static objects.

[christianclavet]

Hi, I could perhaps describe a little more. Been using BSP editors for a while now...

A BSP file is made of entities, there a specific types of entities.

A "Brush" entity: This is some kind of geometry (mesh) that make up the level and is totally static. (non-moving) A lot of map editor use thoses "Brushes" with CSG to make up the static mesh of the level. Visibility of face and special attributes is determined by the materials (Q3 shaders). Also most editors use this information to do the lightmapping and save the lightmaps inside the BSP.

There is a lot more types of "entities" that can be added to the map as:
- Static meshes (Theses are meshes that have been build outside of the world editor and added to it), some BSP editors point to an external file, some put the mesh into the BSP directly.
- "Dynamic" meshes, as moving objects (doors, gates, etc), they have engine parameter that allow them to move and are handled separately. Most of them contain also the geometry.
- Light nodes.
- Camera nodes.
- Spawn points.
- Path nodes.
- Actors (Skeletal meshes for NPC and other similar types of elements)
- Decals (contain info on what face of the world mesh the decal is positionned)
- Particles systems.
- etc.

Depending on the game engine, the types of entities can differ a lot. (Quake, Source Engine, etc.).

If I understand Hendu correctly, he could have a way to get the entity type and to parse it. Haven't checked it yet, but this could be cool. (Loading the static meshes entities, dynamic meshes and decals could be supported by Irrlicht but are not parsed) Having the ability to load the other types as scenenodes and handle them ourself could be really nice!

[CuteAlien]

What I mean is - there are entities which have models. And those models have the usual geometry for drawing and they have a brush-geometry which seems to be mostly used for collision. So it seems we can now access the brush-geometry, but no longer the normal one.
And the reason why I suspect (from my understanding so far...) BrushEntity is maybe the wrong name and BrushMesh could be better is that this doesn't actually seem to to access the BrushEntity (that's done by searching the enties - so BrushEntity would be an IEntity) but instead that function only returns the Mesh of the BrushEntity. The BrushEntity itself is larger and basically a string which can/could contain more information - or am I wrong there maybe?
I must admit I have the disadvantage of not knowing the editors - I only use the format-description...

edit: If I got it right it would just need another function- the one to get EntityBrushes (from this patch) and one to get EntityMeshes (which would would be similar). And it doesn't really matter if the entity is a brush or not as searching for enties goes so far just over the name and we already can get those. All model-entities seem to be able to have those 2 meshes.

[hendu]

Is there a map showing this? I believe it's not possible for an entity to have both brushes and models as geometry (without custom parameters and thus engine support).


edit:

If I understand Hendu correctly, he could have a way to get the entity type and to parse it. Haven't checked it yet, but this could be cool. (Loading the static meshes entities, dynamic meshes and decals could be supported by Irrlicht but are not parsed) Having the ability to load the other types as scenenodes and handle them ourself could be really nice!

The entities could already be parsed, what I added was a way to get them as separate scenenodes.

edit2:

If named getBrushMesh or similar, it would be harder for mappers to find it. I would be against adding new terminology.

[CuteAlien]

Sorry, I don't have any maps - only the format description which is not even official but just from people who figured it out somehow, but from what I read so far on the web some people seem to use both - usual geometry for rendering and brush-geometry for collision detection.

[hendu]

OK, could you then link to the specs you're using? Perhaps there's a misunderstanding here.