[ANSWERED] Rokoko Motion capture suit news ?

[emullis]

@woland

thank you for the update on this. I purchased two smart suit pro II's not too long ago and, in a zoom meeting with a tech person, asked some questions about this. he said that, contrary to what some folks are saying on the Rokoko Discord, the original Rokoko studio software will not go away. It is no longer being updated, but it will remain operational, so Izzy will remain usable there. Of course, the new suits and studio software are way better in terms of quality of tracking, streaming, and mocap data recording. 

to answer your question: I have a v1 and v2 suit and they both work on either software version. 

I'm doing a project with the suits and Izzy, and would therefore be happy to help with testing. 

[Woland]

@emullis said:

It is no longer being updated, but it will remain operational, so Izzy will remain usable there.

 Yes, indeed. I have used it with a v1 suit for a project recently.

---

@emullis said:

to answer your question: I have a v1 and v2 suit and they both work on either software version. 

I'm doing a project with the suits and Izzy, and would therefore be happy to help with testing.

Feel free to send in a support ticket asking to join the beta program (it's free, there's just a form) and I can get you access to the update Rokoko Studio Live Watcher for testing if you like.

Best wishes,

Woland

[Armando]

@woland Thanks Woland,

I tried today and my first report is that it works very well indeed ! There is just a confusing thing about address port in the manual. Having been using using OSC for a long time It took me a bit to understand. In the MIDI/NET preferences pane we can set the ip port number. In OSC the port number must be the same port that the app who's sending the OSC data (Isadora's default is 1234). Now, my initial reflex has been to set isadora on the same port that appears on the Rokoko Studio Live watcher (14043). When I did that Isadora didn't seem to receive the data that was streamed correctly by Rokoko studio software latest version.

So I quit everything, relaunched isadora, set the Midi/net preference "ip port number" (in Isadora) back to 1234 and then relaunched the rokoko studio software. Everythink worked right away.

Bottom line, I think that : for people that are used to receive osc streams in Isadora and that are used to set ip ports numbers to match  the port number of the software that is sending osc, there should be a note in the mini tutorial that comes with the izzy Rokoko actors that tells them that matching ip port number is not necessary to receive data from the rokoko. In other terms Midi/net precerence pane ip port number can be anything. The important thing is that the port in the rokoko studio software matches the port in the rokoko studio actor in isadora. I hope I am clear.

An additional note I would add is that it would be nice to know what are the coordinates that Isadora receives when the avatar is in the origin point in the rokoko suite.

One last thing (but I have to test better to be more specific). It would be nice to have the elevation value if a character is climbing a stair or a prop.

Just initial thoughts.

Ciao

[Woland]

@armando said:

It would be nice to have the elevation value if a character is climbing a stair or a prop.

 That would be the y-value, no?

[mark]

@armando

Does this look sufficient?

[Armando]

@mark

It looks ok to me, thanks Mark. Maybe you could specifically add a phrase telling that the midi/net port is specifically intended for OSC. I don,t know if Python web requests might create another port conflict. It is out of my league. But it is something to keep in mind.

[Armando]

I filed a bug ticket but I am putting it here although it might not be the appropriate place. I am sorry if this is an inconvenience. But I noticed some inconsistencies between the Rokoko studio live watcher and the skeleton decoder.  

Try the following

1) IN a fresh scene put rokoko studio live watcher and connect the skeleton output to the skeleton input of a skeleton decoder. Tracking output of the latter passes from 0 to 1 if, of course, the livrestream option of the rokoko studio software is active.

2) disconnect the 2 actors

Tracking output on the skeleton decoder is still outputting 1

Now after having disconnected the 2 actors, if I reset to default values the skeleton decoder acor in order to have again a 0 at the tracking output of the skeleton decoder and try to reconnect the skeleton output of the Rokoko Studio Live watcher actor to the skeleton input of the skeleton decoder, I see the red sign at the end of the connection line that tells me that I can't connect the 2 again

Now if I try to put a gate between the skeleton inputs and outputs of the 2 actors gate "in" input property doesn't become " it just becomes three dashes

One last thing : but it is probably a Rokoko studio software problem.

1) livestream in rokoko studio is on with suit conneted

2) disconnect the suit

3) I see that the rcv packet is on.

4) if I disconnect the suit still the Rokoko studio live watcher rcv packet is on.  And a simple integer counter connected to this output property proves it

My suggestion is to add a bypass input property in the rokoko studio actor. so Isadora is not crunching unnecessary numbers saving a little CPU

Lots of more testing are coming. Where is the best place to share that ?

Cheers

[Woland]

@armando said:

1) IN a fresh scene put rokoko studio live watcher and connect the skeleton output to the skeleton input of a skeleton decoder. Tracking output of the latter passes from 0 to 1 if, of course, the livrestream option of the rokoko studio software is active.
2) disconnect the 2 actors
Tracking output on the skeleton decoder is still outputting 1
Now after having disconnected the 2 actors, if I reset to default values the skeleton decoder acor in order to have again a 0 at the tracking output of the skeleton decoder and try to reconnect the skeleton output of the Rokoko Studio Live watcher actor to the skeleton input of the skeleton decoder, I see the red sign at the end of the connection line that tells me that I can't connect the 2 again
Now if I try to put a gate between the skeleton inputs and outputs of the 2 actors gate "in" input property doesn't become " it just becomes three dashes

 Logged, though it seems you can skip a few of your steps. Placing any actor with 'skeleton' data type input or output and resetting it to default values makes that input/output unable to be connected to outputs/inputs with the 'skeleton' data type.

1. Place a Skeleton Decoder actor
2. Select it and choose "Reset to Default Values"
3. ISSUE: It can no longer be connected to actors with a 'skeleton' output, it shows the red circle with the line through it instead when you try to connect it
4. Place a Gate actor
5. Connect the 'out' output property of the Gate actor to the 'skeleton in' input property of the Skeleton Decoder actor
6. ISSUE: The Gate actor's input and output properties mutate and show "---"

[Armando]

@woland Thanks for your brilliant way to circumvent the broadcast limitation.

I still think that as a mutable input that accepts everything else in Isadora, the value input in broadcaster actor should, in theory, accept skeleton data format too. And I have a reason for that. Instead of creating a bunch of broacasters (21 body parts outputting 3 values for x,y,z each means 63 broadcasters and 63 listeners) could just put a rokoko studio watcher with one broadcaster attached to the skeleton output and then just a skeleton decoder with the body part(s) specified in the "point sel" input property attached to the desired input in other actors. I Don't know if this is clear.

Of course all this can already be achieved by broadcasting JSON and parsing it. But I still think that it would be easier. Just a thought

[Armando]

@Armando OH MY GOD !!!! I tried to connect a broadcaster to skeleton output property of the rokokko actor and putting a listener in data mode and it works ! It is just that listener type must t be set on data. when like that its value output becomes "skeleton" if attached to a skeleton decoder. The only confusing part is that the broadcaster value input doesn't show data not skeleton but just three dashes ! It works !!!!

Link to video