[Abagail]

https://gist.github.com/raw/4543512/...modelsizes.inc

There are three functions in this include:

pawn Код:

*   forward Float:GetColSphereRadius(objectmodel);

This gets the radius of the collision spheres for all the GTA objects used in SA (including the SA:MP objects); except skins, vehicles, and weapons. The collision sphere entirely encompases the object, so is a good estimator of the size of the object (for example to set the view distance accordingly). Returns 0.0 on invalid models.

pawn Код:

* forward GetColSphereOffset(objectmodel, &Float:x, &Float:y, &Float:z);

This gets the offsets of the collision sphere for all objects. This information is kept in a separate array as it is generally less useful than the sphere radius. It indicates where the centre of the collision sphere is relative to the centre of the object, a position set to minimise the size of the sphere relative to the object. Note that you can't accurately calculate the exact center of the collision sphere without the quaternion rotation of the object, that is why this is a separate "stock" array - so it isn't included in the compiled code if not used.

pawn Код:

forward GetColCount();

Gets the total number of models for which collision data is stored:

Usage is VERY simple. For model IDs up to 19901, simply use that number as an index in to the data, any other IDs don't exist (but return 0.0):

pawn Код:

for (new i = 0; i != GetColCount(); ++i)
{
    printf("%f", GetColSphereRadius(i));
    new Float:x, Float:y, Float:z;
    GetColSphereOffset(i, x, y, z);
    printf("%f %f %f", x, y, z);
}

Big thanks to Kalcor for dumping the raw data for this out of the game.

Note that due to the sheer volume of data here, the files sets:

Code:
#pragma compress 0

To avoid the warning that it gets set anyway.

Quote:

Originally Posted by Babul yeah, thats what we need: being able to feed the streamer with procedural created stream distances - cool, when it works - thanks

Quote:

@[MM]18240[FMB]: no, that little include lets you get any objects "size", its collision radius sphere. so if you have an object like the little ramp 1665, you can consider its radius returned as 6.0. the "40 meter road" object should return a value close to 21.0? if you take each objects size into account when reading maps, you can work with the object modelid DIRECTLY in order to tell the streamer wether to stream it from a far distance (a 40 meter long road equals a 20.0 meter radius. multiply that 20.0 by 25, you get 500.0 meters stream/draw distance). taking a little object like a chair, table, or anything with a smaller radius like 4.0 meters, multplied by 25 again, results in only 100 meters to stream. whats the trick? that "bias" value of 25, set up PROPERLY, will result in a dynamic streaming process, therefore the "important" objects for racing (streets) gets streamed from far away, while "redundant" objects gets streamed locally, in a small radius only. benefit: HUGE maps visible from a wide distance due to ignoring less important objects! addition: it can reduce networth bandwidth aswell. mmmkay, was that clear? heh

__________________

Originally by ******. (I have directly restored the thread from his previous thread, however some of the BBCode may be a little messed up).

Download here:
https://gist.githubusercontent.com/Y...modelsizes.inc

or incase that for some reason gets removed
https://evanabagail.net/files/modelsizes.inc

[iSkyline]

Wow, this is really nice!

[Crayder]

Question, will you be updating this Abagail?

[Abagail]

I am willing to update the include as needed. If anyone has any bugs or suggestions I'd be glad to look into them. Additionally, I have created a proper github page for the include here:
https://github.com/Abagail/Y_Modelsizes/

As for the new objects, if anyone wants to assist me in getting their sizes let me know and I will try to update the include as soon as possible.

[Crayder]

As for the new objects, I think Pottus has got it covered and you can easily update this frequently using ColAndreas. I asked him on the release development about getting the size since he already loads all collision files anyways, and he has replied.

Quote:

Originally Posted by Pottus It should be possible in fact there is likely a way to do this with Bullet internally. I looked into it and there is this member function in the btCollisionShape() class. Код: void btCollisionShape::getBoundingSphere ( btVector3 & center, btScalar & radius ) const I'm pretty sure that has to be it I will test when I get back from the cottage this weekend.

[Abagail]

It isn't very directly related, however I have added a function allowing you to check if an object is a custom SA:MP one or not. If the include can't find the approriate version then 0 is returned for the version func - same as the IsSAMPObject function.

The function is pretty simple:

pawn Код:

IsSAMPObject(modelid);

GetSAMPObjectVersion(modelid);

You can use the following defines for the version func:

pawn Код:

