I'm extremely lacking in the modeling area!
What's the difference between bsp and mdl models?
Why would you use one over the other?
What's The Difference?
What's The Difference?
Good God! You shot my leg off!
-
frag.machine
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Besides, it's better (both to create and to render) a single textured brush to represent ammo or medikits, than an elaborated model.
That said, personally I believe it's only because Quake was actually a rushed work, and it lacked a lot of polishing. Of course, nobody really cared about that (and some even prefer not see that
) because, frankly, we hadn't nothing to compare back then, so any rough aspect was overly compensated by the novelty of an awesome real 3D world. This sensation of rushed work is reinforced by this comments of Romero about how, after more than a year of work, they scraped everything and restarted from near zero, and delivered the game in seven months.
That said, personally I believe it's only because Quake was actually a rushed work, and it lacked a lot of polishing. Of course, nobody really cared about that (and some even prefer not see that
) because, frankly, we hadn't nothing to compare back then, so any rough aspect was overly compensated by the novelty of an awesome real 3D world. This sensation of rushed work is reinforced by this comments of Romero about how, after more than a year of work, they scraped everything and restarted from near zero, and delivered the game in seven months. John Romero wrote:Regardless, the decision was ultimately made to take what the team had established in terms of levels and art design, and rework Doom. Romero was disgusted. “I was like, ‘That is so lame’,” he laughs. “But that’s basically when I realised(sic), ‘I’m finished here.’ I went off and redesigned the game, handed everybody out the spec sheets for what they’d be doing with the new, revamped design, and it was all about total execution for seven months. (...)
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC 
(LordHavoc)
(LordHavoc)MDL:
* Supports animation, frame groups, etc
* Supports multiple skins, skin groups
* Some wonky display problems as mentioned above
* Unable to do independent and locational animated textures
* Requires a basic bounding box
* Does not support movetype_push in standard engines
BSP:
* Does not support animations, skins, etc
* Does support animated textures, with different textures on each face, each operating independently
* Fairly easy to get the look you want and to blend in with the surrounding level, while mdls can be troublesome in this area.
* BSP models can be made SOLID_BSP and MOVETYPE_PUSH. This allows them them to have dimensions exactly matching their shape, instead of a bounding box. MOVETYPE_PUSH doesn't interact with other BSP brushes, but it does push everything else around.
Basically, when you make a platform or door in your level editor, you're making a BSP model for that object. BSP models made within the map have temporary names like "*1", "*2", etc (labeled in the order they're defined in the map). If you wanted to have an independent bsp model that could be spawned at will (i.e. a vehicle or other object), you could make it separately in the level editor, compile it, and put it into your progs folder and set an object's model to it.
I think that covers most stuff.
* Supports animation, frame groups, etc
* Supports multiple skins, skin groups
* Some wonky display problems as mentioned above
* Unable to do independent and locational animated textures
* Requires a basic bounding box
* Does not support movetype_push in standard engines
BSP:
* Does not support animations, skins, etc
* Does support animated textures, with different textures on each face, each operating independently
* Fairly easy to get the look you want and to blend in with the surrounding level, while mdls can be troublesome in this area.
* BSP models can be made SOLID_BSP and MOVETYPE_PUSH. This allows them them to have dimensions exactly matching their shape, instead of a bounding box. MOVETYPE_PUSH doesn't interact with other BSP brushes, but it does push everything else around.
Basically, when you make a platform or door in your level editor, you're making a BSP model for that object. BSP models made within the map have temporary names like "*1", "*2", etc (labeled in the order they're defined in the map). If you wanted to have an independent bsp model that could be spawned at will (i.e. a vehicle or other object), you could make it separately in the level editor, compile it, and put it into your progs folder and set an object's model to it.
I think that covers most stuff.
When my computer inevitably explodes and kills me, my cat inherits everything I own. He may be the only one capable of continuing my work.
leileilol offered the simplest, most to-the-point answer. To elaborate:
Perspective correction:
In software engines, the textures on MDL textures warp, especially when clipped by the screen edge (that is, when the model is part on-screen and part off-screen). This undermines Quake's look of solidness. Id Software's software-3D games have always had this "solid" look which separated them from the competition (for comparison, look at the walls in Daggerfall, or *shudder* Ultima Underworld). Basically, the texture coordinates are accurate at the vertices, but along the surface of triangles they screw up (to put it in layman's terms). The larger the triangle on the screen, the more screwed up it will look. Ammo boxes (being fundamentally composed of gigantic triangles) look especially bad.
Lighting:
BSP models have lighting compiled into them. So they are lit the same, no matter where in the map they are placed. This is a drawback. But, Quake is kind of arcade-y, and the designers probably considered it an advantage that the ammo boxes were always well-lit and visible. MDLs, on the other hand, derive their lighting by tracing downward and reading the lightmap value from the floor beneath them, afterwards adding a fake, slightly directional "shading" effect. So, if you replaced the ammoboxes with MDL variants, you would suddenly find that ammo placed in dark corners is now suitably dark and hard to see.
Bounding boxes:
When using SOLID_BBOX on a BSP model (as for example the ammo boxes do), as soon as you call setmodel() a bounding box will be set for you, being a box fitted around the model's geometry. On the other hand, MDLs, when you call setmodel(), get a hard-coded '-16 -16 -16', '16 16 16' bounding box, which you have to override manually with a setsize() call. (Some newer engines however auto-calculate a proper bbox size.) This isn't a problem, except with drop-in MDL replacements, such as Asaki's pak2.pak: if you replace the BSP explobox models with MDLs and don't modify the code (since the default progs don't call setsize), the exploboxes will have messed up bboxes.
Also, BSP models can use SOLID_BSP (I think), which gives perfectly accurate collision detection, rather than a simple bounding box.
Finally, there are the things with animation and animated skins, which Wazat mentioned.
Perspective correction:
In software engines, the textures on MDL textures warp, especially when clipped by the screen edge (that is, when the model is part on-screen and part off-screen). This undermines Quake's look of solidness. Id Software's software-3D games have always had this "solid" look which separated them from the competition (for comparison, look at the walls in Daggerfall, or *shudder* Ultima Underworld). Basically, the texture coordinates are accurate at the vertices, but along the surface of triangles they screw up (to put it in layman's terms). The larger the triangle on the screen, the more screwed up it will look. Ammo boxes (being fundamentally composed of gigantic triangles) look especially bad.
Lighting:
BSP models have lighting compiled into them. So they are lit the same, no matter where in the map they are placed. This is a drawback. But, Quake is kind of arcade-y, and the designers probably considered it an advantage that the ammo boxes were always well-lit and visible. MDLs, on the other hand, derive their lighting by tracing downward and reading the lightmap value from the floor beneath them, afterwards adding a fake, slightly directional "shading" effect. So, if you replaced the ammoboxes with MDL variants, you would suddenly find that ammo placed in dark corners is now suitably dark and hard to see.
Bounding boxes:
When using SOLID_BBOX on a BSP model (as for example the ammo boxes do), as soon as you call setmodel() a bounding box will be set for you, being a box fitted around the model's geometry. On the other hand, MDLs, when you call setmodel(), get a hard-coded '-16 -16 -16', '16 16 16' bounding box, which you have to override manually with a setsize() call. (Some newer engines however auto-calculate a proper bbox size.) This isn't a problem, except with drop-in MDL replacements, such as Asaki's pak2.pak: if you replace the BSP explobox models with MDLs and don't modify the code (since the default progs don't call setsize), the exploboxes will have messed up bboxes.
Also, BSP models can use SOLID_BSP (I think), which gives perfectly accurate collision detection, rather than a simple bounding box.
Finally, there are the things with animation and animated skins, which Wazat mentioned.
F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.
Thanks,
Now I know why nobody has tried converting all of the bsp models to mdl models.
The reason I was asking is because I was bouncing some ammo boxes around with Quake Matt's Gyro add-on and noticed that the ammo boxes tend to disappear into the walls and seemed to act different... I don't know, maybe it was my imagination.
Now I know why nobody has tried converting all of the bsp models to mdl models.
The reason I was asking is because I was bouncing some ammo boxes around with Quake Matt's Gyro add-on and noticed that the ammo boxes tend to disappear into the walls and seemed to act different... I don't know, maybe it was my imagination.
Good God! You shot my leg off!
Well, one oddity with those ammo and health bsps is they are not centered around their origin. Instead, their origin is down at one of their bottom corners. So if you spin them you'll get weird effects.
And DP has some stuff-goes-through-walls issues in certain cases, which I haven't been able to narrow down to a science yet. :/
And DP has some stuff-goes-through-walls issues in certain cases, which I haven't been able to narrow down to a science yet. :/
When my computer inevitably explodes and kills me, my cat inherits everything I own. He may be the only one capable of continuing my work.
yup, I noticed that the origin was not centered... made the ammo box look like it had a small heavy object in on of it's corners.Wazat wrote:Well, one oddity with those ammo and health bsps is they are not centered around their origin. Instead, their origin is down at one of their bottom corners. So if you spin them you'll get weird effects.
And DP has some stuff-goes-through-walls issues in certain cases, which I haven't been able to narrow down to a science yet. :/
Well, I know this isn't the QC section... but since this discussion is here I will throw a thought out here...
I wonder if an entity could be spawned without a model then set that entities size to that of the ammo box. Next attach the ammo box to the new entity with DP's MOVETYPE_FOLLOW. Maybe the ammo box will behave as a mdl model? Hmmm, I'm going to give it a try.
Good God! You shot my leg off!
This is highly interesting, could someone please wiki it?
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
I'm not really sure what you're trying to accomplish here. "Behave as a mdl model"? There should be no behavioural difference between a entity using a BSP model and an entity using a MDL model.Junrall wrote:I wonder if an entity could be spawned without a model then set that entities size to that of the ammo box. Next attach the ammo box to the new entity with DP's MOVETYPE_FOLLOW. Maybe the ammo box will behave as a mdl model? Hmmm, I'm going to give it a try.
F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.
I'm sure it's my lack of knowledge in the mdl and bsp area. It just seams that when I bounce a bsp around it tends to disappear into the walls whereas any other mdl bounces off of walls just fine.Sajt wrote:I'm not really sure what you're trying to accomplish here. "Behave as a mdl model"? There should be no behavioural difference between a entity using a BSP model and an entity using a MDL model.
Also, the ammo box's self.origin is set at one of it's corners rather than at the very center... like a mdl model would be. This makes the ammo box look weird when it is rotating and bouncing off of walls.
Again, I'm using Gyro... so, maybe this is causing the bsp models to disappear into the walls.
My thought was that maybe I could overlay an ammo box with an entity that was the same size then apply DP's MOVETYPE_FOLLOW to both the ammo box and entity. I could then use Gyro physics to bounce the entity around which in turn would keep the box from disappearing into walls and behave like a mdl'ed entity that is set to MOVETYPE_BOUNCE. And, hopefully, the ammo box will spin around it's center... or rather, the entities center.
Again, I lack the knowledge of mdl and bsp models and how Quake handles them. This is the point at which I end up over thinking things and come up with some crazy-hair-ball-idea then later find out that all I had to do was add 1 and 1 to get 2!
Good God! You shot my leg off!
OffTopic: I do know that if you spawn an alias model (.mdl) where the bounding box is touching the bsp INCLUDING velocity the model will pass thru the wall. (Ack! I just had an idea to how to disable wall passes in QBALL)...
on topic:
Here's a tacky idea, is it possible to define BSP data (compiled) within quakeC and dynamically spawn map entities? Immediately im thinking of random polygons of varied size that can also slide around, (imagine walking on a waterbed), to create random Rocket Arena arenas.
on topic:
Here's a tacky idea, is it possible to define BSP data (compiled) within quakeC and dynamically spawn map entities? Immediately im thinking of random polygons of varied size that can also slide around, (imagine walking on a waterbed), to create random Rocket Arena arenas.
Is it feasible to use a non animated BSP model as a player model, an airplane? Does this mean more accurate collision hits?Wazat wrote: * BSP models can be made SOLID_BSP and MOVETYPE_PUSH. This allows them them to have dimensions exactly matching their shape, instead of a bounding box.