[x3d-public] Request for RenderedTexture
John Carlson
yottzumm at gmail.com
Sun Apr 12 18:58:04 PDT 2026
What I was trying to get at was a RenderedTexture capturing video from
MovieTexture, and the MovieTexture showing a live video feed for example.
I think this is a current capability, possibly. But the Desktop can
already do that. It depends on what level of security is enforced. One
shouldn’t expect more security from an X3D browser than the rest of the
desktop.
Apologies for any miscommunication.
John
On Sun, Apr 12, 2026 at 7:40 PM Don Brutzman <don.brutzman at gmail.com> wrote:
> Thanks for considering this.
>
> Note that, other than simple reference to http/https, the X3D Architecture
> neither defines nor restrict what kinds of url protocols are defined, nor
> what invocation variations of https are permitted. Such support is defined
> in other standards (typically IETF) and providing other support is a
> decision for HTML browsers and X3D browsers.
>
> The url field is [in out] throughout X3D, so redefining a url list at run
> time would have the effect of terminating the previous operation and
> starting a new one.
>
> The current RenderedTexture node prose is defined for images or series of
> images. Whether that becomes a movie file seems like a potential browser
> feature - Castle offers that already for current viewpoint. I think we
> should stick with that scope for now before going further towards any kind
> of "RenderedMovieTexture" capability.
>
> I believe the current draft prose similarly defines precautions for secure
> use, offering and sometimes requiring options supporting multiple
> stakeholders: browsers, scene authors, and end users.
>
> If browser builders are willing to pursue saving of RenderedTexture
> outputs subject to specified X3DUrlOutputObject requirements, then
> producing some test cases will be interesting to see if all this is
> possible safely and securely. It certainly is a new shared capability for
> X3D if we can get it right.
>
> all the best, Don
> --
> X3D Graphics, Maritime Robotics, Distributed Simulation
> Relative Motion Consulting https://RelativeMotion.info
>
>
> On Sun, Apr 12, 2026 at 1:28 PM John Carlson <yottzumm at gmail.com> wrote:
>
>> One might want to consider the implications of streaming from an X3D
>> browser instead of using a local file. Some URLs might not have a file
>> extension, so content type is desired, and content type should probably not
>> be updatable, due to security risks.
>>
>> Also consider that some image formats (extensions) are both image and
>> video.
>>
>> There should definitely be an option to turn off the capture on the part
>> of the user, and that’s not something the system can override.
>>
>> One must also consider if a rendered texture is capturing a movie texture
>> and possible third party impacts of revealing someone else’s video feed in
>> the browser to a X3DUrlOutputObject, even a local file.
>>
>> Thanks,
>>
>> John
>> On Sun, Apr 12, 2026 at 2:01 PM Don Brutzman via x3d-public <
>> x3d-public at web3d.org> wrote:
>>
>>> Thanks again for developmental efforts and discussions. Dick and I
>>> reviewed further last week.
>>>
>>> As previously noted, security precautions are significant for saving
>>> texture/depth images. We haven't really had to consider such issues
>>> before... it seems better to consider a new interface,
>>> *X3DUrlOutputObject*.
>>>
>>> The latest draft spec prose follows. As ever, all consideration and
>>> potential improvements are welcome.
>>>
>>> - X3D Architecture, draft 4.1, clause 18 Texturing component, 18.4.7
>>> RenderedTexture
>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/texturing.html#RenderedTexture>
>>> -
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/texturing.html#RenderedTexture
>>>
>>> Editors note: under discussion.
>>> 18.4.7 RenderedTexture
>>>
>>> RenderedTexture : X3DTexture2DNode, X3DUrlOutputObject {
>>> SFNode [in,out] children NULL [X3DBackgroundNode,X3DFogObject,X3DViewpointNode, X3DChildNode]
>>> SFBool [in,out] depthMap FALSE
>>> SFString [in,out] description ""
>>> MFInt32 [in,out] dimensions [128,128,4,1,1] [0,infinity)
>>> SFBool [in,out] enabled TRUE
>>> SFBool [out] isActive
>>> SFNode [in,out] metadata NULL [X3DMetadataObject]
>>> SFBool [] repeatS TRUE
>>> SFBool [] repeatT TRUE
>>> SFBool [in,out] replaceImage TRUE
>>> SFNode [] textureProperties NULL [TextureProperties]
>>> SFString [in,out] update "NONE" ["NONE"|"NEXT_FRAME_ONLY"|"ALWAYS"]
>>> MFString [in,out] url [] [URI]
>>> }
>>>
>>> RenderedTexture is a texture node that renders the view from a local
>>> viewpoint or separate scene into an offscreen buffer, producing an image
>>> that can be applied to geometry in real time. Such images can also be saved
>>> to a local file or stream. RenderedTexture enables effects such as dynamic
>>> reflections, live video screens, shadows, or portals by continuously
>>> updating the texture based on the rendered content.
>>>
>>> The *children* field can include a single specific viewpoint from which
>>> to render to texture. If no X3DViewpointNode is defined, then the currently
>>> bound viewpoint in the scene is used. The *children* field can also
>>> explicitly define a single optional background node, single optional fog
>>> node, and a single X3DChildNode scene subgraph to be used when creating the
>>> render image.
>>>
>>> The *depthMap* field indicates that a generated texture contains a
>>> depth buffer for the image, instead of the color buffer.
>>>
>>> The *dimensions* field sets values for width, height, color components
>>> [1..4] and number of multiple render targets (MRT).
>>>
>>> The *enabled* field enables and disables node operation.
>>>
>>> The *replaceImage* field defines whether only a single updated image
>>> file or multiple image files can be saved.
>>>
>>> The *update* field controls regeneration of the texture, where "NONE" means
>>> no updates after initialization, "NEXT_FRAME_ONLY" means a single
>>> update, and "ALWAYS" means continuous updates. See 34.4.2
>>> GeneratedCubeMapTexture
>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/environmentalTexturing.html#GeneratedCubeMapTexture> for
>>> details.
>>>
>>> The *url* field optionally defines a relative address to a file name
>>> that can be used for storing one or more rendered textures. See 18.4.1
>>> ImageTexture
>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/texturing.html#ImageTexture> for
>>> supported file formats.
>>>
>>> Security considerations and requirements in 9.3.3 *X3DUrlOutputObject*
>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#X3DUrlOutputObject> are
>>> essential and must be observed whenever data output might occur.
>>>
>>> Editors note: additional considerations follow, overall status
>>> maintained in Mantis 1529 <https://mantis.web3d.org/view.php?id=1529>.
>>>
>>> 1. Security precautions: saving output information to a file is a
>>> new capability for X3D. Need to require user permission for saving images
>>> (if allowed by local file system) due to potential loss of privacy.
>>> 2. Rather than overloading or subsetting X3DUrlObject
>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#X3DUrlObject>,
>>> security precautions for privacy concepts, file storage etc. are handled in
>>> new interface X3DUrlOutputObject
>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#X3DUrlOutputObject>
>>> .
>>> 3. Added *enabled* and *replaceImage* fields for greater control of
>>> functionality both by authors and by users at run time.
>>> 4. Likely need an inputOnly SFBool triggering mechanism for a single
>>> image, perhaps *setRenderNextFrame* or by setting enabled TRUE.
>>> 5. What is the meaning of multiple render targets (MRT)?
>>> 6. This node matches the interface for X3DSensorNode. If detecting
>>> whether writing a file counts as sensing, should we add that?
>>> 7. Likely future capability: connecting url to an output video
>>> stream.
>>>
>>> and a first draft for
>>>
>>> - X3D Architecture, draft 4.1, clause 9 Networking component, 9.3.3
>>> *X3DUrlOutputObject*
>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#X3DUrlOutputObject>
>>> -
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/networking.html#X3DUrlOutputObject
>>>
>>> 9.3.3 *X3DUrlOutputObject*
>>>
>>> X3DUrlOutputObject {
>>> SFString [in,out] description ""
>>> SFBool [in,out] enabled TRUE
>>> SFBool [out] isActive
>>> MFString [in,out] url [] [URI]
>>> }
>>>
>>> This abstract interface is inherited by all nodes that publish data on
>>> the local file system or to the World Wide Web, such as RenderedTexture
>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/texturing.html#RenderedTexture>
>>> .
>>>
>>> The *description* field is useful for authors to communicate functional
>>> intent of the data output process. Mechanisms for displaying such
>>> description hints are intentionally not specified and may vary among X3D
>>> browsers.
>>>
>>> The *enabled* field either enables or disables data output processing
>>> by the node.
>>>
>>> The *isActive* field provides a TRUE event when node data output
>>> becomes active, and a FALSE event when node data output is stopped.
>>>
>>> Security precautions are significant since url data output raises
>>> privacy considerations that include possible observation of user behaviour,
>>> revealing restricted-access scene observations, and the potential for
>>> unintended information disclosure.
>>>
>>> Browsers must provide one or more configuration mechanisms to ensure
>>>
>>> 1. General permissions are provided for a browser to save data,
>>> 2. Specific permissions are granted by a user to save data in the
>>> current session, and
>>> 3. Ensuring permissions are granted before overwriting prior saved
>>> data.
>>>
>>> NOTE It is considered good security practice for X3D browsers to ensure
>>> that an indication is provided when data output is occurring.
>>> Have fun with X3D rendering and Web extensibility! 😁
>>>
>>> all the best, Don
>>> --
>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>> Relative Motion Consulting https://RelativeMotion.info
>>>
>>>
>>> On Sun, Mar 22, 2026 at 10:11 AM Don Brutzman <don.brutzman at gmail.com>
>>> wrote:
>>>
>>>> *Wow! *Thanks for this interesting proposal Holger (and Michalis, and
>>>> X3DOM team). This is an excellent and interesting prospect for X3D 4.1.
>>>>
>>>> - X3D Architecture 4.1 draft — ISO/IEC 19775-1:202x — X3D
>>>> Architecture index page
>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/Architecture.html>
>>>> -
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/Architecture.html
>>>>
>>>> with list of current v4.1 draft nodes at
>>>>
>>>> - X3D Architecture draft 4.1, Node, abstract node type, and
>>>> abstract interface index
>>>> -
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/nodeIndex.html
>>>> - New nodes in X3D 4.1 draft: EnvironmentLight
>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/nodeIndex.html#EnvironmentLight>
>>>> , FontLibrary
>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/nodeIndex.html#FontLibrary>
>>>> , HAnimPose
>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/nodeIndex.html#HAnimPose>
>>>> , InlineGeometry
>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/nodeIndex.html#InlineGeometry>
>>>> , Tangent
>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/nodeIndex.html#Tangent>
>>>> - also at X3D Tooltips in English version 4.0 (with X3D version
>>>> 4.1 draft) <https://www.web3d.org/x3d/tooltips/X3dTooltips.html>
>>>> - https://www.web3d.org/x3d/tooltips/X3dTooltips.html
>>>>
>>>> *Looking back:* perhaps someone knows if any Web3D Conference papers
>>>> were written on this topic? I searched the ACM Digital Library but was not
>>>> able to narrow the query well enough.
>>>>
>>>> - WEB3D Conference - Home <https://dl.acm.org/conference/web3d>
>>>> - https://dl.acm.org/conference/web3d
>>>>
>>>> *Looking ahead: *wondering if we might add an inputOnly field to
>>>> trigger saving the rendered image to a file, along with a local relative
>>>> url for saving that file? Having such functionality might be a powerful
>>>> way for people to use X3D models as an authoring tool. The specification
>>>> would necessarily need to add some security precautions for implementations
>>>> that will keep end users in charge of permitting such a capability.
>>>>
>>>> Have fun with X3D! 😁 👉 📷
>>>>
>>>> all the best, Don
>>>> --
>>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>>> Relative Motion Consulting https://RelativeMotion.info
>>>>
>>>>
>>>> On Sun, Mar 22, 2026 at 2:44 AM Holger Seelig via x3d-public <
>>>> x3d-public at web3d.org> wrote:
>>>>
>>>>> The latest version of X_ITE now includes the new RenderedTexture node.
>>>>> This node is very close to Castle's and X3DOM's RenderedTexture. Therefore,
>>>>> it makes sense to standardize this node and possibly include it in the new
>>>>> X3D 4.1 standard.
>>>>>
>>>>> Description (from Castle)
>>>>> RenderedTexture is a texture rendered from a specified viewpoint in
>>>>> the 3D scene. This can be used for a wide range of graphic effects, the
>>>>> most straightforward use is to make something like a "security camera" or a
>>>>> "portal", through which a player can peek what happens at a other place in
>>>>> 3D world, or to make a mirror.
>>>>>
>>>>> Documentation for the node in the respective browsers
>>>>> X_ITE:
>>>>> https://create3000.github.io/x_ite/components/texturing/renderedtexture/
>>>>> Castle:
>>>>> https://castle-engine.io/x3d_implementation_texturing_extensions.php#section_ext_rendered_texture
>>>>> X3D’OM: https://doc.x3dom.org/author/Texturing/RenderedTexture.html
>>>>>
>>>>> Example file in X_ITE Playground
>>>>>
>>>>> https://create3000.github.io/x_ite/playground/?url=https://create3000.github.io/media/examples/Texturing/RenderedTexture/RenderedTexture.x3d
>>>>>
>>>>> Best regards,
>>>>> Holger
>>>>>
>>>>> —
>>>>> Holger Seelig
>>>>> holger.seelig at yahoo.de
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> x3d-public mailing list
>>>>> x3d-public at web3d.org
>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>>>
>>>> _______________________________________________
>>> x3d-public mailing list
>>> 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/20260412/76c49e49/attachment-0001.html>
More information about the x3d-public
mailing list