BSP brush entities

[hendu]

Hi burning, glad you could join! I hear you wrote the original Q3 support.

if you want to load doors ( i did this already, but it seemed 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.

Already done, merged, shown in an example, and used in my private projects.

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!

I'm afraid this was not my goal - automatic support for doors in existing Q3 maps. My goal was full customizable usage of any entities in custom maps as well as existing Q3 ones.

While having that support would make a Q3 clone less lines of code, it would be much more limited. It couldn't be used for say windows, vegetation, weirdly moving statues, stage prop that might be removed at night, etc etc.

Or even weirdly opening doors

[burningreggae]

2nd. ah i did an update and now i see you loaded the internal models and named then BrushEntities.
what you are doing is correct, but the name of the functions are really confusing if you are used to id3tech.

a) idTech uses the term brush for a set of planes forming a convex hull and also has the lumps named like this.
b) Entities are the string pairs forming a class description. ( spawn variables )

what you have is a static mesh ( SMesh, correct) which was embedded by the map compiler. BUT!!! this is only the case for static models with one frame.
every other model (md3, mdc) has to be loaded from outside. and there are for example model2 and model3 spawn variables, not only variable model.

an absolute clean way would be if you take the mesh, name it "mysupermap.*1", "*2"... store it in an simple model-format ( or original md3) and register it globally to the modelmanager ( memfiles!) , like the lightmaps are globally available. ( per level )
because that's what it is...

when i did it, i uses the alread existing getMesh method, enlarged eQ3MeshIndex and returned the embedded model...
its the same as you did and maybe more confusing than your way;-)

please continue your work! greetings!

[hendu]

but the name of the functions are really confusing if you are used to id3tech.

Yes, but that is the term used in the editors (NetRadiant, GtkRadiant, DarkRadiant..).

every other model (md3, mdc) has to be loaded from outside. and there are for example model2 and model3 spawn variables, not only variable model.

The non-embedded model files are not in my scope; they are already possible. Your code can check for those keys and then load the appropriate model from its archives.

please continue your work! greetings!

I think this feature is finished. But if I come across something else I need in irrlicht and think it would benefit others

[netpipe]

the patch was accepted into the trunk but the demo wont compile is there an example to use for this thats ready for compile against svn ?

[hendu]

Do you have the right version (brushent_example_v2.tgz)? If so, what are the errors?

[netpipe]

aha it does work thanks