VERSION_3C
VERSION_3C_R5
VERSION_037_RC1
VERSION_037_RC2
VERSION_037_RC3
VERSION_037_RC4

If there are any SA:MP objects / ranges I've missed, please let me know.

[Pottus]

I was testing bullet physics on bounding spheres and discovered that it is returning values less than what it shown in the model sizes include I am going to validate
the sizes and report back to see which one is correct. I'm putting my money on ColAndreas but I could be wrong

@Edit - It would seem ColAndreas has got it correct the model sizes are all incorrectly over sized in the include!

This is object 3337 I am using a bounding size of 2.68 the model size include shows it is 3.0 which gives a over sized bounding sphere of 0.3 meters which is indeed
very inaccurate.

[Crayder]

That's pretty bad ass. I was going to ask on the ColAndreas thread if it would also have a sphere offset function, but nvm, question answered...

[Pottus]

@Edit okay looks like ColAndreas is bang on with calculating model sizes! It really shows that the model size include is inaccurate. So what I need to do to fix is get a list of collision models and any corresponding LOD objects then retrieve all the data through a server that has ColAndreas loaded.

Код:

[23:49:21] Bounding Sphere ColAndreas: 2.679598
[23:49:21] Bounding Sphere Model Sizes: 3.001899
[23:49:21] ColSphere Offset ColAndreas: 0.026070, 0.001708, 1.584063
[23:49:21] ColSphere Offset Model Sizes: 0.027227, 0.001707, 1.582939

[vermaritt]

To Pottus, why are you using bullet for getting the radius/offset of bounding sphere, you can just extract them from the .col files. I might be wrong but this can be done, most probably.

[Mutha_X]

Quote:

Originally Posted by Pottus I was testing bullet physics on bounding spheres and discovered that it is returning values less than what it shown in the model sizes include I am going to validate the sizes and report back to see which one is correct. I'm putting my money on ColAndreas but I could be wrong @Edit - It would seem ColAndreas has got it correct the model sizes are all incorrectly over sized in the include! This is object 3337 I am using a bounding size of 2.68 the model size include shows it is 3.0 which gives a over sized bounding sphere of 0.3 meters which is indeed very inaccurate.

That inaccuracy may be caused with method that used to get bounding radius, for example getting distance between center of bounding sphere and point on the sphere can be different to maximum distance between position of object and one of its verticles.
If you use first method you will use correction (offset) position of the center due object rotation and non-zero BV center position. You know.

[Pottus]

Quote:

Originally Posted by vermaritt To Pottus, why are you using bullet for getting the radius/offset of bounding sphere, you can just extract them from the .col files. I might be wrong but this can be done, most probably.

You are correct you can use that data but it seems that Rockstar used oversized bounding spheres they are not accurate at all.

[Baltazar]

How to extract bounding spheres from .col files? :O I definitely need to find out the method

[Crayder]

Quote:

Originally Posted by Baltazar How to extract bounding spheres from .col files? :O I definitely need to find out the method

You can't get correct sizes from the col files, as pottus said above:

Quote:

Originally Posted by Pottus You are correct you can use that data but it seems that Rockstar used oversized bounding spheres they are not accurate at all.

However, bullet physics (library used in ColAndreas) has it's own way of determining a more correct size for each object model.

[Abagail]

I will try to make a version that uses ColAndreas to return the data; however I must say I haven't really experimented with ColAndreas yet so I don't know how it'll work out.

[Baltazar]

Quote:

Originally Posted by Crayder You can't get correct sizes from the col files, as pottus said above:

Yes, the radiuses are oversized and that... but still want to be able to extract it how to achieve it?

[Crayder]

Код:

stock Float:CA_GetColSphereRadius(objectmodel)
{
	new Float:tmp, rad;
	if(0 <= objectmodel <= 19999)
	{
		CA_GetModelBoundingSphere(objectmodel, tmp, tmp, tmp, rad);
		return rad;
	}
	return 0.0;
}

stock CA_GetColSphereOffset(objectmodel, &Float:x, &Float:y, &Float:z)
{
	new Float:tmp;
	if(0 <= objectmodel <= 19999)
	{
		CA_GetModelBoundingSphere(objectmodel, x, y, z, tmp);
		return 1;
	}
	return 0;
}

Simple as that, but it's kinda pointless since the CA function alone is fine.

[Baltazar]

I mean how do I extract all this from .col files!

[Crayder]

It was obviously humor, but still factual. He is the one who extracted the data before.