Skip to content
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

Merged
merged 1 commit into from
Jul 26, 2018
Merged

Add snap to floor functionality to the editor #20022

merged 1 commit into from
Jul 26, 2018

Conversation

EIREXE
Copy link
Contributor

@EIREXE EIREXE commented Jul 7, 2018

glitteringarcticduckling-size_restricted 1

UE4 style floor snapping.

Default binding is page down.

@Zylann
Copy link
Contributor

Zylann commented Jul 8, 2018

I was nearly going to make a plugin for that because I need it, but glad to see an initiative to integrate into core :)
Several notes after reading the code:

  • You should implement it using UndoRedo, currently it cannot be undone
  • Don't just set the translation of the Spatial, it would be better to take its AABB into account, and snap from its bottom
  • It won't work for scenes having no colliders (not sure if that's a problem though)

@EIREXE
Copy link
Contributor Author

EIREXE commented Jul 8, 2018

@Zylann

You should implement it using UndoRedo, currently it cannot be undone

I will do that

Don't just set the translation of the Spatial, it would be better to take its AABB into account, and snap from its bottom

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.

It won't work for scenes having no colliders (not sure if that's a problem though)

If there's no floor to snap to it just doesn't snap to anything.

@EIREXE
Copy link
Contributor Author

EIREXE commented Jul 8, 2018

I just realised that maybe we could simply get the AABB from all VisualInstances and use that, can someone think of a better way?

@Zylann
Copy link
Contributor

Zylann commented Jul 8, 2018

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.

@EIREXE
Copy link
Contributor Author

EIREXE commented Jul 8, 2018

I will do that then.

@EIREXE
Copy link
Contributor Author

EIREXE commented Jul 8, 2018

How do you guys suggest I get the bounds of collision physics?

@toger5
Copy link
Contributor

toger5 commented Jul 8, 2018

git reset HEAD~4
git commit -a -m "commit message"
git push -f

;)

it's really nice to have snap to floor!

@EIREXE
Copy link
Contributor Author

EIREXE commented Jul 8, 2018

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

@EIREXE
Copy link
Contributor Author

EIREXE commented Jul 9, 2018

I have merged the commits and it now works with collisionshapes too.

@EIREXE
Copy link
Contributor Author

EIREXE commented Jul 21, 2018

fails on travis only, anyone knows why this is?

@Zylann
Copy link
Contributor

Zylann commented Jul 21, 2018

It looks like it doesn't like templates in your get_child_nodes function. Maybe it needs the typename prefix before T.
Also, did you try to not make it a member function since it's private? (and just make it a normal function in the .cpp)

@EIREXE
Copy link
Contributor Author

EIREXE commented Jul 21, 2018

@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;
Copy link
Member

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.

Copy link
Contributor Author

@EIREXE EIREXE Jul 21, 2018

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

@mhilbrunner
Copy link
Member

I build & tested this locally, it seems to be working fine. Thanks for the contribution :)

@mhilbrunner
Copy link
Member

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

@Zylann
Copy link
Contributor

Zylann commented Jul 24, 2018

Hmm I wonder something: in my terrain editor, terrain chunks are not nodes. They are mesh instances that exist in VisualServer only. Collision is also not generated in editor for performance reasons (and is not very useful to keep updating it as it gets edited constantly and had no use so far). But how would snap to floor work in this situation?

@mhilbrunner
Copy link
Member

@Zylann The PR does check VisualInstance.size. No idea beyond that.

@Zylann
Copy link
Contributor

Zylann commented Jul 24, 2018

@mhilbrunner the code searches for VisualInstance nodes. But my terrain doesn't use nodes, it only uses VisualServer directly. That means it won't work and I wonder what to do about it :/

@mhilbrunner
Copy link
Member

mhilbrunner commented Jul 24, 2018

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

@Zylann
Copy link
Contributor

Zylann commented Jul 24, 2018

@Zylann Maybe your terrain could use nodes, e.g. one per chunk?

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.
I thought there would be a way to simply ask VisualServer instead of the scene tree when looking for VisualInstances (selection does that I think? so why not snap), but I'm curious what reduz thinks about it.

@EIREXE
Copy link
Contributor Author

EIREXE commented Jul 25, 2018

@mhilbrunner What edit menu? You mean the top bar?
image

@EIREXE
Copy link
Contributor Author

EIREXE commented Jul 25, 2018

image
I made it like this, let me know what you think.

@Two-Tone
Copy link

Two-Tone commented Jul 25, 2018 via email

@mhilbrunner
Copy link
Member

mhilbrunner commented Jul 25, 2018

reduz> I would put that in the Transform menu

Can you move the option there? :) Sorry for not being precise initially.

@EIREXE
Copy link
Contributor Author

EIREXE commented Jul 26, 2018

Like this?

image

@mhilbrunner
Copy link
Member

Yes. Thanks for making those changes, and thanks for the making the contribution in the first place!

@mhilbrunner mhilbrunner merged commit 6cf5eb8 into godotengine:master Jul 26, 2018
@seadra
Copy link

seadra commented Jul 27, 2018

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

@mhilbrunner
Copy link
Member

Well, it uses the extents, I'm not sure what the alternative would be for a Mesh Collider - use Raycasts downwards?

@Zylann
Copy link
Contributor

Zylann commented Jul 27, 2018

@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.
@mhilbrunner it should use AABBs only for the snapped objects, not the environment. If AABBs are used for environment then it's not good (should use mesh data to intersect manually after broad AABB detection)

@mhilbrunner
Copy link
Member

Ah, right.

@AndreaCatania
Copy link
Contributor

Just found it for case, Thanks you for this "so useful" addition!

@EIREXE
Copy link
Contributor Author

EIREXE commented Jul 27, 2018

@Zylann Yes it uses a raycast, unless there's a better way I'm not familiar with.

@seadra
Copy link

seadra commented Jul 27, 2018

@Zylann The terrain I tested with uses convex static body, which was generated by Godot.

@Zylann
Copy link
Contributor

Zylann commented Jul 28, 2018

@seadra that explains it then. Convex means Godot will generate an encompassing mesh collider. Try using concave trimesh instead.

@seadra
Copy link

seadra commented Jul 28, 2018

@Zylann Thanks, that was it! But there's still some considerable margin/gap between the object collider and the ground...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants