x3dom-developers — Where the developers of X3DOM itself discuss new features.

Re: [x3dom-developers] [x3d-public] X3DOM dev url changed, HTML invocation questions

[John C. <yot...@gm...>]

Also, looking at dev tools Network tab gives good information.

But you’re likely aware…

John
On Tue, Jul 15, 2025 at 1:01 PM Don Brutzman via x3d-public <
x3d...@we...> wrote:

> Interesting... I pulled down a fresh copy of Firefox and tested there as
> well.  Once again, no images loaded into the X3DOM scene.
>
> These images should be legal and allowed by X3DOM, they are in a direct
> subdirectory beneath the X3DOM page in question.  They would be allowed in
> any other HTML page.
>
> Possible approach: perhaps x3dom.js can catch the exception and treat it
> as OK, when appropriate?   The following debugger screenshot from Firefox
> hints at that possibility, i.e. "Uncaught DOMException"
>
> [image: image.png]
>
> (Opinion: running a local CORS server is of course a workaround, but that
> means development/testing with a difference setup than deployment, slowing
> efforts and introducing other potential issues.  So relaxing this
> overzealous restriction on local content loading local content seems
> worthwhile.)
>
> all the best, Don
>
> On Tue, Jul 15, 2025 at 4:40 AM vmarchetti--- via x3d-public <
> x3d...@we...> wrote:
>
>> I think these errors are a result of web browser configuration or policy
>> rathen than a change in the x3dom code.
>>
>> I am seeing the reported problem in loading ImageTexture resources from
>> the local file system in my install of Chrome, but not in Firefox. That
>> leads me to think it's a difference in how each browser is interpreting the
>> security risk of reading a local file through an XHR request, an issue
>> related to the CORS specification.
>>
>> Vince Marchetti
>>
>> On Jul 14, 2025, at 9:08 PM, Don Brutzman via x3d-public <
>> x3d...@we...> wrote:
>>
>> Thank you Andreas.  I have
>>
>>    - taken out the CSS for SANS, SERIF, TYPEWRITER
>>    - updated the node-list url,
>>    - tested both updated addresses for x3dom-full.js
>>
>> Here are two examples using your preferred address:
>>
>>    -
>>    https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/Animation/BoxSwitchX3dom.xhtml
>>    -
>>    https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/Animation/RotationCalculatorExampleX3dom.xhtml
>>
>> However, a problem has emerged.  Neither model is displaying image
>> textures when launched on local host.
>> ERROR: [Utils|createTexture2D] Can't http request: images/WhiteImage.png
>> ERROR: [Utils|createTexture2D] Can't http request: images/YellowImage.png
>> ERROR: [Utils|createTexture2D] Can't http request:
>> images/TurquoiseImage.png
>> ERROR: [Utils|createTexture2D] Can't http request: images/GreenImage.png
>> ERROR: [Utils|createTexture2D] Can't http request: images/GreyImage.png
>> ERROR: [Utils|createTexture2D] Can't http request: images/RedImage.png
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> <image.png>
>>
>> Hopefully this is a fixable issue, TIA for any scrutiny.  This was a very
>> useful capability when invoking the original
>> https://x3dom.org/download/dev/x3dom-full.js
>>
>> all the best, Don
>>
>> On Sun, Jul 13, 2025 at 8:45 PM Andreas Plesch <and...@gm...>
>> wrote:
>>
>>> Answers below.
>>>
>>> On Sun, Jul 13, 2025 at 2:21 PM Don Brutzman <don...@gm...>
>>> wrote:
>>>
>>>> Andreas writes on 10 JUL 2025:
>>>>
>>>>> I have deployed a new dev version.
>>>>> Please note that the download link for the dev version of x3dom has
>>>>> migrated from x3dom.org/download/dev (not updated) to
>>>>> https://cdn.jsdelivr.net/gh/x3dom/x3dom-dev/dist/x3dom.js (preferred)
>>>>> or
>>>>> https://x3dom.github.io/x3dom-dev/dist/x3dom.js
>>>>> which is
>>>>> automatically updated through
>>>>> https://github.com/x3dom/x3dom-dev
>>>>> for every merged PR at
>>>>> https://github.com/x3dom/x3dom
>>>>> The netlify link is obsolete.
>>>>
>>>>
>>>>> Andreas
>>>>
>>>>
>>>> Thanks for the alert.  I am hoping to get the address and invocation
>>>> correct in our X3D Example Archives scenes by updating the conversion
>>>> stylesheet.
>>>>
>>>>    - X3D Example Archives
>>>>    -
>>>>    https://www.web3d.org/x3d/content/examples/X3dResources.html#Examples
>>>>    -
>>>>    https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/X3dToX3domX_ITE.xslt
>>>>
>>>> The X3dToX3domX_ITE.xslt stylesheet produces the following header in
>>>> these examples:
>>>>
>>>>    - X3D Example Archives: X3D4WA, X3D for Web Authors, Chapter 01
>>>>    Technical Overview, Hello World
>>>>    -
>>>>    https://www.web3d.org/x3d/content/examples/X3dForWebAuthors/Chapter01TechnicalOverview/HelloWorldIndex.html
>>>>    -
>>>>    https://www.web3d.org/x3d/content/examples/X3dForWebAuthors/Chapter01TechnicalOverview/HelloWorldX3dom.xhtml
>>>>
>>>> <!DOCTYPE html>
>>>>
>>>> <!--
>>>> =================================================================== -->
>>>>
>>>> <!-- embedded X3D scene appears after html/head/script and style
>>>> entries -->
>>>>
>>>> <!--
>>>> =================================================================== -->
>>>>
>>>> <html xmlns="http://www.w3.org/1999/xhtml">
>>>>
>>>> <head>
>>>>
>>>> <title>Hello World!, HelloWorld.x3d (X3DOM)</title>
>>>>
>>>> <meta http-equiv="X-UA-Compatible" content="chrome=1,IE=edge"/>
>>>>
>>>> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
>>>>
>>>> <meta name="generator"
>>>>
>>>> content="https://www.web3d.org/x3d/stylesheets/X3dToX3domX_ITE.xslt"/>
>>>>
>>>> <script type="text/javascript" src="
>>>> https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js">
>>>> </script>
>>>>
>>>> <!-- Numbered X3DOM release versions: https://www.x3dom.org/download
>>>> -->
>>>>
>>>> <!-- Developer X3DOM release version:
>>>> https://www.x3dom.org/download/dev -->
>>>>
>>>> <link rel="stylesheet"
>>>>
>>>> type="text/css"
>>>>
>>>> href="https://x3dom.org/download/dev/x3dom.css"/>
>>>>
>>>> <script type="text/javascript"
>>>>
>>>> src="https://x3dom.org/download/dev/x3dom-full.js"/>
>>>>
>>>>
>>>> Questions please, before I start a major rebuild:
>>>>
>>>>    1. *x3dom.js or x3dom-full.js ? (both look to be available)*
>>>>
>>>> x3dom-full.js
>>>
>>>>
>>>>    1. *Same treatment for x3dom.css or is it no longer used?*
>>>>
>>>> Yes, same treatment. It is still used.
>>>
>>>>
>>>>    1. *What is up-to-date guidance whenText node is included?*  I have
>>>>
>>>>
>>>>    - "X3DOM Text Example
>>>>    The following scenes demonstrate the use of the text and fontsyle
>>>>    nodes. You can also use web fonts, however on windows there is a glitch.
>>>>    You have to use and display the font in your document before you can use
>>>>    them in X3DOM."
>>>>    - https://x3dom.org/x3dom/example/x3dom_text.html
>>>>
>>>> <meta name="warning"
>>>>
>>>> content="Webfonts must be loaded prior to using Text node in X3D
>>>> scene... see https://x3dom.org/x3dom/example/x3dom_text.html"/>
>>>>
>>>> <!-- X3DOM needs Web Fonts when an X3D Text node is included -->
>>>>
>>>> <!-- adapted from https://x3dom.org/x3dom/example/x3dom_text.html and
>>>> https://web.mit.edu/jmorzins/www/fonts.html -->
>>>>
>>>> <style type="text/css">
>>>>
>>>> /*
>>>> =============================================================================
>>>> */
>>>>
>>>> @font-face {
>>>>
>>>> font-family: 'SERIF'; /* default original */
>>>>
>>>> font-style: normal;
>>>>
>>>> font-weight: 700;
>>>>
>>>> src: local('Roman'), url('Roman.ttf') format('truetype');
>>>>
>>>> }
>>>>
>>>> @font-face {
>>>>
>>>> font-family: 'SERIF'; /* default alternate */
>>>>
>>>> font-style: normal;
>>>>
>>>> font-weight: 700;
>>>>
>>>> src: local('Times New Roman'), local('TimesNewRoman'), url('Times New
>>>> Roman.ttf') format('truetype');
>>>>
>>>> }
>>>>
>>>> /*
>>>> =============================================================================
>>>> */
>>>>
>>>> @font-face {
>>>>
>>>> font-family: 'SANS'; /* default original */
>>>>
>>>> font-style: normal;
>>>>
>>>> font-weight: 400;
>>>>
>>>> src: local('Arial'), url('Arial.ttf') format('truetype');
>>>>
>>>> }
>>>>
>>>> @font-face {
>>>>
>>>> font-family: 'SANS'; /* default alternate */
>>>>
>>>> font-style: normal;
>>>>
>>>> font-weight: 400;
>>>>
>>>> src: local('Helvetica'), url('Helvetica.ttf') format('truetype');
>>>>
>>>> }
>>>>
>>>> /*
>>>> =============================================================================
>>>> */
>>>>
>>>> @font-face {
>>>>
>>>> font-family: 'TYPEWRITER'; /* default original */
>>>>
>>>> font-style: normal;
>>>>
>>>> font-weight: 900;
>>>>
>>>> src: local('Courier'), url('Courier.ttf') format('truetype');
>>>>
>>>> }
>>>>
>>>> @font-face {
>>>>
>>>> font-family: 'TYPEWRITER'; /* default alternate */
>>>>
>>>> font-style: normal;
>>>>
>>>> font-weight: 900;
>>>>
>>>> src: local('Courier New'), url('Courier New.ttf') format('truetype');
>>>>
>>>> }
>>>>
>>>> /*
>>>> =============================================================================
>>>> */
>>>>
>>>> </style>
>>>>
>>>> <style type="text/css" media="screen, print">
>>>>
>>>> .webfont { font-size:200%; font-family:'TYPEWRITER'; color:green;} /*
>>>> Conversion TODO font families: SANS SERIF TYPEWRITER */
>>>>
>>>> </style>
>>>>
>>>>
>>> I think this guidance still applies for custom font families if a
>>> FontLibrary node is not used. FontLibrary font loading does not require
>>> this css. Also, all basic X3D font families do not require css.
>>> https://github.com/x3dom/x3dom/blob/master/test/functional/fonts.html
>>> has examples.
>>>
>>>
>>>> and
>>>>
>>>> *4. Is the following still the best up-to-date list of supported nodes?*
>>>>
>>>> https://andreasplesch.github.io/x3dom/dist/doc/author/nodes.html
>>>>
>>>> P.S. node wish list: IndexedTriangleFanSet, Script
>>>>
>>>>
>>> https://x3dom.github.io/x3dom-dev/dist/doc
>>>
>>> would be the best source for up to date documentation on supported nodes
>>> with dev releases as it is built and deployed along with the library.
>>>
>>>
>>> Thanks in advance for all improvements to these invocations, and thanks
>>>> as ever for ongoing progress with X3DOM!
>>>>
>>>> all the best, Don
>>>>
>>>
>>> All the best, Andreas
>>> --
>>> Andreas Plesch
>>> Waltham, MA 02453
>>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d...@we...
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d...@we...
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
> _______________________________________________
> x3d-public mailing list
> x3d...@we...
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>

Re: [x3dom-developers] [x3d-public] X3DOM dev url changed, HTML invocation questions

[John C. <yot...@gm...>]

Don, sometimes you have to assign “routes” on the server to handle file
extensions, for example express.  So for example, search for the block if
code with the magic function calls in my express server.  I recently added
“*.rb” for JRuby files:

https://github.com/coderextreme/X3DJSONLD/blob/master/app.js

I had to remember every time I get a new file type.  It’s a pain in the
neck, but it does add some security.

John


On Tue, Jul 15, 2025 at 1:01 PM Don Brutzman via x3d-public <
x3d...@we...> wrote:

> Interesting... I pulled down a fresh copy of Firefox and tested there as
> well.  Once again, no images loaded into the X3DOM scene.
>
> These images should be legal and allowed by X3DOM, they are in a direct
> subdirectory beneath the X3DOM page in question.  They would be allowed in
> any other HTML page.
>
> Possible approach: perhaps x3dom.js can catch the exception and treat it
> as OK, when appropriate?   The following debugger screenshot from Firefox
> hints at that possibility, i.e. "Uncaught DOMException"
>
> [image: image.png]
>
> (Opinion: running a local CORS server is of course a workaround, but that
> means development/testing with a difference setup than deployment, slowing
> efforts and introducing other potential issues.  So relaxing this
> overzealous restriction on local content loading local content seems
> worthwhile.)
>
> all the best, Don
>
> On Tue, Jul 15, 2025 at 4:40 AM vmarchetti--- via x3d-public <
> x3d...@we...> wrote:
>
>> I think these errors are a result of web browser configuration or policy
>> rathen than a change in the x3dom code.
>>
>> I am seeing the reported problem in loading ImageTexture resources from
>> the local file system in my install of Chrome, but not in Firefox. That
>> leads me to think it's a difference in how each browser is interpreting the
>> security risk of reading a local file through an XHR request, an issue
>> related to the CORS specification.
>>
>> Vince Marchetti
>>
>> On Jul 14, 2025, at 9:08 PM, Don Brutzman via x3d-public <
>> x3d...@we...> wrote:
>>
>> Thank you Andreas.  I have
>>
>>    - taken out the CSS for SANS, SERIF, TYPEWRITER
>>    - updated the node-list url,
>>    - tested both updated addresses for x3dom-full.js
>>
>> Here are two examples using your preferred address:
>>
>>    -
>>    https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/Animation/BoxSwitchX3dom.xhtml
>>    -
>>    https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/Animation/RotationCalculatorExampleX3dom.xhtml
>>
>> However, a problem has emerged.  Neither model is displaying image
>> textures when launched on local host.
>> ERROR: [Utils|createTexture2D] Can't http request: images/WhiteImage.png
>> ERROR: [Utils|createTexture2D] Can't http request: images/YellowImage.png
>> ERROR: [Utils|createTexture2D] Can't http request:
>> images/TurquoiseImage.png
>> ERROR: [Utils|createTexture2D] Can't http request: images/GreenImage.png
>> ERROR: [Utils|createTexture2D] Can't http request: images/GreyImage.png
>> ERROR: [Utils|createTexture2D] Can't http request: images/RedImage.png
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> <image.png>
>>
>> Hopefully this is a fixable issue, TIA for any scrutiny.  This was a very
>> useful capability when invoking the original
>> https://x3dom.org/download/dev/x3dom-full.js
>>
>> all the best, Don
>>
>> On Sun, Jul 13, 2025 at 8:45 PM Andreas Plesch <and...@gm...>
>> wrote:
>>
>>> Answers below.
>>>
>>> On Sun, Jul 13, 2025 at 2:21 PM Don Brutzman <don...@gm...>
>>> wrote:
>>>
>>>> Andreas writes on 10 JUL 2025:
>>>>
>>>>> I have deployed a new dev version.
>>>>> Please note that the download link for the dev version of x3dom has
>>>>> migrated from x3dom.org/download/dev (not updated) to
>>>>> https://cdn.jsdelivr.net/gh/x3dom/x3dom-dev/dist/x3dom.js (preferred)
>>>>> or
>>>>> https://x3dom.github.io/x3dom-dev/dist/x3dom.js
>>>>> which is
>>>>> automatically updated through
>>>>> https://github.com/x3dom/x3dom-dev
>>>>> for every merged PR at
>>>>> https://github.com/x3dom/x3dom
>>>>> The netlify link is obsolete.
>>>>
>>>>
>>>>> Andreas
>>>>
>>>>
>>>> Thanks for the alert.  I am hoping to get the address and invocation
>>>> correct in our X3D Example Archives scenes by updating the conversion
>>>> stylesheet.
>>>>
>>>>    - X3D Example Archives
>>>>    -
>>>>    https://www.web3d.org/x3d/content/examples/X3dResources.html#Examples
>>>>    -
>>>>    https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/X3dToX3domX_ITE.xslt
>>>>
>>>> The X3dToX3domX_ITE.xslt stylesheet produces the following header in
>>>> these examples:
>>>>
>>>>    - X3D Example Archives: X3D4WA, X3D for Web Authors, Chapter 01
>>>>    Technical Overview, Hello World
>>>>    -
>>>>    https://www.web3d.org/x3d/content/examples/X3dForWebAuthors/Chapter01TechnicalOverview/HelloWorldIndex.html
>>>>    -
>>>>    https://www.web3d.org/x3d/content/examples/X3dForWebAuthors/Chapter01TechnicalOverview/HelloWorldX3dom.xhtml
>>>>
>>>> <!DOCTYPE html>
>>>>
>>>> <!--
>>>> =================================================================== -->
>>>>
>>>> <!-- embedded X3D scene appears after html/head/script and style
>>>> entries -->
>>>>
>>>> <!--
>>>> =================================================================== -->
>>>>
>>>> <html xmlns="http://www.w3.org/1999/xhtml">
>>>>
>>>> <head>
>>>>
>>>> <title>Hello World!, HelloWorld.x3d (X3DOM)</title>
>>>>
>>>> <meta http-equiv="X-UA-Compatible" content="chrome=1,IE=edge"/>
>>>>
>>>> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
>>>>
>>>> <meta name="generator"
>>>>
>>>> content="https://www.web3d.org/x3d/stylesheets/X3dToX3domX_ITE.xslt"/>
>>>>
>>>> <script type="text/javascript" src="
>>>> https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js">
>>>> </script>
>>>>
>>>> <!-- Numbered X3DOM release versions: https://www.x3dom.org/download
>>>> -->
>>>>
>>>> <!-- Developer X3DOM release version:
>>>> https://www.x3dom.org/download/dev -->
>>>>
>>>> <link rel="stylesheet"
>>>>
>>>> type="text/css"
>>>>
>>>> href="https://x3dom.org/download/dev/x3dom.css"/>
>>>>
>>>> <script type="text/javascript"
>>>>
>>>> src="https://x3dom.org/download/dev/x3dom-full.js"/>
>>>>
>>>>
>>>> Questions please, before I start a major rebuild:
>>>>
>>>>    1. *x3dom.js or x3dom-full.js ? (both look to be available)*
>>>>
>>>> x3dom-full.js
>>>
>>>>
>>>>    1. *Same treatment for x3dom.css or is it no longer used?*
>>>>
>>>> Yes, same treatment. It is still used.
>>>
>>>>
>>>>    1. *What is up-to-date guidance whenText node is included?*  I have
>>>>
>>>>
>>>>    - "X3DOM Text Example
>>>>    The following scenes demonstrate the use of the text and fontsyle
>>>>    nodes. You can also use web fonts, however on windows there is a glitch.
>>>>    You have to use and display the font in your document before you can use
>>>>    them in X3DOM."
>>>>    - https://x3dom.org/x3dom/example/x3dom_text.html
>>>>
>>>> <meta name="warning"
>>>>
>>>> content="Webfonts must be loaded prior to using Text node in X3D
>>>> scene... see https://x3dom.org/x3dom/example/x3dom_text.html"/>
>>>>
>>>> <!-- X3DOM needs Web Fonts when an X3D Text node is included -->
>>>>
>>>> <!-- adapted from https://x3dom.org/x3dom/example/x3dom_text.html and
>>>> https://web.mit.edu/jmorzins/www/fonts.html -->
>>>>
>>>> <style type="text/css">
>>>>
>>>> /*
>>>> =============================================================================
>>>> */
>>>>
>>>> @font-face {
>>>>
>>>> font-family: 'SERIF'; /* default original */
>>>>
>>>> font-style: normal;
>>>>
>>>> font-weight: 700;
>>>>
>>>> src: local('Roman'), url('Roman.ttf') format('truetype');
>>>>
>>>> }
>>>>
>>>> @font-face {
>>>>
>>>> font-family: 'SERIF'; /* default alternate */
>>>>
>>>> font-style: normal;
>>>>
>>>> font-weight: 700;
>>>>
>>>> src: local('Times New Roman'), local('TimesNewRoman'), url('Times New
>>>> Roman.ttf') format('truetype');
>>>>
>>>> }
>>>>
>>>> /*
>>>> =============================================================================
>>>> */
>>>>
>>>> @font-face {
>>>>
>>>> font-family: 'SANS'; /* default original */
>>>>
>>>> font-style: normal;
>>>>
>>>> font-weight: 400;
>>>>
>>>> src: local('Arial'), url('Arial.ttf') format('truetype');
>>>>
>>>> }
>>>>
>>>> @font-face {
>>>>
>>>> font-family: 'SANS'; /* default alternate */
>>>>
>>>> font-style: normal;
>>>>
>>>> font-weight: 400;
>>>>
>>>> src: local('Helvetica'), url('Helvetica.ttf') format('truetype');
>>>>
>>>> }
>>>>
>>>> /*
>>>> =============================================================================
>>>> */
>>>>
>>>> @font-face {
>>>>
>>>> font-family: 'TYPEWRITER'; /* default original */
>>>>
>>>> font-style: normal;
>>>>
>>>> font-weight: 900;
>>>>
>>>> src: local('Courier'), url('Courier.ttf') format('truetype');
>>>>
>>>> }
>>>>
>>>> @font-face {
>>>>
>>>> font-family: 'TYPEWRITER'; /* default alternate */
>>>>
>>>> font-style: normal;
>>>>
>>>> font-weight: 900;
>>>>
>>>> src: local('Courier New'), url('Courier New.ttf') format('truetype');
>>>>
>>>> }
>>>>
>>>> /*
>>>> =============================================================================
>>>> */
>>>>
>>>> </style>
>>>>
>>>> <style type="text/css" media="screen, print">
>>>>
>>>> .webfont { font-size:200%; font-family:'TYPEWRITER'; color:green;} /*
>>>> Conversion TODO font families: SANS SERIF TYPEWRITER */
>>>>
>>>> </style>
>>>>
>>>>
>>> I think this guidance still applies for custom font families if a
>>> FontLibrary node is not used. FontLibrary font loading does not require
>>> this css. Also, all basic X3D font families do not require css.
>>> https://github.com/x3dom/x3dom/blob/master/test/functional/fonts.html
>>> has examples.
>>>
>>>
>>>> and
>>>>
>>>> *4. Is the following still the best up-to-date list of supported nodes?*
>>>>
>>>> https://andreasplesch.github.io/x3dom/dist/doc/author/nodes.html
>>>>
>>>> P.S. node wish list: IndexedTriangleFanSet, Script
>>>>
>>>>
>>> https://x3dom.github.io/x3dom-dev/dist/doc
>>>
>>> would be the best source for up to date documentation on supported nodes
>>> with dev releases as it is built and deployed along with the library.
>>>
>>>
>>> Thanks in advance for all improvements to these invocations, and thanks
>>>> as ever for ongoing progress with X3DOM!
>>>>
>>>> all the best, Don
>>>>
>>>
>>> All the best, Andreas
>>> --
>>> Andreas Plesch
>>> Waltham, MA 02453
>>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d...@we...
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d...@we...
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
> _______________________________________________
> x3d-public mailing list
> x3d...@we...
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>

[x3dom-developers] Web3D 2025: Early Bird Alert | July 10, 2025 | Register now and save

[Web3D C. <ann...@we...>]

Web3D 2025: Learn, Collaborate, Network and Innovate

Web3D 2025 Conference (https://web3d.siggraph.org/2025/registration/) , from Sept 9 -10, 2025 in Siena, Italy. Co-located with Digital Heritage 2025 (https://digitalheritage2025.unisi.it/) .
Early registration ends 10th July 2025.
Register (https://web3d.siggraph.org/2025/registration/) now and learn from the best in the 3D Web industry. Engage with a passionate community of like-minded enthusiasts. Join us to advance the exciting world of 3D on the Web!
Program Details (https://web3d.siggraph.org/2025/program/)    Keynote Speaker (https://web3d.siggraph.org/2025/keynote-speakers/) .

Papers:  Presenting original work in 3D research and their applications.
Posters: Interactive posters presenting results of ongoing or recently completed work in 3D web research and applications.
Industrial Use Cases: Use cases aimed at demonstrating how 3D web technologies may be used in industrial applications.
Tutorials:  Courses presenting introductory and advanced applications of 3D Web technologies to students and to experienced practitioners.
Workshops: Workshops providing a forum for researchers and practitioners from both the Web and 3D multimedia communities, to discuss and exchange positions on current and emergent 3D web topics.
Competitions (https://web3d.siggraph.org/2025/competitions/) : Annual competitions dedicated to Shape the Future of 3D Web Tools and Humanoid Animation. Win prizes over $1,200. Create opportunities for collaboration among developers, industry experts, and educators to share knowledge and resources. Gain recognition, and visibility within the 3D industry.

Become a Part of Our Legacy. Sponsor and support the conference. View Sponsorship Prospectus (https://web3d.siggraph.org/2025/wp-content/uploads/Web3D-2025-Prospectus.pdf)

Sponsored by ACM SIGGRAPH in cooperation with Web3D Consortium (https://www.web3d.org)  supported by Eurographics (https://www.eg.org/wp/) .

If you would like more information about the conference, please visit our website (https://web3d.siggraph.org/)  or email us at pro...@we... (mailto:pro...@we...)
See you in Siena, Italy!
Learn More (https://web3d.siggraph.org/)

============================================================
** Facebook (http://www.facebook.com)
** Twitter (https://twitter.com/Web3Dconsortium)
** YouTube (https://www.youtube.com/c/Web3DConsortium)
** Website (www.web3d.org)
** Email (mailto:we...@we...)
Copyright © 2025 Web3D Consortium, All rights reserved.
 You are receiving this email because you opted in via our website.

Our mailing address is:
Web3D Consortium
133 Lorimer St
Salinas, CA 93901-2021
USA
Want to change how you receive these emails?
You can ** update your preferences (https://web3d.us10.list-manage.com/profile?u=0051673b83909ae284624feb2&id=f1ef934431&e=43bd7983eb&c=3275fb2ebd)
or ** unsubscribe from this list (https://web3d.us10.list-manage.com/unsubscribe?u=0051673b83909ae284624feb2&id=f1ef934431&t=b&e=43bd7983eb&c=3275fb2ebd)
.
 Email Marketing Powered by Mailchimp
https://login.mailchimp.com/signup/email-referral/?aid=0051673b83909ae284624feb2

[x3dom-developers] Web3D 2025 - Papers Deadline Extended to 22 May 2025

[Web3D A. <ann...@we...>]

Web3D 2025 Conference (https://web3d.siggraph.org/2025/) (Sept 9-10, Siena, Italy) - Call for Papers, Posters, and Industrial Use Cases submission deadline extended to May 22, 2025. Call for Participation (https://web3d.siggraph.org/2025/call-for-papers/)
Submit Here (https://easychair.org/conferences/?conf=web3d2025) .

Considering the high level of interest and numerous requests we have received, we have extended the papersubmission (https://web3d.siggraph.org/cfp/) deadline to May 22 2025 at 10:00 PM PDT (GMT-0700). We understand that this extension will provide you with additional time to finalize your research and prepare your paper for submission. We encourage you to take advantage of this opportunity to ensure the quality and completeness of your work.  Submit Here (https://easychair.org/conferences/?conf=web3d2025) . Should you have any questions please contact us at pro...@we... (mailto:pro...@we...?subject=Web3D%202025) .
Accepted work will be published in the Web3D 2025 ACM Conference Proceedings, available in the ACM Digital Library (https://dl.acm.org/) . Works selected for the Best Paper awards will be invited to submit extended versions to the Computers & Graphics journal (https://www.sciencedirect.com/journal/computers-and-graphics) .

Benefits of submitting your work:
* Gain visibility and exposure to an international audience passionate about 3D graphics
* Network and engage with leading minds in your industry
* Drive the conversation and inspire the next generation of creators and innovators
* Unlock new opportunities through published work

Ready to make an impact?
* Submit here  (https://easychair.org/conferences/?conf=web3d2025)
* Call for Participation (https://web3d.siggraph.org/2025/call-for-papers/)
* Submission Guidelines (https://web3d.siggraph.org/2025/call-for-papers/submission-guidelines/)
* Important Dates (https://web3d.siggraph.org/2025/call-for-papers/#important-dates)
* Questions: pro...@we... (mailto::pro...@we...)
* Conference Website: https://web3d.siggraph.org/2025 (https://web3d.siggraph.org/2025/)
* Program and Registration coming soon

For more information, including submission guidelines and important dates, please visit the conference website (https://web3d.siggraph.org/2025/)  or contact the program committee at pro...@we... (mailto::pro...@we...)

Thank you for your continued support and interest in the Web3D Conference. We look forward to receiving your valuable contributions and seeing you in Siena, Italy.



** More details at: Web3D News and Events  (https://www.web3d.org/news-events)
------------------------------------------------------------
Learn More (https://web3d.siggraph.org/)

============================================================
** Facebook (http://www.facebook.com)
** Twitter (https://twitter.com/Web3Dconsortium)
** Website (https://web3d.siggraph.org/)
Copyright © 2025 Web3D Consortium, All rights reserved.
 You are receiving this email because you opted in via our website.

Our mailing address is:
Web3D Consortium
133 Lorimer St
Salinas, CA 93901-2021
USA
Want to change how you receive these emails?
You can ** update your preferences (https://web3d.us10.list-manage.com/profile?u=0051673b83909ae284624feb2&id=f1ef934431&e=43bd7983eb&c=201925a781)
or ** unsubscribe from this list (https://web3d.us10.list-manage.com/unsubscribe?u=0051673b83909ae284624feb2&id=f1ef934431&t=b&e=43bd7983eb&c=201925a781)
.
 Email Marketing Powered by Mailchimp
https://login.mailchimp.com/signup/email-referral/?aid=0051673b83909ae284624feb2

[x3dom-developers] Web3D 2025 - Deadline Changed to 15 May 2025

[Web3D A. <ann...@we...>]

Web3D 2025 Conference (https://web3d.siggraph.org/2025/) - Call for Papers, Posters, and Industrial Use Cases

Submission Deadline Changed to May 15, 2025
Submission PlatformEasyChair (https://easychair.org/conferences/?conf=web3d2025)

The Web3D Consortium (https://www.web3d.org/) invites you to share your best work at the Web3D 2025 Conference, taking place from September 9-10, 2025 in the beautiful city of Siena, Italy. Co-located with Digital Heritage 2025 (https://digitalheritage2025.unisi.it/)  (8-13 September).

The theme for this year's conference is "Digital Legacies and Immersive Futures," focusing on the integration of virtual reality, augmented reality, and other immersive technologies into the digital heritage domain. This integration aims to create engaging digital environments for exploration, learning, collaboration, and communication. The conference will bring together experts from around the world to discuss the latest research, development, and practices related to these technologies.

We welcome submissions of academic papers, posters, and industrial use cases on awide range of topics (https://web3d.siggraph.org/2025/call-for-papers/#topics) , including (but not limited to) web/mobile 3D content creation, immersive realities, digital cultural heritage, 3D compression, publishing technology, tools, and related studies.

The submission deadline for papers, posters, and industrial use cases is May 15, 2025, at 10:00 PM PDT (GMT-0700).  We have also changed our submission platform to Easychair - Submit here

Accepted work will be published in the Web3D 2025 ACM Conference Proceedings, available in the ACM Digital Library (https://dl.acm.org/) . Works selected for the Best Paper awards will be invited to submit extended versions to the Computers & Graphics journal (https://www.sciencedirect.com/journal/computers-and-graphics) .

Benefits of submitting your work:
* Gain visibility and exposure to an international audience passionate about 3D graphics
* Network and engage with leading minds in your industry
* Drive the conversation and inspire the next generation of creators and innovators
* Unlock new opportunities through published work

For more information, including submission guidelines and important dates, please visit the conference website (https://web3d.siggraph.org/2025/)  or contact the program committee at pro...@we... (mailto::pro...@we...)

We look forward to your contributions and to seeing you at Web3D 2025 in Siena, Italy!


** Ready to make an impact?
------------------------------------------------------------
* Submit here  (https://easychair.org/conferences/?conf=web3d2025)
* Call for Participation (https://web3d.siggraph.org/2025/call-for-papers/)
* Submission Guidelines (https://web3d.siggraph.org/2025/call-for-papers/submission-guidelines/)
* Important Dates (https://web3d.siggraph.org/2025/call-for-papers/#important-dates)
* Questions: pro...@we... (mailto::pro...@we...)
* Conference Website: https://web3d.siggraph.org/2025/
* Program and Registration coming soon


** More details at: Web3D News and Events  (https://www.web3d.org/news-events)
------------------------------------------------------------
Learn More (https://web3d.siggraph.org/)

============================================================
** Facebook (http://www.facebook.com)
** Twitter (https://twitter.com/Web3Dconsortium)
** Website (https://web3d.siggraph.org/)
Copyright © 2025 Web3D Consortium, All rights reserved.
 You are receiving this email because you opted in via our website.

Our mailing address is:
Web3D Consortium
133 Lorimer St
Salinas, CA 93901-2021
USA
Want to change how you receive these emails?
You can ** update your preferences (https://web3d.us10.list-manage.com/profile?u=0051673b83909ae284624feb2&id=f1ef934431&e=43bd7983eb&c=77ad45ec72)
or ** unsubscribe from this list (https://web3d.us10.list-manage.com/unsubscribe?u=0051673b83909ae284624feb2&id=f1ef934431&t=b&e=43bd7983eb&c=77ad45ec72)
.
 Email Marketing Powered by Mailchimp
https://login.mailchimp.com/signup/email-referral/?aid=0051673b83909ae284624feb2

[x3dom-developers] Web3D 2025 - 2nd Call for Papers - Deadline 1st May 2025

[Web3D A. <ann...@we...>]

Web3D 2025 Conference (https://web3d.siggraph.org/2025/) - Call for Papers, Posters, and Industrial Use Cases

Submission Deadline: May 1, 2025

The Web3D Consortium (https://www.web3d.org/) invites you to share your best work at the Web3D 2025 Conference, taking place from September 9-10, 2025 in the beautiful city of Siena, Italy. Co-located with Digital Heritage 2025 (https://digitalheritage2025.unisi.it/)  (8-13 September).

The theme for this year's conference is "Digital Legacies and Immersive Futures," focusing on the integration of virtual reality, augmented reality, and other immersive technologies into the digital heritage domain. This integration aims to create engaging digital environments for exploration, learning, collaboration, and communication. The conference will bring together experts from around the world to discuss the latest research, development, and practices related to these technologies.

We welcome submissions of academic papers, posters, and industrial use cases on awide range of topics (https://web3d.siggraph.org/2025/call-for-papers/#topics) , including (but not limited to) web/mobile 3D content creation, immersive realities, digital cultural heritage, 3D compression, publishing technology, tools, and related studies.

The submission deadline for papers, posters, and industrial use cases is May 1, 2025, at 10:00 PM PDT (GMT-0700).

Accepted work will be published in the Web3D 2025 ACM Conference Proceedings, available in the ACM Digital Library (https://dl.acm.org/) . Works selected for the Best Paper awards will be invited to submit extended versions to the Computers & Graphics journal (https://www.sciencedirect.com/journal/computers-and-graphics) .

Benefits of submitting your work:
* Gain visibility and exposure to an international audience passionate about 3D graphics
* Network and engage with leading minds in your industry
* Drive the conversation and inspire the next generation of creators and innovators
* Unlock new opportunities through published work

For more information, including submission guidelines and important dates, please visit the conference website (https://web3d.siggraph.org/2025/)  or contact the program committee at pro...@we... (mailto::pro...@we...)

We look forward to your contributions and to seeing you at Web3D 2025 in Siena, Italy!


** Ready to make an impact?
------------------------------------------------------------
* Papers, Posters and Industrial Use Cases Submit here  (https://openreview.net/group?id=DigitalHeritage/2025/Congress_and_Expo)
* Tutorials, workshops, Competition Submit here (https://www.web3d.org/conferences/submissions-2025)
* CFP (https://web3d.siggraph.org/2025/call-for-papers/)
* Submission Guidelines (https://web3d.siggraph.org/2025/call-for-papers/submission-guidelines/)
* Important Dates (https://web3d.siggraph.org/2025/call-for-papers/#important-dates)
*  Questions: pro...@we... (mailto::pro...@we...)
* PDF version of the CFP (https://web3d.siggraph.org/2025/wp-content/uploads/Web3D-2025-CFP.pdf)
* Program and Registration coming soon
* https://web3d.siggraph.org/2025/


** Web3D News and Events  (https://www.web3d.org/news-events)
------------------------------------------------------------
Learn More (https://web3d.siggraph.org/)

============================================================
** Facebook (http://www.facebook.com)
** Twitter (https://twitter.com/Web3Dconsortium)
** Website (https://web3d.siggraph.org/)
Copyright © 2025 Web3D Consortium, All rights reserved.
 You are receiving this email because you opted in via our website.

Our mailing address is:
Web3D Consortium
133 Lorimer St
Salinas, CA 93901-2021
USA
Want to change how you receive these emails?
You can ** update your preferences (https://web3d.us10.list-manage.com/profile?u=0051673b83909ae284624feb2&id=f1ef934431&e=43bd7983eb&c=2e299a53b8)
or ** unsubscribe from this list (https://web3d.us10.list-manage.com/unsubscribe?u=0051673b83909ae284624feb2&id=f1ef934431&t=b&e=43bd7983eb&c=2e299a53b8)
.
 Email Marketing Powered by Mailchimp
https://login.mailchimp.com/signup/email-referral/?aid=0051673b83909ae284624feb2

Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

[Andreas P. <and...@gm...>]

No problem at all. It would be just interesting. Sketchfab has many free
models if Maya can import the formats it uses.
-Andreas

On Tue, Mar 18, 2025 at 11:30 PM Bergstrom, Aaron <aar...@un...>
wrote:

> Andreas,
>
>
>
> Understood, however, the sword model is only the model I am using for
> initial testing.
>
>
>
> I don’t have access to a broad range of content to test for the other
> fields, but my Maya python class that supports the CommonSurfaceShader
> includes support for all of the following:
>
>
>
> class CommonSurfaceShader():
>
> def __init__(self):
>
> self.DEF = ''
>
> self.USE = ''
>
> self._RK__containerField = ''
>
> self.alphaFactor = 1.0
>
> self.alphaTexture = None
>
> self.ambientFactor = (0.2, 0.2, 0.2)
>
> self.ambientTexture = None
>
> self.ambientTextureCoordinateId = 0
>
> self.diffuseFactor = (0.8, 0.8, 0.8)
>
> self.diffuseTexture = None
>
> self.diffuseTextureCoordinateId = 0
>
> self.emissiveFactor = (0.0, 0.0, 0.0)
>
> self.emissiveTexture = None
>
> self.emissiveTextureCoordinateId = 0
>
> self.metadata = None
>
> self.normalScale = (2.0, 2.0, 2.0)
>
> self.normalTexture = None
>
> self.normalTextureCoordinateId = 0
>
> self.shininessFactor = 0.2
>
> self.shininessTexture = None
>
> self.shininessTextureCoordianteId = 0
>
> self.specularFactor = (0.0, 0.0, 0.0)
>
> self.specularTexture = None
>
> self.specularTextureCoordianteId = 0
>
>
>
> So I just need access to more content (Maya or FBX) to test the export
> beyond diffuseTexture. I could potentially add most or all of the other CSS
> fields, but I would need access to content that would test the export of
> those additional fields.
>
>
>
> Aaron
>
>
>
> *From:* Andreas Plesch <and...@gm...>
> *Sent:* Monday, March 17, 2025 1:34 PM
> *To:* Bergstrom, Aaron <aar...@un...>
> *Cc:* x3d...@li...
> *Subject:* Re: [x3dom-developers] Maya/RawKee export for X3DOM Material
> node
>
>
>
> Hi Aaron,
>
>
>
> That looks good. I noticed that the sword example only uses a diffuse
> texture. The CommonSurfaceShader and new Material nodes really only provide
> an improvement over regular Material if additional textures like a normal
> texture are also provided.
>
> Would the exporter provide textures other than diffuse if available in the
> Maya model ? CommonSurfaceShader supports normal, shininess, and specular
> textures.
>
>
>
> -Andreas
>
>
>
> On Sat, Mar 15, 2025 at 4:52 PM Bergstrom, Aaron <aar...@un...>
> wrote:
>
> Andreas,
>
>
>
> The more I dug into it, the more I realized that it would just be easiest
> to check the encoding at the time of export, and write out a
> CommonSurfaceShader node instead of the Material node if the encoding was
> ‘html’.
>
>
>
> So that’s what it does. I changed very little code to make it work… so it
> didn’t take me nearly as long as I expected that it would.
>
>
>
> See an HTML version of the Sword model exported using RawKee for Maya that
> uses a CommonSurfaceShader instead of a Material node. Same URL as before:
>
> https://vr.csgrid.org/x3dom/swordtest.html
>
>
>
> To compare it to what it looks like in Maya, see this screenshot:
>
> https://vr.csgrid.org/x3dom/maya-screenshot.png
>
>
>
> Looks nearly identical to what is displayed in Maya, so I’m pretty happy
> with the results.
>
>
>
> If you check the HTML source of swordtest.html, you’ll see it uses a
> CommonSurfaceShader.
>
>
>
> I’m only exporting Material/CommonSurfaceShader for Maya Phong, PhongE,
> Blinn, and Lambert shaders. Otherwise the exporter defaults to
> PhysicalMaterial nodes for all other Maya shaders no matter the X3D
> encoding (XML, VRML, JSON, or HTML).
>
>
>
> I need to do a bit of more code work yet to tighten up my PhysicalMaterial
> node export, but that doesn’t affect the swordtest.html example using
> CommonSurfaceShader.
>
>
>
> Aaron
>
>
>
> *From:* Bergstrom, Aaron
> *Sent:* Friday, March 14, 2025 9:49 AM
> *To:* Andreas Plesch <and...@gm...>
> *Cc:* x3d...@li...
> *Subject:* RE: [x3dom-developers] Maya/RawKee export for X3DOM Material
> node
>
>
>
> Excellent, I can make that approach work too.
>
>
>
> Aaron
>
>
>
>
>
> *From:* Andreas Plesch <and...@gm...>
> *Sent:* Friday, March 14, 2025 9:45 AM
> *To:* Bergstrom, Aaron <aar...@un...>
> *Cc:* x3d...@li...
> *Subject:* Re: [x3dom-developers] Maya/RawKee export for X3DOM Material
> node
>
>
>
> Hi Aaron,
>
>
>
> While CommonSurfaceShader would indeed be the basis for an updated
> Material node, I do not think that such updating could occur in the near or
> medium term future.
>
>
>
> So you were right the first time and a CommonSurfaceShader option for
> RawKee would be great to have if possible.
>
>
>
> Yes, CommonSurfaceShader would be added to the MFNode Appearance.shaders
> field.
>
>
>
> It is a MFNode field to be able to contain fallbacks, in order of
> preference:
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/shaders.html#Selecting
> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/shaders.html#Selecting>
>
>
>
> I think providing such fallbacks occurs very rarely in practice, and is
> perhaps not supported by most x3d browsers. I am not aware of an example.
>
>
>
> All the best, -Andreas
>
>
>
> On Fri, Mar 14, 2025 at 10:30 AM Bergstrom, Aaron <aar...@un...>
> wrote:
>
> Andreas,
>
>
>
> Oops, I misunderstood your email.
>
>
>
> I see that you were proposing CommonSurfaceShader as the basis for an
> updated Material node.
>
>
>
> So change what I just said, for now I will add an export option that
> allows the user to select the export type they want to use:
>
>    - Material (old style with textures added to Appearance)
>    - Material (new style with textures in the material node)
>    - PhysicalMaterial
>
>
>
> Aaron
>
>
>
>
>
> *From:* Bergstrom, Aaron <aar...@un...>
> *Sent:* Friday, March 14, 2025 8:59 AM
> *To:* Andreas Plesch <and...@gm...>
> *Cc:* x3d...@li...
> *Subject:* Re: [x3dom-developers] Maya/RawKee export for X3DOM Material
> node
>
>
>
> Andreas,
>
>
>
> Thank you for this.
>
>
>
> Based on your feedback, for at least the older shader types in Maya, I’ll
> add an export option allowing the user to pick which method they want to
> use for exporting a shader, either:
>
>    - Material (old style with textures added to Appearance)
>    - Material (new style with textures in the material node)
>    - PhysicalMaterial
>    - CommonSurfaceShader
>
>
>
> It’ll probably take me a few days to re-write that section of the exporter
> code, but I should have the change completed by the end of the month.
>
>
>
> I would assume that “CommonSurfaceShader” would be added to the “shaders”
> field of the Appearance node. However, I see that “shaders” is an MFNode
> field. Do you have an example/tutorial of how multiple shaders are used, or
> is having multiple shaders not common? Why is “shaders” an MFNode field and
> not an SFNode field?
>
>
>
> Aaron
>
>
>
> *From:* Andreas Plesch <and...@gm...>
> *Sent:* Thursday, March 13, 2025 9:16 PM
> *To:* Bergstrom, Aaron <aar...@un...>
> *Cc:* x3d...@li...
> *Subject:* Re: [x3dom-developers] Maya/RawKee export for X3DOM Material
> node
>
>
>
> Hi Aaron,
>
>
>
> It is probably time to support the X3D v.4 Material features but it is not
> in the cards in the near term. See
>
>
>
> https://doc.x3dom.org/tutorials/lighting/commonSurfaceShaderNode/index.html
>
>
> and
>
>
> https://andreasplesch.github.io/x3dom/test/functional/commonSurfaceShader06.html
>
>
>
> for an older x3dom equivalent which is very similar but can only use one
> set of texture coordinates.
>
>
>
> This would be also the starting point for supporting the new Material
> fields if anybody is interested in giving it a try.
>
>
>
> Also note that the x3dom PhysicalMaterial is older than X3D v.4 and mostly
> intended for glTF inlines. So it does not exactly conform to X3D v.4. I
> think for example it directly accepts binary buffers which can be passed to
> webgl.
>
>
>
> Hope this helps, -Andreas
>
>
>
> On Thu, Mar 13, 2025 at 12:04 PM Bergstrom, Aaron <aar...@un...>
> wrote:
>
> I realize that X3DOM supports the ‘PhysicalMaterial’ node, but are there
> any plans to update support for the old ‘Material’ node to be X3D 4.0
> compliant?
>
>
>
> The new RawKee plugin has 4.0 export support for both the
> ‘PhysicalMaterial’ and ‘Material’ nodes. I’m currently exporting Maya
> Phong, PhongE, Blinn, and Lambert shadingEngine nodes as 4.0 ‘Material’
> nodes. However, X3DOM doesn’t seem to support the 4.0 texture map features
> for the 4.0 ‘Material’ node.
>
>
>
> If there is no intent to have X3DOM to support the newer features of the
> ‘Material’ node going forward, I will change how I am exporting the Phong,
> PhongE, Blinn, and Lambert shaders from Maya.
>
>
>
> Thanks,
>
>
>
> Aaron
>
> _______________________________________________
> x3dom-developers mailing list
> x3d...@li...
> https://lists.sourceforge.net/lists/listinfo/x3dom-developers
>
>
>
>
> --
>
> Andreas Plesch
> Waltham, MA 02453
>
>
>
> --
>
> Andreas Plesch
> Waltham, MA 02453
>
>
>
> --
>
> Andreas Plesch
> Waltham, MA 02453
>


-- 
Andreas Plesch
Waltham, MA 02453

Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

[Bergstrom, A. <aar...@un...>]

Andreas,

Understood, however, the sword model is only the model I am using for initial testing.

I don’t have access to a broad range of content to test for the other fields, but my Maya python class that supports the CommonSurfaceShader includes support for all of the following:

class CommonSurfaceShader():
def __init__(self):
self.DEF = ''
self.USE = ''
self._RK__containerField = ''
self.alphaFactor = 1.0
self.alphaTexture = None
self.ambientFactor = (0.2, 0.2, 0.2)
self.ambientTexture = None
self.ambientTextureCoordinateId = 0
self.diffuseFactor = (0.8, 0.8, 0.8)
self.diffuseTexture = None
self.diffuseTextureCoordinateId = 0
self.emissiveFactor = (0.0, 0.0, 0.0)
self.emissiveTexture = None
self.emissiveTextureCoordinateId = 0
self.metadata = None
self.normalScale = (2.0, 2.0, 2.0)
self.normalTexture = None
self.normalTextureCoordinateId = 0
self.shininessFactor = 0.2
self.shininessTexture = None
self.shininessTextureCoordianteId = 0
self.specularFactor = (0.0, 0.0, 0.0)
self.specularTexture = None
self.specularTextureCoordianteId = 0

So I just need access to more content (Maya or FBX) to test the export beyond diffuseTexture. I could potentially add most or all of the other CSS fields, but I would need access to content that would test the export of those additional fields.

Aaron

From: Andreas Plesch <and...@gm...>
Sent: Monday, March 17, 2025 1:34 PM
To: Bergstrom, Aaron <aar...@un...>
Cc: x3d...@li...
Subject: Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Hi Aaron,

That looks good. I noticed that the sword example only uses a diffuse texture. The CommonSurfaceShader and new Material nodes really only provide an improvement over regular Material if additional textures like a normal texture are also provided.
Would the exporter provide textures other than diffuse if available in the Maya model ? CommonSurfaceShader supports normal, shininess, and specular textures.

-Andreas

On Sat, Mar 15, 2025 at 4:52 PM Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>> wrote:
Andreas,

The more I dug into it, the more I realized that it would just be easiest to check the encoding at the time of export, and write out a CommonSurfaceShader node instead of the Material node if the encoding was ‘html’.

So that’s what it does. I changed very little code to make it work… so it didn’t take me nearly as long as I expected that it would.

See an HTML version of the Sword model exported using RawKee for Maya that uses a CommonSurfaceShader instead of a Material node. Same URL as before:
https://vr.csgrid.org/x3dom/swordtest.html

To compare it to what it looks like in Maya, see this screenshot:
https://vr.csgrid.org/x3dom/maya-screenshot.png

Looks nearly identical to what is displayed in Maya, so I’m pretty happy with the results.

If you check the HTML source of swordtest.html, you’ll see it uses a CommonSurfaceShader.

I’m only exporting Material/CommonSurfaceShader for Maya Phong, PhongE, Blinn, and Lambert shaders. Otherwise the exporter defaults to PhysicalMaterial nodes for all other Maya shaders no matter the X3D encoding (XML, VRML, JSON, or HTML).

I need to do a bit of more code work yet to tighten up my PhysicalMaterial node export, but that doesn’t affect the swordtest.html example using CommonSurfaceShader.

Aaron

From: Bergstrom, Aaron
Sent: Friday, March 14, 2025 9:49 AM
To: Andreas Plesch <and...@gm...<mailto:and...@gm...>>
Cc: x3d...@li...<mailto:x3d...@li...>
Subject: RE: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Excellent, I can make that approach work too.

Aaron


From: Andreas Plesch <and...@gm...<mailto:and...@gm...>>
Sent: Friday, March 14, 2025 9:45 AM
To: Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>>
Cc: x3d...@li...<mailto:x3d...@li...>
Subject: Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Hi Aaron,

While CommonSurfaceShader would indeed be the basis for an updated Material node, I do not think that such updating could occur in the near or medium term future.

So you were right the first time and a CommonSurfaceShader option for RawKee would be great to have if possible.

Yes, CommonSurfaceShader would be added to the MFNode Appearance.shaders field.

It is a MFNode field to be able to contain fallbacks, in order of preference: https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/shaders.html#Selecting<https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/shaders.html#Selecting>

I think providing such fallbacks occurs very rarely in practice, and is perhaps not supported by most x3d browsers. I am not aware of an example.

All the best, -Andreas

On Fri, Mar 14, 2025 at 10:30 AM Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>> wrote:
Andreas,

Oops, I misunderstood your email.

I see that you were proposing CommonSurfaceShader as the basis for an updated Material node.

So change what I just said, for now I will add an export option that allows the user to select the export type they want to use:

  *   Material (old style with textures added to Appearance)
  *   Material (new style with textures in the material node)
  *   PhysicalMaterial

Aaron


From: Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>>
Sent: Friday, March 14, 2025 8:59 AM
To: Andreas Plesch <and...@gm...<mailto:and...@gm...>>
Cc: x3d...@li...<mailto:x3d...@li...>
Subject: Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Andreas,

Thank you for this.

Based on your feedback, for at least the older shader types in Maya, I’ll add an export option allowing the user to pick which method they want to use for exporting a shader, either:

  *   Material (old style with textures added to Appearance)
  *   Material (new style with textures in the material node)
  *   PhysicalMaterial
  *   CommonSurfaceShader

It’ll probably take me a few days to re-write that section of the exporter code, but I should have the change completed by the end of the month.

I would assume that “CommonSurfaceShader” would be added to the “shaders” field of the Appearance node. However, I see that “shaders” is an MFNode field. Do you have an example/tutorial of how multiple shaders are used, or is having multiple shaders not common? Why is “shaders” an MFNode field and not an SFNode field?

Aaron

From: Andreas Plesch <and...@gm...<mailto:and...@gm...>>
Sent: Thursday, March 13, 2025 9:16 PM
To: Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>>
Cc: x3d...@li...<mailto:x3d...@li...>
Subject: Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Hi Aaron,

It is probably time to support the X3D v.4 Material features but it is not in the cards in the near term. See

https://doc.x3dom.org/tutorials/lighting/commonSurfaceShaderNode/index.html
and
https://andreasplesch.github.io/x3dom/test/functional/commonSurfaceShader06.html

for an older x3dom equivalent which is very similar but can only use one set of texture coordinates.

This would be also the starting point for supporting the new Material fields if anybody is interested in giving it a try.

Also note that the x3dom PhysicalMaterial is older than X3D v.4 and mostly intended for glTF inlines. So it does not exactly conform to X3D v.4. I think for example it directly accepts binary buffers which can be passed to webgl.

Hope this helps, -Andreas

On Thu, Mar 13, 2025 at 12:04 PM Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>> wrote:
I realize that X3DOM supports the ‘PhysicalMaterial’ node, but are there any plans to update support for the old ‘Material’ node to be X3D 4.0 compliant?

The new RawKee plugin has 4.0 export support for both the ‘PhysicalMaterial’ and ‘Material’ nodes. I’m currently exporting Maya Phong, PhongE, Blinn, and Lambert shadingEngine nodes as 4.0 ‘Material’ nodes. However, X3DOM doesn’t seem to support the 4.0 texture map features for the 4.0 ‘Material’ node.

If there is no intent to have X3DOM to support the newer features of the ‘Material’ node going forward, I will change how I am exporting the Phong, PhongE, Blinn, and Lambert shaders from Maya.

Thanks,

Aaron
_______________________________________________
x3dom-developers mailing list
x3d...@li...<mailto:x3d...@li...>
https://lists.sourceforge.net/lists/listinfo/x3dom-developers


--
Andreas Plesch
Waltham, MA 02453


--
Andreas Plesch
Waltham, MA 02453


--
Andreas Plesch
Waltham, MA 02453

[x3dom-developers] new x3dom dev release

[Andreas P. <and...@gm...>]

https://github.com/x3dom/x3dom-dev has a new 1.8.4-dev release with HAnim
improvements and a few minor fixes. See the Changelog at
https://github.com/x3dom/x3dom-dev/blob/main/dist/CHANGELOG.md

The dev-releases are only available from github which also enables the
jsdelivr cdn for fast access:

https://cdn.jsdelivr.net/gh/x3dom/x3dom-dev/dist/x3dom.js

and many variants.

The x3dom.org server does not appear to provide nightly releases any more.

Have fun, Andreas
-- 
Andreas Plesch
Waltham, MA 02453

Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

[Andreas P. <and...@gm...>]

Hi Aaron,

That looks good. I noticed that the sword example only uses a diffuse
texture. The CommonSurfaceShader and new Material nodes really only provide
an improvement over regular Material if additional textures like a normal
texture are also provided.
Would the exporter provide textures other than diffuse if available in the
Maya model ? CommonSurfaceShader supports normal, shininess, and specular
textures.

-Andreas

On Sat, Mar 15, 2025 at 4:52 PM Bergstrom, Aaron <aar...@un...>
wrote:

> Andreas,
>
>
>
> The more I dug into it, the more I realized that it would just be easiest
> to check the encoding at the time of export, and write out a
> CommonSurfaceShader node instead of the Material node if the encoding was
> ‘html’.
>
>
>
> So that’s what it does. I changed very little code to make it work… so it
> didn’t take me nearly as long as I expected that it would.
>
>
>
> See an HTML version of the Sword model exported using RawKee for Maya that
> uses a CommonSurfaceShader instead of a Material node. Same URL as before:
>
> https://vr.csgrid.org/x3dom/swordtest.html
>
>
>
> To compare it to what it looks like in Maya, see this screenshot:
>
> https://vr.csgrid.org/x3dom/maya-screenshot.png
>
>
>
> Looks nearly identical to what is displayed in Maya, so I’m pretty happy
> with the results.
>
>
>
> If you check the HTML source of swordtest.html, you’ll see it uses a
> CommonSurfaceShader.
>
>
>
> I’m only exporting Material/CommonSurfaceShader for Maya Phong, PhongE,
> Blinn, and Lambert shaders. Otherwise the exporter defaults to
> PhysicalMaterial nodes for all other Maya shaders no matter the X3D
> encoding (XML, VRML, JSON, or HTML).
>
>
>
> I need to do a bit of more code work yet to tighten up my PhysicalMaterial
> node export, but that doesn’t affect the swordtest.html example using
> CommonSurfaceShader.
>
>
>
> Aaron
>
>
>
> *From:* Bergstrom, Aaron
> *Sent:* Friday, March 14, 2025 9:49 AM
> *To:* Andreas Plesch <and...@gm...>
> *Cc:* x3d...@li...
> *Subject:* RE: [x3dom-developers] Maya/RawKee export for X3DOM Material
> node
>
>
>
> Excellent, I can make that approach work too.
>
>
>
> Aaron
>
>
>
>
>
> *From:* Andreas Plesch <and...@gm...>
> *Sent:* Friday, March 14, 2025 9:45 AM
> *To:* Bergstrom, Aaron <aar...@un...>
> *Cc:* x3d...@li...
> *Subject:* Re: [x3dom-developers] Maya/RawKee export for X3DOM Material
> node
>
>
>
> Hi Aaron,
>
>
>
> While CommonSurfaceShader would indeed be the basis for an updated
> Material node, I do not think that such updating could occur in the near or
> medium term future.
>
>
>
> So you were right the first time and a CommonSurfaceShader option for
> RawKee would be great to have if possible.
>
>
>
> Yes, CommonSurfaceShader would be added to the MFNode Appearance.shaders
> field.
>
>
>
> It is a MFNode field to be able to contain fallbacks, in order of
> preference:
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/shaders.html#Selecting
> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/shaders.html#Selecting>
>
>
>
> I think providing such fallbacks occurs very rarely in practice, and is
> perhaps not supported by most x3d browsers. I am not aware of an example.
>
>
>
> All the best, -Andreas
>
>
>
> On Fri, Mar 14, 2025 at 10:30 AM Bergstrom, Aaron <aar...@un...>
> wrote:
>
> Andreas,
>
>
>
> Oops, I misunderstood your email.
>
>
>
> I see that you were proposing CommonSurfaceShader as the basis for an
> updated Material node.
>
>
>
> So change what I just said, for now I will add an export option that
> allows the user to select the export type they want to use:
>
>    - Material (old style with textures added to Appearance)
>    - Material (new style with textures in the material node)
>    - PhysicalMaterial
>
>
>
> Aaron
>
>
>
>
>
> *From:* Bergstrom, Aaron <aar...@un...>
> *Sent:* Friday, March 14, 2025 8:59 AM
> *To:* Andreas Plesch <and...@gm...>
> *Cc:* x3d...@li...
> *Subject:* Re: [x3dom-developers] Maya/RawKee export for X3DOM Material
> node
>
>
>
> Andreas,
>
>
>
> Thank you for this.
>
>
>
> Based on your feedback, for at least the older shader types in Maya, I’ll
> add an export option allowing the user to pick which method they want to
> use for exporting a shader, either:
>
>    - Material (old style with textures added to Appearance)
>    - Material (new style with textures in the material node)
>    - PhysicalMaterial
>    - CommonSurfaceShader
>
>
>
> It’ll probably take me a few days to re-write that section of the exporter
> code, but I should have the change completed by the end of the month.
>
>
>
> I would assume that “CommonSurfaceShader” would be added to the “shaders”
> field of the Appearance node. However, I see that “shaders” is an MFNode
> field. Do you have an example/tutorial of how multiple shaders are used, or
> is having multiple shaders not common? Why is “shaders” an MFNode field and
> not an SFNode field?
>
>
>
> Aaron
>
>
>
> *From:* Andreas Plesch <and...@gm...>
> *Sent:* Thursday, March 13, 2025 9:16 PM
> *To:* Bergstrom, Aaron <aar...@un...>
> *Cc:* x3d...@li...
> *Subject:* Re: [x3dom-developers] Maya/RawKee export for X3DOM Material
> node
>
>
>
> Hi Aaron,
>
>
>
> It is probably time to support the X3D v.4 Material features but it is not
> in the cards in the near term. See
>
>
>
> https://doc.x3dom.org/tutorials/lighting/commonSurfaceShaderNode/index.html
>
>
> and
>
>
> https://andreasplesch.github.io/x3dom/test/functional/commonSurfaceShader06.html
>
>
>
> for an older x3dom equivalent which is very similar but can only use one
> set of texture coordinates.
>
>
>
> This would be also the starting point for supporting the new Material
> fields if anybody is interested in giving it a try.
>
>
>
> Also note that the x3dom PhysicalMaterial is older than X3D v.4 and mostly
> intended for glTF inlines. So it does not exactly conform to X3D v.4. I
> think for example it directly accepts binary buffers which can be passed to
> webgl.
>
>
>
> Hope this helps, -Andreas
>
>
>
> On Thu, Mar 13, 2025 at 12:04 PM Bergstrom, Aaron <aar...@un...>
> wrote:
>
> I realize that X3DOM supports the ‘PhysicalMaterial’ node, but are there
> any plans to update support for the old ‘Material’ node to be X3D 4.0
> compliant?
>
>
>
> The new RawKee plugin has 4.0 export support for both the
> ‘PhysicalMaterial’ and ‘Material’ nodes. I’m currently exporting Maya
> Phong, PhongE, Blinn, and Lambert shadingEngine nodes as 4.0 ‘Material’
> nodes. However, X3DOM doesn’t seem to support the 4.0 texture map features
> for the 4.0 ‘Material’ node.
>
>
>
> If there is no intent to have X3DOM to support the newer features of the
> ‘Material’ node going forward, I will change how I am exporting the Phong,
> PhongE, Blinn, and Lambert shaders from Maya.
>
>
>
> Thanks,
>
>
>
> Aaron
>
> _______________________________________________
> x3dom-developers mailing list
> x3d...@li...
> https://lists.sourceforge.net/lists/listinfo/x3dom-developers
>
>
>
>
> --
>
> Andreas Plesch
> Waltham, MA 02453
>
>
>
> --
>
> Andreas Plesch
> Waltham, MA 02453
>


-- 
Andreas Plesch
Waltham, MA 02453

Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

[Bergstrom, A. <aar...@un...>]

All,

I’m open to expanding CommonSurfaceShader support to more Maya shaders, but I would need to work with a Maya artist who has an understanding of shaders and the CommonSurfaceShader output.

Either that, or get access to 3D Studio Max content in the form of FBX that has also been previously exported to the HTML encoding.

I could import the FBX into Maya, and then compare that to the previous HTML export from Max, and then alter the RawKee export functions accordingly for CommonSurfaceShader.

Max content that uses most of the CommonSurfaceShader fields would be the most preferable. But I’d take a bunch of different FBX/HTML examples to for comparison.

Thanks,

Aaron

From: Bergstrom, Aaron <aar...@un...>
Sent: Saturday, March 15, 2025 3:53 PM
To: Andreas Plesch <and...@gm...>
Cc: x3d...@li...
Subject: Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Andreas,

The more I dug into it, the more I realized that it would just be easiest to check the encoding at the time of export, and write out a CommonSurfaceShader node instead of the Material node if the encoding was ‘html’.

So that’s what it does. I changed very little code to make it work… so it didn’t take me nearly as long as I expected that it would.

See an HTML version of the Sword model exported using RawKee for Maya that uses a CommonSurfaceShader instead of a Material node. Same URL as before:
https://vr.csgrid.org/x3dom/swordtest.html

To compare it to what it looks like in Maya, see this screenshot:
https://vr.csgrid.org/x3dom/maya-screenshot.png

Looks nearly identical to what is displayed in Maya, so I’m pretty happy with the results.

If you check the HTML source of swordtest.html, you’ll see it uses a CommonSurfaceShader.

I’m only exporting Material/CommonSurfaceShader for Maya Phong, PhongE, Blinn, and Lambert shaders. Otherwise the exporter defaults to PhysicalMaterial nodes for all other Maya shaders no matter the X3D encoding (XML, VRML, JSON, or HTML).

I need to do a bit of more code work yet to tighten up my PhysicalMaterial node export, but that doesn’t affect the swordtest.html example using CommonSurfaceShader.

Aaron

From: Bergstrom, Aaron
Sent: Friday, March 14, 2025 9:49 AM
To: Andreas Plesch <and...@gm...<mailto:and...@gm...>>
Cc: x3d...@li...<mailto:x3d...@li...>
Subject: RE: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Excellent, I can make that approach work too.

Aaron


From: Andreas Plesch <and...@gm...<mailto:and...@gm...>>
Sent: Friday, March 14, 2025 9:45 AM
To: Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>>
Cc: x3d...@li...<mailto:x3d...@li...>
Subject: Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Hi Aaron,

While CommonSurfaceShader would indeed be the basis for an updated Material node, I do not think that such updating could occur in the near or medium term future.

So you were right the first time and a CommonSurfaceShader option for RawKee would be great to have if possible.

Yes, CommonSurfaceShader would be added to the MFNode Appearance.shaders field.

It is a MFNode field to be able to contain fallbacks, in order of preference: https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/shaders.html#Selecting<https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/shaders.html#Selecting>

I think providing such fallbacks occurs very rarely in practice, and is perhaps not supported by most x3d browsers. I am not aware of an example.

All the best, -Andreas

On Fri, Mar 14, 2025 at 10:30 AM Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>> wrote:
Andreas,

Oops, I misunderstood your email.

I see that you were proposing CommonSurfaceShader as the basis for an updated Material node.

So change what I just said, for now I will add an export option that allows the user to select the export type they want to use:

  *   Material (old style with textures added to Appearance)
  *   Material (new style with textures in the material node)
  *   PhysicalMaterial

Aaron


From: Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>>
Sent: Friday, March 14, 2025 8:59 AM
To: Andreas Plesch <and...@gm...<mailto:and...@gm...>>
Cc: x3d...@li...<mailto:x3d...@li...>
Subject: Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Andreas,

Thank you for this.

Based on your feedback, for at least the older shader types in Maya, I’ll add an export option allowing the user to pick which method they want to use for exporting a shader, either:

  *   Material (old style with textures added to Appearance)
  *   Material (new style with textures in the material node)
  *   PhysicalMaterial
  *   CommonSurfaceShader

It’ll probably take me a few days to re-write that section of the exporter code, but I should have the change completed by the end of the month.

I would assume that “CommonSurfaceShader” would be added to the “shaders” field of the Appearance node. However, I see that “shaders” is an MFNode field. Do you have an example/tutorial of how multiple shaders are used, or is having multiple shaders not common? Why is “shaders” an MFNode field and not an SFNode field?

Aaron

From: Andreas Plesch <and...@gm...<mailto:and...@gm...>>
Sent: Thursday, March 13, 2025 9:16 PM
To: Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>>
Cc: x3d...@li...<mailto:x3d...@li...>
Subject: Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Hi Aaron,

It is probably time to support the X3D v.4 Material features but it is not in the cards in the near term. See

https://doc.x3dom.org/tutorials/lighting/commonSurfaceShaderNode/index.html
and
https://andreasplesch.github.io/x3dom/test/functional/commonSurfaceShader06.html

for an older x3dom equivalent which is very similar but can only use one set of texture coordinates.

This would be also the starting point for supporting the new Material fields if anybody is interested in giving it a try.

Also note that the x3dom PhysicalMaterial is older than X3D v.4 and mostly intended for glTF inlines. So it does not exactly conform to X3D v.4. I think for example it directly accepts binary buffers which can be passed to webgl.

Hope this helps, -Andreas

On Thu, Mar 13, 2025 at 12:04 PM Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>> wrote:
I realize that X3DOM supports the ‘PhysicalMaterial’ node, but are there any plans to update support for the old ‘Material’ node to be X3D 4.0 compliant?

The new RawKee plugin has 4.0 export support for both the ‘PhysicalMaterial’ and ‘Material’ nodes. I’m currently exporting Maya Phong, PhongE, Blinn, and Lambert shadingEngine nodes as 4.0 ‘Material’ nodes. However, X3DOM doesn’t seem to support the 4.0 texture map features for the 4.0 ‘Material’ node.

If there is no intent to have X3DOM to support the newer features of the ‘Material’ node going forward, I will change how I am exporting the Phong, PhongE, Blinn, and Lambert shaders from Maya.

Thanks,

Aaron
_______________________________________________
x3dom-developers mailing list
x3d...@li...<mailto:x3d...@li...>
https://lists.sourceforge.net/lists/listinfo/x3dom-developers


--
Andreas Plesch
Waltham, MA 02453


--
Andreas Plesch
Waltham, MA 02453

Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

[Bergstrom, A. <aar...@un...>]

Andreas,

The more I dug into it, the more I realized that it would just be easiest to check the encoding at the time of export, and write out a CommonSurfaceShader node instead of the Material node if the encoding was ‘html’.

So that’s what it does. I changed very little code to make it work… so it didn’t take me nearly as long as I expected that it would.

See an HTML version of the Sword model exported using RawKee for Maya that uses a CommonSurfaceShader instead of a Material node. Same URL as before:
https://vr.csgrid.org/x3dom/swordtest.html

To compare it to what it looks like in Maya, see this screenshot:
https://vr.csgrid.org/x3dom/maya-screenshot.png

Looks nearly identical to what is displayed in Maya, so I’m pretty happy with the results.

If you check the HTML source of swordtest.html, you’ll see it uses a CommonSurfaceShader.

I’m only exporting Material/CommonSurfaceShader for Maya Phong, PhongE, Blinn, and Lambert shaders. Otherwise the exporter defaults to PhysicalMaterial nodes for all other Maya shaders no matter the X3D encoding (XML, VRML, JSON, or HTML).

I need to do a bit of more code work yet to tighten up my PhysicalMaterial node export, but that doesn’t affect the swordtest.html example using CommonSurfaceShader.

Aaron

From: Bergstrom, Aaron
Sent: Friday, March 14, 2025 9:49 AM
To: Andreas Plesch <and...@gm...>
Cc: x3d...@li...
Subject: RE: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Excellent, I can make that approach work too.

Aaron


From: Andreas Plesch <and...@gm...<mailto:and...@gm...>>
Sent: Friday, March 14, 2025 9:45 AM
To: Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>>
Cc: x3d...@li...<mailto:x3d...@li...>
Subject: Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Hi Aaron,

While CommonSurfaceShader would indeed be the basis for an updated Material node, I do not think that such updating could occur in the near or medium term future.

So you were right the first time and a CommonSurfaceShader option for RawKee would be great to have if possible.

Yes, CommonSurfaceShader would be added to the MFNode Appearance.shaders field.

It is a MFNode field to be able to contain fallbacks, in order of preference: https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/shaders.html#Selecting<https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/shaders.html#Selecting>

I think providing such fallbacks occurs very rarely in practice, and is perhaps not supported by most x3d browsers. I am not aware of an example.

All the best, -Andreas

On Fri, Mar 14, 2025 at 10:30 AM Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>> wrote:
Andreas,

Oops, I misunderstood your email.

I see that you were proposing CommonSurfaceShader as the basis for an updated Material node.

So change what I just said, for now I will add an export option that allows the user to select the export type they want to use:

  *   Material (old style with textures added to Appearance)
  *   Material (new style with textures in the material node)
  *   PhysicalMaterial

Aaron


From: Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>>
Sent: Friday, March 14, 2025 8:59 AM
To: Andreas Plesch <and...@gm...<mailto:and...@gm...>>
Cc: x3d...@li...<mailto:x3d...@li...>
Subject: Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Andreas,

Thank you for this.

Based on your feedback, for at least the older shader types in Maya, I’ll add an export option allowing the user to pick which method they want to use for exporting a shader, either:

  *   Material (old style with textures added to Appearance)
  *   Material (new style with textures in the material node)
  *   PhysicalMaterial
  *   CommonSurfaceShader

It’ll probably take me a few days to re-write that section of the exporter code, but I should have the change completed by the end of the month.

I would assume that “CommonSurfaceShader” would be added to the “shaders” field of the Appearance node. However, I see that “shaders” is an MFNode field. Do you have an example/tutorial of how multiple shaders are used, or is having multiple shaders not common? Why is “shaders” an MFNode field and not an SFNode field?

Aaron

From: Andreas Plesch <and...@gm...<mailto:and...@gm...>>
Sent: Thursday, March 13, 2025 9:16 PM
To: Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>>
Cc: x3d...@li...<mailto:x3d...@li...>
Subject: Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Hi Aaron,

It is probably time to support the X3D v.4 Material features but it is not in the cards in the near term. See

https://doc.x3dom.org/tutorials/lighting/commonSurfaceShaderNode/index.html
and
https://andreasplesch.github.io/x3dom/test/functional/commonSurfaceShader06.html

for an older x3dom equivalent which is very similar but can only use one set of texture coordinates.

This would be also the starting point for supporting the new Material fields if anybody is interested in giving it a try.

Also note that the x3dom PhysicalMaterial is older than X3D v.4 and mostly intended for glTF inlines. So it does not exactly conform to X3D v.4. I think for example it directly accepts binary buffers which can be passed to webgl.

Hope this helps, -Andreas

On Thu, Mar 13, 2025 at 12:04 PM Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>> wrote:
I realize that X3DOM supports the ‘PhysicalMaterial’ node, but are there any plans to update support for the old ‘Material’ node to be X3D 4.0 compliant?

The new RawKee plugin has 4.0 export support for both the ‘PhysicalMaterial’ and ‘Material’ nodes. I’m currently exporting Maya Phong, PhongE, Blinn, and Lambert shadingEngine nodes as 4.0 ‘Material’ nodes. However, X3DOM doesn’t seem to support the 4.0 texture map features for the 4.0 ‘Material’ node.

If there is no intent to have X3DOM to support the newer features of the ‘Material’ node going forward, I will change how I am exporting the Phong, PhongE, Blinn, and Lambert shaders from Maya.

Thanks,

Aaron
_______________________________________________
x3dom-developers mailing list
x3d...@li...<mailto:x3d...@li...>
https://lists.sourceforge.net/lists/listinfo/x3dom-developers


--
Andreas Plesch
Waltham, MA 02453


--
Andreas Plesch
Waltham, MA 02453

Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

[Bergstrom, A. <aar...@un...>]

Excellent, I can make that approach work too.

Aaron


From: Andreas Plesch <and...@gm...>
Sent: Friday, March 14, 2025 9:45 AM
To: Bergstrom, Aaron <aar...@un...>
Cc: x3d...@li...
Subject: Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Hi Aaron,

While CommonSurfaceShader would indeed be the basis for an updated Material node, I do not think that such updating could occur in the near or medium term future.

So you were right the first time and a CommonSurfaceShader option for RawKee would be great to have if possible.

Yes, CommonSurfaceShader would be added to the MFNode Appearance.shaders field.

It is a MFNode field to be able to contain fallbacks, in order of preference: https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/shaders.html#Selecting<https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/shaders.html#Selecting>

I think providing such fallbacks occurs very rarely in practice, and is perhaps not supported by most x3d browsers. I am not aware of an example.

All the best, -Andreas

On Fri, Mar 14, 2025 at 10:30 AM Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>> wrote:
Andreas,

Oops, I misunderstood your email.

I see that you were proposing CommonSurfaceShader as the basis for an updated Material node.

So change what I just said, for now I will add an export option that allows the user to select the export type they want to use:

  *   Material (old style with textures added to Appearance)
  *   Material (new style with textures in the material node)
  *   PhysicalMaterial

Aaron


From: Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>>
Sent: Friday, March 14, 2025 8:59 AM
To: Andreas Plesch <and...@gm...<mailto:and...@gm...>>
Cc: x3d...@li...<mailto:x3d...@li...>
Subject: Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Andreas,

Thank you for this.

Based on your feedback, for at least the older shader types in Maya, I’ll add an export option allowing the user to pick which method they want to use for exporting a shader, either:

  *   Material (old style with textures added to Appearance)
  *   Material (new style with textures in the material node)
  *   PhysicalMaterial
  *   CommonSurfaceShader

It’ll probably take me a few days to re-write that section of the exporter code, but I should have the change completed by the end of the month.

I would assume that “CommonSurfaceShader” would be added to the “shaders” field of the Appearance node. However, I see that “shaders” is an MFNode field. Do you have an example/tutorial of how multiple shaders are used, or is having multiple shaders not common? Why is “shaders” an MFNode field and not an SFNode field?

Aaron

From: Andreas Plesch <and...@gm...<mailto:and...@gm...>>
Sent: Thursday, March 13, 2025 9:16 PM
To: Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>>
Cc: x3d...@li...<mailto:x3d...@li...>
Subject: Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Hi Aaron,

It is probably time to support the X3D v.4 Material features but it is not in the cards in the near term. See

https://doc.x3dom.org/tutorials/lighting/commonSurfaceShaderNode/index.html
and
https://andreasplesch.github.io/x3dom/test/functional/commonSurfaceShader06.html

for an older x3dom equivalent which is very similar but can only use one set of texture coordinates.

This would be also the starting point for supporting the new Material fields if anybody is interested in giving it a try.

Also note that the x3dom PhysicalMaterial is older than X3D v.4 and mostly intended for glTF inlines. So it does not exactly conform to X3D v.4. I think for example it directly accepts binary buffers which can be passed to webgl.

Hope this helps, -Andreas

On Thu, Mar 13, 2025 at 12:04 PM Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>> wrote:
I realize that X3DOM supports the ‘PhysicalMaterial’ node, but are there any plans to update support for the old ‘Material’ node to be X3D 4.0 compliant?

The new RawKee plugin has 4.0 export support for both the ‘PhysicalMaterial’ and ‘Material’ nodes. I’m currently exporting Maya Phong, PhongE, Blinn, and Lambert shadingEngine nodes as 4.0 ‘Material’ nodes. However, X3DOM doesn’t seem to support the 4.0 texture map features for the 4.0 ‘Material’ node.

If there is no intent to have X3DOM to support the newer features of the ‘Material’ node going forward, I will change how I am exporting the Phong, PhongE, Blinn, and Lambert shaders from Maya.

Thanks,

Aaron
_______________________________________________
x3dom-developers mailing list
x3d...@li...<mailto:x3d...@li...>
https://lists.sourceforge.net/lists/listinfo/x3dom-developers


--
Andreas Plesch
Waltham, MA 02453


--
Andreas Plesch
Waltham, MA 02453

Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

[Andreas P. <and...@gm...>]

Hi Aaron,

While CommonSurfaceShader would indeed be the basis for an updated Material
node, I do not think that such updating could occur in the near or medium
term future.

So you were right the first time and a CommonSurfaceShader option for
RawKee would be great to have if possible.

Yes, CommonSurfaceShader would be added to the MFNode Appearance.shaders
field.

It is a MFNode field to be able to contain fallbacks, in order of
preference:
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/shaders.html#Selecting

I think providing such fallbacks occurs very rarely in practice, and is
perhaps not supported by most x3d browsers. I am not aware of an example.

All the best, -Andreas

On Fri, Mar 14, 2025 at 10:30 AM Bergstrom, Aaron <aar...@un...>
wrote:

> Andreas,
>
>
>
> Oops, I misunderstood your email.
>
>
>
> I see that you were proposing CommonSurfaceShader as the basis for an
> updated Material node.
>
>
>
> So change what I just said, for now I will add an export option that
> allows the user to select the export type they want to use:
>
>    - Material (old style with textures added to Appearance)
>    - Material (new style with textures in the material node)
>    - PhysicalMaterial
>
>
>
> Aaron
>
>
>
>
>
> *From:* Bergstrom, Aaron <aar...@un...>
> *Sent:* Friday, March 14, 2025 8:59 AM
> *To:* Andreas Plesch <and...@gm...>
> *Cc:* x3d...@li...
> *Subject:* Re: [x3dom-developers] Maya/RawKee export for X3DOM Material
> node
>
>
>
> Andreas,
>
>
>
> Thank you for this.
>
>
>
> Based on your feedback, for at least the older shader types in Maya, I’ll
> add an export option allowing the user to pick which method they want to
> use for exporting a shader, either:
>
>    - Material (old style with textures added to Appearance)
>    - Material (new style with textures in the material node)
>    - PhysicalMaterial
>    - CommonSurfaceShader
>
>
>
> It’ll probably take me a few days to re-write that section of the exporter
> code, but I should have the change completed by the end of the month.
>
>
>
> I would assume that “CommonSurfaceShader” would be added to the “shaders”
> field of the Appearance node. However, I see that “shaders” is an MFNode
> field. Do you have an example/tutorial of how multiple shaders are used, or
> is having multiple shaders not common? Why is “shaders” an MFNode field and
> not an SFNode field?
>
>
>
> Aaron
>
>
>
> *From:* Andreas Plesch <and...@gm...>
> *Sent:* Thursday, March 13, 2025 9:16 PM
> *To:* Bergstrom, Aaron <aar...@un...>
> *Cc:* x3d...@li...
> *Subject:* Re: [x3dom-developers] Maya/RawKee export for X3DOM Material
> node
>
>
>
> Hi Aaron,
>
>
>
> It is probably time to support the X3D v.4 Material features but it is not
> in the cards in the near term. See
>
>
>
> https://doc.x3dom.org/tutorials/lighting/commonSurfaceShaderNode/index.html
>
>
> and
>
>
> https://andreasplesch.github.io/x3dom/test/functional/commonSurfaceShader06.html
>
>
>
> for an older x3dom equivalent which is very similar but can only use one
> set of texture coordinates.
>
>
>
> This would be also the starting point for supporting the new Material
> fields if anybody is interested in giving it a try.
>
>
>
> Also note that the x3dom PhysicalMaterial is older than X3D v.4 and mostly
> intended for glTF inlines. So it does not exactly conform to X3D v.4. I
> think for example it directly accepts binary buffers which can be passed to
> webgl.
>
>
>
> Hope this helps, -Andreas
>
>
>
> On Thu, Mar 13, 2025 at 12:04 PM Bergstrom, Aaron <aar...@un...>
> wrote:
>
> I realize that X3DOM supports the ‘PhysicalMaterial’ node, but are there
> any plans to update support for the old ‘Material’ node to be X3D 4.0
> compliant?
>
>
>
> The new RawKee plugin has 4.0 export support for both the
> ‘PhysicalMaterial’ and ‘Material’ nodes. I’m currently exporting Maya
> Phong, PhongE, Blinn, and Lambert shadingEngine nodes as 4.0 ‘Material’
> nodes. However, X3DOM doesn’t seem to support the 4.0 texture map features
> for the 4.0 ‘Material’ node.
>
>
>
> If there is no intent to have X3DOM to support the newer features of the
> ‘Material’ node going forward, I will change how I am exporting the Phong,
> PhongE, Blinn, and Lambert shaders from Maya.
>
>
>
> Thanks,
>
>
>
> Aaron
>
> _______________________________________________
> x3dom-developers mailing list
> x3d...@li...
> https://lists.sourceforge.net/lists/listinfo/x3dom-developers
>
>
>
>
> --
>
> Andreas Plesch
> Waltham, MA 02453
>


-- 
Andreas Plesch
Waltham, MA 02453

Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

[Bergstrom, A. <aar...@un...>]

Andreas,

Oops, I misunderstood your email.

I see that you were proposing CommonSurfaceShader as the basis for an updated Material node.

So change what I just said, for now I will add an export option that allows the user to select the export type they want to use:

  *   Material (old style with textures added to Appearance)
  *   Material (new style with textures in the material node)
  *   PhysicalMaterial

Aaron


From: Bergstrom, Aaron <aar...@un...>
Sent: Friday, March 14, 2025 8:59 AM
To: Andreas Plesch <and...@gm...>
Cc: x3d...@li...
Subject: Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Andreas,

Thank you for this.

Based on your feedback, for at least the older shader types in Maya, I’ll add an export option allowing the user to pick which method they want to use for exporting a shader, either:

  *   Material (old style with textures added to Appearance)
  *   Material (new style with textures in the material node)
  *   PhysicalMaterial
  *   CommonSurfaceShader

It’ll probably take me a few days to re-write that section of the exporter code, but I should have the change completed by the end of the month.

I would assume that “CommonSurfaceShader” would be added to the “shaders” field of the Appearance node. However, I see that “shaders” is an MFNode field. Do you have an example/tutorial of how multiple shaders are used, or is having multiple shaders not common? Why is “shaders” an MFNode field and not an SFNode field?

Aaron

From: Andreas Plesch <and...@gm...<mailto:and...@gm...>>
Sent: Thursday, March 13, 2025 9:16 PM
To: Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>>
Cc: x3d...@li...<mailto:x3d...@li...>
Subject: Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Hi Aaron,

It is probably time to support the X3D v.4 Material features but it is not in the cards in the near term. See

https://doc.x3dom.org/tutorials/lighting/commonSurfaceShaderNode/index.html
and
https://andreasplesch.github.io/x3dom/test/functional/commonSurfaceShader06.html

for an older x3dom equivalent which is very similar but can only use one set of texture coordinates.

This would be also the starting point for supporting the new Material fields if anybody is interested in giving it a try.

Also note that the x3dom PhysicalMaterial is older than X3D v.4 and mostly intended for glTF inlines. So it does not exactly conform to X3D v.4. I think for example it directly accepts binary buffers which can be passed to webgl.

Hope this helps, -Andreas

On Thu, Mar 13, 2025 at 12:04 PM Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>> wrote:
I realize that X3DOM supports the ‘PhysicalMaterial’ node, but are there any plans to update support for the old ‘Material’ node to be X3D 4.0 compliant?

The new RawKee plugin has 4.0 export support for both the ‘PhysicalMaterial’ and ‘Material’ nodes. I’m currently exporting Maya Phong, PhongE, Blinn, and Lambert shadingEngine nodes as 4.0 ‘Material’ nodes. However, X3DOM doesn’t seem to support the 4.0 texture map features for the 4.0 ‘Material’ node.

If there is no intent to have X3DOM to support the newer features of the ‘Material’ node going forward, I will change how I am exporting the Phong, PhongE, Blinn, and Lambert shaders from Maya.

Thanks,

Aaron
_______________________________________________
x3dom-developers mailing list
x3d...@li...<mailto:x3d...@li...>
https://lists.sourceforge.net/lists/listinfo/x3dom-developers


--
Andreas Plesch
Waltham, MA 02453

Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

[Bergstrom, A. <aar...@un...>]

Andreas,

Thank you for this.

Based on your feedback, for at least the older shader types in Maya, I’ll add an export option allowing the user to pick which method they want to use for exporting a shader, either:

  *   Material (old style with textures added to Appearance)
  *   Material (new style with textures in the material node)
  *   PhysicalMaterial
  *   CommonSurfaceShader

It’ll probably take me a few days to re-write that section of the exporter code, but I should have the change completed by the end of the month.

I would assume that “CommonSurfaceShader” would be added to the “shaders” field of the Appearance node. However, I see that “shaders” is an MFNode field. Do you have an example/tutorial of how multiple shaders are used, or is having multiple shaders not common? Why is “shaders” an MFNode field and not an SFNode field?

Aaron

From: Andreas Plesch <and...@gm...>
Sent: Thursday, March 13, 2025 9:16 PM
To: Bergstrom, Aaron <aar...@un...>
Cc: x3d...@li...
Subject: Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

Hi Aaron,

It is probably time to support the X3D v.4 Material features but it is not in the cards in the near term. See

https://doc.x3dom.org/tutorials/lighting/commonSurfaceShaderNode/index.html
and
https://andreasplesch.github.io/x3dom/test/functional/commonSurfaceShader06.html

for an older x3dom equivalent which is very similar but can only use one set of texture coordinates.

This would be also the starting point for supporting the new Material fields if anybody is interested in giving it a try.

Also note that the x3dom PhysicalMaterial is older than X3D v.4 and mostly intended for glTF inlines. So it does not exactly conform to X3D v.4. I think for example it directly accepts binary buffers which can be passed to webgl.

Hope this helps, -Andreas

On Thu, Mar 13, 2025 at 12:04 PM Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>> wrote:
I realize that X3DOM supports the ‘PhysicalMaterial’ node, but are there any plans to update support for the old ‘Material’ node to be X3D 4.0 compliant?

The new RawKee plugin has 4.0 export support for both the ‘PhysicalMaterial’ and ‘Material’ nodes. I’m currently exporting Maya Phong, PhongE, Blinn, and Lambert shadingEngine nodes as 4.0 ‘Material’ nodes. However, X3DOM doesn’t seem to support the 4.0 texture map features for the 4.0 ‘Material’ node.

If there is no intent to have X3DOM to support the newer features of the ‘Material’ node going forward, I will change how I am exporting the Phong, PhongE, Blinn, and Lambert shaders from Maya.

Thanks,

Aaron
_______________________________________________
x3dom-developers mailing list
x3d...@li...<mailto:x3d...@li...>
https://lists.sourceforge.net/lists/listinfo/x3dom-developers


--
Andreas Plesch
Waltham, MA 02453

Re: [x3dom-developers] Maya/RawKee export for X3DOM Material node

[Andreas P. <and...@gm...>]

Hi Aaron,

It is probably time to support the X3D v.4 Material features but it is not
in the cards in the near term. See

https://doc.x3dom.org/tutorials/lighting/commonSurfaceShaderNode/index.html
and
https://andreasplesch.github.io/x3dom/test/functional/commonSurfaceShader06.html

for an older x3dom equivalent which is very similar but can only use one
set of texture coordinates.

This would be also the starting point for supporting the new Material
fields if anybody is interested in giving it a try.

Also note that the x3dom PhysicalMaterial is older than X3D v.4 and mostly
intended for glTF inlines. So it does not exactly conform to X3D v.4. I
think for example it directly accepts binary buffers which can be passed to
webgl.

Hope this helps, -Andreas

On Thu, Mar 13, 2025 at 12:04 PM Bergstrom, Aaron <aar...@un...>
wrote:

> I realize that X3DOM supports the ‘PhysicalMaterial’ node, but are there
> any plans to update support for the old ‘Material’ node to be X3D 4.0
> compliant?
>
>
>
> The new RawKee plugin has 4.0 export support for both the
> ‘PhysicalMaterial’ and ‘Material’ nodes. I’m currently exporting Maya
> Phong, PhongE, Blinn, and Lambert shadingEngine nodes as 4.0 ‘Material’
> nodes. However, X3DOM doesn’t seem to support the 4.0 texture map features
> for the 4.0 ‘Material’ node.
>
>
>
> If there is no intent to have X3DOM to support the newer features of the
> ‘Material’ node going forward, I will change how I am exporting the Phong,
> PhongE, Blinn, and Lambert shaders from Maya.
>
>
>
> Thanks,
>
>
>
> Aaron
> _______________________________________________
> x3dom-developers mailing list
> x3d...@li...
> https://lists.sourceforge.net/lists/listinfo/x3dom-developers
>


-- 
Andreas Plesch
Waltham, MA 02453

Re: [x3dom-developers] Texture Mapping Issue with IndexedFaceSet model exported from Maya

[Bergstrom, A. <aar...@un...>]

Andreas,

Yep, that definitely was the issue. I added all the closing tags and ‘swordtest.html’ is working as expected now.
https://vr.csgrid.org/x3dom/swordtest.html

Also, I already made the HTML/XML change in the RawKee plugin as well, and pushed it to the repo.

Thanks for the quick feedback!

Aaron

From: Andreas Plesch <and...@gm...>
Sent: Thursday, March 13, 2025 7:12 AM
To: Bergstrom, Aaron <aar...@un...>
Cc: x3d...@li...
Subject: Re: [x3dom-developers] Texture Mapping Issue with IndexedFaceSet model exported from Maya

Hi Aaron,

HTML is peculiar because it requires unknown elements to have full closing tags:
<ImageTexture></ImageTexture>

This is in contrast to xml.

There is also the xhtml encoding which is xml but is rarely used.

So adding full closing tags to all nodes should fix it.

It would be great if you could add direct html support to the plugin but I do not know if x3d.py has an option to always generate full closing tags.

Let us know how it goes,

-Andreas

On Wed, Mar 12, 2025 at 3:08 AM Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>> wrote:
X3DOM does not appear to be properly mapping textures when the X3D XML markup is embedded as HTML tags in an HTML file.

Any feedback as to why I may be seeing this issue is appreciated. Please see the detailed explanation below.

I’ve been working on exporting X3DOM content from Maya using my updated RawKee X3D export plugin for Maya.
https://github.com/und-dream-lab/rawkee/

Using RawKee, I’ve exported a sword model from Maya as test content. I have created 5 files and placed them on my test server at https://vr.csgrid.org/
Bullet 5 - shows the sword model as it looks like in Maya just before it is exported.
Bullet 1 - is the sword model exported out to HTML and displayed using X3DOM version 1.8.3
Bullet 2 - is the sword model that uses the exact same XML tags found in the HTML file, but written to a standalone swordtest.x3d file.
Bullet 3 - is the ‘swordtest.x3d’ file displayed in a web page via an ‘Inline’ tag using X3DOM version 1.8.3
Bullet 4 - is the ‘swordtest.x3d’ file displayed in a web page using X_ITE.

  1.  https://vr.csgrid.org/x3dom/swordtest.html
  2.  https://vr.csgrid.org/x3dom/swordtest.x3d
  3.  https://vr.csgrid.org/x3dom/swordtest2.html
  4.  https://vr.csgrid.org/x_ite/x_ite.html
  5.  https://vr.csgrid.org/x3dom/maya-screenshot.png

Am I doing something wrong? What would it be?

Thanks,

Aaron




_______________________________________________
x3dom-developers mailing list
x3d...@li...<mailto:x3d...@li...>
https://lists.sourceforge.net/lists/listinfo/x3dom-developers


--
Andreas Plesch
Waltham, MA 02453

Re: [x3dom-developers] Texture Mapping Issue with IndexedFaceSet model exported from Maya

[Bergstrom, A. <aar...@un...>]

Andreas,

Ahh, excellent. I will make those changes.

At the moment, I am only using x3d.py to hold the data that I extract from Maya. Because of some of the issues with export from the version of x3d.py that I am using, I wrote my own companion script that writes to all the different encodings.

I am currently using the same methods in my companion script to export to both HTML and XML. It’s a somewhat trivial change to separate them out and add in closing tags. Now that I know it’s required for HTML, I will most likely have it implemented tomorrow.

Thanks for the info!

Aaron

From: Andreas Plesch <and...@gm...>
Sent: Thursday, March 13, 2025 7:12 AM
To: Bergstrom, Aaron <aar...@un...>
Cc: x3d...@li...
Subject: Re: [x3dom-developers] Texture Mapping Issue with IndexedFaceSet model exported from Maya

Hi Aaron,

HTML is peculiar because it requires unknown elements to have full closing tags:
<ImageTexture></ImageTexture>

This is in contrast to xml.

There is also the xhtml encoding which is xml but is rarely used.

So adding full closing tags to all nodes should fix it.

It would be great if you could add direct html support to the plugin but I do not know if x3d.py has an option to always generate full closing tags.

Let us know how it goes,

-Andreas

On Wed, Mar 12, 2025 at 3:08 AM Bergstrom, Aaron <aar...@un...<mailto:aar...@un...>> wrote:
X3DOM does not appear to be properly mapping textures when the X3D XML markup is embedded as HTML tags in an HTML file.

Any feedback as to why I may be seeing this issue is appreciated. Please see the detailed explanation below.

I’ve been working on exporting X3DOM content from Maya using my updated RawKee X3D export plugin for Maya.
https://github.com/und-dream-lab/rawkee/

Using RawKee, I’ve exported a sword model from Maya as test content. I have created 5 files and placed them on my test server at https://vr.csgrid.org/
Bullet 5 - shows the sword model as it looks like in Maya just before it is exported.
Bullet 1 - is the sword model exported out to HTML and displayed using X3DOM version 1.8.3
Bullet 2 - is the sword model that uses the exact same XML tags found in the HTML file, but written to a standalone swordtest.x3d file.
Bullet 3 - is the ‘swordtest.x3d’ file displayed in a web page via an ‘Inline’ tag using X3DOM version 1.8.3
Bullet 4 - is the ‘swordtest.x3d’ file displayed in a web page using X_ITE.

  1.  https://vr.csgrid.org/x3dom/swordtest.html
  2.  https://vr.csgrid.org/x3dom/swordtest.x3d
  3.  https://vr.csgrid.org/x3dom/swordtest2.html
  4.  https://vr.csgrid.org/x_ite/x_ite.html
  5.  https://vr.csgrid.org/x3dom/maya-screenshot.png

Am I doing something wrong? What would it be?

Thanks,

Aaron




_______________________________________________
x3dom-developers mailing list
x3d...@li...<mailto:x3d...@li...>
https://lists.sourceforge.net/lists/listinfo/x3dom-developers


--
Andreas Plesch
Waltham, MA 02453

[x3dom-developers] Maya/RawKee export for X3DOM Material node

[Bergstrom, A. <aar...@un...>]

I realize that X3DOM supports the 'PhysicalMaterial' node, but are there any plans to update support for the old 'Material' node to be X3D 4.0 compliant?

The new RawKee plugin has 4.0 export support for both the 'PhysicalMaterial' and 'Material' nodes. I'm currently exporting Maya Phong, PhongE, Blinn, and Lambert shadingEngine nodes as 4.0 'Material' nodes. However, X3DOM doesn't seem to support the 4.0 texture map features for the 4.0 'Material' node.

If there is no intent to have X3DOM to support the newer features of the 'Material' node going forward, I will change how I am exporting the Phong, PhongE, Blinn, and Lambert shaders from Maya.

Thanks,

Aaron

Re: [x3dom-developers] Texture Mapping Issue with IndexedFaceSet model exported from Maya

[Andreas P. <and...@gm...>]

Hi Aaron,

HTML is peculiar because it requires unknown elements to have full closing
tags:
<ImageTexture></ImageTexture>

This is in contrast to xml.

There is also the xhtml encoding which is xml but is rarely used.

So adding full closing tags to all nodes should fix it.

It would be great if you could add direct html support to the plugin but I
do not know if x3d.py has an option to always generate full closing tags.

Let us know how it goes,

-Andreas

On Wed, Mar 12, 2025 at 3:08 AM Bergstrom, Aaron <aar...@un...>
wrote:

> X3DOM does not appear to be properly mapping textures when the X3D XML
> markup is embedded as HTML tags in an HTML file.
>
>
>
> Any feedback as to why I may be seeing this issue is appreciated. Please
> see the detailed explanation below.
>
>
>
> I’ve been working on exporting X3DOM content from Maya using my updated
> RawKee X3D export plugin for Maya.
>
> https://github.com/und-dream-lab/rawkee/
>
>
>
> Using RawKee, I’ve exported a sword model from Maya as test content. I
> have created 5 files and placed them on my test server at
> https://vr.csgrid.org/
>
> *Bullet 5* - shows the sword model as it looks like in Maya just before
> it is exported.
>
> *Bullet 1* - is the sword model exported out to HTML and displayed using
> X3DOM version 1.8.3
>
> *Bullet 2* - is the sword model that uses the exact same XML tags found
> in the HTML file, but written to a standalone swordtest.x3d file.
>
> *Bullet 3* - is the ‘swordtest.x3d’ file displayed in a web page via an
> ‘Inline’ tag using X3DOM version 1.8.3
>
> *Bullet 4* - is the ‘swordtest.x3d’ file displayed in a web page using
> X_ITE.
>
>    1. https://vr.csgrid.org/x3dom/swordtest.html
>    2. https://vr.csgrid.org/x3dom/swordtest.x3d
>    3. https://vr.csgrid.org/x3dom/swordtest2.html
>    4. https://vr.csgrid.org/x_ite/x_ite.html
>    5. https://vr.csgrid.org/x3dom/maya-screenshot.png
>
>
>
> Am I doing something wrong? What would it be?
>
>
>
> Thanks,
>
>
>
> Aaron
>
>
>
>
>
>
>
>
> _______________________________________________
> x3dom-developers mailing list
> x3d...@li...
> https://lists.sourceforge.net/lists/listinfo/x3dom-developers
>


-- 
Andreas Plesch
Waltham, MA 02453

[x3dom-developers] Texture Mapping Issue with IndexedFaceSet model exported from Maya

[Bergstrom, A. <aar...@un...>]

X3DOM does not appear to be properly mapping textures when the X3D XML markup is embedded as HTML tags in an HTML file.

Any feedback as to why I may be seeing this issue is appreciated. Please see the detailed explanation below.

I've been working on exporting X3DOM content from Maya using my updated RawKee X3D export plugin for Maya.
https://github.com/und-dream-lab/rawkee/

Using RawKee, I've exported a sword model from Maya as test content. I have created 5 files and placed them on my test server at https://vr.csgrid.org/
Bullet 5 - shows the sword model as it looks like in Maya just before it is exported.
Bullet 1 - is the sword model exported out to HTML and displayed using X3DOM version 1.8.3
Bullet 2 - is the sword model that uses the exact same XML tags found in the HTML file, but written to a standalone swordtest.x3d file.
Bullet 3 - is the 'swordtest.x3d' file displayed in a web page via an 'Inline' tag using X3DOM version 1.8.3
Bullet 4 - is the 'swordtest.x3d' file displayed in a web page using X_ITE.

  1.  https://vr.csgrid.org/x3dom/swordtest.html
  2.  https://vr.csgrid.org/x3dom/swordtest.x3d
  3.  https://vr.csgrid.org/x3dom/swordtest2.html
  4.  https://vr.csgrid.org/x_ite/x_ite.html
  5.  https://vr.csgrid.org/x3dom/maya-screenshot.png

Am I doing something wrong? What would it be?

Thanks,

Aaron

[x3dom-developers] Web3D 2025 Call for Papers - Deadline 1st May 2025

[Web3D A. <ann...@we...>]

Web3D 2025 Conference (https://web3d.siggraph.org/2025/) - Call for Papers, Posters, and Industrial Use Cases

Submission Deadline: May 1, 2025

The Web3D Consortium (https://www.web3d.org/) invites you to share your best work at the Web3D 2025 Conference, taking place from September 8-9, 2025 in the beautiful city of Siena, Italy.

This year's Web3D Conference will be co-located with Digital Heritage 2025 (https://digitalheritage2025.unisi.it/)  (8-13 September), creating a premier international forum that unites 3D Web Technology with multiple heritage domains and conferences.

The 30th International Conference on 3D Web Technology, Web3D 2025, will address a wide range of research, development, and practices related to various 3D application domains, including Digital Cultural Heritage. The theme for this year's conference is "Digital Legacies and Immersive Futures," focusing on the integration of virtual reality, augmented reality, and other immersive technologies into the digital heritage domain. This integration aims to create engaging digital environments for exploration, learning, collaboration, and communication.

As interactive 3D and digital heritage technologies continue to evolve, it is crucial to develop new ways for people to engage, learn, and collaborate. The purpose of the Web3D 2025 Conference is to study and share the principles of the latest advancements in interactive 3D technologies, including those within the Digital Heritage field.

The conference will bring together experts from around the world to discuss the latest research, development, and practices related to these technologies.

We welcome submissions of academic papers, posters, and industrial use cases on awide range of topics (https://web3d.siggraph.org/2025/call-for-papers/#topics) , including (but not limited to) web/mobile 3D content creation, immersive realities, digital cultural heritage, 3D compression, publishing technology, tools, and related studies.

The submission deadline for papers, posters, and industrial use cases is May 1, 2025, at 10:00 PM PDT (GMT-0700).

Accepted work will be published in the Web3D 2025 ACM Conference Proceedings, available in the ACM Digital Library (https://dl.acm.org/) . Works selected for the Best Paper awards will be invited to submit extended versions to the Computers & Graphics journal (https://www.sciencedirect.com/journal/computers-and-graphics) .

Benefits of submitting your work:
* Gain visibility and exposure to an international audience passionate about 3D graphics
* Network and engage with leading minds in your industry
* Drive the conversation and inspire the next generation of creators and innovators
* Unlock new opportunities through published work

For more information, including submission guidelines and important dates, please visit the conference website (https://web3d.siggraph.org/2025/)  or contact the program committee at pro...@we... (mailto::pro...@we...)

We look forward to your contributions and to seeing you at Web3D 2025 in Siena, Italy!


** Ready to make an impact?
------------------------------------------------------------
* CFP (https://web3d.siggraph.org/2025/call-for-papers/)
* Submission Guidelines (https://web3d.siggraph.org/2025/call-for-papers/submission-guidelines/)
* Submit here (https://openreview.net/group?id=DigitalHeritage/2025/Congress_and_Expo#tab-recent-activity)
* Important Dates (https://web3d.siggraph.org/2025/call-for-papers/#important-dates)
*  Questions: pro...@we... (mailto::pro...@we...)
* PDF version of the CFP (https://web3d.siggraph.org/2025/wp-content/uploads/2025/03/Web3D-2025-CFP-6March2025-3.pdf)
* Program and Registration coming soon


** Web3D News and Events  (https://www.web3d.org/news-events)
------------------------------------------------------------
Learn More (https://web3d.siggraph.org/)

============================================================
** Facebook (http://www.facebook.com)
** Twitter (https://twitter.com/Web3Dconsortium)
** Website (https://web3d.siggraph.org/)
Copyright © 2025 Web3D Consortium, All rights reserved.
 You are receiving this email because you opted in via our website.

Our mailing address is:
Web3D Consortium
133 Lorimer St
Salinas, CA 93901-2021
USA
Want to change how you receive these emails?
You can ** update your preferences (https://web3d.us10.list-manage.com/profile?u=0051673b83909ae284624feb2&id=f1ef934431&e=43bd7983eb&c=53ff5cc3e6)
or ** unsubscribe from this list (https://web3d.us10.list-manage.com/unsubscribe?u=0051673b83909ae284624feb2&id=f1ef934431&t=b&e=43bd7983eb&c=53ff5cc3e6)
.
 Email Marketing Powered by Mailchimp
https://login.mailchimp.com/signup/email-referral/?aid=0051673b83909ae284624feb2

[x3dom-developers] Forcing Software rendering?

[Polys, N. <np...@vt...>]

What sorts of browser or network settings would trigger X3DOM to go to software rendering?

in the client browser, webgl is enabled and there is a GPU.



--
Nicholas F. Polys, Ph.D.

Director of Visual Computing
Virginia Tech Research Computing

Affiliate Professor
Virginia Tech Department of Computer Science
https://people.cs.vt.edu/~npolys/ <https://people.cs.vt.edu/~npolys/>

Re: [x3dom-developers] Constant page refresh?

[John C. <yot...@gm...>]

I tried with 1.8.3.  Apparently, it's something to do with Meteor's hot
reloading at this point.

John

On Fri, Jan 17, 2025 at 4:26 PM John Carlson <yot...@gm...> wrote:

> When I use:
>
> https://www.x3dom.org/download/dev/x3dom-full.js
>
> in a script tag, I get constant page refresh, but when I use:
>
> node_modules/x3dom/x3dom.js
>
> There's no issues with refresh.  AFAIK, I am using Meteor's npm.
>
> I'll try with a released version.
>
> Thanks,
>
> John
>