Breakable Glass

[Springheel]

Anyone have experience with this? I followed these instructions:

 

Create your brush and give it your glass texture
Convert it to a func_fracture entity
Give it the property health with a value (experiment to see how many hits you want it to take before it breaks.)
It automatically produces shards of glass and sound when it breaks.
You can optionally give it the property target to trigger something after it breaks. For instance if it has a frobable object on the other side you don't want the player to be able to frob until it breaks you would use a clip brush atdm:target_set_frobable around the object.

 

 

Works great on a brush. On a model, everything works except it makes the original model looks like it was fractured before any damage was done.

[SteveL]

Curious. Does the model version shatter and fall immediately, or do the shards just hang there suspended in space? Do they then fall if you hit them?

 

Is the model version still a func_fracture with all the same spawnargs, just with a "model" spawnarg instead of a brush model? Does your model have a single surface mesh?

 

Brittle fractures get "shattered" into shards at spawn time. The model gets carved up, but until you hit it, those shards should be sitting up where the window is. You don't actually see separate shards until they start to fall. If your shards are hanging in midair, the calculation of the origins of the individual shards must be going wrong when a model is being used instead of a brush. That's the only explanation I can think of.

[Bikerdude]

I beleive Arcturus is the person for this, as he made a brakeable version of the St Lucia model.

[SteveL]

I think I can see what's up after trying it in a quick test map. The shards hang in mid-air, until you hit them at which point they react normally.

 

Here are my two func_fractures in DR: the left a brush, the right a straw rug model, which has only 1 surface and has been turned on its side to face the player like a window. In the TDM screenshot the rug model has been divided into shards which have the right orientation but which are placed where they would have been if the rug hadn't been rotated in DR. That'll be the bug. Worldspawn has no "rotate" spawnarg -- when you rotate a brush in DR its verts are moved, it doesn't gain a rotation setting. The game must be ignoring the rotation of the model when it places the shards after carving up the model at spawn time.

 

[SteveL]

Fixed in svn

[grayman]

quick!

[SteveL]

I did test it honest

[Arcturus]

I beleive Arcturus is the person for this, as he made a brakeable version of the St Lucia model.

That wasn't me

[Springheel]

Fixed in svn

 

 

Brilliant! Thanks Steve! Here's what I plan to do with it:

 

 

 

Everything working hunky-dory, although I'm not sure why it takes multiple hits to break the glass with the sword...I've set the health to "1". This seems to happen sometimes with brush glass too.

[SteveL]

The video's private...

[Springheel]

It says it's public...?

[SteveL]

It's visible now. I was maybe just too quick off the mark. That looks fun!

... I'm not sure why it takes multiple hits to break the glass with the sword...I've set the health to "1". This seems to happen sometimes with brush glass too.

?

[Springheel]

Also, where are the flinder settings set, anyone know off-hand? I think they disappear a little too soon atm.

[SteveL]

Also, where are the flinder settings set, anyone know off-hand? I think they disappear a little too soon atm.

 

It seems to be hard-coded:

 

const int SHARD_ALIVE_TIME    = 5000;
const int SHARD_FADE_START    = 2000;

which I think must mean that the shard starts to fade after 2 seconds and vanishes after 5.

 

It should be easy enough to replace those constants with a spawnarg that defaults to those values.

[grayman]

What constitutes the model? It looks like a brush would have sufficed.

[Springheel]

In that example, brushes probably would work. Though it's faster to add a glass model that's customized to fit exactly inside the case model.

 

It should be easy enough to replace those constants with a spawnarg that defaults to those values.

 

 

That would be great---it's a bit jarring to have them completely disappear so quickly.

[demagogue]

Re why 1hp still requires multiple hits. What comes to my mind is the func_destructables have multiple stages of increasing destruction before the final destroyed stage. So I'd first see if func_fractures might not have a similar thing of increasing fracturing (which aren't showing) until the final shatter. That is, the health works in stages.

 

Otherwise, maybe the fracture technically happens but it takes more hits to actually make them fly out. Or the hits are effectively being blunted for some reason. But I'm just randomly speculating now.

[Hecateus]

Otherwise, maybe the fracture technically happens but it takes more hits to actually make them fly out. Or the hits are effectively being blunted for some reason. But I'm just randomly speculating now.

It might be that the hits must be in an exact spot. Flakebridge Monosteryt iirc

had some breakable tomb covers, which could be broken open in one hit with the jack...but only if they were hit in a exact spot....after much personal frustration

 

[SteveL]

You can hit a func fracture anywhere. Maybe only parts of the objects you mention are func fractures.

 

Otherwise, maybe the fracture technically happens but it takes more hits to actually make them fly out.

 

That's pretty much it. When the item gets "killed", i.e. struck by more damage than it has health, it enters a "broken" state but it doesn't shatter. Once it's in a broken state, any kind of touch will make it shatter, including the player walking in to it. But you do need an extra touch. We could add an "easy_smash" spawnarg if people want to use it

[SteveL]

That would be great---it's a bit jarring to have them completely disappear so quickly.

 

Done. There are new "ShardAliveTime" and "ShardFadeStart" spawnargs in DR. I've made the rest of the func_fracture spawnargs visible in DR too, which they weren't before.

 

ShardFadeTime isn't much use. It works the same way that particles fade out, by using vertexColor. So it'll only work on vertexColor materials, which we use a lot for particles but not much for anything else.

[Sotha]

Cool! Considering it is a thieving game, we get to smash display cases surprisingly seldom.

 

Does the AI react to the sound of shattering glass, btw? Would be jarring if it didn't.

[Springheel]

 

That's pretty much it. When the item gets "killed", i.e. struck by more damage than it has health, it enters a "broken" state but it doesn't shatter. Once it's in a broken state, any kind of touch will make it shatter, including the player walking in to it. But you do need an extra touch. We could add an "easy_smash" spawnarg if people want to use it

That doesn't really describe what I'm seeing. You can see in the video that the arrow destroys the glass with one hit--that happens every time with projectiles. Mines also shatter them instantly. Melee hits sometimes shatter in one hit, but other times they just paint a crack decal on them.

[SteveL]

The arrows and mines are possibly doing a double-tap: damage and force. I'll have a look what's going on.

[Springheel]

Does the AI react to the sound of shattering glass, btw? Would be jarring if it didn't.

 

 

Absolutely. That's why we have the mechanic of shooting moss arrows at glass to break them more quietly (which, as far as I know, has never been used and might not even work).

 

edit: was just testing, and now I'm not sure if AI are reacting to the sound of the sword hitting glass, or the glass breaking. When shot the moss arrow at the window, two bad things happened. One, there was no indication that the window was mossed--the moss behaved the same as if I'd shot it at the wall. Two, nearby AI still reacted as if they heard something when I hit the glass, although the glass made no "shatter" sound when it broke. This mechanic obviously needs some work.

[Springheel]

The arrows and mines are possibly doing a double-tap: damage and force. I'll have a look what's going on.

 

 

 

Some interesting anomolies

 

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.