Breakable Glass

[Hecateus]

I don't know if it helps to look but, The Alchemist

had window which took 3 broadhead arrows to take out.

 

[HMart]

 

3. The performance affect of having a mine blow up and shatter the glass of five different display cases (4 fracture entities each) at once dropped my framerate to 3 until the glass disappeared. That might be problematic.

 

 

It looks the shards use the regular doom3 rigid body physics and we all know how finicky they are, so no wonder calculating that many shards makes the system really slow.

 

The only solutions to this are:

 

1 - Update the idtech 4 physics system to be more stable, multithreaded or run on a separate thread.

 

2 - Replace the physics system with another one like Newton (used on Penumbra and Amnesia) or ODE (used on stalker).

 

But both options i'm afraid will never happen because they need someone very knowledgeable of idtech 4 and physics systems.

Edited July 16, 2015 by HMart

[SteveL]

1. One sword hit causes a "cracked" decal to appear on the glass. The glass, in this state, is now intangible to arrows (they fly right through and damage the glass on the opposite side of the case) and held objects (the held object moves right through the glass). Throwing a junk object also goes through the glass and breaks the glass on the opposite side. A further strike with a sword or bj breaks the glass.

 

2. Held objects can break regular glass just by being pushed against the glass. Thrown objects seem to break the glass first try as well. Neither cause cracked decals.

 

3. The performance affect of having a mine blow up and shatter the glass of five different display cases (4 fracture entities each) at once dropped my framerate to 3 until the glass disappeared. That might be problematic.

