January 2025

For each of my Rigs I'd added bone items which are used only to animate the position of an object.

This is something that's quite common in video games. For example, you can animate the position of a weapon in the hands of a character directly via the character's animation.

This is what I use to position Cobble on Talas' tongue.

To have more control in the animation files without having to add new constraints, I've added support for Sub Items as I do with the hand and foot controllers.

For example, here the animation uses the tongue bone item, but Cobble's position is constrained by the Sub Item.

This avoids the need to teleport Cobble during transitions at the end of animations to give him the right orientation, as he will change orientation during the animation.

This also makes it easier to animate the camera in VR.

Most of the time I try to keep the camera constrained to the character whatever its animation.

If I animate the Sub Item in such a way as to move the character in a way that is consistent with the animation of his body, it's as if I were animating the VR camera directly.

So I've managed to get this result in VR. You can see that the animation remains more or less linear to keep the movement ‘VR friendly’.

I've also updated my MMVS plugin for blender by adding functions that allow me to pre-configure the scene using Item and Sub Items.

With a simple click I can prepare a blender scene for vore animations.

Animations

More animations.

Collisions Pass

I saw the collision boxes on Talas' head allowing Cobble to enter his beak in free movement without being blocked.

Not to be confused with contact collisions, which do not involve physical interaction.

Contact collisions are much more detailed, but also consume a lot more resources.

I've reworked this a bit too, but only on CPU optimisation.

Contact collisions will now only be updated partially, and the frequency of update will depend on the context.

VR Hand and Global Cleans

During this month I've updated the way the VR hands script handles the different tracking points.

Now the VR hands script will check all the tracking points available from the Open XR and will automatically adapt the points of interest such as the Grab, Aim or Wrist.

Per example :

Quest 2 will send the position of the controller, the Aim and the Grab, so I use this in-game data to generate the position of the Wrist using a predefined offset from the position of the controller. And I use contextual data to animate the fingers.
If I use Quest 2 with full finger tracking, it will only send the position of the Wrist and the finger tracking data. I will therefore generate the Aim and Grab positions from the Wrist.
The Steam index via Steam VR will reinterpret some of the data itself and send it all back. I then use all the positions without generating anything.

Since the tracking is updated in real time, it's now possible to change your controllers or mode without restarting the game as long as it's updated in the Open XR data.

Here I'm switching from controllers to full real-time finger tracking with the Quest 2.

Of course, I've kept in mind that the game is multiplayer and I've reviewed the replication of tracking points and fingers.

To optimise the net code I've created new data structures that are highly compressed and used specifically for transferring data online.

As before, the client will only send data that has changed in relation to the server, but with very specific requests to minimise the weight of the data as much as possible, and with different frequencies depending on the importance.

in Blue is the hand calculated locally and in red is the position understood by the server and which will be retransmitted to the other clients.

In game, of course, the positions are smoothed to avoid the teleportations that can be seen on the server side of the video.

Following the previous modifications I had to revise the code used for the VR grab and attachment points.

And I took the opportunity to make the interactions physical.

Basically, the physical simulation of objects grabbed in VR won't stop, movement and speed will always be simulated, as will collisions.

This allows for better interaction, for example when the player throws an object, as the object will retain its physical inertia.

It also prevents the object from falling through walls, and it's possible to push other objects with it.

Instead of being directly attached to the hand, the object will be physically constrained. I've also had to revise my Grab System to make attachment management configurable.

At the moment the hands themselves don't have any physical interaction, but that's something I'm planning for the future.

Stuck Zone System Moved to C++

I've updated the Stuck Zone System to migrate all the BP code to C++ and at the same time move the management of the net code directly to the character level.

It's a similar change to what I'd done previously with the situation system when it was migrated to C++.

As a reminder, the Stuck Zone System allows you to attach a character to an object and manage its state and certain animations depending on the context and the object.

Stuck Zones are often used in games.

When Cobble uses the ToyCar it's managed by a Stuck Zone, but also when Talas catches him in his hand or keeps him in his beak.

And of course when Cobble is glued to Talas's paws, under or in his shoes.

This is where updating the replication will have the greatest impact.

Talas's legs have 24 attachment points, the shoes have 32.

Given that replication is now managed at character level, this means that there are now 1 item per character, rather than 56 constant items in the net code bandwidth.

It optimises the gameplay without changing the number of attachment points.

In Editor Debug Tools

To make debugging and testing easier I've created little tools that run recurring scripts for debugging.

All I have to do is add the actor to my scene and it will automatically execute the debugging scripts with the parameters defined.

Additional Tools

To automate certain tasks and save time I had created a script that allowed me to create HTML files from Office documents specifically for the game site.

At the beginning of the month I reworked this script to make it more open to other file types via the Pandoc software.

I also added better management of media files and compression for the web.

This devblog's media currently weighs 232 MB, but with compression I'm down to 63 MB.