This is my first time posting in ANY forum so pardon me if I don't follow the correct layout.
Currently I am trying to fix a custom car that the windows are currently bulletproof, I have been searching for hours for a solution, I got as far where the window actually cracks but doesnt break. The issue that I have is whenever I add "Crash" to the materials or to the windows[COL] and I export it they reset and is removed by itself.
Issue with User Defined Properties
Re: Issue with User Defined Properties
You should edit window COL object(s) on polygons level and assign "type of surface" on every polygon of every COL object. The "type of surface" is a numeric value in ID slot. To make things simpler, you can use "Options->GTA5" window to have a selection list of surface types. Once you change the type of surface, the behavior in game will change.
Adding the "Crash" user-defined option will add extra data in exported .yft file and quite likely the game will create holes in an object. There are plenty of limitations there. In particular, the holes are created in a L1 geometry object (high Level of Detail) and vertices/polygons count on L1 geometry objects for windows can affect dramatically. Also, the shape of holes (the area that does not disappear) is controlled by extra objects named ".crash" with vertex-painted area.
I advise to import original game model first and examine scene setup and window COL surface types. Then you will get the base idea on how things have to be set up for proper export.
Adding the "Crash" user-defined option will add extra data in exported .yft file and quite likely the game will create holes in an object. There are plenty of limitations there. In particular, the holes are created in a L1 geometry object (high Level of Detail) and vertices/polygons count on L1 geometry objects for windows can affect dramatically. Also, the shape of holes (the area that does not disappear) is controlled by extra objects named ".crash" with vertex-painted area.
I advise to import original game model first and examine scene setup and window COL surface types. Then you will get the base idea on how things have to be set up for proper export.
-
- Posts: 2
- Joined: Mon Jun 17, 2024 5:41 am
Re: Issue with User Defined Properties
This worked thanks! BUT I cant recreate for the life of me how to crack the window, with your help the bullets go through the window but the window itself does not crack/break, can you help me with this sorry.
Re: Issue with User Defined Properties
grab the window object and its collision from original vehicle first. just to make tests on your own vehicle; if it does work in game, use your own geometry object and game's original collision model -> test again.
there are the following conditions for an window to crack in game:
1. L1 geometry object has not that much vertices/polygons (check original model and you can double or even 4x the original vertices/poly count safely)
2. a vehicle_vehglass shader should be used on material (and vehicle_vehglass_inner for the interior-facing polygons).
3. a "crash" user-defined option is assigned on material (vehicle_vehglass if I'm not mistaken)
4A. a "crash" user-defined option is assigned on an associated COL object.
4B. an object ".crash" is added as a child of window COL object. The crash object should be a grid surface with rows/columns limit of ~4cm per row/column width. Vertices on .crash object should be painted white to mask the area of glass to retain and painted black to mask the area of glass to crash. Shades of grey from black to white are the area where game will apply some random crash-or-retain logic when shattering the glass.
5. The geometry object should have UV#2 channel mapped (usually onto "glass_dirt" texture). Availability of UV#2 mapping is important, as it is also used to map a shatter-glass texture onto the window. You can add user-defined option "UV" on a COL object to apply custom UV scale factor for shatter-glass texture (e.g. if some window has visually different size of shatter-glass pattern in game you can fine-tune it with UV user-defined option).
6. The polygon surface-type on COL objects should be set to a value of "vehicle glass" group.
7. The COL object for the window should have quite simple shape. Avoid using complex geometry topology, game can reject this collision and no impact will happen.
Mind to test all collisions in game for impact with different types of objects: vehicles, ped/player, static scene elements (walls, buildings) and dynamic scene elements (light poles, trash bins etc.)
there are the following conditions for an window to crack in game:
1. L1 geometry object has not that much vertices/polygons (check original model and you can double or even 4x the original vertices/poly count safely)
2. a vehicle_vehglass shader should be used on material (and vehicle_vehglass_inner for the interior-facing polygons).
3. a "crash" user-defined option is assigned on material (vehicle_vehglass if I'm not mistaken)
4A. a "crash" user-defined option is assigned on an associated COL object.
4B. an object ".crash" is added as a child of window COL object. The crash object should be a grid surface with rows/columns limit of ~4cm per row/column width. Vertices on .crash object should be painted white to mask the area of glass to retain and painted black to mask the area of glass to crash. Shades of grey from black to white are the area where game will apply some random crash-or-retain logic when shattering the glass.
5. The geometry object should have UV#2 channel mapped (usually onto "glass_dirt" texture). Availability of UV#2 mapping is important, as it is also used to map a shatter-glass texture onto the window. You can add user-defined option "UV" on a COL object to apply custom UV scale factor for shatter-glass texture (e.g. if some window has visually different size of shatter-glass pattern in game you can fine-tune it with UV user-defined option).
6. The polygon surface-type on COL objects should be set to a value of "vehicle glass" group.
7. The COL object for the window should have quite simple shape. Avoid using complex geometry topology, game can reject this collision and no impact will happen.
Mind to test all collisions in game for impact with different types of objects: vehicles, ped/player, static scene elements (walls, buildings) and dynamic scene elements (light poles, trash bins etc.)
-
- Posts: 1
- Joined: Thu Nov 07, 2024 3:30 pm
Re: Issue with User Defined Properties
What you shared is very useful, each step is explained in detail and specifically about technical requirements, setting attributes and how to apply,.... Thank you