Quantcast

Jump to content

» «
Photo

Help with collision polygon format (Bounds/YBN)

Best Answer Chipsman, 14 March 2017 - 06:39 PM

The situation with spheres is very strange as for me, I don't do anything special in openIV and it renders them as they should be rendered. Judging by your screenshots it looks like the pivot point of your sphere is not located in the center of it (looks like it is somewhere at AABB.Max or so)

 

As I remember I also had problems with boxes rotation in due time, and then I decided just to generate box in world coordinates at once. Primitive algorithm:

1) calculate the center of the top diagonal (c1)

2) calculate the center of the bottom diagonal (c2)

3) calculate orientation vector c1-c2=c 

4) translate two top points along the vector -c

5) translate two bottom points along the vector +c

6) that's all, we have 4 vertices of the top base and 4 vertices of the bottom base, now we can generate faces

Go to the full post


8 replies to this topic
dexyfex
  • dexyfex

    Player Hater

  • Members
  • Joined: 04 Mar 2017
  • None

#1

Posted 14 March 2017 - 12:36 PM

Hi everyone,

 

I've been working on adding collision mesh display in the CodeWalker app:

unknown.png

 

Unfortunately as you can see, triangles are rendering fine, but I'm having some trouble with the boxes, spheres, cylinders and capsules. Basically spheres are appearing in the wrong places, and most boxes are the wrong orientation and/or size (I think cylinders and capsules will have the same issue but those are not being rendered yet).

 

So does anyone here have any knowledge of the format of these polygons specified in the collision bounds data? (In YBN/WBN files and drawables)

The most detailed structure info I've found about these polygons is at:
https://github.com/Z...clude/phBound.h (thanks FiveM guys!)
- see the struct phBoundPoly in that file (I'll refer to that from here on). In the sphere, capsule and box union structs, a type value is specified, which the file suggests is 1 for sphere, 2 for capsule, and 3 for box. Which is partly correct, but I've found it's just the lowest 3 bits in that value that defines the type. The rest of the bits in that type value is unknown to me, and seems to maybe contain the data for offsetting the spheres, and orienting the boxes. Unfortunately it's not obvious how though...

As far as I can tell, OpenIV can draw these bounds correctly, so obviously someone has solved this problem already.
Can anyone help?

Thanks!


Chipsman
  • Chipsman

    OpenIV Team

  • Members
  • Joined: 18 Apr 2008
  • None
  • Best Tool 2016 [OpenIV]
    Major Contribution Award [Mods]

#2

Posted 14 March 2017 - 02:10 PM

struct
{
    uint16_t type; // 1
    uint16_t index;

    float radius;
} sphere;

index - vertex index which is the center of the sphere
radius - radius of the sphere
 

struct
{
    uint16_t type; // 2
    uint16_t index;

    float radius;
    int16_t indexB;
} capsule;

index - vertex index which is the center of the top hemisphere of the capsule
indexB - vertex index which is the center of the bottom hemisphere of the capsule
radius - the radius of the hemisphere 
 
Cylinder has the same structure as a capsule: index and indexB - vertex indices which are the centers of the bases of the cylinder, radius - base radius
 

struct
{
    uint32_t type; // 3

    int16_t indices[4];
} box;

indices - vertex indices which form two diagonals of the box bases

00TA6EU.png


p.s.: I don't remember exactly vertices order, so you should check them anyway


dexyfex
  • dexyfex

    Player Hater

  • Members
  • Joined: 04 Mar 2017
  • None

#3

Posted 14 March 2017 - 04:48 PM

Thanks Chipsman,

 

I had already assumed most of what you mentioned from that code... However it seems that there is maybe also something else to it.

Here's a better spheres example:
unknown.png

 

The triangle vertices are lining up (almost) perfectly with the rendered models (see the tree trunks), but the spheres here seem to be in the wrong location. I triple checked the spheres are being drawn with their centers at the location specified by the poly's vertex. But obviously they are in the wrong position... 


As for boxes, I had noticed that the 4 vertices seemed to specify the opposite diagonal corners, as shown in your pic. But the vertex order does not seem to be consistent. So this means that some boxes render fine but others are all messed up. (At the moment I calculate a quaternion from these vertices to orient my boxes, along with the centroid and the size vectors)

 

Most of this building is defined as boxes, and most of the boxes in it seem to be fine, but obviously my calculation is going wrong.
unknown.png
 

 

For reference, here's the calculation I'm using to get the box size and orientation:
 

uint boxType = BitConverter.ToUInt32(bytes, 0);
short boxIndex1 = BitConverter.ToInt16(bytes, 4);
short boxIndex2 = BitConverter.ToInt16(bytes, 6);
short boxIndex3 = BitConverter.ToInt16(bytes, 8);
short boxIndex4 = BitConverter.ToInt16(bytes, 10);
int i1 = boxIndex1 & 0x7FFF;//this mask seems to be required...
int i2 = boxIndex2 & 0x7FFF;
int i3 = boxIndex3 & 0x7FFF;
int i4 = boxIndex4 & 0x7FFF;
Vector3 p1 = verts[i1];
Vector3 p2 = verts[i2];
Vector3 p3 = verts[i3];
Vector3 p4 = verts[i4];
Vector3 ax1 = Vector3.Normalize(Vector3.Cross(p2 - p1, p4 - p3));
Vector3 ax2 = Vector3.Normalize(Vector3.Cross(p3 - p1, p4 - p2));
Vector3 ax3 = Vector3.Normalize(Vector3.Cross(p4 - p1, p2 - p3));
float s1 = Math.Abs(Vector3.Dot(ax1, p4 - p1));
float s2 = Math.Abs(Vector3.Dot(ax2, p4 - p1));
float s3 = Math.Abs(Vector3.Dot(ax3, p2 - p1));
Vector3 scale = new Vector3(s1, s2, s3);
Quaternion orientation = Quaternion.LookAtLH(Vector3.Zero, ax3, ax2);
Vector3 center = (p1 + p2 + p3 + p4) * 0.25f;

I'm just not sure why it would end up with weird quaternions here... I think I wrote it such that as long as they are all diagonally opposite corners it should just work, but there could be some other issue that I'm not seeing. The main thing I did notice though is that the 3 axes I computed don't always seem to be orthogonal, but obviously they should be, if the 4 corners were all corners of a box...


Chipsman
  • Chipsman

    OpenIV Team

  • Members
  • Joined: 18 Apr 2008
  • None
  • Best Tool 2016 [OpenIV]
    Major Contribution Award [Mods]

#4

Posted 14 March 2017 - 06:39 PM   Best Answer Edited by Chipsman, 14 March 2017 - 06:43 PM.

The situation with spheres is very strange as for me, I don't do anything special in openIV and it renders them as they should be rendered. Judging by your screenshots it looks like the pivot point of your sphere is not located in the center of it (looks like it is somewhere at AABB.Max or so)

 

As I remember I also had problems with boxes rotation in due time, and then I decided just to generate box in world coordinates at once. Primitive algorithm:

1) calculate the center of the top diagonal (c1)

