Khronos X3D presentation plan - michaliskambi/x3d-tests GitHub Wiki
Table of Contents
- X3D talk
- X3D intro
- Differences: where glTF is minimalistic, X3D is not.
- Things we added in X3D 4.0 (just some highlights of interest to glTF)
- Things we plan
- http://web3d.org/mailman/listinfo/x3d-public_web3d.org
- Weekly each Friday
You're all invited.
X3D is an open standard for 3D models.
Royalty free.
In many ways, it is similar to glTF, and has some similar goals. I will talk about it in a second.
X3D format idea comes from VRML which comes from Inventor.
- A model is a collection of nodes (spec defines nodes),
- nodes have fields (all fields have a default value).
- X3D spec says what are the nodes and how to encode them in files.
https://www.web3d.org/standards (look at nodes' spec)
V4 (look at this version!)
- https://www.web3d.org/x3dv4-public-working-draft
- http://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/
There are encodings -- XML and classic are most popular.
- I'm often using "classic" when I manually craft X3D in text editor. It's easiest to read/write by humans. Many X3D tools support it.
- Pretty much all X3D-related software can input/output at least XML encoding. Obviously, it's easiest to implement (as you don't need any specialized parser, you just use XML library in your favorite programming language).
Here's a sample of X3D in class encoding. Basic nodes: Shape
, Appearance
etc.
The simplest demos below were deliberately written "live" during presentation:) So you can see it's easy. I have added them to this wiki for future reference.
#X3D V4.0 utf8
PROFILE Interchange
Shape {
appearance Appearance {
material PhysicalMaterial {
baseColor 1 1 0
}
}
geometry Sphere {
}
}
Save this as whatever.x3dv
, open in any X3D viewer ( https://www.web3d.org/x3d/content/X3dResources.html ) , I was using view3dscene for presentation ( https://castle-engine.io/view3dscene.php ).
Phong:
#X3D V4.0 utf8
PROFILE Interchange
Shape {
appearance Appearance {
material Material {
diffuseColor 1 1 0
}
}
geometry Sphere {
}
}
All the nodes and fields meaning -- see X3D specs.
In XML encoding it is:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE X3D PUBLIC "ISO//Web3D//DTD X3D 4.0//EN" "http://www.web3d.org/specifications/x3d-4.0.dtd">
<X3D profile="Interchange" version="4.0"
xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance"
xsd:noNamespaceSchemaLocation="http://www.web3d.org/specifications/x3d-4.0.xsd">
<head>
<meta name="generator" content="view3dscene, https://castle-engine.io/view3dscene.php" />
<meta name="source" content="anchor_test.x3dv" />
</head>
<Scene>
<Shape>
<Appearance>
<Material
diffuseColor="1 1 0" />
</Appearance>
<Sphere />
</Shape>
</Scene>
</X3D>
(Save as whatever.x3d
)
You can view X3D with lots of software, I use my view3dscene / CGE, and it reads both classic and xml.
That's basically the end of X3D description. Now I'd have to describe to you over 100 X3D nodes :)
Lots of nodes
- probably noone implements 100% (although FreeWRL is close).
- in practice, like 10 essential nodes, 20 common nodes.
- Spec solution to chaos: profiles. Like interchange or immersive. So, while authors cannot really expect that browsers implement "Full", but they can reasonably expect that almost all browsers support "interchange" or "interactive" or "immersive" profiles.
Many X3D implementations. Both open-source and proprietary. Many platforms. Including WebGL/HTML5 (see X3DOM, X_ITE)
Of course it means X3D is much bigger and more complicated spec, and harder to manage. It also means we have some more features.
X3D has features for (probably not in glTF scope) :
- volume rendering,
- 3D sound,
- particle systems.
X3D has features for (may be well in glTF scope) :
-
2D textures (duh)
-
3D textures http://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/texture3D.html
-
cubemaps (including auto-generated ones) http://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/environmentalTexturing.html
These may well be within glTF scope. E.g. lack of cubemaps meant that https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Vendor/EXT_lights_image_based had to invent a way to define a cubemap within the extension.
-
custom shaders http://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/shaders.html
- (mine extension to shaders) composable shader effects https://castle-engine.io/compositing_shaders.php
-
X3D has also interactons
- sensors on touch, drag
- sensors of visibillity
-
X3D has also
- scripting inside X3D
- PROTOs. Define a new node from a composition of others.
- ROUTEs, as a flexible way to design "how one thing affects another".
Animations in X3D are a composition of
TimeSensor
+ interpolator + anything that receives updates. See https://castle-engine.io/x3d_implementation_interpolation.php . E.g. you can do texture coordinate interpolation (not in glTF), without the X3D spec needing to define it explicitly. X3D just says "use these nodes, and connect in any way you want".
-
DEF / USE
#X3D V4.0 utf8
PROFILE Interchange
DEF aaaa Shape {
appearance Appearance {
material Material {
diffuseColor 1 1 0
}
}
geometry Sphere {
}
}
Transform {
translation 4 0 0
children USE aaaa
}
(Emphasis: look at X3D 4.0 spec, https://www.web3d.org/x3dv4-public-working-draft http://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/ )
In X3D 4.0 I added X3D nodes for PBR materials. With metallic-roughness model, deliberately very consistent with glTF 2.0, but also consistent with existing X3D Phong materials. See https://github.com/michaliskambi/x3d-tests/wiki/X3D-version-4%3A-New-features-of-materials%2C-lights-and-textures
At least 3 implementations (Castle Game Engine, X3DOM, X_ITE) explore how to convert glTF->X3D seamlessly. See https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D .
Simple properties to enable shadows on light sources.
BTW I'm curious is shadows definition planned for glTF lights too. E.g. as part of KHR_lights_punctual .
Just emissive.
https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D#materials
glTF materials specified with KHR_materials_unlit extension should be converted to X3D 4.0 UnlitMaterial. Note that baseColor/baseTexture are converted to X3D emissiveColor/emissiveTexture (we are inconsistent in naming here with glTF (base->emissive), because this is better: this color is really used like "emissive" and it allows for X3DOneSidedMaterialNode to have emissive* fields that are inherited by all materials).
https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D#materials
Image-based lighting, in a way consistent with glTF (here I'm interested about glTF plans, e.g. do you plan to incorporate EXT_lights_image_based or something else). See https://github.com/michaliskambi/x3d-tests/wiki/Image-Based-Lighting-(EnvironmentLight-node) .
I can also describe existing X3D nodes for cubemaps. We'll use them to define IBL environment.
Gamma correction statement in spec. Right now X3D leaves gamma correction decision up to the browser. See https://castle-engine.io/manual_gamma_correction.php , https://github.com/michaliskambi/x3d-tests/wiki/Gamma-correction-in-X3D-and-glTF , https://github.com/michaliskambi/x3d-tests/wiki/Gamma-Correction-in-Future-X3D .
Binary format for per-vertex data, 100% compatible with glTF. With optional DRACO. Essentially glTF binary data should be also useful in X3D. https://github.com/michaliskambi/x3d-tests/wiki/Binary-meshes
-
I heard during talk that glTF 2.0 metallic-roughness may be at some point deprecated, and we should look at specular-glossiness. TODO: Double-confirm to make sure.
-
Note that X3D spec should "stand on its own". We don't say just "do it like glTF" (well, temporarily we say that when it comes to PBR equations, but that's just temporary). In the long run, X3D just "happens to be compatible with glTF" because we made it in a consistent way. But not because it simply points to glTF and says "do it like in glTF".