[x3d-public] Upgraded AllenDutton.x3d, fully comparable in X_ITE in X3DOM

[John Carlson]

Works great, thanks for the workaround.  I will try to test in other
browsers.

John
On Thu, Jul 17, 2025 at 4:40 AM Michalis Kamburelis <
michalis.kambi at gmail.com> wrote:

> > I'm not sure why mouse clicking on text didn't work in Castle Model
> Viewer, there aren't any Script tags.  Weird, surely enough.  Do you have
> feedback, Michalis?
>
> Thanks for the report. Hm, investigating, it's because the
> TouchSensors (like <TouchSensor DEF='Stand_Touch'...>) are inside a
> collision node that disables collisions:
>
>     <Collision DEF='HUD' enabled='false'>
>
> ( Link to exact line in GitHub soruces:
>
> https://github.com/coderextreme/X3DJSONLD/blob/841aff1527a4ade2dbafe302b43e37bc0a59e4ac/src/main/data/AllenDutton.x3d#L319
> )
>
> Changing this to say
>
>     <Collision DEF='HUD' enabled='true'>
>
> makes it work in Castle Model Viewer, i.e. the clicks on Stand / Run /
> Walk/ Jump text are then detected and fire the appropriate animations
> correctly.
>
> This is a bug in our Castle Model Viewer, to be clear:
>
> - Spec says that "Collision.enabled" should affect collisions with
> avatar (i.e. camera), but in Castle Game Engine / Castle Model Viewer
> we actually use it to mean more (if something has disabled collisions,
> we don't build spatial structure for it, and so even mouse clicks on
> it will not be detected).
>
> - And, as John reports, every other X3D browser does it differently.
>
> - So, it's our bug, though admittedly it's not something I see an easy fix
> for.
>
>      Internal background and reasons: I'm reluctant to complicate our
> collision handling to account for this, as we already are in a
> transition from "own octrees" -> physics engine (Kraft, and future
> PhysX), some gory details on
> https://castle-engine.io/roadmap#_more_physics . So we already have
> somewhat complicated code around this, and cleaning it up is on the
> roadmap but it will take some time (like, hopefully I can do this by
> the end of 2025; it's not something I can fix e.g. right this week :)
> ). So, hopefully this should be fixed in the future, but not
> immediately.
>
> Hm, I'm sorry, I don't have a good answer to this now. It's our bug,
> but I don't think I can solve it easily. The easiest workaround for
> now is to toggle this "Collision.enabled" to true, if you don't really
> care if camera collides with it or not.
>
> Regards,
> Michalis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250718/38d114a2/attachment.html>