tempestvr
patreon
6-axis VaM Plugin
🕑 Added 2020-08-21 12:48:18 +0000 UTCIf you like VaM and you've built a T-wist this is the update you've no double been waiting for.
This is an update to my VaM Serial Controller (v2.1) to include a sixth axis: the "R0" or X-rotation axis. In short, now the girl in VaM can control the T-wist and when she rotates around you you can feel it. No doubt we can expect to see textured sleeves being sold out over the next few months.
Measuring this angle has proven to be slightly more tricky than the other five axes and I have in fact spent a lot of time on it the last week or so. A lot of it has been chasing down an annoying little bug. I'm pleased with the result though, and hopefully this can be the definitive VaM TCode plugin until VaM 2.0 comes in and I probably have to re-write the whole thing.
I have also included in this post the latest iteration of my prototype random stroker plugin, which will be familiar to my patrons. This will output TCode just like the serial controller, however instead of the girl controlling the plugin, this plugin will control the girl's hips. It's pre-programmed with a set of randomised thrusting, grinding and teasing motions.
In theory this plugin be dropped into any scene with a male and a female. Be sure they are in the right position first however or her pelvis will be catapulted across the room. No animation patterns are required, and in fact it works best without: just pose and go.
The control interface is still pretty primitive, but I'd love to hear feedback. This is also the sort of tech that could in theory be hooked up to something like the Nogasm/Protogasm. Let me know what you think.
Enjoy!
I'm off to see if I can figure out how to get these on VamHub.
Comments
NIghtmareQueenJune
Could you add this post to the VaM plugin tag here on Patreon? It would be way easier to find it this way.
Tom
Slightly off topic, but I've always been bothered by the video game parlance for Z axis as "distance in front of or behind the camera". I've always been a hobbyist DIY person, and that naturally evolved into 3D printing and designing things in CAD software. In the actual world, X/Y seem obviously to represent the ground plane, with Z representing altitude. I don't have any formal training and it's always driven me crazy when I try dabbling in Unity or similar frameworks. Am I just totally wrong, or is this some throwback to the origin of video games being mostly flat side-scrollers that didn't need 3 axes?
TempestVR
Not at all. Are you on the discord server? It'd be great to see you on there. We talk quite a bit about improving the code.
xanameg
Happy to share : - ) Sorry I may have jumped the gun on what needed sharing, though
TempestVR
I should also say thanks for sharing. This is useful stuff!
TempestVR
You're not supposed to *look* at my code. Good grief! Pay no attention to the man behind the curtain! No you are absolutely right. If you take a look at the code for the random stroker you will see that I have actually started to get a handle on quaternions and made much more extensive use of them. The Serial Controller plugin is many months old and predates all that knowledge. In an ideal world I could sit down and totally re-write the code to achieve 6-axis control, but with VaM 2.0 coming I just wanted to add the extra axis on the existing plugin. If you want to have a go at writing a better plugin I would be very happy with you doing that. In fact I'd be happy to give you all the help you wanted. I've got a lot of other stuff I want to be working on and not enough time.
xanameg
Seasoned game dev, here. I've just read your code. It looks like your intent, here, is to use RefLineX/Y/Z as a new coordinate basis. This is not a bad idea, but you are making things much more complicated for yourself by not using Unity3D's builtin transform mathematics. For instance, you should not be needing to use dot products against reference axis projections to calculate euler angles. Instead, you should project the pelvis into the coordinate space defined by your RefLineX/Y/Z lines and go from there. There are lots of ways to do this. I would recommend the following: Firstly, build a Quaternion representing the global rotation of your, ahem, "user" oriented reference space, rather than relying directly on reference coordinates. You can, for instance, do the following: IE, do not bother calculating RefLineY. Instead, compute RefLinex Quaternion q = Quaternion.LookRotation(refB-refH, refA-refB); This will createa quaternion representing the rotation of an object whose z-axis points in the direction from refH to refB, whose y-axis points in the direction from refB to refA, and whose x-axis is pointed in the only remaining direction. This lets you avoid using copious amounts of cross products : - ) You'll notice I picked these so that the, eh, "member" axis points along our new y axis, and so that the general perceptual forward direction is the z axis. This is, IIRC, different than what you have done, but it is Unity3D standard, and I have a hard time reliably breaking from that patterning. Substitute your preferred axes as you wish. Anyways, now that you have this quaternion, you can do some fun things: q * Vector3.up will give you what you once referred to as "refLineX" q * Vector3.left will give you what you once referred to as "refLineZ" (if I am not mistaken) q * Vector3.forward will give you, I am pretty sure, what you once referred to as "refLineY" Yadda yadda. The other thing this lets you do is compare angles. Say you wanted to know what the euler angle rotation of someones hips are relative to the coordinate system defined by q! Say you already have the rotation of those hips, and they are named targHipRot. What you seek, essentially, is: q * targHipRotLocal = targHipRot The multiplication order here is important, you can read up on it at: https://answers.unity.com/questions/810579/quaternion-multiplication-order.html But if we do some algebra, we arrive at: targHipRotLocal = Quaternion.Inverse(q) * targHipRot; So we can get the rotation of targHipObj relative to q just by left-hand-multiplying it by q's inverse. Neat! Now, you can do fancy things like: targHipRotLocal.eulerAngles.y = What you once called (I think?) rxTarget ? This should be your new 6th axis. targHIpRotLocal.eulerAngles.x will give you what you had called, I hink, rzTarget And finally for ryTarget, you will want targHipRotLocal.eulerAngles.z Anyways, definitely take a closer look at Quaternions. They are your friend, and they could have prevented your hours of headbanging over calculating yaw via axis projections!
