What I like & what I don't

I don`t see a difference. Thus my question. When i type in four times 30 into the offset box then i am at 120. When i add 30 four times to the absolute value, then i am also at 120.

The only difference is that i need to do that in an extra edit box. And that i don`t need to add a mathematical sign like a plus or a minus. But in case of a multiplication it`s already better to be able to calculate instead of working with an offset box.

1. Create a box at zero.
2. Set the pivot orientation to 'Object', position to 'Selection'.
3. Make sure in 'Object Mode'.
4. Turn on 'Move' manipulator so we can see the axis directions.
5. In 'Manipulation Input' Window, set this to the Rotate-Absolute field, (45, 45, 45) and execute it. Make a screen shot of this pose. Name it 'pose1'.
6. set this to the Rotate-Absolute field, (45, 90, 45) and execute it. Make a screen shot of this pose. Name it as 'pose2'.
7. Undo and the Rotate_Absolute files should be back to (45, 45, 45).
8. set this to the Rotate-Offset field, (0, 45, 0) and execute it. Make a screen shot of this pose. Name it as pose3'

Compare the three poses you should be able to spot the difference.
The visual expolanation, imagine you rotate it by your hand in the real world.
pose 2: From zero orientation, rotate x 45, rotate y 90, rotate z 45.
pose 3: From zero orientation, rotate x 45, rotate y 45, rotate z 45, rotate y 45.

As you can see, if you use the the absolute fields, The application will read the values of the three absolute fields to generate a result space. But if you use the offset fields, the application will only read the input offset value and rotate the manipulator by that amount along the corresponding axis from the current manipulator pose. The same as you just use your mouse to rotate that axis by the offset input amount manually.

The only thing about my conception that is bugging me is, that you perhaps always have to switch between object and world space. What if I mostly want to edit the absolute postiion but also the local rotation axis? I think it would be wise to have a window where the local and global values are side by side. Besides position and orientation, I would put Size on the global column and Scale on the local column. The layout would still be the same, just that the offset fields would be replaced by the local values.

As I said, the "local" checkbox should have an impact on the input fields. Or even better: Forget about the local checkbox, remove it and control it via the manipulation setting as you would normally do. So these two don't work against each other and you always know where to set your space.

No, I'll still keep it. You can try this
1. Create Two objects.
2. Rotate them sperately so they don't have the same orientation and should be facing different directions.
3. Make sure the two objects are selected.
4. Check the 'Local move' Option.
5. Drag Position x/y/z label to move the two objects. They should move in different directions. You won't be able to to this with the manipulator method.

I'm still trying to understand how things work and what the implication of my suggestions are. I feel the concept of the input fields in Nvil is not quite intuitive, maybe I even found a bug.

Translation/Move/Position: When I am in object space and enter a value on one axis into absolute, it translates/rotates by world axes. But when I click&drag the axis letter in front of absolute, it translates by local object axis? The numeric input should also work on local axes, just like click&drag. Remember, that when changing to object space the input fields should all be set to 0 (at origin/pivot of the object) and everything I enter in this mode would be an offset along the local axis. The world space holds the absolute position of the object.

Rotation/Orientation: This time the behaviour should be the other way around. Object space holds the rotation in relation to world space axes. Nvil already does that, but there's a small bug, that got me confused. The absolute input of the x-axis rotates around the world x axis in object mode! It should defintately rotate around the local axis as do the y and z axes. The click&drag of the x-axis works fine though. Now in world space, rotation always displays as 0.0.0 and everything I enter there is an offset around world axes. The values for all the axes in object space would change accordingly. When I would now enter an expression for rotation into one field while in object space, only this axis would update. Nvil does that already.

In this setting I don't see the need for "Offset Fields" if I would be able to use + - / * in the input fields.

I attached a simple scene to play around with that I used to visualize what is happening when fiddling around with local rotation and move.

I think it is quite a simple concept. The offset fields and x/y/z label drag are used to mimic the operations you do with the manipulator in the scene, highlight axis, clik and drag.

No, I'll still keep it. You can try this
1. Create Two objects.
2. Rotate them sperately so they don't have the same orientation and should be facing different directions.
3. Make sure the two objects are selected.
4. Check the 'Local move' Option.
5. Drag Position x/y/z label to move the two objects. They should move in different directions. You won't be able to to this with the manipulator method.

So this is a cool trick (thanks for sharing), but there are a few coherence issues with that: I should be able to enter the numeric offset directly (like valueX+1) to move a bunch of objects 1 unit in each local direction. But this trick only works in the object list. When I'm in object mode and try the same thing in the manipulation window, it won't work. All objects get translated along world axis. Why is that if I'm in object space?! That's what I mean by "lack of concept" or unintuitive.
With these offset fields I'm still not able to do multiplication/division.

Your example to demonstrate the differences when rotating are absolutely true, but I don't think that is what he actually meant. Let's say we are again in object space and want to rotate something around a local axis. If I enter ValueX+45 into a field, as a modeller I should know that all the values for all axes get recalculated, because they change their orientation in worldspace. That's due to the fact, that they must remain perpendicular to one another (not in maya as I mentioned).

I think that you really did a fine job, but my opinion is that my suggestions would make the software more coherent and therefor easy to use and understandable.

I think that you really did a fine job, but my opinion is that my suggestions would make the software more coherent and therefor easy to use and understandable.

I understand and very appreciate your input and the app has been improved by your good suggestions already. But sometimes it is possible that the app works in a different but better way and you haven't understood yet.

The only thing about my conception that is bugging me is, that you perhaps always have to switch between object and world space. What if I mostly want to edit the absolute postiion but also the local rotation axis? I think it would be wise to have a window where the local and global values are side by side. Besides position and orientation, I would put Size on the global column and Scale on the local column. The layout would still be the same, just that the offset fields would be replaced by the local values.

I don't think it is practical as there are world, object, selection, parent, screen, manual space options here. By the way, 'What if I mostly want to edit the absolute postiion but also the local rotation axis' can be achieved already in the 'Manipulation Input' window with proper pivot orientation/position settings.

So this is a cool trick (thanks for sharing), but there are a few coherence issues with that: I should be able to enter the numeric offset directly (like valueX+1) to move a bunch of objects 1 unit in each local direction. But this trick only works in the object list. When I'm in object mode and try the same thing in the manipulation window, it won't work. All objects get translated along world axis. Why is that if I'm in object space?! That's what I mean by "lack of concept" or unintuitive.
With these offset fields I'm still not able to do multiplication/division.

The input fields in 'Object List' are for individual objects. They are not manipulator related. While the input fields in 'Manipulation Input' window is selection and manipulator related. They work on the whole selection as a group in all modes.

Your example to demonstrate the differences when rotating are absolutely true, but I don't think that is what he actually meant. Let's say we are again in object space and want to rotate something around a local axis. If I enter ValueX+45 into a field, as a modeller I should know that all the values for all axes get recalculated, because they change their orientation in worldspace. That's due to the fact, that they must remain perpendicular to one another (not in maya as I mentioned).

Of course, if you enter ValueX+45 into absolute field, the app will recalculate. But if you enter 45 in offset field, it is not. Imagine you have an object in the scene, you don't care what its current orientation is, you just want to rotate it along its y axis by 33.3 exactly, how can you do it with just absolute input fields?

The good news is: Your object transformation already works better than Blender's! I couldn't find a way in Blender to rotate an object around a global axis by numeric input. It always uses the local axes. It seems you can only rotate around global axes via visual tools in Blender, regardless of which space you have chosen.

But you can use multiple arithmetic expressions in the input fields. So if for whatever reason I want to rotate or translate by additional 3 times 12/7, it's no problem. Just type in "+3*12/7" behind the original value and you're done. Sadly, Nvil can't do that (yet).

Ok, I let alone your precious offset fields for now. They just should do multiplication as well.
But what I still don't understand: 3 different windows to input values. That's 2 too many. Furthermore:

The input fields in 'Object List' are for individual objects. They are not manipulator related. While the input fields in 'Manipulation Input' window is selection and manipulator related. They work on the whole selection as a group in all modes.

Why would you do that?! For me it makes more sense, if it wouldn't treat the selected objects as a group when in object orientation mode. Think about this: I have a bunch of non-uniform objects (different position, orientation, scale[not to confuse with size]) selected and want to offset each of them by a specific value along the local x axis of each object. Same goes for rotation and scale! As I see it, it's not possible at the moment.

*Whew* This is a tough one. ^^

+ Island selection method is useful and pattern selection is quite fun!

As you can see, if you use the the absolute fields, The application will read the values of the three absolute fields to generate a result space. But if you use the offset fields, the application will only read the input offset value and rotate the manipulator by that amount along the corresponding axis from the current manipulator pose. The same as you just use your mouse to rotate that axis by the offset input amount manually.

I start to understand what you mean. What i don`t understand though is why this shouldn`t work with an expression and just one edit box. You just manipulate just one edit box by an expression, so just this axis should change. The first value of the expression is the absolute coordinate, the second value is the offset.

I start to understand what you mean. What i don`t understand though is why this shouldn`t work with an expression and just one edit box. You just manipulate just one edit box by an expression, so just this axis should change. The first value of the expression is the absolute coordinate, the second value is the offset.

Give me an example of the 'expression'. Do you use that in TrueSpace?

Let`s say i have 30 in the Y rotation. Then i type in a +30. What you can read now is 30+30. When i hit enter then it turns into 60. And the model rotates to 60.

