Crossposting feature request. Declaratively modifying routes about castle-engine HOT 3 CLOSED

Addressing some things you wrote here, and on Discord, and in create3000/sunrize#1 :

1. We have documentation how to build X3D graph (with nodes and fields and routes) using CGE Pascal API. Quoting from Discord:

See https://castle-engine.io/viewport_and_scenes_from_code , https://castle-engine.io/vrml_x3d.php for docs and more links how to build an X3D graph in Pascal code using CGE. This includes creating nodes, setting fields, seting up ROUTEs.

For ROUTEs in specific, see e.g. example on https://castle-engine.io/x3d_implementation_interpolation.php , section "1.2. Building an animation in Object Pascal code", it shows you to use AddRoute method.

2. We don't plan to add manipulation of nodes or routes to CastleScript. This is beyond what we want to do with CastleScript, see https://castle-engine.io/castle_script.php . We don't want to extend CastleScript for this purpose.

Eventually we may support EcmaScript in CGE in view3dscene, at which point we will want to expose standard SAI for X3D authors. And then we will follow whatever the X3D standard says about it. But EcmaScript is admittedly not a priority for now, as almost all CGE users do manipulation of models from "outside" (like from Pascal) not from inside (like in X3D Script).

3. Sorry, I don't see a reason to join create3000/sunrize#1 . It's not clear what you want there. If there's a missing feature in X3D SAI for routes (but I don't know if there is), it's probably best to talk about it on x3d-public.

from castle-engine.

AD 3 - I see you already talked about it on x3d-public, in thread "[x3d-public] Proposed Standard additions. MFStringSequencer and MFNodeSequncer".

I do agree with notion (from Vincent in that thread on x3d-public) that it (changing ROUTEs at runtime) may be outside of X3D spec. Some browsers may want to optimize for the ROUTE arrangement when loading. Actually CGE/view3dscene also does processing when loading ("detect affected fields") but it practically doesn't preclude API to add/remove routes at runtime.

The CGE/view3dscene plans remain the same:

• We already support adding / removing ROUTEs using Pascal.

• We don't plan to add support for adding / removing ROUTEs using CastleScript. As explained on https://castle-engine.io/castle_script.php , we don't plan to extend CastleScript much at all. CastleScript is useful to simple tasks, and that's good enough. We don't want to pursue extending CastleScript more. For most CGE users, they modify nodes/fields/routes from "outside" (so, from Pascal, see docs above), not from "inside" (like from Script inside a model) and this better matches how people expect a game/3D engine to behave.

• When/if we'll add support for EcmaScript in CGE/view3dscene, we'll follow X3D standard for SAI. We'll be happy to add extensions, compatible with e.g. X_ITE, so e.g adding JS API mentioned in create3000/sunrize#1 ( create3000/sunrize#1 (comment) ) would be within our plans.

  The EcmaScript in CGE/view3dscene, while it's something I consider, remains not high priority. For a game engine, such usage of scripts "inside" is not useful. Usage from "outside" is more useful, for which we offer Pascal API, and think about other languages (like Python).

from castle-engine.

from castle-engine.