2) calculate the center of the bottom diagonal (c2)

3) calculate orientation vector c1-c2=c 

4) translate two top points along the vector -c

5) translate two bottom points along the vector +c

6) that's all, we have 4 vertices of the top base and 4 vertices of the bottom base, now we can generate faces

  • dexyfex likes this

dexyfex
  • dexyfex

    Player Hater

  • Members
  • Joined: 04 Mar 2017
  • None

#5

Posted 15 March 2017 - 09:33 AM

Thanks again...

I found out eventually the problem with the spheres.. It was a silly mistake, I was using the bounds base class position vector rather than the geometry subclass position vector. Seems strange that there would be two (slightly) different position vectors. Perhaps something to do with the BVH, or bounding boxes..?

I also managed to get the boxes drawing correctly, by using an algorithm very similar to what you described. Your approach worked well to generate individual triangles to make up the boxes, but I wanted to use an instanced rendering approach, so I needed a more compact form to represent the box. So using your approach I calculated the 3 vertices adjacent to vertex 1 (ie connected by an edge), which then I use like a 3x3 matrix to finally position the vertices to be rendered (rather than using a quaternion).

unknown.png
(Screenshot of correct collision boxes)

I still need to implement the cylinders and capsules but I think they should be fairly simple in comparison to the boxes.


Chipsman
  • Chipsman

    OpenIV Team

  • Members
  • Joined: 18 Apr 2008
  • None
  • Best Tool 2016 [OpenIV]
    Major Contribution Award [Mods]

#6

Posted 15 March 2017 - 10:10 AM

I was using the bounds base class position vector rather than the geometry subclass position vector. Seems strange that there would be two (slightly) different position vectors. Perhaps something to do with the BVH, or bounding boxes..?


As I understand, the first one is just the center of AABB, the second one - pivot point of the geometry, in most cases they are the same but can be different.

dexyfex
  • dexyfex

    Player Hater

  • Members
  • Joined: 04 Mar 2017
  • None

#7

Posted 16 March 2017 - 06:09 AM

It just seems a bit odd since I thought the vertex data would have to always be inside the bounding box. I guess R* have their reasons though! (perhaps the vertex data does not cover the full 16-bit range).

Still on-topic I think - I've been searching for a while to find a complete list of all the material IDs and names (and colours) to use.. Do you know if there is one available anywhere? Also does OpenIV use colours from game data or are they just chosen for the material name? I guess it would be nice to have the same colours in my app.
The closest I've found to a list of names corresponding to the IDs has been in the NY to V converter at: (it's not complete) 
https://github.com/Z...Bound_ny_five.h
 


_CP_
  • _CP_

    Boss

  • Feroci
  • Joined: 27 Dec 2007
  • Poland
  • Most Helpful Modding 2016 [Runner-up]
    Best Vehicle 2016 [IVPack]
    Best Map 2013 "ViceCityStories PC Edition"

#8

Posted 16 March 2017 - 10:39 AM

It's in materials.dat
update\update.rpf\common\data\materials\materials.dat

  • dexyfex likes this

dexyfex
  • dexyfex

    Player Hater

  • Members
  • Joined: 04 Mar 2017
  • None

#9

Posted 16 March 2017 - 02:08 PM

Ah thanks! I guess I should have found that one already :)
A bit unfortunate in this case that it doesn't define a colour for the materials though...





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users