[X3D-Ecosystem] [x3d-public] claude code example: producing a simple X3D scene

[Don Brutzman]

Thanks Michalis for reminder about X3DLightNode intensity, makes excellent
sense.

I checked, there is no upper limit on intensity in X3D 4.0 or 4.1 draft XML
Schema.  The validation error for these examples occurred because the
scenes use X3D version 3.3.

So for the touched-up models, there is a choice to be made:
a. keep PointLight intensity at 1.5 and X3D version at 3.3 in the
LLM-generated scenes, propagating a validation error (that is possibly
beyond the capability of an X3D browser only supporting version 3.3 and
potentially leading to a run-time load error).
b. removing <xs:maxInclusive value="1"/> limit on lighting nodes in X3D 3.3
schema, introducing divergence from X3D 3.3 specification (shudder).
c, restore original PointLight intensity to 1.5 and changing X3D version to
4.0 in the LLM-generated scenes (similar to already changing
profile='Immersive' to eliminate numerous component statements).

Following the precept "do the right thing" it seems like option C is
clearly the right choice, especially for encouraging correct long-term
generation of content.  That encourages best practice to match chosen model
values. So... this change has been applied and published.

I will add a diagnostic rule to X3D Schematron that reports X3D 4.0 is
needed whenever scenes at a lower X3D version use a lighting intensity
greater than 1.0.  Meanwhile have added a warning in X3D Tooltips for each
of the lighting nodes.

   - X3D Tooltips, PointLight intensity
   - https://www.web3d.org/x3d/content/X3dTooltips.html#PointLight.intensity
   - *Warning:* values greater than 1.0 require X3D version='4.0' or
   greater.

Thanks for suggesting "Using AI when contributing to Castle Game Engine" as
a precaution, I had just added that earlier this morning.  (May I suggest
linking your other excellent post somewhere in there as well.)

The LargeLanguageModels chapter summary also now includes a link to an
annotated log of the original session, plus a link to X3D AI working group
charter.

   - X3D Example Archives: X3D4AM, X3D for Advanced Modeling, Large
   Language Models
   -
   https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/LargeLanguageModels/index.html
   - session chat log
   <https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/LargeLanguageModels/ClaudeCodeExampleChatLog.pdf>
    at
   https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/LargeLanguageModels/ClaudeCodeExampleChatLog.pdf
   - Using AI when contributing to Castle Game Engine
   <https://castle-engine.io/ai>
   - Web3D Consortium *AI with X3D* Working Group
   <https://www.web3d.org/working-groups/ai-x3d>

New suggestion: since our X3D Example Archives are a useful public resource
that may well be getting used by LLM training algorithms, we should be
careful to enable such user agents to avoid recursing on other
LLM-generated models.  Towards that end, have added the following warning
to these three models.
 12
<https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/LargeLanguageModels/ClaudeCodeSimpleModel.html#12>
            <meta name='* warning *' content='* original model produced by
LLM, careful review and precautions are warranted *'/>
I do not expect we will have many LLM-generated examples in the archives,
but a small number that illustrate how to get things done can be helpful
for modelers.  Reading yesterday's annotated session chat log
<https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/LargeLanguageModels/ClaudeCodeExampleChatLog.pdf>
tells
a story.

Additional thoughts welcome.  Thanks again for all careful scrutiny.

all the best, Don
-- 
X3D Graphics, Maritime Robotics, Distributed Simulation
Relative Motion Consulting  https://RelativeMotion.info


On Sat, Feb 28, 2026 at 8:22 AM Michalis Kamburelis <
michalis at castle-engine.io> wrote:

> > given X3D4 close support for glTF physically based rendering (PBR), are
> upper limits of 1.0 for some rendering fields overly strict, e.g.
> PointLight intensity?
>
> We had this talk already around X3D 4.0 :)
>
> There are no limits on intensity values in X3D >= 4.0.
> "PointLight.intensity" is unbounded. It is "SFFloat [in,out] intensity 1
> [0,∞)" (in
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/lighting.html#PointLight
> ) . Same goes for other light sources.
>
> Reasons:
>
> - ( The change is not really strictly related to glTF (though aligning
> with glTF and looking at their "punctual lights" extension prose helped us
> uncover this issue). )
>
> - In reality, physical brightness of light is unbounded. This is a
> "theoretical argument", i.e. "if our stuff approximates reality, then it
> should be unbounded just like in reality".
>
> - One practical argument is that the limit of intensity to [0,1] in X3D
> 3.x and VRML never achieved any practical gain. E.g. it _did not_ force the
> resulting lighting calculation to fit in [0,1] anyway, browsers had to cut
> the resulting colors anyway if things are too bright (e.g. lit by multiple
> lights), even when intensity of a single light was guaranteed <= 1.
>
> - And having "intensity" unlimited opens the door for things like HDR.
> Basically, let renderers decide for themselves how to handle very bright
> scenes. Maybe one renderer wants to "cut off" colors above (1,1,1), but
> maybe another renderer calculates them to floating-point buffer and does
> post-processing tricks to display bright colors (just like human eye does
> adaptation).
>
> If we have a tool, xsd still claiming there's a limit -- then it was not
> updated for X3D 4.0 :)
>
> P.S. As for AI usage, I recommend also my docs at
> https://castle-engine.io/ai and recent thoughts on
> https://castle-engine.io/wp/2026/02/23/ai-usage-guidelines-and-thoughts-updated-and-test-of-vibe-coding-with-castle-game-engine/
> . Basically, as you say: use but be careful.
>
> Regards,
> Michalis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-ecosystem_web3d.org/attachments/20260228/87db1037/attachment-0001.html>