[Guide] GTA V: Glass crash data (Updated May.2022)
Posted: Sat Aug 08, 2015 10:07 pm
GTA V: Glass crash data guide.
Updated: May 2022 (see below)
Vehicle model usually includes a set of glass objects (windscreen, rear windscreen, door windows) that can be crashed with several shots or during impact with other objects. This includes rendering of shatter-glass effect on glass objects and involves making of holes that can expand up to boundaries of the window. The technical background of this process is hidden inside the game and shaders code, and the data required for this logic is stored inside *.yft files. The data is not explicitly bind to the object itself, instead it just defines the boundary limits for the crash glass holes. The image below shows an original windscreen (orange) with original crash boundary data (red) and a modified windscreen (orange: it's moved aside and rotated), while crash data still makes crash holes in this object with original boundaries:
Glass shatter pattern is imported into the scene as object.crash geometry (e.g. "windscreen.crash") and contains a vertex-color painted template for glass shattering. This "crash data" object can be a child of an associated geometry object or a child of an associated collision object, it doesn't matter. Glass shattering requires a collision, so you can't have a glass shatter on an object, say, "extra_2" unless you create an "extra_2 [COL]" collision.
Some objects that don't need a shatter pattern (e.g. a glass-only object that can be smashed completely, or a small glass over headlights or siren lights) can be used with no shatter-glass painted object. To enable shatter effect on these objects, you should add a Crash user-defined option on an associated collision object. In case your collision object is a compound node, make sure to toggle COL state first. Here's an example of user-defined options on windscreen object:
Exporter will create blank crash data for such an object. This object will still trace bullets and will crash and will show crash holes, but you will miss the small boundary of glass on borders of this object when glass is smashed completely.
Note, you do not need to assign "Crash" user-defined option onto a COL object if you have a "some_name.crash" geometry object in scene. Availability of this object will automatically trigger glass shattering logic on a parent geometry/collision.
An ability to draw crash holes is a exclusive feature of vehicle_vehglass and vehicle_vehglass_inner shaders. Other shaders does not seem to support this option.
Since geometry part can use multiple materials (e.g. outer glass and inner glass), you have to explicitly specify the material that will use glass-crash logic. This is also the case when just one material is used. In case of windscreen and door windows, an "outer" glass should be used for glass-crash. To specify the exporter that some material will be used in glass-crash logic, assign "Crash" user-defined property on material too:
Important: game stores and uses glass-crash logic in model.yft file, not in high-resolution model_hi.yft. Thus, you have to ensure your glass-crash material is actually used on a low-res model, so it is exported into model.yft file.
It is strongly recommended to use exactly the same set of materials on L0 and L1 models (hi-res and low-res models), so both model.yft and model_hi.yft will get exactly the same set of materials stored inside.
You can create a palette of polygons hidden deep inside a mesh (where these are not visible) on, say, chassis L0 and chassis L1 meshes, and assign each available material onto one poly of this palette. This will force ZModeler to export model with all of your materials. If you add some new material in scene, add it into palette on L0 and L1.
ZModeler does not validates materials pack when exporting hi-res and low-res models, as these are separated independent routines.
When in-game glass-crash is detected, the game will drop rendering of hi-res geometry associated with respective object (it will stop drawing windscreen from model_hi.yft when you shot windscreen) and will render associated low-res geometry (probably with glass-crash) instead.
Updated: May 2022 (see below)
Vehicle model usually includes a set of glass objects (windscreen, rear windscreen, door windows) that can be crashed with several shots or during impact with other objects. This includes rendering of shatter-glass effect on glass objects and involves making of holes that can expand up to boundaries of the window. The technical background of this process is hidden inside the game and shaders code, and the data required for this logic is stored inside *.yft files. The data is not explicitly bind to the object itself, instead it just defines the boundary limits for the crash glass holes. The image below shows an original windscreen (orange) with original crash boundary data (red) and a modified windscreen (orange: it's moved aside and rotated), while crash data still makes crash holes in this object with original boundaries:
Glass shatter pattern is imported into the scene as object.crash geometry (e.g. "windscreen.crash") and contains a vertex-color painted template for glass shattering. This "crash data" object can be a child of an associated geometry object or a child of an associated collision object, it doesn't matter. Glass shattering requires a collision, so you can't have a glass shatter on an object, say, "extra_2" unless you create an "extra_2 [COL]" collision.
Some objects that don't need a shatter pattern (e.g. a glass-only object that can be smashed completely, or a small glass over headlights or siren lights) can be used with no shatter-glass painted object. To enable shatter effect on these objects, you should add a Crash user-defined option on an associated collision object. In case your collision object is a compound node, make sure to toggle COL state first. Here's an example of user-defined options on windscreen object:
Exporter will create blank crash data for such an object. This object will still trace bullets and will crash and will show crash holes, but you will miss the small boundary of glass on borders of this object when glass is smashed completely.
Note, you do not need to assign "Crash" user-defined option onto a COL object if you have a "some_name.crash" geometry object in scene. Availability of this object will automatically trigger glass shattering logic on a parent geometry/collision.
An ability to draw crash holes is a exclusive feature of vehicle_vehglass and vehicle_vehglass_inner shaders. Other shaders does not seem to support this option.
Since geometry part can use multiple materials (e.g. outer glass and inner glass), you have to explicitly specify the material that will use glass-crash logic. This is also the case when just one material is used. In case of windscreen and door windows, an "outer" glass should be used for glass-crash. To specify the exporter that some material will be used in glass-crash logic, assign "Crash" user-defined property on material too:
Important: game stores and uses glass-crash logic in model.yft file, not in high-resolution model_hi.yft. Thus, you have to ensure your glass-crash material is actually used on a low-res model, so it is exported into model.yft file.
It is strongly recommended to use exactly the same set of materials on L0 and L1 models (hi-res and low-res models), so both model.yft and model_hi.yft will get exactly the same set of materials stored inside.
You can create a palette of polygons hidden deep inside a mesh (where these are not visible) on, say, chassis L0 and chassis L1 meshes, and assign each available material onto one poly of this palette. This will force ZModeler to export model with all of your materials. If you add some new material in scene, add it into palette on L0 and L1.
ZModeler does not validates materials pack when exporting hi-res and low-res models, as these are separated independent routines.
When in-game glass-crash is detected, the game will drop rendering of hi-res geometry associated with respective object (it will stop drawing windscreen from model_hi.yft when you shot windscreen) and will render associated low-res geometry (probably with glass-crash) instead.