More information about using 3D selection boxes?

Lethn

LOL oh for crying out loud xyz thanks as it so happens I also found this tutorial with some keyword tweaking in the search, will use both and study up. It even looks like this tutorial is properly up to date and the guy is using Godot 4, yep, I wouldn't have been able to work this out on my own, this maths is tricky for people who don't already know it.

xyz

Lethn The way it is done in this tutorial is rather weak. It un-projects a single centerpoint back into screen space and checks if it's inside the selection rectangle. Simple to implement but not good if you're zoomed in, have large units, or strong perspective. It would feel a bit annoying to the player as they'd never know how "deep" they must draw the rect into the unit for selection to take place. My example does universal 3d area-select, the proper way, using 3d bounding boxes. Can be used in rts or any other kind of game.

Lethn

It is fascinating though that a 3D selection box is such a common feature in software yet with game dev there aren't that many examples and tutorials out there for some reason, these two videos were the only ones I could find and there was little to no posts on the topic.

xyz

Lethn Yeah, area-select is commonly needed in games. It may even deserve a place in the core functionality, or at least a solid native plugin. It'd also fit nicely in the cookbook part of the documentation, alongside the recipe for ray-picking, as they typically go hand in hand.

Megalomaniak

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? 😉

xyz

Megalomaniak 👉️ 👈️

Somehow I just knew you'd come and pester me about it 😉
I'll see what I can do.

Lethn

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.

xyz

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.

Lethn

I just wanted to know about 3D selection boxes and then I fell down the rabbit hole ;_;

Lethn

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.

synthnostate

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).

xyz

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.

synthnostate

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".

Lethn

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.

xyz

Lethn The "heaviness" of math is equal in both approaches, as far as part in GDScript is concerned.
In total, the math is much heavier when treating the frustum as a convex mesh. You just don't see it because it's done under the hood 😉

Lethn

Out of sight out of mind LOL 😃

Lethn

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

Lethn Looking at this 3D selection box code that @xyz has provided yeah, it needs breaking down way more to be understandable

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

Lethn I think it's the frustum stuff that's hurting my poor brain the most.

What specifically about the frustum is hurting your brain?

xyz

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 😉

Lethn

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.

synthnostate

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.