New Grid System (align with how 3D modellers work)

[LeeBamberTGC]

MOVE GRID CONTROL Move the grid snapping system from the object properties to a global location at the top menu bar so can be toggled quickly based on what is being edited. It is not a per-object property at all. Notes below from internal talks: Firstly, I don't know of a 3D modeling app or 3d game editor that has separate numeric inputs to set grid size/snapping for each axis. In every program I've every used, other than MAX, if you set the grid to 10 and/or set grid snapping to 10, then it snaps to 10 on the X, Y, and Z axis. This is because you typically want your grid to remain squared. You don't want a grid that's 10 on the X and 15 on the Z. It's also simpler. The end-user only needs to input a single number and that affects the entire grid on all axis. One number would rule them all ... not three (one for each axis). Secondly, grid snapping is always at the intersect where lines cross on a grid, not at the center of the square formed by the grid lines: In the above image, snapping would occur anywhere the lines intersect (I've circled one in red), but not in the center (I've highlighted one area with a red 'X'). Thirdly, objects snap to these intersects based on the object's origin: In the above image, we see the cube's origin is at it's center (as indicated by the circle in the middle of the widget). As you can see, the object snapped to the intersect right where the object's origin is. In the above example, the object's origin was moved to a corner edge. When snapping the object, it snaps to the grid intersect, again, by where it's origin is. In this last example (above), the origin is offset to some place other than an edge or face. The origin still snaps exactly to where grid lines cross. Thirdly, all 3D modeling packages and 3D game editors have snapping on all three axis, X, Y, and Z. MAX currently does not have snapping on the UP or Y axis and this is needed. When creating an interior level, for example, it's important for snapping together upper floors, floors to stairs, etc. Most game objects are built according to a grid, so snapping these objects to get precise placement is a must ... and this includes on the Y axis.

GRID AXIS LOCKING AND PRESERVING OBJECT MESH Y-OFFSETS With regards to y coordinate not respecting local coordinated when trying to place within a build/entity ect. Ideally even if the offset is a 0.0.0 or centered at the local coordinate or changed when importing, placing an entity will always try and place it on top off which ever object you try and place it within. The work around solution to bug/issue is to place the object on flat terrain that is at the same height as the object you want to place within, after which you can use the object widget to move it in place. As you can see, from the image when placed on flat ground the pipes retain the y coordinate height, however once you try place it inside of the objects, it moves above the object + the height of the coordinate offset. Really good work around to the problem would be the ability to lock a particular axis, with either the properties menu or with the widget by adding a widget menu when right clicking. That way you can lock one or two axis and only move in the unlocked axis. FPSC NOTE: with regards to snapping to a particular axis and you will show me where this is located. In FPSC we had a directional arrow that pointed the direction the object will snap in X, Y or Z. it is definitely worth looking at adding back, as it is definitely something I will be using for DLCs in future and users will need to be able to see which direction it snaps.

[MonkeyFrogStudio]

@LeeBamberTGC Just a note (based on the title) - this is not just the standard for 3D modelers, like 3ds max, etc., but also the standard for 3D game editors, like Unity, Unreal, Flax, Godot, etc. It's just how it works in 3D.

[AmenMoses]

Can I suggest, on the subject of object origin, a key modifier to force snapping to centre of object regardless of origin.

i.e. (assuming C key used), then if C key is pressed then object centre used as snapping point, Shift-C could also then do the same but also include Y axis.

There are a lot of models out there with weird origin points and, especially when used as physics objects, when positioning them it often makes more sense to use the actual centre of the object rather than wherever the mesh origin happens to be.

(one example that comes to mind are things like wheels/gears/pulleys or ball shapes where you want to position them on a shaft or centrally on top of another object)

Of course this could also be a toggle rather than a modifier.

As a matter of interest does/could the model importer allow the origin/orientation to be altered on importing entities?

When I am constructing vehicles out of parts I often have to export the mesh to something like Fragmotion so I can re-orientate an object to face front or to reposition the origin to match the sensible physics body origin, for example a front wheel steering car needs it's origin to be the centre of the rear axle (i.e. where the radius point of the steering is) and to face +Z. I can't really do this when the only thing I have available is a .dbo file for the model so it would help enormously if this could be done in the importer.

[LeeBamberTGC]

@AmenMoses Back in the days of 2D, we used to call them hotspots and it was always very convenient and useful to move them to exactly where you wanted them, adding this ability in the model importer makes a lot of sense.

@MonkeyFrogStudio Keeping aside the possibility that pressing C and SHIFT+C might mess with other keyboard shortcuts, is the ability to dynamically adjust the anchor position of a selected object (for the temporary purpose of grid snapping) a common ability in other 3D tools, and if so, how do they accomplish this? What I would prefer to avoid is loading up the grid system with so many buttons and options that to a new user who just wants to snap an object to a grid, the system overwhelms them. Hiding extra stuff in advanced is one solution, but I would always prefer a single intuitive system than a nest of prosumer functionality only three people will ever use :)

[MonkeyFrogStudio]

@LeeBamberTGC 3D modeling apps do not dynamically adjust the object center (or, as you've termed it, anchor point). The person modeling the object sets that themselves manually. Normally, if you wanted to create a physics object in a 3D modeling app to be used in a game engine, such as a wheel, you would ensure the object center is right at the center before exporting to be used in a game engine. Since this is the case, there seems to be little reason to be able to adjust this in a game engine's editor ... but that's my opinion. I think, in AmenMoses case, since he's not a modeler, he has to rely on models obtained elsewhere and, as such, cannot guarantee where the object center is. Since this may be the case with many users of MAX, it might be something to consider anyway.

Case in point - I create a door in Blender to be used with the Door script that does not require any animation. I ensure the object center is at the edge of the door where it would swing (the hinge), then export so that once the model is in MAX it swings open/closed appropriately. So, from a modeler's perspective, there's no need to do this in MAX itself. However, once again, someone may not be a modeler and may purchase or get a free door model somewhere and the object center may not be in the correct place. This would make that model unusable to them.

As far as the keyboard shortcuts, it reads like AmenMoses was using that as an example only. In any case, I, personally, don't think this is something that should be done dynamically at all. If the object center needs to be adjusted, it should be done on import. Perhaps something to indicate where the object center is and some means to adjust it before committing to import?

[AmenMoses]

The keyboard shortcut thing is more to do with the fact that a lot of the time you have stock objects with the default origin at the centre floor point but when plonking them down in the scene in a different context want to position them centrally on another entity.

Having to make two versions of the same entity (via the importer or even by editing to original in a modelling app where possible) is a bit of a faff,

[LeeBamberTGC]

@AmenMoses Gotcha, sounds like something that will need careful demonstrating when we have the first draft of the new grid system up and running. No sense my implementing what I 'think' you mean at this stage. Let's get the grid settings out of the object properties and into the top bar, then we can see what keyboard shortcuts we need for the basic stuff, and what we can add for faff-removal :)

[OldFlak]

I have not found a use where I set any one of the grid settings differently - they are always the same in my use case. My usual setting for all four numeric inputs is 10 - but that doesn't mean to say others won't use them differently.

[Necrym59]

You cannot make Max into a modelling app, tbh just let the modelling apps take care of the model and its origins and just deal with it when it comes in, when imported and detect its origin and show it. You could change it there perhaps but i would let the modelling app and modeller correct it.