GameGuru MAX - Add Origin Toggle for Widget and Extra rotation modes

[MonkeyFrogStudio]

Snapping is not quite right. When you change the snapping amount, it seems to move the entire grid just a bit making it difficult to snap items if you change snapping at any point while working on a level. I have a video showing what I mean. After the video, I will explain what I was doing in it:

https://user-images.githubusercontent.com/36735507/155939454-de7b07dd-1fe4-4943-8eb5-038cc16d4fc5.mp4

In the video I've brought in two cubes. The cubes are both 32 units on all sides. I've initially set snapping to 32 on the X and Z axis and, as you can initially see, the cubes snap perfectly to each other. I then adjust the snapping for both axis to 16. As soon as I touch the first cube, it moves slightly. From this point on, it's impossible to snap it to the second cube. But this should not be the case. 16 is half of 32 and, as such, it be able to snap perfectly. After all, two 16 unit grid snaps is exactly equal to one 32 unit grid snaps. But it won't snap. However, if I then touch the second cube, it also moves a bit and now both cubes can be snapped. It's as if the grid had moved when the snapping was changed and touching the cubes caused them to snap to the new grid position.

Next, I adjusted the grid snapping to 8. Again, the behavior is displayed. Touching one of the cubes makes it move and it can no longer be snapped to the other cube until the other cube is also touched so it can reposition itself to the new grid position. Returning grid snapping to 32 gives us the same problem as the grid appears to have moved again. Both cubes have to be touched in order to be able to be snapped together using grid snapping.

This is not a good way to work. Let's say you've placed dozens or hundreds of pieces using one grid setting and, then, for whatever reason, you change your grid setting. Now everything is off! Does this mean you have to go back and re-adjust everything you've already put down because the grid has moved?

I purposefully chose to work with a power of two number for this example. The numbers should work. Items made to snap to each other at a setting of 32 should also snap at 16. And they do ... provided you start with 16 and don't change the grid snap setting. But if you change it when they are already set to a grid, then they won't snap properly to anything newly placed (as seen in the video).

This is not proper grid or grid snapping behavior. The grid should not move (or appear to move) when changing it's value, especially when sticking with something like an even number or a power of two. In a case like what I've demonstrated here, I shouldn't have to risk already placed entities moving if they are touched because grid snapping is activated and the snapping value has been changed. And I should be able to snap entities even if grid values have been changed.

[MonkeyFrogStudio]

Change the grid value should only divide the grid, not cause it to shift.

BTW - why are we allowed to change the X and Z grid settings independently? When would I need a different grid setting for one than the other?

[LeeBamberTGC]

Fixed for this evenings EXP build.

[MonkeyFrogStudio]

@LeeBamberTGC Can't wait to test this one. :)

[MonkeyFrogStudio]

I take it there wasn't an evening build for this (4-21) because I don't see this fix in it?

[LeeBamberTGC]

@ArgentArts It went out quite late. Now on the nonsteam build internal too. Maybe describe what you see in your latest version.

[MonkeyFrogStudio]

@LeeBamberTGC I've taken a look and grids and grid snapping aren't working properly. This is based off my experience in other 3D applications, both modeling programs and game engines. I'll provide an example from Blender:

https://user-images.githubusercontent.com/36735507/164748108-59433c21-93e9-4563-95bc-eaef07e728e2.mp4

In the above video, I set Blender's snapping to 1.000 initially and move a few cubes to show that they snap perfectly, having been made to fit the grid. Then I reset Blender's grid to half that size, 0.500, and move the cubes again. They don't shift anywhere at all when clicked on. When moved, they snap perfectly. It just takes two grid squares to do so, instead of one, since the grid size was halved. I halve the grid again, 0.250, and, again, the cubes don't shift when clicked and they snap perfectly together. What I DON'T have to do is move every single cube to get them to all snap together again. This is because halving the grid size didn't move the grid, but literally cut it in half.

Now, let's look at what happens in GameGuru MAX:

https://user-images.githubusercontent.com/36735507/164749608-1d15985b-5f66-4530-9acc-8f01419a8899.mp4

