<div dir="auto">I apologize that I couldn’t read some of this. I agree that Holger does very good work. Despite that, I initially had difficulty introducing HAnimSegment-based HAnimDisplacers into the mix when HAnimJoint-based HAnimDisplacers worked extremely well with skinned examples. All I’m suggesting is to try to come up with a small example with both joint rotations and segment-based displacers, so the next person doesn’t get tripped up by the same issue. Holger works very quickly, and makes patches quite well. I was hoping for a verified example of something we might want to work sometime in the future, if not right away. I realize you spent a lot of effort at this, and I don’t want to lose that effort.</div><div dir="auto"><br></div><div dir="auto">If Holger has stated “won’t fix,” that would be something that may be very difficult to implement and something to be considered during the standardization process.</div><div dir="auto"><br></div><div dir="auto">I realize you are now on another path, but I want to pick up loose ends if you still have them.</div><div dir="auto"><br></div><div dir="auto">A Jin/Cindy with both facial animation and joint rotations will do. Preferably without extra scripting.</div><div dir="auto"><br></div><div dir="auto">I understand that things get trampled by further developments, which why I tried to reach out quickly.</div><div dir="auto"><br></div><div dir="auto">I have yet to join the MCCF seriously, I admit that. A Google Drive or GitHub link can serve as an alternative source of data to the mailing list, and is probably preferred. YouTube videos work too. OBS seems preferred to make videos, at least on Windows. No voice over needed. If you make videos links on your GitHub README.md, that can be a good source too, an perhaps less public.</div><div dir="auto"><br></div><div dir="auto">I don’t do many presentations myself, due to a birth defect, so I totally understand a reluctance to do them.</div><div dir="auto"><br></div><div dir="auto">John </div><div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sat, May 30, 2026 at 4:56 PM <<a href="mailto:cbullard@hiwaay.net">cbullard@hiwaay.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello John:<br>
<br>
First we (Claude and Claude) did this building on your example. We had <br>
to scale down manyclocks to fit the Jin example. Not a problem but then <br>
gluing the manyclocks head back to the Jin head was tricky as you said <br>
it would be. Then no matter what we tried, we could not get SAI signals <br>
to activate the displacers. That was three days of work. We didn't <br>
isolate why and Claude kept surmising it was an implemenation problem <br>
with X_Ite.<br>
<br>
I was and am skeptical about that. Holger does very good work. The <br>
X_Ite SAI signatures are complicated by polymorphism but that is <br>
acceptable given how many formats it supports. The Whack a Mole of web <br>
standards works like that. No complaints. But developers outside this <br>
community probably need more explanations and more samples. Given the <br>
small size of the active X3D community at this time, resources are <br>
stretched or that is my conclusion. My efforts to build on W3DC tech <br>
are not expected and I have come back in medias res so I have to pick up <br>
and learn more faster. Always ready to be tutored. As the SEALS say, <br>
training is everything.<br>
<br>
AI helps and it complicates. It is a hard worker and knows more about <br>
X3D than I expected but it is seldom current, absorbs the noisiness of <br>
the web including HTML coding that is not that great for training. <br>
Given the fifty first dates aspect of sessions, and that LLMs are <br>
pattern matching engines, working examples are sine qua non to training <br>
them. If one is patient and tests everything, the results are good <br>
particularly if one has as I do, a weak math background.<br>
<br>
Figuring out ways to guide multiple LLMs through a project without <br>
building elaborate harnesses was the first problem and here my <br>
background in structured document processes for engineering integrated <br>
product development was perfect. We learn a lot from military <br>
logistics. But we ARE the domain experts.<br>
<br>
Last night I had to concede to Claude that we weren't making progress. <br>
MCCF implementation is the goal. So I said let's try it the way Claude <br>
suggested: direct through the API. We had devised a simple test <br>
harness for testing the displacers and it changed the code to support <br>
the direct from API approach. It worked immediately. So in a single <br>
session this morning we were able to add the morph system to the facial <br>
editor and run it against the original jin figure mapping the manyclocks <br>
coordinates to the Jin head. And it works. Today. Much more testing <br>
remains.<br>
<br>
MCCF saves data to XML formats then loads that into an X3D scene running <br>
in X_Ite. That enables us to save out the scene data in a non X3D form <br>
that can then be used in other media. IOW, old school markup design for <br>
long lifecycle multiple use, the Holy Grail of military logistics <br>
systems. For me, virtual theatre. For others, simulation systems. <br>
Horses for courses.<br>
<br>
I think what we have is an alternative. Not a replacement. I do not <br>
intend to try to replace X_Ite. That would be stupid. What I offer is <br>
a supplement. A scene builder and character creator in an integrated <br>
framework with X_Ite at the core for rendering and X_Ite or other <br>
editors for building the geometry. I needed an H_Anim editor to meet <br>
the constraints of that framework. So we built one. It can be used by <br>
other systems but it is explicitly designed and tested for MCCF.<br>
<br>
We will turn soon from h-anim editor construction back to the scene <br>
construction tasks where the Q personna (MCCF) engine drives the <br>
emotional expressions and other behaviors given interacting <br>
agents/characters in zone/agents with feedback to the MCCF engine. <br>
Proximity sensors are the key and other sensors can be added. Dialogs <br>
are stored as text and emitted by the TTY voices resident on the <br>
operating system platform. Eventually Eleven Labs or other richer voice <br>
systems.<br>
<br>
With the exception of daily handoff files for session continuity and the <br>
test harness, everything is pushed to the publc github as soon as a <br>
capability works. It may not be complete, but again, the goal at this <br>
time is to prove the concepts and secure the pipes. Anyone who wants to <br>
follow or fork or do other work in whole or pieces is invited to do so.<br>
<br>
It is my intention to put the project under the auspices of the W3DC <br>
when it is fully implemented if they so desire. So if pieces of this <br>
find their way into X_Ite, que bueno. The W3DC is a healthy information <br>
ecosystem made more resilient by breeding successful cultivar with <br>
desirable features. MCCF uses X_ite calls in its mccf_api.py code. It <br>
relies on Holger's rendering engine. This is not possible without that <br>
ecosystem.<br>
<br>
Tell me what you need and I can send files to you in email or you can <br>
join MCCF as a collaborator. I won't post more files back to the public <br>
page as I hit the max size limit and Don was compelled to push back as a <br>
moderator must. No complaints. Bad etiquette on my part. Middle of the <br>
night soggy nogging.<br>
<br>
I am unlikely to do a presentation. I don't travel. Age and.. age. <br>
The Users Guide and other project documents on the Github can be a <br>
source for that. Let younger more fit folk have their day.<br>
<br>
X3D/VRML has a long history and is still alive because of work by folks <br>
such as yourself, Holger, Don, Doug, Richard and others. We have seen a <br>
lot of very prominent efforts at Web3D rise and fall. History and <br>
lifecycles continuously reinforce the need and resilience of <br>
semi-permeable open ecosystems. Fair winds.<br>
<br>
cheers,<br>
len<br>
<br>
<br>
<br>
<br>
<br>
> On 2026-05-30 2:04 pm, John Carlson wrote:<br>
> Len,<br>
> <br>
> This seems like an important capability that could point to more<br>
> generic handling of displacers, especially outside of HAnim.<br>
> <br>
> My requirements were “no scripting/SAI,” so of course, I devised a<br>
> different solution for facial animations. A no-scripting solution is<br>
> highly desirable due to different SAI solutions.<br>
> <br>
> This was quite the technical feat, Len, and is appreciated. Perhaps a<br>
> presentation is in order. Please let me know if you do one.<br>
> <br>
> One might consider a Proto with a script instead of coming up with new<br>
> XML schema.<br>
> <br>
> In the coming days/weeks/months, I will attempt to combine displacer<br>
> animation and joint animation in the same scene, and I would<br>
> appreciate some of your test files, so I can build a minimal example<br>
> without scripting.<br>
> <br>
> I appreciate your efforts, but we really would like to get displacers<br>
> and joint rotations working together, especially for exports from Maya<br>
> and Blender. This may mean we modify X_ITE.<br>
> <br>
> John<br>
</blockquote></div></div>