Skip to main content
14 events
when toggle format what by license comment
Jun 16, 2020 at 10:15 history edited CommunityBot
Commonmark migration
Feb 28, 2016 at 20:25 comment added Jon The method you are using, un-translates,rotates,translates; that's why the first parameter is necessary. When you switch to Quats, you are only replacing the RotationX/Y/Z methods with RotationByQuat(). You'll still do everything else the exact same. The planet geometry is always rotated to match PlanetQuat's vector component. If the vector component changes because PlanetQuat has been rotated, the planet doesn't care or need to know; it will always match itself to whatever the PlanetQuat's vector component is.
Feb 28, 2016 at 20:15 comment added Basic @Jon I'm building up to that... The planet is going to be rotating off-axis, the orbit isn't going to be around the equator, etc... This is just to get the basics right. Re: transform.position, no, that's the Euler angles for the current location and doesn't appear to be used for rotation. Re: Arbitrary origin for rotation, I'm certain you're correct in terms of matrices/quaternions, however, Unity has so many little helper methods, I suspect there's one that does a translate/rotate/translate back. In any case, thanks again for all your help
Feb 28, 2016 at 19:55 comment added Jon I suggest forgetting about Quat's altogether, for now; they are most helpful when you need to integrate more than one simultaneous rotation (Quat rotating Quat per frame). If you are rotating a single object, just stick to Matrix math like you've been using.
Feb 28, 2016 at 19:46 comment added Jon "arbitrary origin when using a quaternion" - no. The reason you have to specify the origin is because you're still using matrix methods. All inputs have to be reduced back down to RotationSpace, with the object at the origin (0,0). If you were applying the Euler angles, calculated by a Quaternion, to your Matrix transform, you'd already be done.
Feb 28, 2016 at 19:41 comment added Jon Does target.transform.position work for RotateAround(point, ..., ...)? planet.transform.position should work too, because both would define the same line/ray.
Feb 28, 2016 at 19:39 vote accept Basic
Feb 28, 2016 at 19:39 comment added Basic @Jon Thanks... That did it. The next steps are broken (of course!) as they're centering the rotation on the camera not the target, but I'll take some time to and try to wokr out how to pass in an arbitrary origin when using a quaternion. Thanks for all your help. Edit: Your comment above just hit the nail on the head...
Feb 28, 2016 at 19:39 comment added Jon We have to Scale, then Rotate, then Translate, with matrices because they all operate at (0,0). To revolve something that isn't at (0,0), you have to remove the translation and scale components, rotate, then reapply the missing components. Quats describe twisting around a direction vector, so they aren't really "at" a location (0,0) or otherwise; they operate on all inputs the same.
Feb 28, 2016 at 19:32 comment added Jon Me too; didn't see that last overload. Try using Space.World as your reference. camToTarget is relative to the world, not to Self.
Feb 28, 2016 at 19:31 comment added Basic @Jon RotateAround is deprecated. I had an "oh shit" moment after looking at the docs, but one of the overloads of Rotate() takes a Vector3 and an Angle (Scroll to the last section of this page. The default "Space" (reference frame) is "Self"). So I did get it right (more by luck than judgement). I verified by creating an explicit Quaternion rotation and multiplying it by the camera transform and got identical (slewing) results. That said, thanks for the suggestion... Never rule out stupidity
Feb 28, 2016 at 16:21 history edited Basic CC BY-SA 3.0
added 1659 characters in body
Feb 28, 2016 at 5:12 answer added Jon timeline score: 2
Feb 28, 2016 at 3:17 history asked Basic CC BY-SA 3.0