We have some fixes for spatial transforms in the coming 6.0.2 version. I tried your patch in it and didn't see any problems. Just to be sure, can you describe what the issue is? What am I looking for? thanks!

When you open the patch, all the objects are horizontally aligned. If using only "X-Z rotate" and "X-Z zoom" parameters everything works fine. Then if you change "Y move" parameter, still no problems. But then if you again change "X-Z rotate" (when "Y move" is not 0) the behavior becomes strange. If you set "Y move" back 0, the objects should be again horizontally aligned but they are not. Even if you disconnect snapshot~ objects, and try positioning camera manually, you can not get back to initial horizontal alignment. It seems that some "automatic" rotation of rendering context takes place somewhere in the process.

When do you plan to release 6.0.2 version?

Thank you!

Maybe you want tripod mode. Try jit.gl.camerea @tripod 1 . In non-tripod mode, which is similar to a flight simulator, there is some bank that happens when rotating in a plane that isn't parallel to the XZ plane. This is what you're seeing. @tripod 1 corrects this. It's like having a camera mounted on a tripod.

Thanks Wesley. That helped but brought me to another problem. When using tripod attribute, Y position is not working when X and Z are set to 0. It seems that Y gets stuck when setting X and Z to zero. I have to significantly change X and Z to unstuck the Y...? See the patch below please...

You can't have a camera at 0 x 0 with tripod 1 since that's counter to what tripod mode entails. If you always have a little bit of x or z, the y should work.

the problem with the second patch posted is that you are setting position at (or close to) position (0,0,0), and you are also setting your lookat to (0,0,0).

since you also have tripod 1 enabled, and you are increasing your Y position, the object can't resolve a position that satisfies both conditions (tripod mode and lookat 0 0 0), and therefore ignores the your position value.

simply set your pak to [ pak 0. 0. 2. ]

@Wesley: Try setting X and Z to some little values, even 0.4, which is much more than little. Y gets stuck and works buggy. In Max5, "tripod 1" was on by default, although that attribute never had a name AFAIK. And having X and Z at 0 while moving Y was never a problem, regardless of lookat position.

@Robert: Why is problem only when changing Y? If lookat is (0,0,0) and position is (0,0,0), I can freely change X or Z and it works fine. And that is how it was in Max5. I never had problems if lookat and position attributes were the same.

The Bottom line is that what I am trying to do (camera moves "on the surface" of the sphere and looks into the center) was "easy" to do in Max5 but in Max6 seems either impossible or there is a bug that prevents it. Please fix that or publish some tutorials because some things have become bizarrely complicated in Max6.

Thanks

Hi t,

I haven't tried your patch, and although it does sound like you should be able to do what you're trying to do in Max6, if you want to do it another way, check out my z.glRotate abstraction. Made in Max5, but works fine in 6 (just tested). I've attached it here, but you can also get it here: http://zacharyseldess.com/z.abstractions.html

best, Zachary

hi t. there is no gl.camera object in max 5 so i'm not sure how it's become bizarrely complicated in max 6. if you want to use the old-style gl.render attributes to move the camera, they still work perfectly.

as mentioned, your problems are a combination of setting camera position very close to lookat with locklook enabled, and trying to align the direction vector with the camera Y axis, as a result of tripod mode enabled. either, disable tripod, disable locklook, or don't align your direction vector with your camera's Y axis (by adding some z or x values in with the y).

this same problem is apparent in max 5. open your last patch in max 5 and replace the gl.camera with prepend camera, attached to a gl.render. as soon as you change camera-y, the image disappears. this is simply a result of the math behind virtual cameras.

we understand that many of the new features are not thoroughly documented and explained yet, and there are solutions for that forthcoming. in the meantime, we are paying close attention to the forums to offer any help and explanations we can, and your feedback is very much appreciated.

also, make sure you check out the new jit.anim.drive object as a possible option for controlling your camera movements.

Try this.

@Zachary: Thanks a lot! Great abstraction! I just need to change mousestate object with 2 numberboxes, change the scaling parameters and that abstraction will be perfect for what I need.

@Robert: You are right, the image disappears also in Max5 when X and Z are set to 0. I wasn't aware of that. But the main thing is that nothing gets stuck in Max5. In Max6 camera gets stuck when X and Z are set to 0. More than that actually - if you try the patch Wesley Smith has posted you notice that minimum attributes of X and Z numberboxes are set to 0.1 and 0.05. Even with that values the camera or image gets stuck / freezes.

And thank you for your explanation.

@Wesley: Very sexy solution, thanks a lot! From technical perspective, that is the patch I need, but from practical perspective, the problem is still present. If I open your patch in Max5 (using camera attribute of git.gl.render) everything works fine. But not in Max6 with jit.gl.camera object. If I set both X and Z to minimum values (0.1 and 0.05) image or camera stucks again - so it is obviously a bug.

It is great what you did with Max6. It has an enormous potential and I can't wait to seriously dig in. But on the other hand, it is very buggy and in my opinion, it was released too soon. Because the thing is that I never know if I am doing something wrong or am I facing a bug. And usually, as in this thread, it is a combination of both. And it takes ages for me to figure out where the bug ends and my mistakes begin...

@t There isn't a bug here. The reason the thing doesn't move when the patch is first loaded is that I didn't put a loadbang on one of the number boxes, so when you go to change the middle box, the radius is 0 in the equations so the camera is going to be stuck at 0 0 0. This isn't because the camera has a bug. It's because the equations in the expr boxes told it to stay at 0 0 0.

@Wesley: if you change all 3 numberboxes (randomly) and then set X and Z to their minimum values (0.1 and 0.05) the camera/image freezes. Y numberbox stops working anb also Z numberbox stops working. That I thought is a bug. I might be wrong but I don't have any reasonable explanation...?

this is all part of the same issue. there is a built-in feature that keeps the camera position from occupying the same space as the lookat point when locklook is enabled, so that the image doesn't disappear as it does in max 5.

i will evaluate how this currently works for a future update, but i'm not sure how much this will change.

for now, your best bet might be to disable locklook, and just set the lookat point manually each time you update the position (just put a bang to a message box "lookat 0 0 0" after your position setter).