Houdini to Mojo3D pipeline

About Monkey 2 Forums Monkey 2 Projects Houdini to Mojo3D pipeline

Tagged: , , ,

This topic contains 15 replies, has 5 voices, and was last updated by  Ethernaut 1 year ago.

Viewing 15 posts - 1 through 15 (of 16 total)
  • Author
  • #12106


    This project is nowhere near a bare minimum state of usability, but I wanted to start sharing its progress here to put some pressure on myself. The game project itself is basically a fake 1980’s looking, 3D vector graphics arcade.

    The core idea here is to use an existing 3D app as the editor that feeds data to the engine, instead of creating my own editor, which would probably take forever. I also have a vested interest in learning Houdini and Python, since they are tools I can use at work.

    In order to finish the game AND learn some useful stuff in the process, here are the main technical goals:

    – A component based engine created with Monkey2 / Mojo3D. Needs to be able to load scenes as .json files.
    Started, In progress

    – Houdini scripts (created in Python) to export scenes and individual assets to the engine.
    Just started

    – Figure out a way to add components directly in Houdini. This is a tough one. I don’t need to see the component’s result in Houdini, but I want to be able to set the parameters, export the scene and reload it in the engine to see the changes. The hard thing is: how do I keep the Houdini interface up to date with the latest components parameters, which exist only in Monkey2 code? The main solution I can think about is to export a list of all available components and their parameters, then read that list on the Houdini side to populate the parameters of custom nodes.

    – I may need a custom file format, since the visibility of each edge is important for the retro vector graphics look. Or at least a file that contains just the extra edge data.

    – Last but not least, I want to have a reasonable grasp of GLSL shaders by the end of it.

    Here’s my first attempt at some Python scripting in all its glory, showing a simple test scene converted to .json. I got basic parameter exporting done, now I need to kludge together some basic component exporting. Doesn’t need to be elegant yet, I just want it to do the basics for now.


    Hope to find time to keep working on this soon.



    New Year’s Update!

    Since I’ve decided to stick with GLTF file format and Houdini doesn’t export directly to it, it became clear I needed some sort of Material editor / Material library manager to allow reimporting of models while preserving material edits done after the first export. Any popular middleware (Unreal, Unity3D) allows this in some form.

    I decided to set other things aside for a moment and focus on creating a Material Editor / Model Viewer built from scratch with Mojo3D and MojoX. It will be similar to Qtek model viewer, but with functionality that allows not only editing a material, but also saving all materials in a model to an external .json file, and then reapplying it in case the model is re-exported from the 3D app. This functionality is being designed as a stand alone Module, and will be available outside the editor.

    I have the basic skeleton working already, material libraries and all, and am spending most of my time figuring out MojoX. Here’s what the rough prototype looks like now:

    As a bonus, I had to improve some things on my Serializer module (which allows saving/loading of Monkey2 object fields and properties to json files) to get the Material Libraries working, and hope to be able to share that module as well soon!

    P.S. That airplane is a model I’m making in Houdini, and is about 90% procedural. You can move things around, resize parts, change cross sections, etc. Super fun to learn that stuff as well! Here’s the somewhat scary node graph for the airplane body (right click and open image in new tab for full resolution):


    Simon Armstrong

    This project looks amazing Ethernaut! I am big fan of Houdini and Touch Designer a younger realtime cousin.

    I have been working on a Lightwave 2018 to GLTF pipeline and got a bit stuck with both PBR materials and animation sequences. I may give up on lightwave materials and use just the name to index into PBR materials that are authored from in game material editor.



    Thanks Simon! Houdini has a somewhat steep learning curve, but the non-destructive workflow clicked with me and I’m enjoying it a lot, despite the constant google searches to see how to do basic things.

    I’m actually considering simply authoring the materials in Houdini’s “Principled” shader (which is like a fancier version of Mojo’s PbrMaterial) using only the attributes that PbrMaterial also has, then simply exporting it to a custom format I can load in Monkey2 code. Visual differences should be minimal, and it’s much easier than making my own editor…

    (I also filed a suggestion for a Houdini GLTF exporter. THAT would be much easier).



    Custom node with PbrMaterial editing in Houdini is on!

    Now I need to get those exported to Mojo3D materials…


    Simon Armstrong

    I have been wondering about using gltf for material only files.

    OK, cool this duckmaterials.gltf is apparently legal:




    I’d love to be able to simply use GLTF for the entire scene, actually! It seems to allow custom extensions, so I could shove some custom data in there when needed. But writing my own GLTF exporter seems like a lot of work…

    Maybe later 😛

    P.S. Can you reference other GLTF files from inside a GLTF file? (to reference external models into a scene)


    Simon Armstrong

    According to the internet no.

    However decorating of placeholder nodes and materials at run time using application defined naming rules should be possible.


    Mojo3D currently strips names from materials so I got stuck with my first implementation of such a technique yesterday.



    Small progress… Houdini Principled shader to Mojo PbrMaterial exporter almost done… here’s a glimpse at the output.



    Oh, and here’s the overly shiny test model, created using Houdini. Soon to be a Monkey2 Banana demo! I’m experimenting with baking all materials to a single material with mapped color/roughness/metalness.

    Yet to be textured though, I wanna add some weathering and (normal mapped) rivets all over the fuselage like 1930’s race planes.



    Great work 🙂



    Airplane has been moved to the “Toy-Plane” banana project… still figuring out the best way to export stuff. One thing is certain: using Substance Painter for textures is a hit! Really cool blend of procedural and painted materials. Probably won’t use that custom material exporter in Houdini anymore, and will move all shading work into S. Painter.

    I hope to finish painting textures in a week or two. Want some white stripes over the red paint, like a racing plane.

    Current demo has improved controls and dynamic animation for things like rudder and ailerons.

    Current export methodology is:

    1. Export from Houdini as FBX with a temp material.
    2. Bring that into Substance Painter, then export multiple channels (Roughness, Normal, etc) to textures.
    3. Import FBX into Qtek Viewer, export GLTF from it (preserves animation)
    4. Load GLTF into Monkey2 code
    5. Replace materials using PbrMaterial.Load( path ) to bring all the textures from Substance Painter in a single line of code.
    6. The canopy alpha is set in code using Model.Alpha, since it’s not coming in the GLTF file (even when I fix it by hand adding the “alphaMode”:”BLEND” line.

    Phew. Every time I update the model is a workout, which is a problem considering how often I revise things… Need to streamline! Being able to remove the Qtek viewer step would be great, but I still haven’t succeeded bringing an animated FBX into Monkey.




    Just tried out the demo, looks really good!


    Cole Chapman

    Great work Ethernaut!



    Mini update: I’ve been working in the Houdini to Mojo3D Exporter Script, and by “working” I mean I’ve rewritten the damn thing three times now…

    I believe I found the best solution, though: no custom Houdini Digital Assets (nodes) at all! I’m simply translating the native Houdini nodes to Mojo3D equivalents via Python script. It expects things to be done in a certain way (Principled Shaders for materials, etc.), but this is actually really fast to update, much faster than maintaining dozens of custom Houdini Digital Assets…

    Next steps are: getting textures in materials and, finally, attempting to load an external model in .FBX format. If all succeeds, I’ll figure out a way to add components to entities directly in Houdini.

    I have to say, being able to work on those .mojo3d files visually and “hot reloading” them after making changes (no need to recompile anything, just hit a shortcut to reload the current scene) is much, much, much faster than dealing with coding the scene directly… no surprise here though.

    Once I have more features in I’ll share the exporter on Github. It’s a single python file, yay! It should also run well on the Free edition of Houdini! 🙂

Viewing 15 posts - 1 through 15 (of 16 total)

You must be logged in to reply to this topic.