BSP brush entities

[CuteAlien]

I found 2 different, but in this they are identical: http://www.mralligator.com/q3/
Here in the "model" section they describe models as working with faces and with brushes.
And I suspect you get that model from the entities section - otherwise I understood it wrong so far.

[CuteAlien]

edit2:

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

*sigh* so hard for me as I might be completely off not knowing really much about that stuff... but from what I understand so far the correct names would be getEntityBrushMesh (or getModelBrushMesh) and getEntityFaceMesh (or similar name). And it would work not only for brush-entities but for all entities with models and my point is that you don't seem to get the BrushEntity here, but you get that earlier already.

edit: Also - my terminology is from the format-description. Could be editors use another terminology... and BrushEntites there for example doesn't refer to the entity-structure but to the brush-structure for some reason. Not really sure what is better in this case to use inside Irrlicht.

[hendu]

Thanks, I see.

The specs are confusing on this, but brushes and faces do not contradict, brushes contain faces. There's only one set of geometry, be it from brushes or from models (which get converted to brushes on map compile, confused yet? )


Irrlicht's BSP loader does not use the brush section of the BSP; it directly handles faces, since having the info on which brush they belong to is useless here. Even in Q3 the info whether you collided with this wall or the one next to it is of limited use.

*sigh* so hard for me as I might be completely off not knowing really much about that stuff... but from what I understand so far the correct names would be getEntityBrushMesh and getEntityFaceMesh (or similar name). And it would work not only for brush-entities but for all entities with models.

Sorry, but this is wrong. An entity with a model = brush entity from Irrlicht's perspective. The model gets compiled to a brush.

It works as is for all types of entities that have geometry.

[CuteAlien]

Hm, I read it just the other way round. That you create brushes in the editor and those get compiled to faces. But that brush-geometry (consisting of convex polygon areas) is kept around additionally and for example still used for collision by people.

[hendu]

Yes, you're right, but that's one level deeper. The point was that models are indistinguishable from brushes after a compile.

[CuteAlien]

Irrlicht's BSP loader does not use the brush section of the BSP; it directly handles faces, since having the info on which brush they belong to is useless here. Even in Q3 the info whether you collided with this wall or the one next to it is of limited use.

OK, I missed that - so you didn't change that part but still return the mesh create by the faces and also ignore the brushes part?
So the "brush" doesn't refer to getting the brush-geometry but to the fact that the entity for which you want to get the mode-mesh was a brush in your case?

[hendu]

Yes. The Models section contains a list of faces for each brush entity. That's all the info that's needed to separate them.

[CuteAlien]

Yes. The Models section contains a list of faces for each brush entity. That's all the info that's needed to separate them.

Ok, but not only for brush entities but for all entities, right? So get entityMesh might be correct?

[hendu]

Only brush entities have geometry? I suppose this is another terminology clash.

[hendu]

Hehe, edits are getting in the way for both of us

So the "brush" doesn't refer to getting the brush-geometry but to the fact that the entity for which you want to get the mode-mesh was a brush in your case?

No. The mapper would call a "model entity" a brush entity too. If the entity has geometry attached to it, it's a brush entity in mapper terms.

[CuteAlien]

Only brush entities have geometry? I suppose this is another terminology clash.

Could be. Christian wrote earlier on that there are a lot more types of entities with geometry and brushes refer only to those belonging to the static part of the level. Maybe different editors also use different terminology?

edit: Sorry for edits ;-) Probably we should rather use chat.

[hendu]

I believe he works with later editors than Q3 (Half-Life 2?). Yeah, that's another complication, with different games.

IRC?

[hendu]

v2 patch and example uploaded. The changes are in the function names and comments.

[CuteAlien]

Thanks, patches applied in svn trunk r3991 and r3992. Example will probably be added another time.

[burningreggae]

Hi!. i'm following this thread and i don't know what you want to change?. the entites and shaders are loaded and parsed since many years..
( entites are stored as paired strings inside the file like "classname" "worldspawn" and are used to spawn items, like doors, additional models. ) nothing more than a script and is exposed by

//! get's an interface to the entities
virtual quake3::tQ3EntityList& IQ3LevelMesh::getEntityList() = 0;

example 21 is using the entitylist.

if you want access to the collision brushes ( irrlicht is using the triangle meshes for rendering & collision ) you have to load the rest of the bsp file. (planes/leafs/leaf nodes). but they don't help you with doors!

// example q3dm0.bsp original quake3 arena
{
"model" "*12"
"_minlight" "0.1"
"team" "richard"
"angle" "180"
"classname" "func_door"
"lip" "16"
}
{
"model" "*13"
"_minlight" "0.1"
"team" "richard"
"classname" "func_door"
"angle" "360"
"lip" "16"
}

if you want to load doors ( i did this already, but it seams the code isn't in irrlicht.. ) you have to first load the rest of the internal static models
in the bsp file.. currently everything is loaded as one consecutive model. a Model only says. i have face20-face60 for rendering. it's no big deal.

than you have to parse the entitylist for "classname" "func_door" or "func_door_rotating". this will give you the modelname for one door side. create a dynamic scene node (q3shaderscenenode if you need shaders), use a big surrounding bounding box. if you step in move your door in the direction of "angle" (models inside bsp are stored in woorld-coordinates).

but as i see the q3levelmesh inside irrlicht is far away from my local code..

please go ahead and try to make the doors open in irrlicht.. i can remember how glad i was when i first stepped to the other side;-)
greetings!