#Is there a way to use an array for ignored entities on a raycast node?

1 messages · Page 1 of 1 (latest)

icy laurel
#

This is a picture of what I am talking about. I am not sure if there is a way, or if it is a feature request that would be possible to do? Any insight would be greatly appreciated.

#

I have two ways I could do what I am trying to with raycasting, one is being able to ignore multiple entities, and not just one or self. The other is setting up more collision groups. This is an issue seeing that only ~60 groups can be set up, and I know this would not surpass it, but I am not sure if its a good route to take to ignore certain entities.

radiant cypress
#

🤔 I'm not sure there's a way to ignore before doing the check with the current nodes. What you could do is have the raycast return all hits, and then check the results against the ignore list to get the first entityId that is not in there. It may be more expensive tho

#

It feels like it could make sense to either have a separate node, or to update this node to allow both a single entity or an array?

icy laurel
vivid pebble
#

@icy laurel If i may ask how are you using all 64 bitmasks ?

icy laurel
#

@vivid pebble Right now I am using around 9 bitmasks (should go up to around 12-13), but setting up raycasting that has a lot of colliders inside of each other I am switching what group or bitmask is used to only detect the colliders I need. I am using this for a building system and mainly for snapping building pieces together. I was a little dramatic when saying that the 64 bitmasks could become an issue. This approach is simple to set up and does not have a performance impact, I believe its actually less expensive since its only raycasting for a certain bitmask, not all.

vivid pebble
#

You implementation of the building system may need to change

#

I actually have just alot of time working on one

#

let me see if I can show you an example

#

it is based off the one from Rust

icy laurel
#

I'd love to see any examples. I am just going with it from the very beginning, and honestly its not horrible and works pretty well, but I am very willing to take suggestions.

vivid pebble
#

basically i created the small house in game

#

sorry i couldn't record video I donn't have any screen capture installed

#

let me show you some of the core

#

Honestly I already forgot how exactly i did it

#

but this is what the layers look like

#

it is major part

#

basically when a prefab type is selected like a wall, floor, ceiling, or door each type raycast for a placement layer for that type

#

there is more to it

#

but I can't remember I didn't comment my code

#

so i trying to read it

#

if you want I can send you this project it is in Godot4

icy laurel
#

This is the collision layers right now that I am working off of. Isn't this basically the same thing? I have wall snapping and foundation snapping already, and when I have a wall chosen it only is raycasting for the wall snapping locations.

vivid pebble
#

it is close there was a specific reason I chose to do this way I am old and just really bad at documenting. I tried at least 3 different methods

#

ok i am fucking retarded

#

sorry

#

in this project I tried too different building methods I was looking at one that didn't work well

#

it explains why i can't find the answer

#

ok what the blue outlines are is static colliders

#

they don't interact with anything

#

you raycast to find them and using their origins you can place a piece of that time

#

so the 4 that are along the bottom are on the floorplacement colliders

#

if you are placing floors you can raycast to hit them and move a instance of the floor to place it

#

you have to raycast the area teh new piece will be in to make sure you don't place existing piece ontop of each other

#

i mean boxoverlap area

#

i believe you can do that in SC

icy laurel
#

Ok, so it does look I am on a great track already, and somehow did a good implementation the first time around. This is what my editor looks like with one foundation and a wall that I set up for testing.

vivid pebble
#

what is this showing ?

icy laurel
#

the static colliders that I raycast to and snap to the origin to place new pieces.

vivid pebble
#

There are methods that doesnt require colliders

#

in my opinion it works the best if you do use coliiders

#

it makes it easier to show exactly what positions are valid

#

what is your problem then ?

#

why are you asking for help ?

#

https://www.youtube.com/watch?v=gkCBCCKeais a grid based building method

✅ Get the Project Files https://unitycodemonkey.com/video.php?v=gkCBCCKeais
🌍 Join the Core Invitational https://invitational.coregames.com/
🌍 Download Core at https://bit.ly/CodeMonkeyxCore
🌍 Join the Core Traffic Jam! https://trafficjam.coregames.com/
👇
🌍 Get my Complete Courses! ✅ https://unitycodemonkey.com/courses
👍 Learn to make awesome g...

▶ Play video
icy laurel
#

I was going to use colliders like I am, but I wanted to be able to ignore multiple entities so I did not need multiple collision layers, I could have all of the snapping points in one, and ignore say all the wall colliders when working with the foundation. It was more of a question if I could use an array to ignore entities with raycasting. Which I am now taking a different approach, but was one way to not use as many collision layers.

vivid pebble
#

that would be a lot to track

#

you would literially need an array of every building piece of that type

#

you could use game tags

#

groups should be fine

#

just have a group of 1 layer

#

is there a limit to the number of physics groups you can have?

icy laurel
#

