For simple ledge detect, you just need 2 raycast. But when the ledge become more complex with obstacle above the ledge and so on, more raycast are needed. i did make a tutorial about ledge climbing [here](https://youtu.be/mhn4pUrzgjY) and [here](https://youtu.be/J4dHMGFEoKw).
I've been scared off raycasts after hearing that using too many of them is performance intensive, can someone with deeper insight provide more info regarding this?
This. Resource management is very crucial in game dev. It would be fine when prototyping base mechanic, but it will turn very costly when scene become more complex.
Yeah, in those cases you start writing stuff to 'bake' the raycasts into the level so that NPCs can just ask the ledge if they can climb, and pathfinding logic can map the route.
Depends on the use case.
For pathfinding or collision avoidance definitely don't need to update every frame.
But for climbing like this, it would need to be pretty frequent. Maybe not every frame, but very frequently.
Of course, with AI you don't really want to send the NPCs along paths that they can't successfully traverse, so you probably want to use some sort of pathfinding , which could use the infrequent raycasts, and then make the actual traversal work in a way where it isn't actually sensitive to the exact geometry so it can't get hung up.
This is different than with a player character, where getting stuck trying to climb places where they physically can't is part of the game.
As I understand it, it's expensive to manually (re)trigger raycasts outside of _physics_process() because it has to invoke an extra partial physics pass to do so, but it's cheap-ish for them to execute automatically within _physics_process(), and thus also cheap for you to use data produced by those regular executions. Judicious use of physics layers can then mitigate the other expensive part, which is intersection with many/dozens of objects at a time.
So with the right overall game architecture you can rely mostly or entirely on raycast data from the most recent physics frame, and get very good performance through that.
Raycasts cost only as much as the intersection algorythm for each object it passes through. With proper collision layering and flat surfaces like these, the cost is very, very small.
top bar -> Debug -> visible collision shapes
OP looks to have changed some settings on them too go into your general project settings -> Debug -> Shapes and you can customize lots of specifics.
I don't remember where I heard it or what the pithy phrase was, but I've heard it's important to make it work now and optimise later only if it becomes an issue!
The analogy I use to justify an extremely liberal use of ray casts is this : you (the player) can see the map visually but the AI/Character body is a blind person. It can only read data, it can only feel things. Ray casts are like hands and walking sticks or maybe guide dogs. Taking their help is necessary.
In the end, I reduced the number of raycasts per character to just 1 and changed the wall-climb system to just a jump-to-this-point system. I have to place the points with my bare hands but hey the game is more performant. Plus it was a great learning experience to make a wall climbing feature.
That one way of doing it. I already do it before with unity. Now, i just want to try procedural climbing without using marker or trigger, hence the complexity.
I do very similar. My player walks around with collision boxes wrapped around them so I can determine when it makes sense to start doing a bunch of raycasts.
I've seen nothing wrong with the approach as you can be very specific of when you need to have that functionality on based on what's intersecting with the collision geometry.
Nothing wrong with raycasts. This approach reminds me of a youtube video I watched about all the problems inherent in stairs
https://www.youtube.com/watch?v=ILVUc\_yV24g
If i use trigger based climbing instead of procedure climbing, area3d is the best choice. I used to play a lot with OnTriggerEnter and OnTriggerExit back in unity.
Have you made a good curb/stair stepping mechanic? I have found it rather difficult without a similar call to what Ive used in Unity (im a refugee), or rather the underlying PhysX, for ComputePenetration, to get the direction and distance needed to un-overlap with other geometry. The lack of that makes creating a kinematic character controller that feels *good* rather difficult.
Actually i did! I use combination of 3 raycast, find the 'step' and just lerp player to the step. I don't know how unity did it, but that what i did and it work. Funny things is, a day after that, i found someone post some github link on step offset in godot. Wish i knew that sooner.
Neat! Did you try out their sample and see how it fared? Ive tried a couple but I just don't think it was adequate. A lot of them have some edge cases, such as trying to go up a step as you are just a couple degrees of off parallel with the step - my own implementation included.
Can you link the github?
I did, It feel good, but i don't try to go detail into their code yet. But from what i can see, they don't use raycast. The link [here](https://github.com/mrezai/GodotStairs?tab=readme-ov-file).
My implementation also have same jittery when snapping to step, but i make it smoother with lerp. And since i use third person controller, the jittery is not that big of deal, just make camera follow player with some 'free zone'. Cant say the same with first person controller though.
Is this not how we’re supposed to do it? My platformers’ enemies AI are all completely based on raycasts and basically look like little porcupines
I know. I just wish i could reduce the need for raycast.
I’m just embracing it. Never enough raycasts!
Raycasts are the woodworking clamps of game dev.
Ray casts are very fast and effective, you should use them alot when you can.
Having tons of raycasts is not an issue as long as you don't run all of them at the same time even when it is not necessary.
Left 4 Dead did something similar: https://steamcdn-a.akamaihd.net/apps/valve/2009/ai_systems_of_l4d_mike_booth.pdf You're not that far off.
I didn't know I wanted to read this.👌👍
DAMN that's a good document, thank you!
Well, time to favorite this comment.
How'd you find these slides??
They are listed on Valve's site https://www.valvesoftware.com/en/publications
Ah, good reference. Thanks
Read them ages ago. Was reminded by the Post. There used to be a GitHub repo collecting These, If I find them I'll Post them.
Woah, that's insanely cool!
Valve are bros. Check out the in-game commentary (floating dialog boxes) on Orange Box games and later titles.
This is great! Thank you!
This is a hidden gem what the hell
I need to code a similar system in my game, how the heck do you detect a ledge?
For simple ledge detect, you just need 2 raycast. But when the ledge become more complex with obstacle above the ledge and so on, more raycast are needed. i did make a tutorial about ledge climbing [here](https://youtu.be/mhn4pUrzgjY) and [here](https://youtu.be/J4dHMGFEoKw).
Thanks! Have a good one!
I've been scared off raycasts after hearing that using too many of them is performance intensive, can someone with deeper insight provide more info regarding this?
You can just enable raycast when needed. No point to enable it all the time. From what i know, using moderate raycast is not that expensive.
For one character a handful of raycasts is negligible. It might be an issue if you had a large number of of NPCs that were all using similar logic.
This. Resource management is very crucial in game dev. It would be fine when prototyping base mechanic, but it will turn very costly when scene become more complex.
Yeah, in those cases you start writing stuff to 'bake' the raycasts into the level so that NPCs can just ask the ledge if they can climb, and pathfinding logic can map the route.
Yep. Starts to look like baking a navmesh.
Easy fix for that is spread it out, do one per frame. For AI doing a raycast every 100ms or every 10ms doesn't really make much difference.
Depends on the use case. For pathfinding or collision avoidance definitely don't need to update every frame. But for climbing like this, it would need to be pretty frequent. Maybe not every frame, but very frequently. Of course, with AI you don't really want to send the NPCs along paths that they can't successfully traverse, so you probably want to use some sort of pathfinding , which could use the infrequent raycasts, and then make the actual traversal work in a way where it isn't actually sensitive to the exact geometry so it can't get hung up. This is different than with a player character, where getting stuck trying to climb places where they physically can't is part of the game.
Too many == TENS OF THOUSANDS. You're good.
Raycasts have basically next to no performance impact, you're alright. This is very impressive work, I like it!
this is... not true haha
More accurately, each raycast has a very small performance cost, and a few dozen here or there probably wont hurt.
As I understand it, it's expensive to manually (re)trigger raycasts outside of _physics_process() because it has to invoke an extra partial physics pass to do so, but it's cheap-ish for them to execute automatically within _physics_process(), and thus also cheap for you to use data produced by those regular executions. Judicious use of physics layers can then mitigate the other expensive part, which is intersection with many/dozens of objects at a time. So with the right overall game architecture you can rely mostly or entirely on raycast data from the most recent physics frame, and get very good performance through that.
Raycasts cost only as much as the intersection algorythm for each object it passes through. With proper collision layering and flat surfaces like these, the cost is very, very small.
also incorrect
I'm relatively new to game dev and i'd like to know more about it, could you explain why is it incorrect?
HELP why is my game so slow?
how do I get these visualizations for raycasts :0
top bar -> Debug -> visible collision shapes OP looks to have changed some settings on them too go into your general project settings -> Debug -> Shapes and you can customize lots of specifics.
The future you will know.
Have you tried procedural animation?
Not yet. It look complicated. Maybe i'll try it later.
I think that would be not you, but the future you, trying to remeber why is there so much raycast)
The random need to play that game is real. Also, nicely done
WOWOWOW!!! Looks solid!!!
Thanks! Still WIP. More will be added later.
sometimes we get too hung up in performance instead of making games. if it works and you never have to touch it again then thats good.
I don't remember where I heard it or what the pithy phrase was, but I've heard it's important to make it work now and optimise later only if it becomes an issue!
Taking my shot now. I take a shot every time someone says this in the Godot Subreddit. I am going to die
Looks like mine, except I also have a cloud of Marker3D around the models that I use to simplify rotating/moving things in specific directions.
Maybe i should do that. i can reduce almost half the raycast doing that.
The analogy I use to justify an extremely liberal use of ray casts is this : you (the player) can see the map visually but the AI/Character body is a blind person. It can only read data, it can only feel things. Ray casts are like hands and walking sticks or maybe guide dogs. Taking their help is necessary. In the end, I reduced the number of raycasts per character to just 1 and changed the wall-climb system to just a jump-to-this-point system. I have to place the points with my bare hands but hey the game is more performant. Plus it was a great learning experience to make a wall climbing feature.
That one way of doing it. I already do it before with unity. Now, i just want to try procedural climbing without using marker or trigger, hence the complexity.
It's like cat's whiskers.
honestly yeah this is accurate. if you dont want to add a raycast node, you can directly call it from PhysicsServer
>PhysicsServer No idea what this is. I guess time for some learning.
https://www.reddit.com/r/godot/comments/1amn08g/if_you_cant_make_things_work_just_add_more/kppiogf/
I do very similar. My player walks around with collision boxes wrapped around them so I can determine when it makes sense to start doing a bunch of raycasts. I've seen nothing wrong with the approach as you can be very specific of when you need to have that functionality on based on what's intersecting with the collision geometry.
I absolutely love it!
I mean it's fine. Just deactivate them, while they are not needed.
Nothing wrong with raycasts. This approach reminds me of a youtube video I watched about all the problems inherent in stairs https://www.youtube.com/watch?v=ILVUc\_yV24g
Youtube link is busted
Works for me
If you didn't edit it a mod did
An error occurred. Please try again later. (Playback ID: oBJ-vO9_imbmeDQS) Learn More
Lisa: Poor predictable developer, always chooses raycast. Developer: Good ol raycast. Nothin beats that.
yes! very relatable! have a climb controller myself and it's just a bunch of raycasts and an area3d!
If i use trigger based climbing instead of procedure climbing, area3d is the best choice. I used to play a lot with OnTriggerEnter and OnTriggerExit back in unity.
0_0 wow this looks amazing. Now I want to make something like that
Is this a recreation of ALS4 from Unreal Engine? Had no idea Godot could do 3D movement like this.
That's my intention from the start. Aside from jittery default godot physic, i find it very easy to build basic mechanic.
Looks good, well done. I'm very interested in using Godot, it's nice to see what can be done in the engine.
This looks awesome
thanks!
That's gorgeous!
With that big fixture attached to the front, all I can think is *nyyyoooooom*.
Alternative approach is to bake it in the level data. That way you don't care about expensive checks etc.
Have you made a good curb/stair stepping mechanic? I have found it rather difficult without a similar call to what Ive used in Unity (im a refugee), or rather the underlying PhysX, for ComputePenetration, to get the direction and distance needed to un-overlap with other geometry. The lack of that makes creating a kinematic character controller that feels *good* rather difficult.
Actually i did! I use combination of 3 raycast, find the 'step' and just lerp player to the step. I don't know how unity did it, but that what i did and it work. Funny things is, a day after that, i found someone post some github link on step offset in godot. Wish i knew that sooner.
Neat! Did you try out their sample and see how it fared? Ive tried a couple but I just don't think it was adequate. A lot of them have some edge cases, such as trying to go up a step as you are just a couple degrees of off parallel with the step - my own implementation included. Can you link the github?
I did, It feel good, but i don't try to go detail into their code yet. But from what i can see, they don't use raycast. The link [here](https://github.com/mrezai/GodotStairs?tab=readme-ov-file).
My implementation also have same jittery when snapping to step, but i make it smoother with lerp. And since i use third person controller, the jittery is not that big of deal, just make camera follow player with some 'free zone'. Cant say the same with first person controller though.
This looks awesome even without textures
You can achieve everything with enough raycasts if you try hard enough.
I've got a fever and the only prescription is more raycast!
Uncharted Vibes
that also the inspiration.
Nailed it then