[x3d-public] CreateHumanoid
GPU Group
gpugroup at gmail.com
Wed Dec 3 08:27:44 PST 2025
CreateHumanoid: MakeHuman adapted as proto with first type HAnimHumanoid,
and maybe (new node type) FileReader for coveroid assets in json like
makehuman.
-Doug
H: for web3d discussions, don't say 'makehuman' or 'MPFB2'. Say
createHumanoid. Then it's more generic.
Copilot Prompt:
What AI systems could I use to modify an existing computer program. In
particular I'd like to adapt makehuman or its MPFB blender python variant,
to web3d Script node in javascript.
Copilot Response:
*Quick Answer:* To adapt *MakeHuman* or its MPFB Blender Python variant
into a Web3D Script Node in JavaScript, you’ll want AI systems that
specialize in *code translation, refactoring, and cross-language adaptation*.
The most relevant tools are *GitHub Copilot, Amazon CodeWhisperer, OpenAI
Codex, Tabnine, Replit Ghostwriter, and Syntha AI*, which can help you
convert Python logic into JavaScript while preserving the 3D modeling
functionality blog.bluelupin.com
<https://blog.bluelupin.com/best-ai-code-tools-for-python-javascript-more-compared/>
syntha.ai.
------------------------------
🔧 AI Systems for Code Modification & Translation 1. *GitHub Copilot*
- Built on advanced language models.
- Excellent at *inline code suggestions* and adapting snippets between
languages.
- Can help translate Python-based geometry or Blender API calls into
JavaScript/Web3D equivalents blog.bluelupin.com
<https://blog.bluelupin.com/best-ai-code-tools-for-python-javascript-more-compared/>
.
2. *Amazon CodeWhisperer*
- Strong at *cross-language code generation*.
- Useful for adapting *Python scripts into JavaScript*, especially when
targeting web frameworks or APIs blog.bluelupin.com
<https://blog.bluelupin.com/best-ai-code-tools-for-python-javascript-more-compared/>
.
3. *OpenAI Codex (API-based)*
- Specialized in *code conversion and explanation*.
- Can take Python functions (e.g., MPFB mesh generation) and output
equivalent JavaScript for Web3D Script nodes blog.bluelupin.com
<https://blog.bluelupin.com/best-ai-code-tools-for-python-javascript-more-compared/>
.
4. *Tabnine*
- Predictive AI coding assistant.
- Helps with *refactoring and filling in missing logic* when porting
code across languages blog.bluelupin.com
<https://blog.bluelupin.com/best-ai-code-tools-for-python-javascript-more-compared/>
.
5. *Replit Ghostwriter*
- Integrated into Replit IDE.
- Supports *multi-language translation* and debugging.
- Handy if you want a *cloud-based environment* to test Python-to-JS
conversions blog.bluelupin.com
<https://blog.bluelupin.com/best-ai-code-tools-for-python-javascript-more-compared/>
.
6. *Syntha AI*
- Offers *code conversion agents* specifically designed for language
translation.
- Includes tools like *Code Converter* and *Code Explainer* to move from
Python to JavaScript while documenting the changes syntha.ai.
------------------------------
🧩 How These Apply to Your Case
- *MakeHuman / MPFB Blender Python Variant*: These rely heavily on
Python for mesh generation, parameterized models, and Blender integration.
- *Web3D Script Node in JavaScript*: Requires porting logic into
JavaScript, likely using *X3DOM, WebGL, or Three.js* to handle 3D
rendering.
Workflow Example:
1. *Extract core mesh generation logic* from MPFB Python scripts.
2. Use *Codex or Syntha AI* to translate Python functions into
JavaScript.
3. Refactor with *Copilot or CodeWhisperer* to integrate into Web3D
Script Node APIs.
4. Test rendering in a Web3D framework (e.g., X3DOM or Three.js).
------------------------------
⚡ Key Considerations
- *API Differences*: Blender’s Python API vs. Web3D’s JavaScript API
will require *manual adaptation*, not just direct translation.
- *Performance*: Web3D runs in browsers, so optimization for *real-time
rendering* is crucial.
- *Hybrid Approach*: AI tools can automate translation, but you’ll need
to guide them with *domain-specific knowledge* of 3D modeling.
------------------------------
✅ *Best Recommendation:* Start with *OpenAI Codex or Syntha AI* for initial
Python-to-JS translation, then refine with *GitHub Copilot* inside your IDE
to adapt the code to Web3D Script Node standards.
Would you like me to sketch out a *step-by-step migration plan* (Python →
JavaScript → Web3D integration) so you can see exactly how to structure the
adaptation?
yes.
Migration plan from MPFB/MakeHuman Python to Web3D Script node in JavaScript
You’re taking a parametric, Python-based human generator and porting it to
a browser runtime that’s event-driven, sandboxed, and GPU-backed. The crux
is to isolate pure geometry and parameter logic from Blender/MakeHuman
APIs, then rebuild those parts against Web3D/X3D Script node semantics and
WebGL-backed rendering.
------------------------------
Scope and target environment
- *Target runtime:* JavaScript in Web3D/X3D (e.g., X3DOM or X_ITE),
using a Script node to generate/update geometry.
- *Rendering backend:* Browser WebGL via the Web3D engine.
- *Output format:* X3D geometry nodes (IndexedFaceSet + Coordinate +
Normal + TextureCoordinate), materials, and possibly morph updates.
------------------------------
Phase 1 — Audit and isolation (Python side)
- *Inventory modules:* Identify files/functions responsible for
- Parameter schema (age, gender, height, BMI, muscle, etc.)
- Topology definition (vertex count, face indices)
- Morph targets / sliders (vertex delta arrays)
- UV layout and materials
- Rigging (defer initially; focus on static mesh + morphs)
- *Separate pure logic from host APIs:*
- *Label:* Mesh math
- Extract functions that compute vertices, indices, normals, UVs.
- *Label:* Morph system
- Gather data structures mapping slider values to vertex deltas.
- *Label:* Asset loading
- Note where files (OBJ, JSON, MHX2) are read; plan browser-friendly
formats.
- *Define a minimal core:* A Python “core” that, given parameters,
returns:
- *Label:* Vertices
- Float32 array shape N×3
- *Label:* Indices
- Uint32 array shape M×3
- *Label:* Normals
- Optional, or compute in JS
- *Label:* UVs
- N×2
------------------------------
Phase 2 — Target design (Web3D/X3D and JS)
- *Choose Web3D stack:* X3DOM or X_ITE; confirm Script interface
(fields, events).
- *Data structures in JS:*
- *Label:* Param object
- A JSON schema for sliders and constraints.
- *Label:* Geometry buffers
- Typed arrays for coordinates, indices, normals, UVs.
- *X3D nodes mapping:*
- *Label:* Geometry
- IndexedFaceSet with Coordinate, Normal, TextureCoordinate.
- *Label:* Materials
- Appearance/Material, optionally ImageTexture.
- *Event flow:*
- *Label:* Input
- Script node receives parameters via fields or UI.
- *Label:* Compute
- Update buffers; set_changed events to push into geometry nodes.
Example Script node skeleton:
<X3D>
<Scene>
<Shape>
<Appearance>
<Material diffuseColor='0.8 0.7 0.6'/>
</Appearance>
<IndexedFaceSet DEF="humanIFS" coordIndex="" solid="true">
<Coordinate DEF="humanCoord" point=""/>
<Normal DEF="humanNormal" vector=""/>
<TextureCoordinate DEF="humanUV" point=""/>
</IndexedFaceSet>
</Shape>
<Script DEF="HumanGenerator" directOutput="true">
<field name="params" type="SFString" accessType="inputOnly"/>
<field name="coord" type="SFNode" accessType="initializeOnly">
<Coordinate USE="humanCoord"/>
</field>
<field name="ifs" type="SFNode" accessType="initializeOnly">
<IndexedFaceSet USE="humanIFS"/>
</field>
<field name="normal" type="SFNode" accessType="initializeOnly">
<Normal USE="humanNormal"/>
</field>
<field name="uv" type="SFNode" accessType="initializeOnly">
<TextureCoordinate USE="humanUV"/>
</field>
<field name="update" type="SFBool" accessType="inputOnly"/>
<![CDATA[
function initialize() {
// bootstrap default geometry
}
function set_params(p) {
var config = JSON.parse(p);
// recompute geometry with config
computeHuman(config);
pushBuffers();
}
function set_update(flag) {
if (flag) { pushBuffers(); }
}
function computeHuman(config) {
// TODO: implement param->geometry
}
function pushBuffers() {
// Assign coord.point, ifs.coordIndex, normal.vector, uv.point
}
]]>
</Script>
</Scene>
</X3D>
------------------------------
Phase 3 — Porting the core logic
- *Parameter schema translation:*
- *Label:* Constraints
- Preserve ranges, dependencies, and anatomical constraints.
- *Label:* Units
- Keep consistent scaling; define meters as base for WebGL.
- *Topology and indices:*
- *Label:* Fixed topology
- Port static index arrays as JSON or binary blobs.
- *Label:* Variants
- If topology varies by gender/age, load appropriate set at init.
- *Morph targets:*
- *Label:* Data format
- Store each slider’s vertex delta as Float32Array aligned to
topology.
- *Label:* Application
- In JS, compute vertices: base + Σ(weight_i × delta_i).
- *Normals and UV:*
- *Label:* Normals
- Start by computing per-face; then switch to per-vertex with
area/angle weighting.
- *Label:* UV
- Use base UV; ensure no seams break under morphs.
- *Blender/MH API replacement:*
- *Label:* Mesh ops
- Replace bpy functions with your own array operations.
- *Label:* Materials
- Map materials to X3D Material/ImageTexture; bake procedural
textures as images if needed.
- *Serialization pipeline:*
- *Label:* Assets
- Host base mesh and morphs as .bin (ArrayBuffer) or .json; fetch via
HTTP.
- *Label:* Caching
- Use IndexedDB for offline caching of large arrays.
Minimal JS compute example (morph application):
// base: Float32Array length 3*N
// deltas: Array of Float32Array length 3*N
// weights: Array of numbers length K
function applyMorphs(base, deltas, weights) {
const out = new Float32Array(base.length);
out.set(base);
for (let k = 0; k < deltas.length; k++) {
const w = weights[k];
if (!w) continue;
const d = deltas[k];
for (let i = 0; i < out.length; i++) out[i] += w * d[i];
}
return out;
}
------------------------------
Phase 4 — Performance and UX
- *Typed arrays and transfer:*
- *Label:* Buffers
- Use Float32Array/Uint32Array; avoid frequent reallocs.
- *Label:* Worker
- Move heavy morph computations to Web Workers; message ArrayBuffers.
- *Incremental updates:*
- *Label:* Slider changes
- Recompute only affected regions if your morph system supports
locality; otherwise full recompute.
- *LOD and decimation:*
- *Label:* Multiple LODs
- Offer low/high topology; switch based on device performance.
- *GPU considerations:*
- *Label:* Normals on GPU
- Optionally compute normals in a vertex shader from morphs if engine
allows custom shaders.
- *UI integration:*
- *Label:* Binding
- Bind sliders to Script params via routes/events; throttle updates.
------------------------------
Phase 5 — Testing, validation, and roadmap
- *Correctness:*
- *Label:* Snapshot tests
- Compare JS vertices against Python outputs for a set of parameter
vectors.
- *Label:* Visual checks
- Side-by-side renders to catch UV stretching or normal artifacts.
- *Numerical stability:*
- *Label:* Constraints
- Clamp extreme combinations; add soft regularization to avoid
self-intersections.
- *Interoperability:*
- *Label:* Export
- Provide GLB/OBJ export for downstream verification.
- *Future features:*
- *Label:* Rigging
- Port armature and skin weights; map to X3D HAnim or custom
animation.
- *Label:* Textures
- Parameterized texture generation or material variants.
- *Label:* Persistence
- Save parameter sets; reproducible IDs for models.
------------------------------
Suggested next steps
- *Define your parameter JSON* with ranges and a small test suite of 10
preset bodies.
- *Extract and freeze the base topology and 5–10 key morphs* from MPFB
to validate the pipeline.
- *Pick X3DOM or X_ITE* and wire the Script node to push buffers into
IndexedFaceSet.
- *Run cross-checks*: emit vertices from both Python and JS for
identical parameters; assert max deviation under a small epsilon.
If you share a snippet of the MPFB functions that generate vertices/morphs,
I can map them one-to-one into the Script node compute stubs and propose
exact data formats for the assets.
/Copilot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20251203/72178a51/attachment-0001.html>
More information about the x3d-public
mailing list