More information about using 3D selection boxes?
- Edited
xyz It'd also fit nicely in the cookbook part of the documentation,
Not to tell you what to do... 
️ 
️ but since I agree with the notion and seeing how you already have about half of it written/done in that previous post, might it be ok to point out that the docs repo does accept pull requests? 
Megalomaniak
Somehow I just knew you'd come and pester me about it
I'll see what I can do.
- Edited
xyz LOL it would be really helpful Xyz and probably help out a lot of people and really anything to avoid multiple topics around the internet with zero real answers, I think there's a debate to be had about the 'best' method though as it seems there are multiple calculations to be done with a 3D selection box from what I've seen posted by others on this topic.
- Edited
Lethn All tutorials you posted so far are making half-assed non-general approaches to avoid doing "complicated" math. What I posted is a general solution that overarches all of the those special cases (e.g. testing only the centerpoints, doing it only on the ground plane etc) . It also discriminates between partial/full enclosure, so you can use it for a system that requires full enclosure to make a selection or a system where merely touching the object is enough. If you insist, it can also behave exactly like what is done in the last video. You just need to make the bounding boxes small. It is in fact the "best" solution, although a bit more computationally expensive than any special case, but not by much.
I just wanted to know about 3D selection boxes and then I fell down the rabbit hole ;_;
- Edited
I think there's also potentially a debate on the multiple methods, but I'll be happy if I can just get a decent selection box that's accurate enough for gaming. As you've probably guessed, I got fed up with my 2D RTS idea because I was annoyed with the TileMap behaviour the most. I would rather deal with that level of maths if I know it's all going to work and I've already sorted out how I'm going to do all the other code for the 3D RTS in my head. I even wonder with RTS' in general if 2.5D is actually the better approach and using 3D sprites is the way to go when it comes to dealing with that thanks to modern software.
Hi, I've been following this over on Minds, guess it's time I joined this forum. My first thought was to use a frustum, but I suggested @Lethn try Camera3D.unproject_position(centerpoint) and do the math in 2D for simplicity because he's relatively new to gamedev (no offense lol). I've made my own 3D engine with broadphase-narrowphase bbox and precise raycast picking, I know how it's done, but it's important not to get carried away, just stick to simple solid code you can understand, and improve it later if you really need to.
Anyway, I thought of simpler method: compute a frustum using @xyz's method, plug the vertexes into a CollisionShape3D attached to an Area3D, and call Area3D.get_overlapping_bodies() to query for selected objects. This should be efficient and accurate. You will need collision meshes on your objects, or Area3Ds if you don't want any physics (use Area3D.get_overlapping_areas in that case).
- Edited
synthnostate Not bad, but it's arguable if it's really simpler. I mean it's basically the same thing but you pile on extra convex mesh collision checks, and a need for additional selection collider setup on each selectable object. Although it may possibly even be faster because checks are done in native code, for a continuous update while dragging you'd need to rebuild the convex mesh collider every frame. If things were done in the same language I'd always go with aabb test rather than full blown convex mesh test. It's much less expensive. Someone should benchmark those two (GDScript aabb check vs native collider check, with frustum rebuild each frame), I'd be interested to see which one is actually faster.
- Edited
Alternatively you could always put up both methods and explain the differences and people could make up their own minds which they want to use, granted, the less maths heavy approach is always more tempting, at the same time though I'm not scared of learning heavy maths these days if it means more efficient code.
Out of sight out of mind LOL 
- Edited
In my defence, what I've been doing most of the time with my stuff is working out game mechanics in general and what can work well versus what can't and how to implement it. Now people are going to see a hell of a lot more from me when it comes to posting up proper projects and won't be able to avoid the spam lol I've got some special things planned for Godot, this engine is impressive overall and I'm going to throw the kitchen sink at it to see how it handles. Looking at this 3D selection box code that @xyz has provided yeah, it needs breaking down way more to be understandable. The theory is fine but definitely some collaboration on making sure there's some sort of up to date documentation is in order and I'll be happy to go through it with people to help lighten the burden a tad, I think it's the frustum stuff that's hurting my poor brain the most.
xyz Exactly, let the engine's battle-tested native code core do the work and keep your code simple. It's probably optimized to skip the convex mesh test when the bboxes don't intersect, and no doubt it uses spatial partitioning to skip the bbox test for objects that aren't even close. And this is cheap compared to full-blown physics, which constantly tests ALL collision meshes against each other.
Remember, a bbox test alone isn't accurate. For example if you have a spherical object and you drag your selection box over the corner of its bbox, it'll be selected even though you're not actually touching the sphere. That's not necessarily better than a centerpoint test. You might as well use collision system and get partitioning and bbox optimizations "for free".
- Edited
synthnostate BBoxes with margins are quite sufficient for most cases in practice, and sphere check against a frustum is even less expensive. But for a large number of units it'd surely pay off to use engine's broadphase optimizations, especially if a large number of selectables is in play. I'd love to see this benchmarked in various scenarios.
synthnostate battle-tested native code
Not sure Godot 4 physics is actually battle-tested though
- Edited
xyz One of the reasons I've been exploring selection boxes so much is I'm doing something of a wave defence/base building game by the way, should be no trouble attempting to break Godot. I've been experimenting with my villagers so far in one of my other projects and Godot 4 has been handling it like a dream, definite performance boost I can confirm compared to Godot 3.5.
- Edited
Or you can just use it by calling the top-level function as you would with other engine functionality. In this thread, you've got everything you need to quickly make a selection system. With the project_rect() function from my example and going with @synthnostate suggestion to use convex mesh collider for the frustum, it's almost trivial to set up.
xyz Not sure Godot 4 physics is actually battle-tested though
lol, true. The physics part needs work. I think the parts we're talking about here are pretty solid though. I'm using Area3D.get_overlapping_bodies() for other purposes with no issues.
- Edited
It's mainly working through all of the shorthand you've written so I understand what I'm even doing here, I need to focus you guys to make this thread more noob friendly lol. I see you've declared three custom variables but aside from the camera and the rect I don't know how to use this. I also don't know what sort of hierarchy setup I'm supposed to be looking at. That's something you definitely have to explain before it goes anywhere near documentation.
For instance, do I take the rect from my previous selection box code and plug that into the rect you've defined? I take it the AABB is supposed to the the collision? I don't know how to use this in relation to search for a group for example, you write it's easy but I think this is a classic example of you looking at more complex stuff on a daily basis lol.