Menu
▾
▴
x3dom-developers — Where the developers of X3DOM itself discuss new features.
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(3) |
Jun
(4) |
Jul
|
Aug
(9) |
Sep
(2) |
Oct
|
Nov
(2) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
(3) |
Feb
(3) |
Mar
(1) |
Apr
|
May
(1) |
Jun
(3) |
Jul
(7) |
Aug
(18) |
Sep
(7) |
Oct
(6) |
Nov
(19) |
Dec
(10) |
| 2013 |
Jan
(6) |
Feb
(30) |
Mar
(12) |
Apr
(26) |
May
(32) |
Jun
(29) |
Jul
(2) |
Aug
(11) |
Sep
(12) |
Oct
(30) |
Nov
(13) |
Dec
(31) |
| 2014 |
Jan
(28) |
Feb
(16) |
Mar
(24) |
Apr
(29) |
May
(25) |
Jun
(28) |
Jul
(52) |
Aug
(23) |
Sep
(8) |
Oct
(80) |
Nov
(26) |
Dec
(62) |
| 2015 |
Jan
(58) |
Feb
(127) |
Mar
(14) |
Apr
(10) |
May
(3) |
Jun
(6) |
Jul
(7) |
Aug
(29) |
Sep
(6) |
Oct
(9) |
Nov
(30) |
Dec
(17) |
| 2016 |
Jan
(41) |
Feb
(16) |
Mar
(19) |
Apr
(7) |
May
(7) |
Jun
(34) |
Jul
(19) |
Aug
(13) |
Sep
(8) |
Oct
(11) |
Nov
(1) |
Dec
(4) |
| 2017 |
Jan
(2) |
Feb
(8) |
Mar
(8) |
Apr
(4) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(7) |
Sep
(20) |
Oct
(7) |
Nov
(5) |
Dec
(1) |
| 2018 |
Jan
|
Feb
(3) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(16) |
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
(3) |
Mar
(2) |
Apr
|
May
(6) |
Jun
|
Jul
(9) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(17) |
Dec
(9) |
| 2021 |
Jan
(9) |
Feb
|
Mar
|
Apr
(3) |
May
(13) |
Jun
(13) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
(12) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(5) |
Jul
|
Aug
(6) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(3) |
Jun
(2) |
Jul
(4) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2025 |
Jan
(29) |
Feb
(1) |
Mar
(17) |
Apr
(2) |
May
(1) |
Jun
(1) |
Jul
(2) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: John C. <yot...@gm...> - 2025-08-30 03:29:44
|
You can also try Andreas’ X3DOM distribution, here: https://andreasplesch.github.io/x3dom/dist/ At least I think that’s it! Good Luck! Ultimately, we have to pull up our sleeves. If you ever get interested in Multi-user X_ITE and maybe Sunrize (I haven’t tried Sunrize yet), let’s do it! Or just try for an Unity or Unreal X3D plugin! But surely Castle Game Engine is better than anything C++? John On Fri, Aug 29, 2025 at 10:19 PM John Carlson <yot...@gm...> wrote: > This is probably a question for Andreas Plesch. I know glTF is at least > partially supported. > > > Also see that I am cc’ing the X3DOM users mailing list. There’s a > developer list too. I guess they are still on sourceforge. > > Heres Andreas’ GitHub branch: > > https://github.com/andreasplesch/x3dom > > You can get to x3dom/x3dom from there. > > If you set the right x3d element attributes, you can see unimplemented > node, I think MultiTextureTransform.js would fit here? > https://github.com/andreasplesch/x3dom/tree/master/src/nodes/Texturing > > Maybe one of other .js files implements it? Download source and do a > folder search? > > UTSL! > > John > > On Fri, Aug 29, 2025 at 9:49 PM Bergstrom, Aaron via X3D-Ecosystem < > x3d...@we...> wrote: > >> How does X3DOM support MultiTextureTransform nodes? >> >> -- >> X3D-Ecosystem mailing list >> X3D...@we... >> http://web3d.org/mailman/listinfo/x3d-ecosystem_web3d.org >> > |
|
From: John C. <yot...@gm...> - 2025-08-30 03:20:09
|
This is probably a question for Andreas Plesch. I know glTF is at least partially supported. Also see that I am cc’ing the X3DOM users mailing list. There’s a developer list too. I guess they are still on sourceforge. Heres Andreas’ GitHub branch: https://github.com/andreasplesch/x3dom You can get to x3dom/x3dom from there. If you set the right x3d element attributes, you can see unimplemented node, I think MultiTextureTransform.js would fit here? https://github.com/andreasplesch/x3dom/tree/master/src/nodes/Texturing Maybe one of other .js files implements it? Download source and do a folder search? UTSL! John On Fri, Aug 29, 2025 at 9:49 PM Bergstrom, Aaron via X3D-Ecosystem < x3d...@we...> wrote: > How does X3DOM support MultiTextureTransform nodes? > > -- > X3D-Ecosystem mailing list > X3D...@we... > http://web3d.org/mailman/listinfo/x3d-ecosystem_web3d.org > |
|
From: Web3D C. <ann...@we...> - 2025-08-10 00:26:05
|
** Celebrating 30 Years of Web3D: Pioneering Innovation and Collaboration in the New 3D Digital Frontier ------------------------------------------------------------ Join the Web3D Consortium (https://www.web3d.org) at SIGGRAPH 2025 (https://s2025.siggraph.org/) in Vancouver, Canada. On Tuesday August 12, Web3D will host Web3D Synergies BOF (https://s2025.conference-schedule.org/presentation/?id=bof_172&sess=sess500) from 4:00PM- 5:30 PM PDT, East Building Room 8, Vancouver Convention Center. This Birds of a Feather session will focus on recent alliances and technological advancements in the field of 3D graphics and virtual environments. This interactive gathering brings together industry leaders, researchers, and enthusiasts to discuss collaborative efforts and innovative solutions that are shaping the future of web-based 3D content. Attendees can expect engaging presentations and networking opportunities, highlighting the latest trends in interoperability, AI, real-time rendering, and immersive experiences. Together, participants will explore how these developments are enhancing user engagement and fostering a more interconnected digital X3D ecosystem. Discussion Topics: Partnerships and Alliances, Web3D Ecosystem, Paths to Interoperability and Industry support, and Member Use cases. Presenters: Anita Havele, Johannes Behr, Aaron Bergstrom, Mike McCann and Casey Gomez Our members will also be presenting at: Cartographic Visualization (Carto) BOF (https://s2025.conference-schedule.org/presentation/?id=bof_101&sess=sess216) Highlighting the future of digital mapping. Monday, August 11, 12:00 - 1:30 PM PDT, East Building Room 15 Take this opportunity to learn from the best in the industry and engage with a passionate community of like-minded enthusiasts. Let's come together to advance the exciting world of 3D on the Web! If you would like more information about Web3D Standards and Use Cases, Please visit us at Web3D.org (https://web3d.org/) Web3D News and Events (https://www.web3d.org/news-events) See you in Vancouver! Learn More (https://www.web3d.org/event/web3d-siggraph-2023) ============================================================ ** 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=7149c3898b) or ** unsubscribe from this list (https://web3d.us10.list-manage.com/unsubscribe?u=0051673b83909ae284624feb2&id=f1ef934431&t=b&e=43bd7983eb&c=7149c3898b) . Email Marketing Powered by Mailchimp https://login.mailchimp.com/signup/email-referral/?aid=0051673b83909ae284624feb2 |
|
From: John C. <yot...@gm...> - 2025-07-15 18:19:38
|
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 > |
|
From: John C. <yot...@gm...> - 2025-07-15 18:09:36
|
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 > |
|
From: Web3D C. <ann...@we...> - 2025-06-25 03:10:28
|
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 |
|
From: Web3D A. <ann...@we...> - 2025-05-13 16:03:05
|
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 |
|
From: Web3D A. <ann...@we...> - 2025-04-28 18:45:32
|
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 |
|
From: Web3D A. <ann...@we...> - 2025-04-07 03:19:48
|
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 |
|
From: Andreas P. <and...@gm...> - 2025-03-20 03:23:00
|
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 |
|
From: Bergstrom, A. <aar...@un...> - 2025-03-19 06:02:59
|
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 |
|
From: Andreas P. <and...@gm...> - 2025-03-18 04:19:48
|
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 |
|
From: Andreas P. <and...@gm...> - 2025-03-17 18:35:00
|
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 |
|
From: Bergstrom, A. <aar...@un...> - 2025-03-17 17:16:23
|
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 |
|
From: Bergstrom, A. <aar...@un...> - 2025-03-15 21:25:42
|
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 |
|
From: Bergstrom, A. <aar...@un...> - 2025-03-14 14:49:12
|
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 |
|
From: Andreas P. <and...@gm...> - 2025-03-14 14:46:01
|
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 |
|
From: Bergstrom, A. <aar...@un...> - 2025-03-14 14:30:41
|
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 |
|
From: Bergstrom, A. <aar...@un...> - 2025-03-14 13:59:39
|
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 |
|
From: Andreas P. <and...@gm...> - 2025-03-14 02:16:35
|
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 |
|
From: Bergstrom, A. <aar...@un...> - 2025-03-13 17:30:05
|
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 |
|
From: Bergstrom, A. <aar...@un...> - 2025-03-13 16:10:14
|
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 |
|
From: Bergstrom, A. <aar...@un...> - 2025-03-13 16:04:22
|
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 |
|
From: Andreas P. <and...@gm...> - 2025-03-13 12:12:45
|
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 |
|
From: Bergstrom, A. <aar...@un...> - 2025-03-12 07:08:13
|
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 |
13 messages has been excluded from this view by a project administrator.
