Add texture hit info to processLineOfSight

[Pirulax]

Fixes #645

This PR aims to add texture related info to hits [Such as hit texture UV, and name], and a more precise "clump hit" position [that is the intersection point of the clump and the line segment]
It uses the hit entity's clump to do so [As it contains all the necessary UV information]

[CrosRoad95]

Take an account that often collision is not the same as model ( as documentation note ) what mean that if i raycast i can get texture of for example collisionless leaves.

What if for example there is no collision hit, but raycast went through some collisionless mesh?
and does it work for vehicles, peds?

[tederis]

It would be nice to get normals as well. Because a collision does not always match the actual surface of a mesh and normals can point in a completely different direction. Sometimes it's important to have "real" normals.

[CrosRoad95]

Dies it work for rotated objects? And maybe its better to make standalone function to raycast mesh rather bloat process line of sight?

[Pirulax]

Yeah, perhaps adding a new function would make more sense, to give the scripter more freedom [And room to optimize], in case they want to do a raycasting against a given entity.
What would you suggest as the name?

The return arguments would be:

• hit pos x, y, z
• hit normal x, y, z
• texture U, V
• texture name
• atomic index
• geometry index
• triangle index

Last three I'm not sure about, but one might find them useful, so might as well add it.

[Pirulax]

Take an account that often collision is not the same as model ( as documentation note ) what mean that if i raycast i can get texture of for example collisionless leaves.

What if for example there is no collision hit, but raycast went through some collisionless mesh? and does it work for vehicles, peds?

Good point.
Sadly, a simple raycast against a given entity is all I need.
This can later be extended as necessary.

Dies it work for rotated objects? And maybe its better to make standalone function to raycast mesh rather bloat process line of sight?

Yes it does work for rotated objects too, as it uses the entity's inverse matrix to transform world position points into object [model] space.

[CrosRoad95]

atomic index
geometry index

this is i'm working on, to get dff atomics, geometry ect. now if you add index instead of userdata what i'm planning, it may cause compatibility problem on my or your side.

I think it should be separete function, raycast against atomic/clump(dff)

[Pirulax]

raycast agianst a clump
are you adding clump as a userdata too?

[tederis]

The problem is now you are doing the work twice: raycast against a collision mesh and DFF geometry after it. There is a lot of unnecessary heavy calculations. I think you should get rid of a standart collision processing part and write a simple ray casting procedure against AABBs. It's not as difficult as it might seem, because this part of game is already reversed and most of the code can be reused.

[Pirulax]

I guess with enough parallelization the mesh raycast will be ultimately faster than the mesh one
Thus, in the end we could actually improve the performance of PLOS [and isLineOfSightClear too]
But, since all this is in the game_sa project I don't have easy access to any threading facilities [AsyncScheduler for example].
The best way to deal with this would be OpenMP, but we don't have it enabled [though, I guess we could enable it?]
Anyways, I find it out-of-scope for now, as for my needs this is enough.

And yeah, writing a simple line/triangle collision test function is quite easy at this point [and I do have experience with it too]

As for the function to raycast against a specific element ( @CrosRoad95 ) instead of adding it to PLOS.
If this wouldn't be available in PLOS you couldn't process native GTA world enetities [ones without an MTA representation].
So, I think, instead of moving it, we could make a separate function too + keep in in PLOS

Also, I ran into a problem.
Kam's scripts seem to export incorrectly, as they don't set the triangle material ID [in the geometry], but rather just use the binmesh extension [plugin] to store it. This is an issue, because the data stored in RpMesh is optimized for rendering, not for collision detection.
This causes the function to return incorrect texture names. UV values are fine though.

[Pirulax]

Okay, so it's kinda working.
Regular objects work just fine, and vehicles do somewhat too.
The issue is that vehicle components [such as doors, the bonnet, etc] seem to not exist? [Demo]
Notice how the ray doesn't seem to hit the door at all, but instead something else behind it.
I'm not sure if it's because that atomic [the door] isn't part of the vehicles clump or something else.

[tederis]

Okay, so it's kinda working. Regular objects work just fine, and vehicles do somewhat too. The issue is that vehicle components [such as doors, the bonnet, etc] seem to not exist? [Demo] Notice how the ray doesn't seem to hit the door at all, but instead something else behind it. I'm not sure if it's because that atomic [the door] isn't part of the vehicles clump or something else.

Maybe there is something that I overlooked, but I can't find a transformation of atomics in your code. It seems like all parts(except the chassis) are in the zero position(or in the vehicle's origin). This may very well be the cause of this erroneous behavior.

[Pirulax]

Yeah, that would explain the issue, since all frames can have a different transform.
I will look into it, thank you.
Only that I'm not sure how the transformations are supposed to be applied? Do they "stack" [like bone transformations], or applying the frame transform [LTM] to the position is enough?

Okay, so, the transforms were missing indeed, but the situation is still pretty much the same.
Issue is that I'm unsure how doors [and other components] are rendered.
Pretty sure each one is just a frame in the clump [and I'm also pretty sure it's the _dummy frames], but even when a dummy frame is hit, the texture info is completely off [and when hovering the mouse over a door, noit the whole door has a collision]...

[Pirulax]

@tederis you're a genius dude, ly
https://www.youtube.com/watch?v=M5FLVLkWcOo

[botder]

Maybe use variables instead? I don't expect anyone to change this code in the foreseeable time, but this seems odd.

[Pirulax]

For the number of args?

[tederis]

Despite the fact that it works the efficiency of an algorithm is terrible. Given that it's expected to be used with vehicles, it's important to notice that those vehicles are often replaced with custom ones which have much more triangles. It definetely requires a parallelization and SIMD optimizations of operations with matrices and vectors (I think SIMD is even more important than a parallelization).

[Pirulax]

Yeah I do agree that the algorithm's performance isn't really all that good.
I could parallelize it, but the facilities [Thread pool, etc] necessary to do so aren't present in the game_sa project .
SIMD would be great though, but I do expect the compiler to use some SIMD by itself [Though, actually enabling it to use AVX would be great, as right now it only uses SSE... And this is why using a libary that does all this SIMD stuff with run-time dispatch would be great)

[tederis]

Yeah I do agree that the algorithm's performance isn't really all that good. I could parallelize it, but the facilities [Thread pool, etc] necessary to do so aren't present in the game_sa project . SIMD would be great though, but I do expect the compiler to use some SIMD by itself [Though, actually enabling it to use AVX would be great, as right now it only uses SSE... And this is why using a libary that does all this SIMD stuff with run-time dispatch would be great)

Unfortunately, the quality of vectorization is insufficient in today's compilers(even with -O3 and enabled vectorization). You can easily see it by the inspection of an assembly. That's why you can find SIMD intrinsics in every math library(including game engine math libs): Eigen, glm, numpy(scipy), UE linear algebra, CryEngine math, and many others.

[Pirulax]

Yes I know it's not perfect, but it's better than plain old x87 arithmetic.

[tederis]

Yes I know it's not perfect, but it's better than plain old x87 arithmetic.

x87 for what? SSE for example has nothing to do with x87. SSE intrinsics (see Intel® Intrinsics Guide) are necessary for any math library(including MTA's one). It's not possible to write an efficient and performant math without it.

[botder]

How heavy is the performance hit?

[Pirulax]

There's no performance hit to PLOS unless this feature is enabled, otherwise it depends on the complexity of the mesh. [Obviously, the more complex, the slower it is].
As you might expect, since we don't utilize SIMD, it's not fast by any means, and it can be improved, but I'd argue we can do that later too [I don't expect this feature to be used very often, and devs already know that PLOS is slow]

[Pirulax]

Wiki page added