A better alternative for RayWorldIntersection

Good afternoon everyone!

I'm coming in with a question after seeing what Star Citizen devs are doing for that project. I'm talking more specifically about this video here
https://www.youtube.com/watch?v=ZMgHhu7 ... JLCaMdeYKz .

As I've mentioned before, I have a little project of my own I'm working on and right now I'm trying to figure out how to 'scan' the area under my vehicle. Right now my vehicle is a sphere, and I'm shooting one ray downwards from its center, but this approach seems very limited. Also, it can't scan an area, it only collides with a surface in one point. Granted, it can give me the distance between its origin and that collision point, but I'm after more than that. I would like to scan an area like these people showed in the above-mentioned video (the Ray Scanning part) and I've tried doing that by manually shooting more rays at certain intervals.. which is insanely demanding computational-wise and quite frankly my PC can't handle it.

So I was wondering if anyone here did something similar and/or has some experience with what I'm trying to accomplish. All I really want is live distance information from a planar area to another (for example from the lower part of my vehicle to the terrain underneath.

Also, a little side question: when I shoot a ray towards the terrain, it gives me two collisions back. I don't have anything between the origin of the ray and the terrain and i still get two collisions. Any insight on this?

Thank you in advance and have a nice day!

Re: A better alternative for RayWorldIntersection

You should look into the Sensor System plugin: http://docs.cryengine.com/pages/viewpag ... d=26217401

It uses an octree implementation so it should incur a much lower performance penalty.

https://www.gamedev.net/articles/progra ... ees-r3529/
Right, on it. Thank you for the suggestion! :)
You could try use a single PWI (PrimitiveWorldIntersection).
You can check the GameSDK Camera Collision code for an example using a sphere.
Is there any trick regarding the way of generating the code of the GameSDK Sample Project? I'm programming in C++ under Microsoft Visual 2017, but when I right-click the project and hit Generate Solution, nothing really happens. I followed the same approach to generating a solution as for any other project, but it didn't work like for the other projects. Or should I find the source code somewhere else?

EDIT: I got back to the Cryengine Source Code and noticed that's where the GameSDK code is, so I'll build that and check out what you pointed me towards. Cheers!

Thank you! :)


P.S. I know this GameSDK Sample Project solution question doesn't belong in this topic, but I think it would be somewhat of an overkill to start a new topic just for this and I also didn't find it under any other topic.

Re: A better alternative for RayWorldIntersection

You could try use a single PWI (PrimitiveWorldIntersection).
You can check the GameSDK Camera Collision code for an example using a sphere.
Hi Flare,
I've followed your suggestion and looked into the Camera Collision code in GameSDK. I've successfully implemented something similar, assigned to a simple sphere entity (custom C++ entity of my own making), however it doesn't seem to be exactly what I'm looking for.
As far as I can tell, the float returned by the PWI function is the distance from my original spherical primitive (that I am 'casting') to the first point of intersection (i.e. the first point where a collision would occur). This is nice and it runs much faster than a Ray with a lot of extra usage, but it still doesn't provide me with distances over the entire sphere area. I've also tried the same with a box primitive (thinking that a sphere collides in a single point with a surface) but even with a box and a flat surface the parea parameter doesn't get populated (it returns a NULL pointer exception when I try accessing it).
Also, I am only guessing that this parameter should store information on the collision area, although I don't have much use for normals and such. But it would be a start learning how it works.

As a side-note, I figured that what I'm looking for might also be dependent on the flags I'm using but I can't be sure yet. Just a thought. Below a short snap of the code I'm using for casting, if helpful.

Code: Select all

primitives::box box; box.center = GetEntity()->GetWorldPos(); box.size = Vec3(1.f, 1.f, 1.f); box.Basis.SetRotationXYZ(GetEntity()->GetWorldAngles()); geom_contact *pContact = 0; float hitDist = gEnv->pPhysicalWorld->PrimitiveWorldIntersection(sphere.type, &sphere, (Vec3(.0f, .0f, -1.f) * 10.f), ent_all, &pContact, 0, rwi_colltype_any | rwi_stop_at_pierceable, 0, 0, 0, 0);
Any thoughts on the matter?


P.S. I'm still looking into the sensors part, haven't made much progress there yet.

Who is online

Users browsing this forum: No registered users and 2 guests