#Is there a way to use an array for ignored entities on a raycast node?
1 messages · Page 1 of 1 (latest)
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.
🤔 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?
Thank you for the suggestion. I will give it a try and see how it works. I am also getting the collision group up and running, which would be less expensive, but this node is only called once in a while in certain situations, so being a little more expensive may not be too big of an impact.
@icy laurel If i may ask how are you using all 64 bitmasks ?
@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.
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
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.
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
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.
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
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.
what is this showing ?
the static colliders that I raycast to and snap to the origin to place new pieces.
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...
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.
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?
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.
this this is the thing. You only need to know the game tags of what you are hittin g
Groups no, layers 64, but that does not seem to be an issue what so ever.
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
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
That is a way to go about this and would work just the same, but filtering by layer not gametag makes the raycast less expensive, which does help out.
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
I like this idea a lot, but if I have say 20 foundations down or 1 I would have to spawn all the colliders in for the 20 foundations every time I switch to a wall type. I think this could have a larger impact, but I could be wrong.
like i said at the start if they are static colliders that don't interact with anything they are low cost
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
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.
I can send a video if its needed, but what I am going for is switching between each type like wall, ceiling, foundation, etc. it is just a button click. Which could make for spawning and despawning to happen very fast if the user is just swapping between them both.
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
Gotcha, that's a good data point
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.
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
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
Thank you for this, I may have to switch to this in the future, and will take note on it right now. I hope it does not come down to this, but if so I have a pretty great alternative method if I can somehow get it working.
it is only 115 lines because putting in different layer simplifies the logic
well you can read and translate
the concepts are the same
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.
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.
yeah it is very easy way to learn
I would suggest c# (when using Godot4)
as GDScript is horrible in several ways
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
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.
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
ooh ok so the switch is based on the user selection, not the hit
This could be done with a better data driven way but i though it added complexity
got it
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.
Oh yeah that's a neat script. Don't need to overcomplicate or optimize things for prototypes for sure
@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.
@placid fiber How do you resolve a post? I cannot seem to find out where to add extra tags.
Done, 🙂
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