Rotate PointClass entities around their origin instead nearest grid cross (snap by origin instead AABB vertex)

[nklbdev]

System Information

TrenchBroom V2023.1 win64 on Windows 10

Expected Behavior

PointClass-entities should snap to grid with its origins when:

• A user creates them on solid entities
• A user rotates them
• A user moves them

Currently this only works when the user creates an entity in the void. Then it snaps to the grid with its origin. But if the user creates a PointClass-entity on the surface of a SolidClass-entity, then the PointClass-entity snaps to the grid by one of the vertices of its bounding box. This causes problems with its rotation and positioning in the future.

Steps to Reproduce

Point entities created in the void

1. Drag any PointClass-entity from Entity Browser to void space in the world.
2. Rotate it.
3. It rotates around it's origin, because it was created with origin snapped to nearest grid cross. Rotation center also snaps to nearest grid cross. Rotation ceter position is equal to origin position.

Point entities created in on the surface

1. Drag any PointClass-entity from Entity Browser to surface of any SolidClass-entity.
2. Rotate it.
3. It rotates around grid-cross nearest to its origin, but them are not equal! Because it was created with one of bounding box vertices snapped to nearest grid cross. Rotation center snaps to grid cross nearest to origin. Rotation ceter position is not equal to origin position.

Thank you very much!

[kduske]

I understand the issue, but the current behavior is there because it makes snapping entities to the visible grid more intuitive. If we snap to the origin, this can break the current behavior in unexpected ways. Do you have any suggestion how to achieve both goals?

Edit: If we did snap the origin to the grid, this would often move an entity into or away from the surface under the mouse. That would not be acceptable IMO.

[nklbdev]

Do you have any suggestion how to achieve both goals?

I think this option is needed. It is not necessary to remove existing functionality.
Maybe add a modifier-key on a keyboard or a checkbox in the rotation UI or in the app settings.

If we did snap the origin to the grid, this would often move an entity into or away from the surface under the mouse. That would not be acceptable IMO.

If, when specifying the character's AABB box, the origin is placed between his feet, then everything will be correct.

size(-8 -8 0, 8 8 32)

[kduske]

Do you have any suggestion how to achieve both goals?

I think this option is needed. It is not necessary to remove existing functionality. Maybe add a modifier-key on a keyboard or a checkbox in the rotation UI or in the app settings.

Adding more modes with modifiers is always the last option. I'd rather we find a way to support both use cases.

If, when specifying the character's AABB box, the origin is placed between his feet, then everything will be correct.

We can't rely on that.

[Nikoraito]

I understand the issue, but the current behavior is there because it makes snapping entities to the visible grid more intuitive. If we snap to the origin, this can break the current behavior in unexpected ways. Do you have any suggestion how to achieve both goals?

Edit: If we did snap the origin to the grid, this would often move an entity into or away from the surface under the mouse. That would not be acceptable IMO.

I agree snapping the entity's origin to the grid isn't desired here, but I don't think that's what OP is trying to address. It's just that the selection of the default point of rotation after that, when the entity is rotated, isn't of the entity's 0,0,0 point, but some other point in space.

I suggest:

1. Set the rotation point by default to the origin of the entity (its 0,0,0) always, regardless of the spawn conditions of that entity (placed in space, against a wall, etc.)

2. Add a button on the rotation tool next to reset which says "nearest grid point" or something to that effect, which places the rotation point on the grid point nearest the origin or whatever the behavior brought up by OP is currently.

I don't think the current behavior of the rotation point is at all intuitive, since it creates two undesirable situations: 1—relative to the entity, the rotation point seems to float around in space depending on the grid size, making it seem inconsistent, and 2—when the entity is rotated about a point that isn't its origin, its origin is bumped off of the grid, potentially into other brushes, which I would argue is quite confusing, and requires manual interference to correct afterwards.

[kduske]

@Nikoraito Thanks, that sounds like a good idea.

@nklbdev What do you think?

[nklbdev]

It would be great!

This would make it possible to correctly orient light sources and other objects.

I don’t use Quake, but import the maps into Godot.

The origin of the torches is on the wall.
The main character's origin is on the floor in the center of the lower circle of the body cylinder.

Now I've come up with a way to rotate an object around its origin. I go into rotation mode, copy the origin from the entity properties and paste it into the rotation center input field. After this, I can rotate the object around the center.

The biggest problem is not this, but the initial positioning of the object with the AABB snapping to the grid. After this, it is difficult to calculate the necessary coordinates for the origin so that it ends up at the grid point.

[kduske]

What should we do if more than a single entity is selected?

[nklbdev]

Hmmm. In Blender there are many rotation pivot vatiants: center, origin (of last selected object), 3D-cursor and others...
I don't know. I'll think about it tomorrow!

[kduske]

The question is where should TB place the rotation origin when there is more than a single entity in the selection?

• the origin of one of the selected entities
• the current strategy (center of selection bounds, snapped to grid)
• ...

