Hello, Using a vehicle Lua script, I am trying to find a world coordinate relative to a vehicle's position and orientation. The goal is that when the car drives around, (assuming the vehicle has not deformed from a collision), the coordinate will appear to always be in the same location relative to the vehicle. (for example: the orange dot is always at the front of the vehicle regardless of rotation) So far, my closest attempt to achieving this has been to find the offset of the desired location of the coordinate relative to the vehicle's position coordinate and then adding that offset to the vehicle's current position each time I wish to find the coordinate. Code: local position = vec3(obj:getPosition()) local forward = vec3(obj:getDirectionVector()) local coordinate = forward * 2 + position This somewhat works, however the resulting coordinate seems to move around relative to the vehicle when the vehicle moves or changes orientation. (for example: the orange dot floats around relative to the front of the vehicle when rotating) I've also attempted to reference the location of the coordinate relative to the center of the vehicle's bounding box. Unfortunately, it seems that only the game engine can access the bounding box center coordinate. I'd appreciate any ideas or suggestions you have to accomplish this.
No idea if it will help but have you tried to find out how it's done in the in-game GPS system? It knows the position and rotation of the vehicle so it could help
Edit #2: I did more experimenting and found that integrating the velocity by delta time (dt parameter of updateGFX) and multiplying the result by 2 and adding this to the position seems to make it work really well. So the code becomes: Code: local position = vec3(obj:getPosition()) + 2 * vec3(obj:getVelocity()) * dt local forward = vec3(obj:getDirectionVector()):normalized() local coordinate = forward * 2 + position Edit: I did a little bit of testing and now I think the problem is with obj:getPosition() not updating quickly enough to keep up with the position of the vehicle. Although with some trickery, you can actually send data between Vehicle Lua and GameEngine Lua, but you will probably still face the same problem as it takes about one frame to send data between each other (e.g. if you call a method in GameEngine Lua from Vehicle Lua that returns data, you will receive that data on the next updateGFX function call) The direction vector is actually not completely normalized so normalizing might help a bit. So your code just becomes: Code: local position = vec3(obj:getPosition()) local forward = vec3(obj:getDirectionVector()):normalized() local coordinate = forward * 2 + position I'm a bit curious what sort of mod you're making if you don't mind me asking since I'm making a mod that adds Automatic Emergency Braking to vehicles that uses this sort of code to offset the origin of the raycast to the front of the vehicle.
Thanks for the link. Interesting, so we both are working on the same project (I don't know if you want to collab or not ) Well here's my prototype demonstration if you want to check it out: And right now I have it also working for detecting vehicles.
now see how would this work if say one of the brakes was damaged. Does it take an accurate reading of braking power into account before calculating when to start braking? also it would be much more realistic if it would start braking at 75% then jump to 100% when it gets close enough, the 75z being 100% of the normal braking power and the 100% being the 25% of emergency braking power that modern cars have
Well my method basically assumes that you have 1g of available deceleration and doesn't factor in the surface grip level or available braking power. But I don't believe real-life AEB systems actually factor in these parameters.
fair enough. Only thing now would just be making the braking more realistic. If you just suddenly applied 100% brakes you would probably cause an accident
I guess I could try implementing two stages of braking (first at 0.5g's and second at 1.0g's) and also make it not brake so close. Also I'm gonna be adding a warning chime or something before the system activates.
Also I'm gonna try and make it work around corners since right now it only works in a straight line which makes it basically brake for any sort of curve in the road :\
Thanks for the tip. I gave your solution a try but seemed to experience the same issue. However, in testing it out I did discover a very solid solution to this problem within the game's "ai" lua file like so: Code: local position = vec3(obj:getFrontPosition()) This seemed to work much better. Great minds think alike
@angelo234 Out of curiosity, how are you thinking of dealing with situations where the vehicle approaches a hill that would otherwise be safe to traverse at speed? The video you posted appears to indicate you are using only two raycast to view the approach velocity of whatever is directly in front of the vehicle. In the hill scenario above, the car would likely interpret that as a wall approaching at a dangerous velocity and slam on the brakes. You may want to consider using more raycasts at various angles to calculate the angle/pitch of the road to determine if it is a continuous surface vs an obstruction.
If you put ray casts on the bottom of the car at an angle you can measure the change of ground angle and them use that data to compensate on the main raycast also there should be a way to override the system once it’s stopped or is stopping, like a triple tap on the gas pedal. Cause what if you are going 80mph on the highway and it just starts stopping to a halt and you can’t shut it off ALSO what if there was a theoretical leaf or stick blocking the sensor? Doesn’t matter in the BeamNG universe but I’m just wondering how you would go about solving that problem
Good to know that local position = vec3(obj:getFrontPosition()) works for you, although it wasn't the solution for my problem, which was actually the time lag between sending the position data to the GameEngine Lua from Vehicle Lua and GameEngine Lua rendering the ray cast lol. Anyways, since the video posted, I have added more raycasts and so it works better now. Although I haven't made mine account for hills, but my raycasting method gives me information about the normal vector of the surface hit. And I can use that with the directional vector of the vehicle to find the angle between the two. And so if they are 90 degrees between each other, then I would just disregard the raycast distance. But if they are 45 degrees or some sort of threshold like that or lower between each other, then that would be considered an obstacle. In the real world, if it starts braking, you can't really do much about it lol. And if there was something blocking the sensor, the system would pretty much just deactivate. So if the sensor was reading zero distance for a while, it would just shut off.
What if you grabbed the positional data using the game engine at the same time as the raycast? Code: local command = [[ local vehicle = be:getObject(]] .. obj:getID() .. [[) local position = vehicle:getPosition() local velocity = vehicle:getVelocity() local p1 = -- insert vector magic here -- local p2 = -- insert vector magic here -- local distance = be:castRay(p1, p2) -- return distance to some form of callback -- ]] obj:queueLuaCommand(command)
True I could just get the vehicle position in the GameEngine Lua... Lol I mean the position data lag wasn't too much of a problem for me so I didn't really worry about it before, but I might as well just do it this way since it's a lot better than some hackish integration method. Since we are working on basically the same project, do you want to work together or should we compete to make the best one?
A lot of semi trucks have this system here in europe, and some truckers don't really like it because it brakes randomly. The system can be disabled by either braking manually or letting off the gas pedal and pressing it again.
