Official release notes show that Daz Studio has supported websockets since 2015, though I don't think I've ever seen them used by any plugins. For instance, to drive a live animated face from a domestic webcam (e.g. F-Clone 1.12 can do that, though only it seems only Unity has the inputs needed, via a cheap websockets plugin).

As for Poser, it does not appear to have websockets(?). Though there are a half-dozen open-source websocket Python implementations. 

Initially my general and rather theoretical questions are:

1 - would Poser be able to even support a live data-feed input from a websocket, if a simple Poser-friendly websocket was to be made available via a Python script?

2- could Python then process the resulting data feed, by translating it in real-time into viewport animation of a Poser character's face? The ideal would be to get a live 15 FPS cartoon face in the viewport, using Poser's Comic Book Preview, rather than photoreal rendering.

In F-Clone's case, the stream of data sent is per-frame rotation data which targets the following list, so presumably some translation of names to Poser-dials would be needed:

The developer's English was poor, so in the above list "Mouse" = Mouth, and "Frawn" = Frown. This could be easily fixed in a Poser websocket script, presumably.

With "remote control" of Poser I have already occupied myself 10 years ago :)  For a long time for fun and experimentation. At the end I had a website with which I could operate Poser 9/10 completely.   Everything was built from HTML controls.Including a "preview" of what Poser was currently displaying. The main reason was that the powerful server with the Poser installation was in the server room, Poser runs only on Windows and I use only Linux since ages. RDP and the like was just too slow for Poser at that time.

But things have changed over time.

Currently if I do "remote control", I do it with MQTT and a PAHO client adapted for Poser as part of a script for a special purpose.  Mainly it is used to do gestures and poses (funny to watch when several people work on a group of figures in Poser at the same time, sometimes two on the same character).

By the way, MQTT also supports websockets.

If you don't already know what MQTT is: It's a server application that can receive "commands" from "senders" and forward them to all clients that are connected to certain channels. Sender and receiver can be everyone at the same time (who has access to the server and this has not been restricted).

More precisely, the scheme of my implementation is that all Poser instances first load the same figure and log on to the central MQTT server (by starting the script). The script sets up callbacks for all "actors" (i.e. parameters in the actors of the figure), so that the status of the parameters are reported to the MQTT server. The last updated value of a parameter is the current one that is actively reported to the connected clients.
So whichever connected client last turned the Poser dial "arms up":  All connected Poser instances will perform this movement for their character.

Sending a command is trivially simple:
    send(str("[figure name]/[actorname]/[parametername]"), float(value)).
    send("LaFemme/Body/ArmsUp", 0.5)

As you can imagine, these commands can be issued not only with Poser Callback. A client for a smartphone is a snap, especially since there are already quite a few easy-to-use MQTT client apps for e.g. Android/Apple, with which you can build interfaces with buttons, sliders and the like (actually, those are used for "home control").

So the whole thing makes sense even if you don't have several people working together. For example, you can easily do camera and light control with your smartphone. Touch control instead of mouse push and click for Poser :)

Unfortunately, Poser is out of demand for all the interested people I started the development for (Poser 12, "beta status", a lot of security concerns, no future). And so I haven't done anything else on it for over a year.  But the concept will probably be continued with other software for this particular purpose now (hasn't been finally decided yet).

Answers to your questions:

> 1 - would Poser be able to even support a live data-feed input from a websocket, if a simple Poser-friendly websocket was to be
> made available via a Python script?

Websocket is only the protocol to transfer some data. But something has to produce the data and Poser must process it.

So, yes, it can be done. And websocket is only one way to transfer the required data.

> 2- could Python then process the resulting data feed, by translating it in real-time into viewport animation of a Poser character's
> face? The ideal would be to get a live 15 FPS cartoon face in the viewport, using Poser's Comic Book Preview, rather than
> photoreal rendering.

Of course. But this is where the hard part begins :)

The transport is trivial. For Poser you need a function that opens a channel where Poser can receive something. And a function that either polls this channel constantly or something that is thread controlled.

And without a "return channel" this is just a gimmick.

Thanks adp001. Good to know that a Python websocket script-set may not be the only option. I was trying to avoid haring down the $1,500 Apple smartphones and multi-user capture room route, though, which is what it sounds like you've developed.

I was thinking more like: one person on a Windows PC and an old $50 webcam, greatly speeding up the creation and expression-accuracy of realtime Comic Book renders. Renders intended for comics made with the aid of Poser.

