X3D serializer improvements #1234
Replies: 5 comments 10 replies
-
|
Another consideration is that in X3D the +Y direction is considered the Up direction for viewing purposes while it seems that in Jscad the +Z direction is considered the default Up direction. It does not make a difference for the actual geometry but default views are aligned to the Up direction. A solution would be to wrap the complete output with rotation around the X axis by minus 90 degrees. This would show the output in the same way as expected from Jscad viewers. It should also improve 3d printing compatibility since any 3d printer would probably expect Y coordinates from x3d files to be vertical. |
Beta Was this translation helpful? Give feedback.
-
|
https://github.com/jscad/io/blob/%40jscad/io%400.5.0/packages/x3d-serializer/index.js has the old version of the serializer. It used to use an IndexedFaceSet which allows polygons other than triangles, for example quads. This has the advantage that it would be a more direct representation of the jscad geom3 data structure and would generate smaller files since x3d would take care of the triangulation of the polygons. It has the disadvantage that it takes more work to construct the indices and vertices for the polygons, and some more work to find which vertices are shared between polygons, eg. to deduplicate, if desired. Per polygon coloring seems gone, so no issues there. Another advantage is that IndexedFaceSet has the creaseAngle field which sets a threshold for the angle between polygons below which there is smoothing, when supported. A disadvantage would be that it seems all serializers generalize/triangulate first for consistency and simplicity. |
Beta Was this translation helpful? Give feedback.
-
|
I guess there could be an option to select the X3D model for 3D geometry. There are several other serializers that have options. |
Beta Was this translation helpful? Give feedback.
-
|
Is there a way to find out which vertices are shared between polygons, other than relying on the actual position of a vertex ? |
Beta Was this translation helpful? Give feedback.
-
|
X3D has support profiles with defined sets of nodes which are made available. Currently, the Interchange profile is requested by the serializer but that profile does not include support for 2d geometry such as 2DPolyline used to represent line geometry. The Immersive or Full profiles would need to be requested for 2d geometry. |
Beta Was this translation helpful? Give feedback.
-
|
There are also the LineSet and IndexedLineSet nodes which use 3d vertices instead of 2d vertices. These nodes are included in the Rendering component which is supported by the Interchange profile if that profile would be preferred, perhaps for 3d printing compatibility although line geometry would not be relevant. |
Beta Was this translation helpful? Give feedback.
-
|
Let's focus n the profiles most commonly used in 3D printing and 2D CNC. Which ones do you suggest? |
Beta Was this translation helpful? Give feedback.
-
|
I checked a few models at https://3d.nih.gov/ which has a large collection intended for 3d printing. Models from the random sample all used the 'Immersive' profile. I am unfamiliar with 2d CNC services. Let me ask on the x3d-public mailing list if somebody has input. |
Beta Was this translation helpful? Give feedback.
-
|
There is also the option to request additional components on top of the profile: So one could request Interchange + 2DGeometry. It is doubtful that many X3D processors take advantage of these statements although x-ite does. |
Beta Was this translation helpful? Give feedback.
-
|
We might want to try a few uploads to IMagerialize https://imaterialise.helpjuice.com/using-imaterialise/supported-3d-file-formats and some interesting reading on 3D software as well... https://i.materialise.com/en/learn/supported-3d-file-formats |
Beta Was this translation helpful? Give feedback.
-
|
is a complex multicolor design I found on the forum using the existing serializer. It was accepted and fixed. Let me try a few more. is the InvoluteGear example modified with 3.3 version and normalPerVertex="false". It was accepted fine. is a modified InvoluteGear with many Shapes and different colors, vertex colors and diffuse only material colors. It was accepted but I do not know how it would actually print. It means imaterialise does not care about the version, can deal with the color node and looks for diffuseColor in Material. |
Beta Was this translation helpful? Give feedback.
-
|
I noticed in the list of supported formats that a lot of software still exports vrml (.wrl). x3d is vrml but in xml encoding. In practice, vrml often refers to vrml97, an older, more limited version. See for example: https://help.solidworks.com/2016/english/solidworks/sldworks/c_vrml_files.htm vrml97 only has these nodes: https://www.web3d.org/documents/specifications/14772/V2.0/ It has only IndexedFaceSet and IndexedLineSet. There are converters between x3d and vrml. It may make sense to offer vrml97 compatible X3D export at some point. |
Beta Was this translation helpful? Give feedback.
-
|
I noticed that very often the per triangle colors are all identical. But they are still assigned in jscad data structure and could be modified manually in a design. I think it would make sense to add a little check in the serializer if all triangle colors are identical and if so use a Material node rather than a huge Color node. This makes the file smaller and processing for printing easier. A note that per triangle colors are only used as diffuse color if there is an additional non-null Material node in X3D. |
Beta Was this translation helpful? Give feedback.
-
This is a continuation of issue #1231 as a discussion for improvements rather than problems. Please let me know if the forum would be a more appropriate place for such a discussion but I would like to keep using github as a single center.
There are three items which I have in mind and would provide PRs for:
All are pretty straightforward to implement.
Ad 1. Currently, an emissiveColor (ambient) is also used which leads to very bright coloring since all colors are additive. The regl renderer also uses a contribution of ambient coloring. For simplicity, the proposal is to just not have an emissiveColor component but I do not know what the original motivation was. This would also make the object color equivalent to the polygon color which in x3d is interpreted as diffuse color. The specular highlighting would improve the rendering look but has a little bit of cost in adding code and output size. This only applies to polygonal geometries. For 2d geometries emissive is needed in X3D.
Ad 2. By default x3d is using averaged normals at vertices for a smooth look. But it is straightforward to switch to a faceted look which is what I would recommend. It makes actual creases at large angles look appropriate and is standard in jscad, There could be an boolean option for the serializer called 'smooth' or 'creases' to turn smooth rendering on but it would apply to all objects in a design. So cubes would look strange (but cuboids good).
Ad 3. It is customary in x3d to omit specifying fields which will have the default value. This is completely optional and there are arguments for and against this. For example, the transparency field would be omitted for opaque objects. Or the normalsPerVertex field would be omitted for smooth objects.
Any comments or feedback much welcome.
I could draft a PR for 1. and 2. without the smooth option to make the discussion more specific.
Beta Was this translation helpful? Give feedback.
All reactions