The cubes were made to snap perfectly to 32 x 32, so the initial grid is set to 32 x 32. I've aligned and snap three cubes, just like in the Blender example. They are perfectly snapped and, as can be seen, they even align to the empty terrain grid. When I move the cubes, they react like the first example in Blender, snapping happily. Then I cut the grid size in half to 16 x 16 and that's where things change. When I click on the first cube, it shifts, as if the grid had shifted. And now it is no longer possible to snap and align that cube to the other, previously placed cubes. The only way to get things to align at this grid size is to MOVE EVERYTHING ELSE, which is not a good option ... not if you've been working on a level and have hundreds or even thousands of objects placed. You need to be able to change the grid and not have to readjust all the previously set objects.

Halving the grid size again presents us with the same problem - the grid seems to have shifted again making it impossible to snap objects via grid snapping that once previously snapped unless they are all moved to the new grid position. Anything that was previously set, whether it was snapped to the grid or not, if it gets clicked on, will move to the new grid position!

MAX's grid should work like the example in Blender in the case I've shown here. Since the pieces are built to work on a power of two grid (they are 32 x 32), then they should snap well at 32, 16, 8, 4, etc., equally well without having to be repositioned if they had been snapped at one of them or the other.

I hope these videos and my explanation has helped. If people, like myself, want to release modular pieces for MAX or work with modular pieces in MAX, then snapping has to work right else this becomes an extremely frustrating experience.

[LeeBamberTGC]

@ArgentArts The current grid system added a correction to always grid snap to the center of the grid tile, not the corner. I have changed to align to the top left of the grid tile to see if this has any adverse effects on other users, in the next EXP build. Hopefully the change is not noticed and helps align with the way most artists expect the grid to work.

[MonkeyFrogStudio]

@LeeBamberTGC MAX just updated for me, but grid snapping is behaving the same. I take it this is not yet in the experimental build?

[LeeBamberTGC]

@ArgentArts Nope :) Just knocking a few more off the list while I am in the zone.

[MonkeyFrogStudio]

@LeeBamberTGC I almost cried! I actually gasped! YES! This is exactly how grid snapping should work! Thank you!

[MonkeyFrogStudio]

@LeeBamberTGC Now I'm crying for a completely different reason. Snapping for me is messed up again on all my previously created levels. Even with starting new, we are right back to where we started from. I'll post a video to show you in a moment.

[LeeBamberTGC]

@ArgentArts Video and explanation of what is messed up will help. Right now my build aligns offset and size perfectly at any object size and grab position :)

[MonkeyFrogStudio]

@LeeBamberTGC I may be wrong ... with my newly placed pieces, it now appears to be working, but it's still not quite as expected. I am experimenting and will post a video soon.

[MonkeyFrogStudio]

@LeeBamberTGC So, the issue is that things are jumping when clicked:

https://user-images.githubusercontent.com/36735507/165602880-44926988-6dfd-4aa1-bc79-881deb60c9ae.mp4

(also posted in the other thread)

Other than that, it's looking good. I think I overreacted. I apologize.

[MonkeyFrogStudio]

@LeeBamberTGC Jumping seems to depend a lot on WHERE you click on the object:

https://user-images.githubusercontent.com/36735507/165623304-22023c47-2caf-40f2-8d1f-afc09ded8fd0.mp4

[MonkeyFrogStudio]

@LeeBamberTGC I'm used to the widget sticking to the model/object's origin instead of moving to wherever the end-user clicks. It's often useful as it tells the end-user where the model's origin is. So, when you select a door, for example, and the widget is active, you know if the origin is placed properly for using scripts for animating the door to open/close, etc. It also tells you how the model/object will rotate since the rotation widget would be automatically positioned at the origin of the model. When the widget is just wherever the end-user has clicked, then you really don't know for certain how the model will rotate until you start to rotate it. Same with scale - it's an indicator of where it will scale from, etc.

[synchromesh62]

