Bring back modification of node inside PROTO from API supervisor

[ShuffleWire]

Hello,

I have a useful use-case in favor of reintroducing PROTO modification from API, as discussed in #1923

I need to change on the fly a shape of a PROTO during simulation, but it seems to have a huge performance impact, and moreover it cause me some trouble to get exactly what I want.

What I'm experimenting is to change value (translation, in my case) of nodes inside the PROTO directly, without changing the driving parameter of the PROTO, hence avoiding a regeneration (basically 99% of the PROTO stay the same at each update).

I've tried by changing from the API only the values that should change (a translation), and it works great, and performance are great ! Moreover reset revert all changes made on the PROTO during the simulation, at that's good :)

The only thing is that I had to change in the webots code all boolean "is_read_only" and "is_proto_internal" to false to get it working. Maybe it's not the best way to do it, but it work to demonstrate my point.

Is there anything that could break in the code by doing so ? If no, I feel it's a rather arbitrary choice to avoid this kind of manipulation, which is in my case very useful.

I do understand that a PROTO should be only defined by it's input, and taht what I'm doing contradict this "clean" way, but it's should remains an option to the user, imo.
And in this case clearly document it, and warn the user that it's not the "intended"/"clean" way of doing it.

What do you think ?

I can craft an example to demonstrate my point, but it would take some time, so ping me if you really need one to get my point.

[omichel]

To avoid the regeneration of a procedural PROTO, you should use the IS keyword to expose the value you want to change inside the PROTO. This should be super fast as it shouldn't trigger regeneration of the PROTO. Doesn't this work for you?

[ShuffleWire]

I'm sure it would work (not tested) : I'm already having a list of value (using IS) that are driving the shape of the PROTO, and changing one of them trigger regeneration (or at least cost in performance, so I'm assuming that it)

Moreover I don't see how the change of value of an input will not trigger regeneration : some value would and some wouldn't, and I don't see mechanism of Webot to forecast whenever we need a full regeneration or not.

[omichel]

I believe that if a PROTO parameter is only used with the IS keyword and not with any scripting code, changing its value should not trigger a regeneration. That should be easy to test to confirm.

[ShuffleWire]

but my parameter is used in scripting... :/
It's an array, which is read by the script to generate the proto, hence it's forced to trigger a regeneration.

[ShuffleWire]

Using an example :

This PROTO allows to get a serie of boxes standing on the ground. (the trick is to raise the box to half the height, because the origin of the box is in the middle of the box)
Initially it allows to give coordinates and height.
But during simulation I want to raise them without changing height, hence modify only the translation.
This is why changing directly the translation value of each by the API is very clean, it doesn't mess with the height.
And I would like to avoid having two fields, because that would make two array difficult to maintain.

#VRML_SIM R2023a utf8

PROTO BoxOnGround [
 field MFVec3f     boxes            []
 ]
{
    %{ boxes = fields.boxes.value }%
    %{ nbBox = #(boxes) }%
  Transform {
    children [
        DEF Main Transform {
            children [
                %{ for i = 1, nbBox do }%
                    Transform {
                        translation %{=boxes[i].x}% %{=boxes[i].y}% %{=boxes[i].z/2}%
                        children [
                            Shape {
                                appearance PBRAppearance {
                                    baseColorMap ImageTexture {
                                        url [
                                            "https://raw.githubusercontent.com/cyberbotics/webots/R2023a/projects/appearances/protos/textures/rough_pine/rough_pine_base_color.jpg"
                                        ]
                                    }
                                    metalness 0
                                }
                                geometry Box {
                                    size 1 1 %{=boxes[i].z}%
                                }
                            }
                        ]
                    }
                %{ end }%
            ]
        }
    ]
  }
}

[omichel]

I would say that the PROTOs are not made for this use case. Instead you should program a supervisor that will lay down your cubes one by one at the desired positions, adapting both their size and position. This will save you from PROTO regeneration performance impact.

[ShuffleWire]

yes that is an option, but that not as convenient... As it, I can show off and update the boxes I want from the GUI without the need of a supervisor running.

Aside from this use case, what is the reasoning behind making internal of PROTO read-only ?

[omichel]

It is a design choice to enforce clean code: modifying a PROTO should only happen from the PROTO parameters interface and nothing else. This is similar to what happens with regular nodes. It is not possible to change their internal state, but only to change their exposed parameters. Otherwise it defeats the parameter encapsulation in PROTOs and render the resulting code more difficult to understand as as well as prone to bugs as it opens up many complex possibilities.

[ShuffleWire]

I do feel that it more on the user/PROTO writer to write clean PROTO, not on Webots side. from what I've seen, Webots add code in it's own code base only to enforce what the user should do... IMO for the majority of user, they would not try to mess with PROTO internals, only advanced user will use that option, that could be useful in some situation.

I think that it's not very comparable with node internal, being deeply linked with Webots code, for which user shall not be able to mess with it. But it require to open the Webots code, so only developer should care, regular user/PROTO write can't access those.

For instance, I've a controller that is precisely crafted to talk to my PROTO. The PROTO is hence more or less a useful bag that ease the process of integrating, moving, and displaying data, concept, object, behavior into Webots. For what I've tried, a PROTO is really a powerful piece of Webots to make nice objects !

To summaries my opinion :

1. Restricting a useful option add mess in Webots code by the addition of guards and logic, and i don't think it improve clean code
2. Giving option to advanced user to use the full potential of their PROTO is better
3. "Official" PROTO files produced by the Webots teams could very well be more pedantic with this rules, just to show the right way
4. Internal/regular node shall not expose there internal, but PROTO are not the same : they are often designed by a user to be used by himself as a tool, hence the link between implementation and usage is very tight. So accessing the internal seems ok.