Create .bsp models from within maps

[Cobalt]

So we have bsp models in the health and ammo boxes and the exploboxes which are dynamic and can be spawned on any map.

Doors, plats and func_walls use models referenced in the map with an asterisk prefix, IE: model *69

While these ents have an absmax and an absmin that points to their upper and lower bbox coordinates, their .origin is world or '0 0 0' ...according to my tests within QC.

Would it be possible with a map editor to extrace these models, and save them as seperate bsp type models like the ammo boxes , healths etc?

I ask because there are these items for example....one is a teleport which has (5) seperate models embedded in E1m3, and the various telepads on the maps for example:

http://imgur.com/o1XK3tY


http://imgur.com/XbDGAkA

[ceriux]

why not just remake them yourself?

[Spike]

you could use an external bsp object, sure... except that your lighting would be as terrible as mdl is. and probably worse than that.
full rtlights could help solve that, but they're not exactly cheap.
you'd also need a new progs.dat
whats wrong with using prefabs?
some engines will have issues despite this.

actually, I believe inline models were an afterthought. its easier to design your map and light it properly when each thing is part of a single whole, instead of editing it and affecting lots of other maps too. plus there would be obvious lighting discontinuities.

[Cobalt]

[Cobalt]

[mankrip]

External BSP models have their own lightmap, which is not lit by world lights.
Put ammo boxes in a dark area of the map, and they'll look terribly out of place, because they will still be lit as if they were in a bright area. That's worse than MDL lighting.

Makaqu 1.6 fixes that by using the lightpoint value of the world to change the lightmaps of the external BSP models; I don't know of any other engines that does this. However, that solution isn't as accurate as making those models part of the world's BSP.
For some of the other engines, as Spike said, you can use full real time lighting, which is slower and doesn't look the same.

Teleporters and telepads usually don't move, so there's no point in separating them from the world. And in an ideal scenario, there would probably be no external BSP models; exploboxes, ammo, health, etc would all be prefabs compiled within the map. Too bad the default progs.dat doesn't support that.

By the way, the .origin of inline BSP models being '0 0 0' is atrocious, because it ruins things when we want to make an inline rotating BSP model that's properly lit, since afaik BSP models only rotates around their .origin.

[Spike]

there are ways to avoid an origin at '0 0 0'. Different ways... many of them awkward but used anyway... depends which tool you use... my favourite is the origin brush method, but most q1 tools seem to prefer targetting some point entity instead.
hexen2 actually has an abslight field, allowing the mapper to explicitly set the single light value used on the bsp object. its a lazy way around dodgy lighting, and results in flat-looking movers that makes it obvious that it moves. it solves the imediate problem, anyway. its also used on transparent teleporters, giving them a slightly etherial look, so hurrah for that.

a prefab is basically a collection of brushes that can be inserted and moved into place, but compiled as part of the map instead of being a separate entity. most map editors support some sort of prefab, some even provide a few!

[Cobalt]

[mankrip]

Inline models are the solution you're looking for. They are not static, but they're compiled within the world.

Prefabs and inline models are different things. Prefabs are just brushes, and you can use them on either the world model or inline models. Prefabs used on the world model becomes a static part of it.

Inline models are individual entities. They are not part of the world, but their models are compiled within the world. Doors, platforms and buttons are inline models.

Inline models are also called "submodels" in the engine code.

[r00k]

I would think using an alias model would be easier for a broken window; using an animation for all the broken pieces.
also a vanilla engine only has 256 submodels...

[mankrip]

Oriented SPR sprites would be more accurate than MDL models. Their texture UV mapping algorithm is mostly the same as the BSP surface UV mapping. You'd only need an engine with lit sprites support.

And for the window on the wall (either the intact one or the remaining portion of it after it's broken), an inline BSP submodel does the job.

[Cobalt]

Well the trouble with inline seems to be they are "baked" into the map and you cant spawn them dynamicly regardless if the map has them or not. Im not a mapper but from QC I can see they have an absmin and absmax value with respect to them which is also in correct to the map coordinates they appear in, in regars to their top and lower box corers of course. Their .origin is always world origin or ' 0 0 0 ' , and yea, I have seen QC that adds absmin and absmax then divides it in half to determine the center of that model, but from a "self" perspective (self being the actual model ent) , its .origin is world and in its traditional format all the ID maps with these kind of models use that system. My question was how to , if possible - make them into real .bsp models like the other bsp models are.

Regarding sprites, I think they are only 2 dimensional, at least last I checked, so I dont think they are an option here......

[mankrip]

I don't see why glass shards would have to be "tridimensional". SPR sprites are flat, but they can be freely rotated in 3D space like any other model.

Also, why exactly would you need to spawn such BSP entities at custom locations? That's only really needed if you don't have the source of the map. If you have the source, you can create those entities anywhere you want.

And if you don't have the source, there's no way to remove the current windows of the map, so you can't really replace them.

[Cobalt]

Ok for the glass shrapnels sure could be sprites. But that was really just an example to illustrate the question better. Im more interested in making the models I linked photos to, but my question is, can a map editor go in and find the "inline" models that compose that teleporter, then somehow make it into one seperate bsp model? Same for the telepad, but I know its not a seperate model, and is permanently part of the BSP, but I was curious if its merely as simple as copying the brush es for that area into an editor and trimming off the excess under to make a spawnable telepad for example.

[mankrip]

That's not possible, because they are part of the world model, and not inline submodels. The BSP compiler cuts out any part of them that isn't in an open space, so, for example, that telepad's brush doesn't have a bottom face anymore.

As for inline submodels, such as doors, that's technically possible, but I don't think there's any tool that does that.

However, there's a BSP "decompiler" somewhere, that can get a BSP map and try to create an appropriate .map source for it. I remember someone using it to convert Hexen II maps to Quake, and saying that the .map files had to be adjusted because the "decompiling" wasn't perfect.

Personally, I'd just open the BSP file in Quark and use it as a guide to manually create identical BSP models of the desired parts.
That's what I did to create the BSP sky models of the original ID1 maps for JoyMenu (which used those to make the skies non-solid, in a workaround for the "solid skies" bug of the original maps).