Support for exporting GLTF

[t-oster]

Hi,

we are using castle-model-viewer to convert our GLTF models to x3d for interactive applications. In order to view those in augmented-reality (e.g. android), we need to convert back our updated x3d scene to gltf. We have some scripts with two specific versions of blender and docker in place, which is able to convert a subset of x3d stuff to gltf, but any advanced materials etc. are not supported.

How much effort would it be to extend the castle-model-viewer to be also able to export gltf? Since it can import gltf, there should be already many problems solved.

Can you estimate how much work it would be and maybe point me at the right direction?

[t-oster]

EDIT: I just saw on https://castle-engine.io/castle-model-converter#_all_command_line_options We plan to add soon glTF output (from any input). . Is there any roadmap for this feature or even some (beta?) source-code?

[michaliskambi]

Hi! Indeed this feature (saving to glTF) is already planned. For both Castle Model Viewer and command-line Castle Model Converter and online converter.

It makes total sense in our context, as an engine invested heavily in both X3D and glTF. We have the nodes, we know how X3D aligns with glTF, I'm working heavily with both standards (see e.g. https://github.com/michaliskambi/x3d-tests/wiki , https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D ).

There's no beta yet, the prototype implementation exists only in my head so far :) I predict it's about a week of work to make in useful state, with ability to convert from X3D to glTF static thing (like meshes, PBR materials, texture coordinates). Maybe another week to make it rock across all our tools, and to account that I'm always wrong with these estimations :) Animations (skinned or morph targets) would require more work, we already want to add some CGE-specific X3D nodes to better align these concepts with X3D, and these nodes would also help with round-trip conversion -- so for the 1st implementation we will likely not support animations (let me know if you'd need animations critically too).

For now my priority is releasing Castle Game Engine 7.0-alpha3, so admittedly I put this feature in lower priority, though it is definitely something I want to do one day. Let me know if you want to bump priority of this, it's OK to tell me just "we need this critically ASAP" , it sometimes works with me :)

( P.S. If you need this feature commercially, for a company, I am open to doing work-for-hire within this scope. We could use a donation -- one time or regular -- towards this goal, see https://www.patreon.com/castleengine , https://castle-engine.io/donate_other.php . We could also have regular b2b invoices through our OpenCollective . )

[t-oster]

Hi, thanks for the detailed answer. We're only using static models so far, and we are not planning to have any animations etc anytime soon, so conversion of static files would be sufficient.

Right now we are using our docker-blender workflow, but that's limited to simple material nodes with diffuse-textures. We now started to use CommonSurfaceShader-Nodes (which could be converted to PhyiscalMaterial) because we need normal-maps, but those don't work with blender.'s x3d-import.
We already think of implementing those in the blender importer, but neither blenders internal datastructures, nor python are high on our skill-list, so this may be a deadend.

I am not sure if my ideas will make it into a commercial product, we are still in a proof-of-concept phase for the AR feature and it is not on the official roadmap, but I will bring it up in the next meetings.

[michaliskambi]

Thank you! Let me know how it goes.

To be clear, this is a feature we want to do anyway, regardless of whether you'd like to sponsor it. X3D->glTF conversion for our engine, with big emphasis on X3D and glTF, makes total sense. But sponsoring it would bump my priorities a bit and be much appreciated :) I have high hopes for funding my work on Castle Game Engine and related tools (Castle Model Viewer etc.) this year, I took a "leap of faith" 2 months ago and actually work full-time on our engine now -- I count on people/companies support to ideally be able to do it forever :) I have to make a proper blog post about it.

As for CommonSurfaceShader, I would indeed recommend to switch the workflow to new X3D 4 nodes -- the Phong Material in X3D 4 was extended so much that it made CommonSurfaceShader no longer useful. And using PhysicalMaterial from X3D 4 is eveb better, for full glTF alignment and modern look. For some of my (old) thoughts about X3D 4 PBR materials, see https://github.com/michaliskambi/x3d-tests/wiki -- I considered just adding CommonSurfaceShader to X3D spec, but ultimately it was a better idea to add PhysicalMaterial and extend Material.