I'm unclear about why the user would need a "return channel" here? Are you perhaps assuming a multiuser performance stage where actors need to respond to each other?

HartyBart posted at 1:12 PM Mon, 18 October 2021 - #4429059

I'm unclear about why the user would need a "return channel" here? Are you perhaps assuming a multiuser performance stage where actors need to respond to each other?

Using a Python server lib in Poser is not as easy as it sounds, because all those libs are made around Pythons TCPServer using socket.select(...). They will block Poser until something happens on the selected port.

Here is the source of a websocket server at github

You have to find a way around that blocking problem. If you find a solution, you will get support for just one single App. I would prefer a more general solution to connect Poser to the outside world. I think a "Broker" (a server outside of Poser) is the better solution.

I made a TCPserver some time ago. Maybe that can help in some way:

https://adp.spdns.org/#PoserTalkr

Thanks, your PoserTalkr.py looks impressive. Though I'm still not clear about the need for a two-way data stream though, on a websocket. StackOverflow clarifies a bit on the differences between TCP and WebSocket, and this seems to help me understand:

"When you send bytes from a buffer with a normal TCP socket, the send function returns the number of bytes of the buffer that were sent. If it is a non-blocking socket or a non-blocking send then the number of bytes sent may be less than the size of the buffer. If it is a blocking socket or blocking send, then the number returned will match the size of the buffer but the call may block. With WebSockets, the data that is passed to the send method is always either sent as a whole "message" or not at all. Also, browser WebSocket implementations do not block on the send call."

My attempt at a translation: A TCP byte stream needs to flow both ways. But Websocket messages only need to flow one-way.

Also useful was this explanation:

"The problem is that usually Web servers have only one port open for security reasons, namely port 80. By definition one port can attach to one application ONLY. So what if a client wants to use a service, other than Web (HTTP), but there is only one port available? Voila! Websockets! These allow you to initiate a connection via HTTP, but then negotiate to use the websockets protocol (assuming the server is capable of doing so) to allow a more "TCP socket"-like communication stream."

Clarifying attempt at a translation: "A TCP byte stream needs to flow both ways (talking 'there and back, and back again'). But Websocket messages only need to flow one-way ('sender-to-receiver')." There is no need for a websocket to request and check the messages sent to it, they just flow in constantly.

HartyBart posted at 5:11 PM Mon, 18 October 2021 - #4429076

Also useful was this explanation:

"The problem is that usually Web servers have only one port open for security reasons, namely port 80. By definition one port can attach to one application ONLY. So what if a client wants to use a service, other than Web (HTTP), but there is only one port available? Voila! Websockets! These allow you to initiate a connection via HTTP, but then negotiate to use the websockets protocol (assuming the server is capable of doing so) to allow a more "TCP socket"-like communication stream."

What the above explanation means, is, that a server is only reachable via a certain port. This is port 80. Behind this port usually runs a piece of software, called "webserver". this webserver is able to analyse the message the client used to contact the server and decides if http or another protocol like websockets is requested by that client for further communications (see "http header"; in the websocket-server source I mentioned above: Line 368).

HartyBart posted at 5:23 PM Mon, 18 October 2021 - #4429077

Clarifying attempt at a translation: "A TCP byte stream needs to flow both ways (talking 'there and back, and back again'). But Websocket messages only need to flow one-way ('sender-to-receiver')." There is no need for a websocket to request and check the messages sent to it, they just flow in constantly.

Note that the roles are clearly defined. The client in this case is the one that sends the data. This is the software that produced the data from the webcam. The client sends the data to the server, i.e. to Poser. In order for both to understand each other, Poser must run the complete server protocol. Otherwise the client sends nothing, because the client thinks that there is no real server listening.

As long as you do not control both sides, you must follow the standard protocol (HTTP protocol). This is the basic requirement for the web to work at all and for data to end up where it is supposed to.

If you control both sides, you can immediately switch to another, simpler system. Here, for example, it would be short, stateless UDP messages. That means only a handful of lines in the script.

StackOverflow clarifies a bit on the differences between TCP and WebSocket, and this seems to help me understand:

The misunderstanding might be: Websocket is a web protocol which uses TCP sockets for network communication :)

I was trying to avoid haring down the $1,500 Apple smartphones

Seems your solution, F-Clone, is dead now. I couldn't find any store to buy it.

But maybe this here is something: https://androidappsforme.com/facial-motion-capture-apps-android/