[x3d-public] X3D for Advanced Modeling Examples Archive, Tool Conversions: Blender Issues List

Michalis Kamburelis michalis.kambi at gmail.com
Wed Nov 1 08:15:05 PDT 2017


2017-11-01 3:53 GMT+01:00 Don Brutzman <brutzman at nps.edu>:
> http://x3dgraphics.com/examples/X3dForAdvancedModeling/ToolConversions/BlenderConversionIssues.txt
>

I browsed the above document (
http://x3dgraphics.com/examples/X3dForAdvancedModeling/ToolConversions/BlenderConversionIssues.txt
) and some of the issues mentioned there could IMHO be left "unfixed",
because they are not actual bugs or problems. And "fixing" them would
likely complicate the X3D exporter code.

1. It's not a real problem IMHO that an exporter sometimes writes
explicitly field values that are equal to default. E.g. writing
"<DirectionalLight direction='-0.0000 0.0000 -1.0000'/>" when in fact
"<DirectionalLight/>" is enough. It's not really a problem, the output
is correct either way, and this makes exporter code simpler (instead
of including a lot of "ifs", that is "if this value is not equal to
default...").

2. Writing trailing zeroes, like "0.0000" instead of "0", is not a
problem. The exporter uses a standard Python formatting routines, and
it may be best to keep it that way, instead of complicating the
exporter code with custom formatting only to avoid trailing zeroes in
some cases.

    One may argue that 1. and 2. are important to keep the X3D file
size small, but in my experience, the X3D file size is mostly affected
by huge fields like Coordinate.point, IndexedFaceSet.coordIndex, etc.
How do you encode the rest (like lights or viewpoints or transforms)
doesn't matter much for the file size.

3. <X3D profile='Immersive'> is used because sometimes the exporter
may need Immersive. As far as I recall, H3D extensions may even use
ComposedShader node. IMHO it's simpler to always output <X3D
profile='Immersive'> than to add a logic that tries to guess whether
the <X3D profile='Immersive'> or <X3D profile='Interactive'> is
needed.

Other notes:

- As for invalid orientation (with normal vector = zero): Indeed, it's
a bug that should be submitted and corrected. In my tests, it only
occurs on Viewpoint node -- maybe this information is helpful. It was
once fixed in the past (it wasn't actually a bug in the X3D exporter),
but the bug came back at some point.

- You write """NavigationInfo headlight="off"/> means model is
invisible. """. Actually, without the headlight, the model is
almost-black. It is not invisible (it will be visible on non-black
Background, or when Inlined within a larger X3D scene that has
lights). And it is not perfectly black (most X3D browsers have some
"scene ambient factor", that works even without the headlight). And
that is only true if you didn't add any other lights, and for this
reason, the model is also almost-black in Blender render. IOW, I'm
unsure is this is a problem to be fixed in X3D exporter. A model
without any lights is black -- this is reasonable behaviour.

Regards,
Michalis



More information about the x3d-public mailing list