[x3d-public] X3DOM dev url changed, HTML invocation

Tue Jul 15 19:48:02 PDT 2025

>    https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/Animation/RotationCalculatorExampleX3dom.xhtml

The offsets in rotation look like more than just parallax.
Thanks,
Joe

-----Original Message-----
From: Extensible 3D (X3D) Graphics public discussion <x3d-public at web3d.org>
Sent: Jul 15, 2025 7:12 PM
To: Extensible 3D (X3D) Graphics public discussion <x3d-public at web3d.org>
Cc: John Carlson <yottzumm at gmail.com>, Andreas Plesch <andreasplesch at gmail.com>
Subject: Re: [x3d-public] X3DOM dev url changed, HTML invocation

For https, you can run one of these two commands, then configure in your web server.   # interactiveopenssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 3650 -nodes# non-interactive, 10 years expiration in git for windows (git bash), localhost openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 3650 -nodes -subj '//CN=localhost' 

This is what I use for node.js.  I don’t check in the keys.

I believe Let’s Encrypt is still available for non-localhost.
On Tue, Jul 15, 2025 at 3:44 PM Andreas Plesch via x3d-public <x3d-public at web3d.org (mailto:x3d-public at web3d.org)> wrote:
Hi Don,

The images and the relative url are completely legal. The problem is the file:// protocol which is not compatible with CORS in general. The simplest solution is to just run a small httpd server (node, python, java:  ) and use https://localhost (https://docs.oracle.com/en/java/javase/21/docs/specs/man/jwebserver.html) . There then is no CORS setup needed. This is actually development which is closer to deployment because then both use a http server.

x3dom can catch the exception but cannot make it ok for the web browser to load the image file anyway. Unfortunately, it is the web browser which may be seen as overzealous.

Apparently, chrome has a flag to disable CORS checking (not tested):

https://medium.com/@beligh.hamdi/run-chrome-browser-without-cors-872747142c61
https://blog.christopherhoelter.com/disable-cors-checks-chrome

Similarly, firefox has a config option which persists (tested, worked for me):

https://www.devdude.com/disable-cors/

Hope this helps, -Andreas

Message: 1
Date: Tue, 15 Jul 2025 11:00:29 -0700
From: Don Brutzman <don.brutzman at gmail.com (mailto:don.brutzman at gmail.com)>
To: "Extensible 3D (X3D) Graphics public discussion"
        <x3d-public at web3d.org (mailto:x3d-public at web3d.org)>
Cc: "vmarchetti at kshell.com (mailto:vmarchetti at kshell.com)" <vmarchetti at kshell.com (mailto:vmarchetti at kshell.com)>,
        x3dom-developers at lists.sourceforge.net (mailto:x3dom-developers at lists.sourceforge.net)
Subject: Re: [x3d-public] X3DOM dev url changed, HTML invocation
        questions
Message-ID:
        <CABx5f7eezsn1LURQft==ECQ85OZ3hmHqLSrWb7YNh6_VhPy=9Q at mail.gmail.com (mailto:9Q at mail.gmail.com)>
Content-Type: text/plain; charset="utf-8"

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-public at web3d.org (mailto:x3d-public at web3d.org)> 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-public at web3d.org (mailto:x3d-public at web3d.org)> 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 <andreasplesch at gmail.com (mailto:andreasplesch at gmail.com)>
> wrote:
>
>> Answers below.
>>
>> On Sun, Jul 13, 2025 at 2:21?PM Don Brutzman <don.brutzman at gmail.com (mailto:don.brutzman at gmail.com)>
>> 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 (http://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

-- 
Andreas Plesch
Waltham, MA 02453

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org (mailto:x3d-public at web3d.org)
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250716/f6e6a98e/attachment.html>