[x3d-public] Blender X3D support teleconference Dec 10 2024

Tue Dec 10 10:25:13 PST 2024

Thank you a lot for the meeting! I quickly wrote down a few things I
remembered, along with my TODOs, and some after-meeting-thoughts and
research.

@Vincent hopefully this can be complementary to your meeting notes --
my notes below are likely *not* complete, I only wrote things I
remembered because they selfishly relate to something I want :) And
again thank you for "taking point" on this task, Blender->X3D exporter
is very important for me (and I think it matters for other people a
lot too, at least in my domain "indie gamedev" where Blender rules as
3D authoring tool). It's great to see progress here!

Michalis TODOs:

1. *Find* (from actual usage in CGE / Cat-astrophe Games)
    and/or
    *make* (what I would consider "normal" usage by Blender/3D artists)

    ...an example .blend file using using texture transform Blender node.

2. See what does existing Blender->glTF exporter (from Khronos)
support in regards to above (texture transform). So that we support
(at least) similar setup in our Blender->X3D exporter.

    OK, this is easily done, they documented it nicely:
https://docs.blender.org/manual/en/dev/addons/import_export/scene_gltf2.html#uv-mapping
, section "UV Mapping",

    """
    Settings from the Mapping node are exported using a glTF extension
named KHR_texture_transform. There is a mapping type selector across
the top. Point is the recommended type for export. Texture and Vector
are also supported. The supported offsets are:

    - Location - X and Y
    - Rotation - Z only
    - Scale - X and Y
    """

    I will provide testcases covering it too.

    https://github.com/KhronosGroup/glTF-Sample-Assets should also
have working demos of this, should be these ones:
    https://github.com/KhronosGroup/glTF-Sample-Assets/tree/main/Models/TextureTransformTest
    https://github.com/KhronosGroup/glTF-Sample-Assets/tree/main/Models/TextureTransformMultiTest

3. Provide some testcases of using materials (with non-white color)
and per-vertex colors (with non-trivial values, some non-constant
across vertexes and some constant across vertexes) in Blender.

    To test upcoming Vincent implementation of per-vertex colors in
Blender->X3D exporter, that will

    phase 1: just export X3D ColorPerVertex with premultiplied
material * per-vertex

    phase 2: give users an option to use CGE extension (maybe in X3D
4.1)? to have Color[RGBA].mode="MODULATE" ,
https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D#per-vertex-colors
.

Other topics:

4. Texture export from Blender->X3D fixed

5. ImageTexture export when texture embedded in Blender fixed

6. Default for X3D path generation changed to not be "AUTO" (good,
this was convoluted) to "COPY" (always creates new files).

    Michalis notes: This doesn't really match our use-cases (for
current glTF we also advise using "Keep Original", see
https://castle-engine.io/blender ). When you have a texture library
(reused by 3D models). And/or when you think of your textures "data
that is not touched, only referred to, by 3D models".

    Of note: glTF does it a bit differently than X3D's pathMode. In
glTF exporter, they have "Keep Original", by default *off*. So it does
match the new default of X3D, good! But, also, it behaves
automatically good (does not really copy) in the simplest case, when
.blend is accompanied by textures.

   So, don't pay much attention to me for now :) I don't know what I
want, exactly, myself. And glTF exporter by default has "Keep
Original" = "off", which is  somewhat like new X3D default path mode =
"COPY" (Michalis TODO: test, to see what does "somewhat" mean here,
how close are they equal). In general, if X3D export defaults would be
similar to glTF export defaults, then this is almost always good for
me too (because glTF defaults are generally good), and it seems this
is the case now, so -> all cool.

7. Material export:

    - What Blender->X3D is doing now is export "Viewport Display" colors

    - phase 1: should instead export Blender material (BSDF) colors to
X3D PhysicalMaterial.baseColor,matallic,roughness

    - phase 2:
      give people a choice "use Material or PhysicalMaterial"?
      or give people a choice
      "use X3D 3.x with Material or X3D 4.x with PhysicalMaterial"? I
like this idea! Simplifies things while still providing options.

    Note: We also have now UnlitMaterial in X3D 4.0, corresponds to
Blender's "Background" material type, and glTF exporter already
handles it (that is, Blender's Background -> glTF unlit). Would be
nice to also support it in Blender->X3D.

8. Correct MFString in Blender - to make a testcase, it would be
easiest to first have support of Text Blender -> Text X3D (not
downgrade to mesh, as I think happens now).

Regards,
Michalis

niedz., 24 lis 2024 o 23:14 John Carlson via x3d-public
<x3d-public at web3d.org> napisał(a):
>
> Great!  I’ll probably copy this into my exporter at some point.  Thanks!
>
> John
>
> On Sun, Nov 24, 2024 at 4:09 PM Vincent Marchetti via x3d-public <x3d-public at web3d.org> wrote:
>>
>> There will be another teleconference to discuss projects and progress related to Blender support of X3D import, export, and workflow.
>>
>> Date/Time is December 10, 2024. at 12:00 PM EST, 17:00 UTC
>>
>> Location: https://docs.google.com/document/d/19f9L9LczB4vVfiSN9OsajnmvSkvz6RZaS6f4LsrqZNA/edit?usp=sharing
>>
>> Agenda Document: https://docs.google.com/document/d/19f9L9LczB4vVfiSN9OsajnmvSkvz6RZaS6f4LsrqZNA/edit?usp=sharing
>>
>> Review of recent news:
>>
>> A pull request for re-enabling export of the ImageTexture X3D node was merged into the trunk of the Blender.org X3D import/export extension. It will be released for updating existing Blender 4.2 installation, as soon as some issues discovered in testing are resolved.
>>
>> These issues described in the pull request thread at https://projects.blender.org/extensions/io_scene_x3d/pulls/39
>> They basically involve distangling effects of the difference between filepaths and URLs, the difference between POSIX and Windows filepaths, and the correct implementation of MFString encoding. I think we just need to dot our i's and cross t's carefully.
>>
>> Vince Marchetti
>>
>>
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org