Acid Bubbles updated Embody with a new update entry:
Embody v1.4.3
Read the rest of this update entry...
Embody v1.4.3
Read the rest of this update entry...
-
-
Hi Guest!
Please be aware that we have released a critical security patch for VaM. We strongly recommend updating to version 1.22.0.7 using the VaM_Updater found in your installation folder.
Details about the security patch can be found here.
- Thread starter Acid Bubbles
- Start date
Ran into an odd issue today while putting the finishing touches on an upcoming scene.
I realized that I was using Embody for the male character (which works great) and Passenger on my "camera" as it flies around the scene when you do the cam view. (See my Last Goodbye scene for an example of how I've used it in the past.)
I decided it might be cleaner (requiring one less plugin) to just use Embody for both. I loaded Embody onto my empty object the same as I did before with Passenger, but I'm having some very strange jerky/skipping motions when I animate that object with Timeline and enter Passenger view in Embody that I don't see with just Passenger. I'll have to get some video to show you exactly what I'm seeing. It's super strange. It doesn't happen with every animation, and I was able to partially kill it by using the "smoothing" in the Passenger section of Embody. Unfortunately smoothing doesn't jive with the scene or that kind of tight camera movement, do I can't leave it that way.
Have you seen anything like that before?
I realized that I was using Embody for the male character (which works great) and Passenger on my "camera" as it flies around the scene when you do the cam view. (See my Last Goodbye scene for an example of how I've used it in the past.)
I decided it might be cleaner (requiring one less plugin) to just use Embody for both. I loaded Embody onto my empty object the same as I did before with Passenger, but I'm having some very strange jerky/skipping motions when I animate that object with Timeline and enter Passenger view in Embody that I don't see with just Passenger. I'll have to get some video to show you exactly what I'm seeing. It's super strange. It doesn't happen with every animation, and I was able to partially kill it by using the "smoothing" in the Passenger section of Embody. Unfortunately smoothing doesn't jive with the scene or that kind of tight camera movement, do I can't leave it that way.
Have you seen anything like that before?
@vamurai Mmmh, I spent quite a long time trying to improve on Passenger's fluidity when making Embody, but pretty much ended up with "I cannot do better than what I did with the original Passenger" so technically they use the same method. And it's absolutely fine to use Embody on more than one atom. It should be only enabled on one atom at a time, but I have a mechanism in place to auto-disable Embody when you enable it somewhere else... so I'm not sure what could be the cause. If you do have a video (or a scene I can try, it can be just the JSON doesn't need to be a .var) I'd be curious to see what you're observing.
Most of the time jerky animations are due to either frame drops or physics having a hard time, but if you don't have the problem with Passenger then there's definitely something to fix. Let me know if you have something for me to investigate!
Most of the time jerky animations are due to either frame drops or physics having a hard time, but if you don't have the problem with Passenger then there's definitely something to fix. Let me know if you have something for me to investigate!
Alright, I recorded a quick video of what I'm seeing. This animation is about ten seconds long, and the first time I run through it, I enable Passenger. The animated, rotating "camera" Atom is nice and smooth.
Next I run through the same animation again, only this time I enable Embody. The animation is no longer smoth, almost looking like it's dropping frames, or havign some other problem. I run the animation twice more with Embody, both times adjusting Rotation Smoothing up, and you can see that it seems to help the shaking a bit, but doesn't quite fix it.
Next I run through the same animation again, only this time I enable Embody. The animation is no longer smoth, almost looking like it's dropping frames, or havign some other problem. I run the animation twice more with Embody, both times adjusting Rotation Smoothing up, and you can see that it seems to help the shaking a bit, but doesn't quite fix it.
This is very obvious in the video... I'm confused why you'd get such different results. I don't have enough time at the moment for as serious investigation I did try a quick camera animation using Embody and Timeline and it looked smooth, so I imagine there's something here. If you can send the scene JSON I can at least verify that I also cannot reproduce in your scene, but I'll investigate more regardless as soon as I can.
For sure. I'll get you a copy of it tomorrow to take a look at. Again, it's strange, it doesn't happen in all animations, only some of them. I'll also spend se more time with it and see if I can get some more data: (Is the frame rate actually dropping? Are there other things that can impact it, like the amount or angles of movement of the Atom? What other settings in Passenger/Embody can I modify to create/remove the problem?)
Thanks for looking into it! Ultimately not a huge deal right now, but it was definitely strange to see, and had me second-guessing my animations for at least an hour or so! Haha.
Thanks for looking into it! Ultimately not a huge deal right now, but it was definitely strange to see, and had me second-guessing my animations for at least an hour or so! Haha.
PM'd some more info, and a link to that file!
Alright, here are some preliminary tests.
I ran some back-to-back comparisons between Passenger and Embody to see if frame rates were a problem. From what I can tell, it doesn't seem to be an overall frame rate dip.
Next I tried to see what I could tell about the different animations, and why some seemed okay and others didn't. After tinkering, it seems that the amount the Atom rotates seems to have more effect than how far/much it moves. Here are some demo clips I took that show what I'm getting at:
Here is the a clip of the original animation:
Here are internal and external clips of JUST movement of the atom, no rotation:
Here are internal and external clips of one axis with A LOT of rotation:
And a pair of axes with moderate rotation:
And one axis of moderate rotation, along with one axis of moderate movement:
Based on my testing, I feel like there must be something off in how it's translating or trying to smooth rotation. I hope this helps!
I ran some back-to-back comparisons between Passenger and Embody to see if frame rates were a problem. From what I can tell, it doesn't seem to be an overall frame rate dip.
Next I tried to see what I could tell about the different animations, and why some seemed okay and others didn't. After tinkering, it seems that the amount the Atom rotates seems to have more effect than how far/much it moves. Here are some demo clips I took that show what I'm getting at:
Here is the a clip of the original animation:
Here are internal and external clips of JUST movement of the atom, no rotation:
Here are internal and external clips of one axis with A LOT of rotation:
And a pair of axes with moderate rotation:
And one axis of moderate rotation, along with one axis of moderate movement:
Based on my testing, I feel like there must be something off in how it's translating or trying to smooth rotation. I hope this helps!
It definitely does, I didn't have time to investigate yet but it was already clear from your original video that there's something Embody is doing wrong (or, not "as right") somewhere. I'll read this carefully and let you know how it goes!
I think the problem is linked to specifically z rotation (roll), which is a great clue. I can easily reproduce the issue (or at least one of the issues, we'll see).
And I have a bad solution 
Running the algorithm _twice_ per render frame. I'm not sure yet where the margin of error comes from, but I have a plan B if I don't figure it out
Running the algorithm _twice_ per render frame. I'm not sure yet where the margin of error comes from, but I have a plan B if I don't figure it out
@vamurai figured it out! Here's what happened. To align the camera to a specific point, I have to make some weird stuff; namely, I move the navigation rig around so the "head" ends up aligned with the object. But the head is "higher" than the floor, which means when you rotate around the y axis, the position stays the same, but when you rotate around the z axis, the actual position moves _a lot_. And since I did those calculations together, it didn't account for the rotation actually moving where the "floor" should be. So, the next frame, there's some distance to catch up, etc.
The solution: compute rotation first, then position next. Fix coming up
The solution: compute rotation first, then position next. Fix coming up
Acid Bubbles updated Embody with a new update entry:
Embody v1.4.4
Read the rest of this update entry...
Embody v1.4.4
Read the rest of this update entry...
This was a WAY faster response than I expected! Thanks for your effort here, fantastic work!@vamurai figured it out! Here's what happened. To align the camera to a specific point, I have to make some weird stuff; namely, I move the navigation rig around so the "head" ends up aligned with the object. But the head is "higher" than the floor, which means when you rotate around the y axis, the position stays the same, but when you rotate around the z axis, the actual position moves _a lot_. And since I did those calculations together, it didn't account for the rotation actually moving where the "floor" should be. So, the next frame, there's some distance to catch up, etc.
The solution: compute rotation first, then position next. Fix coming up
- Messages
- 273
- Reactions
- Points
- 43
@vamurai figured it out! Here's what happened. To align the camera to a specific point, I have to make some weird stuff; namely, I move the navigation rig around so the "head" ends up aligned with the object. But the head is "higher" than the floor, which means when you rotate around the y axis, the position stays the same, but when you rotate around the z axis, the actual position moves _a lot_. And since I did those calculations together, it didn't account for the rotation actually moving where the "floor" should be. So, the next frame, there's some distance to catch up, etc.
The solution: compute rotation first, then position next. Fix coming up
Wait ... Embody modifies the navigation rig?
That might explain some trouble I've been having running Embody together with FreeRotate.cs - I didn't want to bother you with it, bcs, while FreeRotate is a favorite of mine, it's rather old-ish, contains some "ugly" hacks of pretty basic level VR-navigation functionality, and is probably amongst the lesser-used plugins.
(Problem is that when I used both Embody and FreeRotate and "pitched down" past roughly 45° degrees, somehow, the movement axes would get swapped (like fwd/back would become up/down ... something like that))
Nothing I'd want you to bother yourself with - but maybe it might give me a hint as to what is going wrong with two of my favorite plugins.
P.S.: Could I impose on you to give me a pointer where exactly Embody is making the abovementioned calculations for the Navigation Rig? (I could always run a diff of the two most recent versions, true, but ... I'd feel better "hearing it from the horse's mouth" rather than poking around semi-blindly ...)
Last edited:
@case762 sure! This is the spot: https://github.com/acidbubbles/vam-embody/blob/master/src/Passenger/PassengerModule.cs#L266
There was a lot of experimentation to get there but there's not a lot of code! Note that there's this in the latest version to allow rotating the X axis with Passenger:
github.com
So maybe you don't need the other plugin anymore?
There was a lot of experimentation to get there but there's not a lot of code! Note that there's this in the latest version to allow rotating the X axis with Passenger:
vam-embody/src/Passenger/PassengerModule.cs at master · acidbubbles/vam-embody
Plugins to improve possession experience (include Improved PoV, Passenger and Snug) - acidbubbles/vam-embody
github.com
So maybe you don't need the other plugin anymore?
- Messages
- 273
- Reactions
- Points
- 43
Thanks!
Errrrh ... do I see this right that Embody is querying the VR Controller-Joystick to modify the pitch? Bcs I just ran Vamurai's new scene with the latest Embody and I could swear ...
... hmmmh.
?!?
Yeah, if Embody indeed allows to control pitch with the VR-controller stick, my main reason for using FreeRotate would indeed be gone.
P.S.: Which stick is "JoystickControl.GetAxis(SuperController.singleton.navigationUpAxis)" listening to - the VR-Controller Joysticks, or the "X-box controller" sticks? (I vaguely recall we were having a tangential discussion a while back, and you convincingly explained to me that messing with VR-Controller binds in VaM is a tough one, bcs there's no option to disable VaM's default VR-controller settings (unlike the default VaM keybinds, which can be disabled by the user)? Something like that?)
It's the right VR stick; and indeed, generic bindings to the VR controllers are tricky because of the VaM integration, but here I have a special case because I cancel whatever VaM does with the joysticks due to the nature of the plugin, so I'm free to record the joystick actions and do something else with them So yes I could add xbox controls too if they don't work already.
So yes I could add xbox controls too if they don't work already.
- Messages
- 273
- Reactions
- Points
- 43
It's the right VR stick; and indeed, generic bindings to the VR controllers are tricky because of the VaM integration, but here I have a special case because I cancel whatever VaM does with the joysticks due to the nature of the plugin, so I'm free to record the joystick actions and do something else with them
Yay!
Not for me - my main usecase for FreeRote is "finetuning position in VR". Little on-the-fly adjustments to better align my body position with the PoV-char's body posture. I usually do some "personalization edits" to scenes, which means I'm already juggling the keyboard and the VR-controllers - adding the X-Box controller to the mix is ... not really what I'm looking for.
All right, well let me know if the new behavior works for you!
@Jiraiya I missed your message, sorry! (feel free to join on on Discord, it's sometimes easier to follow conversations). I tried doing a few videos in the Embody wiki, did you see them?
I had a super vision of the wizard, but as I implemented it and tested it with people I realized it wasn't as obvious as I thought. You need to contortion yourself a lot to position your hands and body in a way that's meaningful. That's why I made it experimental... so you're not stupid (at least his isn't point to you being stupid!) it's just something that "clicks" once you get it.
Check out the wiki and the videos, it should help: https://github.com/acidbubbles/vam-embody/wiki/Snug
But in a nutshell, the idea is that you simply "offset" how much closer or further from your body should the VR hands be, so they "touch" at the same distance even though your size is not the same.
Imaging you put your hand on your stomach. Your VR hand is 5 inches away from the VR person's stomach! That's not good. With Snug, you can tweak the "stomach scale Z" and "stomach offset Z" to adjust the hand so it touches your stomach in VR too.
Enable the rings to "see" the difference and center of your offsets.
I had a super vision of the wizard, but as I implemented it and tested it with people I realized it wasn't as obvious as I thought. You need to contortion yourself a lot to position your hands and body in a way that's meaningful. That's why I made it experimental... so you're not stupid (at least his isn't point to you being stupid!) it's just something that "clicks" once you get it.
Check out the wiki and the videos, it should help: https://github.com/acidbubbles/vam-embody/wiki/Snug
But in a nutshell, the idea is that you simply "offset" how much closer or further from your body should the VR hands be, so they "touch" at the same distance even though your size is not the same.
Imaging you put your hand on your stomach. Your VR hand is 5 inches away from the VR person's stomach! That's not good. With Snug, you can tweak the "stomach scale Z" and "stomach offset Z" to adjust the hand so it touches your stomach in VR too.
Enable the rings to "see" the difference and center of your offsets.
Wow Case, I didn't know about that Free Rotate plugin. I would have been all over that except Acid Bubbles went ahead and did a better fix!
This is a huge accessability help for me with nasty arthritis that has totally seized up my neck so I can't rotate it at all.
I came here to ask about that line in the update hoping it meant what I thought it meant! Off to try it out!
Free rotate will be a nice help in some scenes that just don't have the male and you basically hover in position. Although I could continue to do my current hack and just throw embody on something like the player navigation object. No clue what that does, but I seem to be able to embody it and rotate it freely.
This is a huge accessability help for me with nasty arthritis that has totally seized up my neck so I can't rotate it at all.
I came here to ask about that line in the update hoping it meant what I thought it meant! Off to try it out!
Free rotate will be a nice help in some scenes that just don't have the male and you basically hover in position. Although I could continue to do my current hack and just throw embody on something like the player navigation object. No clue what that does, but I seem to be able to embody it and rotate it freely.
You cannot "save" the Embody state, you can activate it as part of a trigger though.