Game tags was going to be the plan, but if you had enough building pieces out in the world it still would be a lot for the script to handle. In all I think I am just going to stick to collision layer detection, and if it begins to have a performance impact I will start removing snapping colliders when placing pieces and add them back when the pieces are removed. Just a small optimization.

vivid pebble
#

this this is the thing. You only need to know the game tags of what you are hittin g

icy laurel
vivid pebble
#

if the object doesn't have the game tag you are looking for discard it and move on to the next

#

rather than filter by layer you are filtering by gametag

#

layers would be better it would be faster

radiant cypress
#

Hum, seeing the whole picture, now I'm thinking... could you just use a single collider layer, and then spawn and despawn the collider based on what element the player is currently selecting/trying to add? That way you don't have to use multiple layers at all

icy laurel
radiant cypress
#

Unless you want to be able to just point at an empty area and fill that in with a new element dynamically. But if the purpose is to have something like Valheim where you select the new piece from a menu, you only actually need one type of colliders at any one time

icy laurel
vivid pebble
#

like i said at the start if they are static colliders that don't interact with anything they are low cost

radiant cypress
#

True. I guess it's a matter of whether it's more expensive to have all the colliders up at once, and then have to filter between them with the raycast, or to just change them when the tool is switched

#

fair static could actually end up being cheaper

vivid pebble
#

I tired two methods. in my prototype

#

the first I had two prefabs one with the mesh and colliders for the world then another prefab with just building colliders that spawned in when the building system was activate.

icy laurel
vivid pebble
#

Freeing the building system colliders when not in use didn't help with performance at all it did add complexity to the code.

#

@icy laurel that is just logic

radiant cypress
vivid pebble
#

if you look at bar at bottom

#

there is text for each building type

icy laurel
#

I am keeping all options on the table, but the main thing right now I believe is to stick with what is working, and if it gets to be a performance hit in the future I will start turning everything static, and try all other approaches to see what I can do to make it more performant.

radiant cypress
#

Then if the problem is that you end up having too many element types where it fills the collision layers, the alternative would be to just have all static colliders always up, and then when the player changes building type, just set the "active_building" layer to the colliders that can be used for that element, and clear the layer for the others

vivid pebble
#

That is entire buiding system for my game

radiant cypress
#

So you'd only ever need one layer. And I'd guess that's a cheaper operation to do once even if it loops through all colliders

vivid pebble
#

gdscript is based on python

#

you should be able to read it

icy laurel
vivid pebble
#

it is only 115 lines because putting in different layer simplifies the logic

#

well you can read and translate

#

the concepts are the same

icy laurel
# vivid pebble

I am not great at python or know too much about it, but I will give it a shot, I should be able to learn whats going on and how your build system is working. Thanks for the file it will be easier to read not in a screen shot.

vivid pebble
#

it reads like english

#

gdscript even more so

icy laurel
#

wow it really does. That is nice since I have no knowledge of gdscript at all, but it seems relatively easy to read and understand.

vivid pebble
#

yeah it is very easy way to learn

#

I would suggest c# (when using Godot4)

#

as GDScript is horrible in several ways

radiant cypress
#

Does raycast3D only return the first hit, or go through the others if an empty selected is returned? I'm wondering how this resolved the raycast when you want to create a floor, point at a floor collider but there's a wall collider in-between.
But yes aside from this it is very simple and streamlined

icy laurel
# vivid pebble I would suggest c# (when using Godot4)

I honestly hate typed languages and do everything but a save system in script canvas or visual scripting. I know a little C++ and am learning more weekly to hopefully help out with code review in the future for o3de, but I will always stick to script canvas if its possible, and so far it seems like 80% of things are.

vivid pebble
#

learn to love typed languages it saves you so much time

#

@radiant cypress each raycast only interacts with 1 layer

#

you set a raycast mask

radiant cypress
#

ooh ok so the switch is based on the user selection, not the hit

vivid pebble
#

This could be done with a better data driven way but i though it added complexity

radiant cypress
#

got it

vivid pebble
#

what prefab type which is a string determine which raycast is used.

#

this is not optimum but easy

#

this is just a small game I am building for my daughter.

#

I try to keep the code as small and flexible as possible when prototyping.

radiant cypress
#

Oh yeah that's a neat script. Don't need to overcomplicate or optimize things for prototypes for sure

vivid pebble
#

@icy laurel Now I remember you have to each structure type like wall, floor, ceiling in it own layer so you can check easily check for existing building pieces in that exact area.

#

You can view each collider as a slot

#

and if you boxcast using the colliders origin and get more hits than expected you know a piece has already been placed there. It prevents you from having to destory and create colliders on placement.

#

It also makes a possible to destroy sections without having to create anything you just delete the building piece.

icy laurel
#

@placid fiber How do you resolve a post? I cannot seem to find out where to add extra tags.

high bison
#

hi...This code doesn't run, it runs with the TickBus command, but it doesn't work in OnActivate.. it works fine in previous versions... can you help me, thanks