@LeeBamberTGC I'm used to the widget sticking to the model/object's origin instead of moving to wherever the end-user clicks. It's often useful as it tells the end-user where the model's origin is. So, when you select a door, for example, and the widget is active, you know if the origin is placed properly for using scripts for animating the door to open/close, etc. It also tells you how the model/object will rotate since the rotation widget would be automatically positioned at the origin of the model. When the widget is just wherever the end-user has clicked, then you really don't know for certain how the model will rotate until you start to rotate it. Same with scale - it's an indicator of where it will scale from, etc.

Have to strongly disagree there .. Classic has always placed the widget where you click and for big models its greatly needed. In fact it was something many users reported as a bug a couple of months back when we did not have it. If you zoom in directly to the top of as door for example to make a slight adjustment its very frustrating if you cannot see the widget to move it.

[AmenMoses]

I agree with synchromesh, the widget needs to appear at the place you clicked the mouse as otherwise when zoomed in for fine movements it just doesn't work.

Also I would request that we have the option to either: 1) rotate around the objects origin, relative to the object orientation (i.e. pitch, yaw, roll) 2) rotate around the origin relative to world axis. 3) rotate around the centre of the object, relative to the object orientation (i.e. pitch, yaw, roll)

The latter is needed for physics objects, as regardless of the mesh origin the physics origin is always the centre of the object.

[MonkeyFrogStudio]

Fair enough.

I see where a majority of our disagreements come from, though (or at least I think I do) - It's a contrast between how things were done in GameGuru Classic and how things are done throughout the majority of 3D apps (modeling programs and other game development apps) on the market. It does make sense, for the sake of consistency, to stick with many of the ways that things were done in Classic for those that have been using Classic. However, it's good to be aware that it may be a sticking point (or at least an oddity) for those of us that approach MAX having not come from Classic, but from other game engines or work a lot in other 3D modeling programs. The way that MAX does a lot of things is ... odd ... from that perspective, but "normal" from the perspective of those who have grown used to using Classic.

The developers of GameGuru MAX need to think about their target market - is it GameGuru Classic users upgrading to MAX? Is it new users who have never used a GameGuru or TGC product before? Is it both? And, if both, what compromises, if any, should be made when it comes to what carries over from the old (as far as how things were done vs. how most things are done just about everywhere else).

The widget, for example, is not just for moving things about (or scaling and rotating). As pointed out, it's normally an indicator of where the object's center is. This way, when you turn the widget into a rotation tool, you know exactly how it's going to rotate. Right now, with the widget being anywhere, you don't. The same goes with scaling via the widget.

As far as being able to move things when we can't see the widget, well, there are a number of ways around that. We can move our view and we can even tap F1 to turn off the widget and move the object via smart move, etc.

[MonkeyFrogStudio]

No worries. I am approaching this as a modeler. Having built levels and worked on complex levels and models, I haven't run into this issue (not being able adjust something for fine movement, etc.). But I can only speak as I see things. I am only one voice. ;)

[Necrym59]

Can we just have a simple tick box option for origin point selection, i prefer the way click anywhere idea as it is now but i do like to find the origin ocasionaly as well. First rule should be 'give the user the option'. It should be availabel in both developer and normal modes, a quick tick for when you need it readily accessible.

[MonkeyFrogStudio]

Heh. I was going to suggest that, actually. ;)

[synchromesh62]

Heh. I was going to suggest that, actually. ;)

Ye i can live with that :)

[MonkeyFrogStudio]

It could be a Developer's option, actually. So, the standard mode could be click anywhere. For anyone that wants to use the widget at the origin, it could be activated via a tick box under the Developer menu. That way, it's out of the way, etc.

[Ratall]

Having the widget appear where you click on the object is convenient but also knowing were the pivot point(origin) is extremely useful. Is there not a way to highlight the origin while allowing widget positional flexibility.

[OldFlak]

I have noticed the same as ArgentArts when it comes to the widget origin point. But being used to Classic it was like just go with it. However if the option was there I would mostly have it show at models origin point, so please give us the option.

AM's options would be awesome - tomorrow is good :)

And please, can we stop hiding options like this in the settings panel. Once developer mode (if we must have it) is turned on, these options should be easily accessed in the UI - not hidden away.

Stop breaking the UI for New Users sake - they will learn :)

[LeeBamberTGC]

I have renamed this and marked as feature request so we do not lose these cool ideas :)