trueSpace uses Eulerangles though. Means when i type in 190 then the expression for this axis jumps to -10. And the other angles may change too, flipping by 180 degrees. Which is a bit nasty sometimes. Because you cannot add it in the way you do with your offset box. trueSpace was Beta when it gots abandoned. And is pretty incomplete in some areas. So Blender is a better example here. It works with Quaternions, and counts up or down behind 0 and 360. Also here a 30+30 is a valid expression. Or a 430*2 Or 60/5.4 Or 120-50. It rotates around the chosen angle by the calculated value. Which is what you do with your offset box.

Since Blender is free, why don`t you simply download it and try it there? To see the Properties panel with the edit boxes hit N

I was expecting an 'Expression' you mentioned which is so special that I can distingquish it's absolute or offset input. If you are not so sure, it's ok.

I have the feeling too that we talk about two different things sometimes. But that`s the way it is

I was expecting an 'Expression' you mentioned which is so special that I can distingquish it's absolute or offset input

You can

19+22
=
Absolute Value + Offset Value

Can't use it. 19+22 can be considered as a new absolute value of 41. Unless you can type in colors and green as absolute red as offset. lol.

You need of course to do string parsing in that case, and separate the two values. With the math signs as a delimiter. And then you can use it

But i still don`t get why you are this fixed at the offset edit boxes and its offset methods anyways. No other app uses this method. Could you please tell me one case where your offset method is of any better use than using absolute values?