-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add snap to floor functionality to the editor #20022
Conversation
I was nearly going to make a plugin for that because I need it, but glad to see an initiative to integrate into core :)
|
I will do that
That's what I wanted to do at first, but I haven't found any way to get the AABB of a node and it's children combined, I could try iterating through the children but I feel like that would get messy.
If there's no floor to snap to it just doesn't snap to anything. |
I just realised that maybe we could simply get the AABB from all VisualInstances and use that, can someone think of a better way? |
If the thing to snap has physics, use its collision shapes. If it doesn't, use its VisualInstance AABBs. If none of those, use origin. |
I will do that then. |
How do you guys suggest I get the bounds of collision physics? |
;) it's really nice to have snap to floor! |
@toger5 I will merge commits when it's done, at the moment it's lacking snap to floor for collision shapes, which I still need someone to help me with. |
I have merged the commits and it now works with collisionshapes too. |
fails on travis only, anyone knows why this is? |
It looks like it doesn't like templates in your |
@Zylann thanks mate, fixed now |
for (int i = 0; i < parent_node->get_child_count(); i++) { | ||
Node *child_node = parent_node->get_child(i); | ||
Set<T *> child_nodes = _get_child_nodes<T>(child_node); | ||
for (typename Set<T *>::Element *I = child_nodes.front(); I; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please don't wrap forcefully when it makes things less readable, like here (several other occurrences). In general we don't have max char limit because the wrap it imposes it almost always bad for readability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Must have been a clang format misconfiguration on my end
I build & tested this locally, it seems to be working fine. Thanks for the contribution :) |
reduz pointed out it would be good for discoverability to have this added to the Editor "Edit" menu so people can easily find it's there and learn the shortcut. Besides that, this should be good to go. :) |
Hmm I wonder something: in my terrain editor, terrain chunks are not nodes. They are mesh instances that exist in |
@Zylann The PR does check |
@mhilbrunner the code searches for |
@Zylann Maybe your terrain could use nodes, e.g. one per chunk? Other than that, we'd need to discuss with reduz/core devs how to do that, or see if there is a way to add to what this PR does, see if the needed information is exposed somewhere in VisualServer. But that really is orthagonal to this PR :) We should aim to get this merged so it works in 90% of cases, then see about how it could work with terrain. But such integration (or lack thereof) is really why I feel terrain should be supported in core. |
That would be a big waste to only do this :/ And even if I did, collision is the only way to go, visual meshes get displaced in shader. |
@mhilbrunner What edit menu? You mean the top bar? |
Side the tool tip for the lock is "Lock the selected object... etc", this
should probably say "Snap the selected object to the floor."
…On Wed, Jul 25, 2018, 3:32 AM Alex Roman Nuñez ***@***.***> wrote:
[image: image]
<https://user-images.githubusercontent.com/3101690/43189061-fe3e850a-8ff5-11e8-86a2-cb3e33359792.png>
I made it like this, let me know what you think.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#20022 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEJESzId5U5ztaUk7WP_4kCZ2pbmHfyBks5uKC0ugaJpZM4VGdzM>
.
|
Can you move the option there? :) Sorry for not being precise initially. |
Yes. Thanks for making those changes, and thanks for the making the contribution in the first place! |
This doesn't seem to be working correctly with a mesh collider; it snaps the object to the level of highest place in the mesh. For example, if you have a terrain with hills, and if you try to snap an object in a valley, snapping make it hovers over the valley (at the height of the hills). |
Well, it uses the extents, I'm not sure what the alternative would be for a Mesh Collider - use Raycasts downwards? |
@seadra does your terrain have a concave trimesh collider? AFAIK this PR uses raycast so the only way for this to happen is the collider is convex. |
Ah, right. |
Just found it for case, Thanks you for this "so useful" addition! |
@Zylann Yes it uses a raycast, unless there's a better way I'm not familiar with. |
@Zylann The terrain I tested with uses convex static body, which was generated by Godot. |
@seadra that explains it then. Convex means Godot will generate an encompassing mesh collider. Try using concave trimesh instead. |
@Zylann Thanks, that was it! But there's still some considerable margin/gap between the object collider and the ground... |
UE4 style floor snapping.
Default binding is page down.