[Guide] GTA V: Glass crash data (*.cwgv)

GTA:V Modding with ZModeler3 discussion.

Moderator: madga182

[Guide] GTA V: Glass crash data (*.cwgv)

Postby Oleg » Sat Aug 08, 2015 10:07 pm

GTA V: Glass crash data guide.

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 cracked 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 game and shader 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:

11_cwgv_windscreen.jpg


This leads us to conclusion that glass crash glass data has no relation to the actual object it will be used with. Since layout of crash data was not yet decoded, this gave us a chance to reuse original glass crash data on your mods. When you import a vehicle, the filter will create a set of *.cwgv files for the objects that used glass crash data (e.g. windscreen.cwgv, windscreen_r.cwgv, window_lf.cwgv, window_rr.cwgv etc.) These files are a glass crash boundary data for associated objects and exporter can use them to reconstruct crash data on exported files: you just need to copy them into an export folder. Even more, if your vehicle has a slightly different layout of windows, you can search among original vehicles for the most suitable layout of each window: you can take windscreen.cwgv from one original vehicle, and windscreen_r.cwgv from a different vehicle, it's no problem on that: just find the one that has about the same position/size/angle of the window as the one you have on your model.

When no glass crash data files avail on export for an object, the 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 the borders of an object when glass is smashed completely. This does not look good, so pay some time to locate a suitable *.cwgv file for proper export.

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.

In order to make the glass object able to crash, you should assign Crash user-defined property onto a collision volume. 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:

12_windscreen_crash_udo.jpg


Adding "Crash" property on collision object will enable glass-crash logic on associated geometry part. 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 that material will be used in glass-crash logic, assign "Crash" user-defined property on material too:

13_windscreen_crash_material_property.jpg


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.

If you don't have a glass-crash CWGV data for your object, you can make it as 3D model. Say, cut out the exterior part of windscreen glass and attach it to chassis. The inner part of windscreen glass can be left used as "windscreen" and should use a material with "Crash" property. Do the same on L1 mesh too. Thus, the game will not crash 'glass' associated with chassis (and that use a material with no "Crash" property) and will smash only glass area left on windscreen object (and that use material with "Crash" property). You suffer poly count slightly and wireframe mesh accuracy, but you get an explicitly defined window boundary that will not crash in game.
User avatar
Oleg
Site Admin
 
Posts: 7631
Joined: Fri Feb 06, 2004 3:54 am

Return to Grand Theft Auto V

Who is online

Users browsing this forum: No registered users and 2 guests