[x3d-public] Request for RenderedTexture

Don Brutzman don.brutzman at gmail.com
Sun Apr 12 12:00:16 PDT 2026 

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20260412/449a6950/attachment-0001.html>

More information about the x3d-public mailing list