1. I can see in the code, when the glass enters the "broken" state ( = 0 health) before it shatters, its collision properties get changed straight away. Until that time, it's solid to whatever things its material properties say it should be solid to. After that point, it's solid to a lot less (not sure exactly what yet, but its "clip contents" change to CONTENTS_RENDERMODEL and all other collision flags are removed. I think we could safely delay that switch in physics until it actually shatters.

 

2. I'll check that one out now that I have my hands on a laptop again.

 

3. For big set scenes like that, it could help to increase the maxShardArea spawnarg which should cut down on the number of shards.

[Springheel]

3. For big set scenes like that, it could help to increase the maxShardArea spawnarg which should cut down on the number of shards.

Where does that spawnarg go?

[SteveL]

Where does that spawnarg go?

On the func_fracture. You'll see it in the inherited spawnargs if you have this morning's svn update.

 

2. Held objects can break regular glass just by being pushed against the glass. Thrown objects seem to break the glass first try as well. Neither cause cracked decals.

I can explain these now. Moveables, melee weapons, and arrows all break glass in slightly different ways. I've had a play with large pewter bowls and panes of glass with only 1 health.

It takes a while to break glass using moveables if the glass starts with its default 40 health. The thrown or wielded bowl does 1 point of damage at a time, but it inflicts that 1 damage several times as it falls down the glass.

 

Thrown items breaking glass

The reason that the bowl can break the glass in one throw is that moveables' collision code first applies damage then applies an impulse, in the same game frame. So there's no need for a second collision to shatter the glass. The player's melee weapons don't apply an impulse after inflicting damage, so they don't break glass in a single hit.

 

Thrown items passing through glass

Moveables pass straight through a pane of glass that's already at 0 health and about to break, without colliding with it. Arrows and the player's melee weapon do break glass that's in that state. This is a simple bug. Like I said above, the glass pane's collision settings get updated when it reaches 0 health, so that only things that are specifically set up to collide with "rendermodels" will hit it. Things that merely collide with ordinary solid items will no longer hit it. Arrows are set up to collide with general solids, plus other projectiles, and rendermodels, so they work. Moveables collide with general solids, plus other moveables and corpses. Not with rendermodels, so they don't work.

 

We probably don't want to mess with moveable physics, but we could delay the glass's change in nature until it actually shatters.

 

Missing fracture marks

Thrown items don't make a mark on the glass. That's because the marks are "requested" by the weapon. When a weapon hits anything, the weapon tells the hit entity to apply damage effects to itself, if it has any defined. When you hit glass with a bowl and the glass has enough health to survive, nothing like that happens. Certainly fixable; we'd just need to avoid getting 2 marks on glass from weapons if we allow any kind of damage to add a mark.

 

I didn't get round to looking at moss arrows yet.

[demagogue]

Yeah, the cracked decal was my first guess, that the health applies a pre-dead damage stage. That's how func_damageables work.

 

Edit. Well Steve has cracked the case, so to speak, so I'll defer to his excellent explanation.

[Hecateus]

Related question. I noticed NHAT, lots of stalagtites/mites. Can one give them the transparancy of glass and make them breakable? ie Icicles? for we are lacking them I think. and it's summer and hot ....ugh

[SteveL]

Yes you can make anything into a func_fracture and it will shatter on impact. But your icicles wouldn't break into solid chunks, they'd break like they were made of a thin layer of hollow glass. So they'd have to be kept thin for the illusion to work, and you'd want to keep the tris as big as possible.

 

An earlier question: Moss blobs don't appear on anything that's too vertical. They do stick to breakable glass ok if it's more on its side. We could consider a special rule for func_fractures, so that the moss blobs stick to them even when vertical.

 

I've not looked at the sound prop yet. I'm in the countryside this week with a terrible data connection so I'm spending more time by the river with a G&T than on the computer.

[Springheel]

I've not looked at the sound prop yet. I'm in the countryside this week with a terrible data connection so I'm spending more time by the river with a G&T than on the computer.

 

 

I can look at that, or at least see what gets propagated to AI. At the moment, it doesn't look like the glass shatter really does get propagated...or if it does, there's no spawnarg controlling it in the func_fracture entity.

 

One gameplay question...how loud should breaking glass be to AI? I would think, realistically speaking, that the sound of breaking glass should alert a guard nearly as much as an explosion or yell for help. Is there any gameplay reason not to do that? Unlike those things, the player might not have much of a choice (assuming they have no moss arrows to muffle the sound).

 

edit: I can confirm that AI are not being alerted by the shattering of the glass. They react to melee weapons hitting the glass (whether it breaks it or not) in the same way they would to hitting a wall. They don't react to arrows hitting the glass at all, which is odd.

 

I've tried adding a propagated sound to the shattering, but it doesn't seem to be having any effect.

 

Ooops. Don't test with AI set to team 0. It's working now.

 

I've added a better cracked glass decal...tried to update the impact sounds of swords and blackjacks, though for some reason they are still playing their default impact sounds when hitting func_fracture glass. The "snd_glass" sound works fine on non-breakable glass, but maybe there is some kind of clipmodel around the func_fracture?

 

edit: I tested with moss arrows, and when I mossed the glass and then shot a regular arrow at it, the AI only reacted to the impact sound of the arrow, which seems about right.

 

One thing just to remind myself--I gassed an AI and his sword broke the glass as he fell...could searching AI bash the glass with their swords?

[SteveL]

I've added a better cracked glass decal

That looks great! *Much* better than the old bullet hole.

 

tried to update the impact sounds of swords and blackjacks, though for some reason they are still playing their default impact sounds when hitting func_fracture glass. The "snd_glass" sound works fine on non-breakable glass, but maybe there is some kind of clipmodel around the func_fracture?

Ah, that'll be because the model gets carved up into fragments at spawn time. THe old model gets replaced with a new carved-up version even though you don't see any cracks until it gets damaged. I can see that the surface type being hit is the default type, not glass. We need to preserve the material properties when the model gets carved up.

 

One thing just to remind myself--I gassed an AI and his sword broke the glass as he fell...could searching AI bash the glass with their swords?

Yes. They will accidentally shatter glass that's already been damaged (0 health), because all it needs is a touch, but they won't do any damage to "healthy" glass, even if they swing their sword at it.

 

 

On peformance: It's better to use a brush with one glass surface and nodraw sides, or a patch, else all 6 sides of your brush shatter into their own shards and you get needlessly many.

 

A quick round-up:

 

Bugs

• Let models be shatterable, not just brushes / patches -- fixed
• Spawnargs to control shard life time -- fixed
• Thrown objects pass straight through glass that's down to 0 health
• Material surface type gets replaced with default when the model gets carved up

Possible changes -- up for debate

1. Moss should stick to func_fractures, even when they are vertical
2. Damage effects should be applied by any damage to glass, not just melee weapon damage
3. Melee weapons should be able to break glass in one hit

To investigate

• Having moss blobs in the mix when glass shatters seems to be hurting performance more (maybe, not tested properly yet). Perhaps they are interacting with the shards. If so, we could stop that happening. I can't think of a reason why glass should need to bounce off moss blobs.

[Destined]

Is it possible to add an impulse to the weapon hit, after damage is applied? If this does the trick for thrown objects, it should also work here. I don't know, if the impulse strength can be influenced, but if we can make it very weak, it should not affect the rest of the gameplay.

[SteveL]

Yes, although we won't actually have to add a force to weapons. I think the simplest way to do it without affecting any other gameplay would be to make the code that deals with the func_fracture getting down to 0 health check whether it's a weapon that inflicted the damage, and if so it can raise a "touch" event that'll make the glass shatter later in the same game frame. Very similar to how the thrown objects break the glass.

[Destined]

Ok. My knowledge of the code is too limited. Just wanted to make a suggestion.

[Springheel]

When you swing a weapon at a movable object, doesn't it move the object? If not it certainly should.

[Springheel]

Moss should stick to func_fractures, even when they are vertical

 

 

Agreed, but perhaps what we need is a different decal that can be applied, rather than the big model blob of moss (actually, I've always hated those moss blobs even on the floor).

[SteveL]

Ok. My knowledge of the code is too limited. Just wanted to make a suggestion.

 

Actually, that might yet prove to be the better way...

 

When you swing a weapon at a movable object, doesn't it move the object? If not it certainly should.

 

 

Yes it does. I had to go take another look at the melee code to work out what's going on. It turns out that weapons do it in the opposite order. They apply the force, then the damage. Moveables apply the damage, then the force. Breaking glass needs the damage first to crack it, then an extra shove to shatter it, in that order.

 

So the least complicated way to fix it would be to switch the order of those events when a melee weapon strikes. I don't *think* that'd have any side-effects... both things happen in the same frame during the weapon's Think() routine, so nothing can happen in between the two. For there to be side-effects, there'd have to be something else in the game like func_fractures, that depended on the order of the effects of a melee blow. Worth trying the simple fix anyway, before thinking about introducing new rules into the code.

 

Agreed, but perhaps what we need is a different decal that can be applied, rather than the big model blob of moss (actually, I've always hated those moss blobs even on the floor).

Agreed. It used to bother me that moss blobs don't cover a surface, so you don't know whether it's safe to tread. Until I figured out that whether or not you can see moss, the whole area within the moss cluster is muted. But it would be nice to use a simpler model or decal instead, with better coverage. For the vertical glass I'm sure we could simply splat a decal on it.

[Springheel]

A decal would have the added benefit of not interfering with the breaking glass physics.

 

One gameplay problem we have to consider--how does the player tell the difference between breakable glass and not?

 

If I come across some glass, and there's an AI nearby, how do I know whether it's worth using a moss arrow on it? If I use an arrow, and it turns out not to be breakable, that's an annoying waste of a tool. If I test it out by hitting it with my sword and it turns out to be breakable, that could instantly shatter the glass and alert the AI, which means I'm probably busted. The player needs to be able to tell whether glass is breakable without having to actually break it.

 

Some ideas off the top of my head--

 

1. Breakable glass somehow looks different than regular glass (difficult to enforce)

2. Breakable glass froblights somehow (not intuitive)

3. Shooting non breakable glass with moss arrow leaves your arrow intact (meh)

4. Some player tool that can tap glass to see if it's breakable?

 

None of these strike me as a great solution.

[Destined]

A decal would have the added benefit of not interfering with the breaking glass physics.

 

What happens with a decal on the broken glass? Does it disappear? I assume, it will get cut into pieces like the glass (although it would be very nice, if the moss would still be visible on the shards)

 

 

One gameplay problem we have to consider--how does the player tell the difference between breakable glass and not?

 

The first things that came to my mind would be:

 

1. Glass that you cannot see through is not breakable (e.g. the window skins with lit/unlit), windows that are seethrough should be made breakable. Are func_fractures moveable by default, so you can put it into a window frame, that is moveable and just link it? I can test it, but if someone already knows, it would save some time.

2. Coming back to tags and map descriptions: The map author can plainly tell beforehand, if he used breakable glass

3. unbreakable glass could have some "reinforcements", like metal bars or something, that go through the glass, so you can still see through, but see, that it is more robust.

 

The 2nd one would be the easiest, but strongly depends on the cooperation of map authors.

[Springheel]

1. Glass that you cannot see through is not breakable (e.g. the window skins with lit/unlit), windows that are seethrough should be made breakable

 

 

 

That can't be done...too many missions have already used see through glass that isn't breakable.

 

 

Are func_fractures moveable by default,

 

 

I don't think they can be movables. They certainly aren't by default.

 

Coming back to tags and map descriptions: The map author can plainly tell beforehand, if he used breakable glass

 

 

How?

 

 

unbreakable glass could have some "reinforcements", like metal bars or something

 

 

 

Again, this can't be done retroactively. Any solution has to take into consideration the way glass has been used thus far (99.9% of which has not been breakable).

[grayman]

One gameplay problem we have to consider--how does the player tell the difference between breakable glass and not?

Easy-peasey:

 

[Destined]

 

 

That can't be done...too many missions have already used see through glass that isn't breakable.

 

 

this can't be done retroactively. Any solution has to take into consideration the way glass has been used thus far (99.9% of which has not been breakable).

 

I see the problem here. I could only think of the solution, that the standard texture of glass is replaced by on, that uses said reinforcements and the "normal" glass texture is renamed to "glass_breakable" or something. But this was just a quick idea, we can just ignore it.

 

 

How?

 

Just put it in the general map description for the downloader. Something like "this mission uses breakable glass". Also just from the top of my head...

[SteveL]

4. Some player tool that can tap glass to see if it's breakable?

The blackjack will do that. As long as the glass' health is higher than blackjack damage, you'll get a crack but no shatter.

 

Does anyone know how much damage the blackjack does? The sword was doing 42 in my tests earlier. Default glass health is currently 40, which is probably too high. It shouldn't take 2 broadheads from close range to smash a window.

[grayman]

IIRC blackjack damage is 2

[SteveL]

What happens with a decal on the broken glass? Does it disappear? I assume, it will get cut into pieces like the glass (although it would be very nice, if the moss would still be visible on the shards)

I think that's what'll happen. There's code to handle decals in the carving-up routine. One to try.

[demagogue]

When an FM uses a non-standard mechanic, like breakable glass, my thinking is for something in the FM fiction itself, like context or a readable, to cue the player to it, and if that's awkward, put it as a note in the loading screen or readme.

 

I'd rather have FMs have a little variety with mechanics, but informed to the player, than total homogeneity. Well if they're important. Some little things might slide and reward player exploration, but important things should usually be cued to the player imo.