To make things easier, we could make it so that the handle always snaps to an entity origin when it is dragged across the entities bounding box. That could be annoying for some other use cases though.

[Nikoraito]

Oh, very good question.

One strategy is to place it at the origin of the last or first entity selected in a series, which comes to mind from another software but I can't say if it's blender or not. Last-selected would make the most sense to use and I think flow very nicely.

A "center" button (perhaps replacing the previously discussed button when multiple entities are selected) could move the point to either the median of all the entity origins, or the center of the bounding box.

One caveat is that I think the centered behavior is what people will expect as default, based on the behavior of other editors like godot and unity; if you go with the last-selected as the default behavior, you may get complaints from users. However by making last-selected the default behavior and creating a "center" button for the center-of-bounding-box strategy, you allow both approaches to be used with relative ease. The question is how useful the choice is.

This is of course working with the assumption that you don't want to introduce any toggling modes/checkboxes.

[Nikoraito]

Also, maybe you could default to the centered behavior if the user uses some mass-selection like double-click or bounding-box, and last-selected if they only select one entity at a time?

This is a really interesting design question

[nklbdev]

Hello! I thought about it and I can offer the following options:

Options for snapping of the selection center (selection list or checkbox):
(I think you first calculate the AABB of the entire selection and then take its center)

• Snap the center of rotation to the grid.
• Place the center of rotation at the center of the selection without snapping to the grid.

Options for choosing the interpretation of objects (selection list or checkbox):

• Interpret PointEntities as origin points (Their AABB does not participate in the calculation of the overall selection center).
• Interpret PointEntities as volumetric brushes.

[kduske]

This is all too complicated in my opinion. So far, I think it would be best to

• use the entity origin as the default position for the rotation handle if one entity is selected
• use the current behavior (center of bounding box, snapped to grid) in any other case
• offer a simple way to snap the rotation center to the origin of an arbitrary entity (e.g. alt+click on an entity will snap the handle to the entities origin while rotate tool is active). This mechanic could later be extended to brush vertices and other interesting points, too.

[nklbdev]

Indeed, this is a large and complex topic.

use the entity origin as the default position for the rotation handle if one entity is selected

Personally, this would be enough for me

However, is it possible to add the ability to initially position PointClass-entities by their origin?

[kduske]

However, is it possible to add the ability to initially position PointClass-entities by their origin?

I don't see how that can work. Entities would end up in walls and floors all the time.

[nklbdev]

Snapping can be destructive at times. You can see this in the video.

2024-01-13-18-36-20.mp4

In addition, PointClass entities do not behave like SodidClass entities. They cannot rotate their AABB in any plane. Essentially they are just points. Their AABB's is just decoration.

Just please give users the ability to work with them as points. I think this will be enough.

P.S.:

I think we understand each other poorly because your entities are more classical. These are volumetric entities with an origin in the center of mass.

I think many would like to use entities whose origin is their point of “attachment” to the world.

Later, when loading the map into the game engine, they are replaced with other objects.

For example, a torch is on the wall. Its origin is at the point where it is attached to the wall. Its angles property allows you to direct it in the desired direction.

And so on.

I also want to say that I really respect your work, and I consider your editor one of the most successful. Its usability is very, very high!

[kduske]

I thought you were talking about the case when you are dragging an entity from the browser into the map. But when you are just dragging an existing object around, TrenchBroom snaps the drag distance, it doesn't care about the shape or dimensions of the things you are dragging at all.

I understand that you want an easier way of putting the origin on a grid intersection. I'll think about it. However,

In addition, PointClass entities do not behave like SodidClass entities. They cannot rotate their AABB in any plane. Essentially they are just points. Their AABB's is just decoration.

I don't know what a "SolidClass" entity is for you. If that's a brush entity, then that means you are counting things like monsters as "PointClass" entities, which they are not. Their bounding box is important to determine their placement because if the bounding box intersects with a brush, the entity will disappear in the game (that's true for most Quake games).

I think we understand each other poorly because your entities are more classical. These are volumetric entities with an origin in the center of mass.

Exactly. TrenchBroom isn't made to be a flexible tool to edit all games. TB makes assumptions that fit games that use the Quake engines. I don't want to make it more flexible just so that TB can fit everyone's engines and their assumptions.

[nklbdev]

Okay, I understand you. I'll find a way to work without these features.
Please don't take it to heart!
Your editor is by far the best I've found! ❤️

[Nikoraito]

This is all too complicated in my opinion. So far, I think it would be best to

• use the entity origin as the default position for the rotation handle if one entity is selected
• use the current behavior (center of bounding box, snapped to grid) in any other case
• offer a simple way to snap the rotation center to the origin of an arbitrary entity (e.g. alt+click on an entity will snap the handle to the entities origin while rotate tool is active). This mechanic could later be extended to brush vertices and other interesting points, too.

I completely agree with this