Having an accurate drag select feature for 3D colliders

[wind salmon]

I'm wondering if anybody knows a more accurate way to drag select objects in a 3D view; currently the set up i have sets up the frustum planes of the camera and then uses a built in function for AABB plane collision testing, but this is very inaccurate for rotated colliders, as the AABB bounds are gigantic, especially with like a large square plate, the drag select catches blocks from a mile away.

[tranquil scroll]

https://discord.com/channels/489222168727519232/1458587107504427192 this post is relevant!

Although, actually, no, that's more about getting correct bounds when the object goes off-screen

it still gives you a large bounding box

[wind salmon]

Yeah, i dont think its too helpful as i have many different kinds of colliders, but its a good start

[tranquil scroll]

I'm not sure how you'd do this efficiently. For mesh colliders, you could just test every vertex of the mesh

you'd transform them into clip space

but this wouldn't work quite right

you'd miss the collider if your box only overlaps an edge between vertices (but doesn't overlap any vertices)

[wind salmon]

I think i tried this but for large box colliders it's basically useless

Maybe i could create a 2D polygon by transforming the vertex positions into screen space and doing some like overlap function? Is that even a thing

[tranquil scroll]

at the least, you could project the entire mesh into screenspace and then test if:

• any vertex is inside the box
• any edge crosses the box

one thing that comes to mind is "picking"

You render each mesh with a unique color

for cursor picking, you look at the color at the pixel the mouse is pointing at, and that tells you what you clicked on

(this is how scene-view selection works)

You could iterate over the resulting texture and select every object whose color appears at least once

this sounds a bit expensive, especially if you want to do this every frame so that you get a nice live preview of what's being selected

it also would only work for mesh colliders that exactly match a mesh that's being rendered

(although, at this point; colliders don't even matter)

you're picking entirely based on the renderers

[wind salmon]

well that would limit me to textureless colors and only a handful of them no? every new variant id need a different color

i already have cursor selection working with raycasts

the only issue really is the accuracy of my drag select

[tranquil scroll]

Each unique object in the scene would have its own ID

[wind salmon]

its an interesting idea, but the moment i want more nuance in the blocks it becomes unviable

[tranquil scroll]

the shader would only be used for picking

this would be entirely unrelated to normal rendering

[wind salmon]

i see

oops

[wind salmon]

i meant to reply to this

[tranquil scroll]

you'd have to be pretty comfortable with unity rendering to implement this

definitely not an easy fix

[wind salmon]

i mean id need to like create a new shader at run time or a new shader for every object prefab

[tranquil scroll]

It'd be a single shader; each object would pass the shader a different ID

[wind salmon]

or just like an extra shader that ever object gets but assign a unique color or sm

i understand what youre saying, ill keep this in mind for later, but selecting individually isnt my current problem

[wind salmon]

@tranquil scroll Hey, was wondering if you know more about the color picking thing. I decided to start making it today and I got the color picking to work, however it doesn't seem to be detecting objects with a transparent property with like custom render queues. Is there a standard solution to this issue?

[tranquil scroll]

Do you have a way to visualize the "selection buffer"? That might help you to see what's wrong.

I guess it could break if the transparent materials are also trying to do alpha-blending in the selection pass

(but you'd have to have explicitly done that)

How are you actually rendering the selection buffer?

are you rendering the scene using shader replacement? https://docs.unity3d.com/6000.3/Documentation/Manual/SL-ShaderReplacement.html

[wind salmon]

Yes, im making a new camera and then using a custom shader with SetReplacementShader and rendering that.

I actually was able to fix the problem by not using a specific rendertype in the shader

[tranquil scroll]

oh yeah, that would have done it

since the render type of your transparent objects wouldn't match

also, opaque rendering with ZWrite+ZTest on is the way to go

[wind salmon]

is that what i currently have

Unrelated I had a problem with rendering transparent objects how i wanted, as sometimes it would appear in front of other objects and stuff

So i had to like dynamically update their renderqueues to a funky value like 3001

then it started working

transparency was a pain honestly

[tranquil scroll]

Yeah, it is

transparency sucks, yes :p

[wind salmon]

i have no idea how things like render queues and such work

Also, do you know if theres a way to select objects behind others? or is that a downside of using color picking

[tranquil scroll]

to allow "clicking through", you could disable any object that has already been selected

re-enable them when the mouse moves

[tranquil scroll]

The render queue is just the order in which objects render

2000 is opaques
2450 is for AlphaTest (still opaque, but with discard/clip instructinos)
2500.5 is the skybox (in between 2500 and 2501)
3000 is for transparents

[wind salmon]

So 3001 kinda overrides the standard transparencies

[wind salmon]

Wouldnt that mean id have to reselect

or would i like iterate again code wise until theres no objects

[tranquil scroll]

Rendering at 3001 means you render after most transparent stuff. This will cause you to draw on top of anything transparent.