New feature: Behaviors

[GameMonetize]

Hey community!

I'm pleased (as always :)) to announce the availability of behaviors: http://doc.babylonjs.com/overviews/behaviors

I don't want to rewrite the documentation here so if you have 5 minutes, do you mind checking it and give your feedback here?

Is it clear enough? What could be missing? any ideas for upcoming new behaviors?

One of the behavior I would like to add is the DraggableBehavior: https://github.com/BabylonJS/Babylon.js/issues/2697

[satguru]

Nice!

How does one define custom behavior?

Currently, "node.behaviors"  lists out only enabled behaviors. Maybe it should list out all ,enabled and disabled,  behaviors

[GameMonetize]

Behaviors are classes, there is no catalog per se (the doc is here to list them)

And to be fair, I can't see a good reason to provide a catalog as you may need to understand what the behavior do before attaching it. So it is clearly a developer task

[sable]

I may be missing something, but shouldn't there be a way to change the properties of the camera behaviours without accessing the private members (e.g. using _bouncingBehavior here)?

Otherwise looks good.

Edit:

I was missing something; should have read the docs better, getBehaviorByName() is obviously how this is done.

[satguru]

Reading the document again I see it defines an interface for the behavior. So if my class implements the interface I should be able to attach it  to a node. Right?

Regarding "node.behaviors", I was thinking from a tooling/editor/inspector perspective. Maybe they can use that to discover and list out all the behaviors attached to a node.

Also instead of

     node.useXYZBehavior = true;

maybe

    node.enableBehavior("XYZ"); ?

This way every time a new behavior is  added, the node properties do not have to change.

Also node.isBehaviorEnablerd("XYZ") to find if a behavior is enabled.

 

 

[GameMonetize]

Hey

Actually for me node.enableBehavior("XYZ") === node.addBehavior(behavior)

I'm not for a global catalog or a registry but I may be wrong. I want the overall process to be dead simple: this is the goal of the useXXXBehavior. I also added direct get accessors like camera.framingBehavior

 

[satguru]

4 hours ago, Deltakosh said:

Actually for me node.enableBehavior("XYZ") === node.addBehavior(behavior)

 

In the demo

https://www.babylonjs-playground.com/#6FBD14

you do not have "camera.addBehaviour(BouncingBehavior)",  what  you have  instead is "camera.useBouncingBehavior = true;"

But I think  I might have misunderstood the purpose of behaviors.

Maybe this is meant for BabylonJS Framework developers rather than BabylonJS Application developers. In other words it can be used by Framework developers  to add additional functionalities  which the Application developers can  then use.  Yes?

[GameMonetize]

You can write it like this:

camera.addBehavior(new BABYLON.BouncingBehavior());

https://www.babylonjs-playground.com/#6FBD14#3

So it is meant for any bjs user. My point was that there is no automatic discovery of available behaviors because it would require too much code for a feature that I'm not sure it worth it compare to a good documentation

[satguru]

Makes sense now.

"camera.useBouncingBehavior = true;" threw me off track.

I thought the behaviors were already added to the camera and useXXXBehavior just enabled or disabled them.

But now I see that useXXXBehavior is same as addBehavior().

[GameMonetize]

Yes:) the useXXXBehavior are just here to make things simple to enable

[Dad72]

It's nice

[Wingnut]

Hi guys.  Interesting feature-adding feature.

hmm.  Isn't "arcRotation", and "free", and "target" and "follow"... all behaviors for a universal camera?

And is hemispheric, directional, spot, and point... behaviors for a universal light?

Is WASD navigation, a behavior for a mesh?

Perhaps those examples... are taking "behaviors" to an extreme.  The library of behaviors could get BIG, and become maintenance-heavy.

Still, behavior-ism is a strange and interesting phenomenon.  It could become a powerful scene-building shortcut system. 

The thought sort-of blows my mind.  It would probably require a substantial re-coding of the entire framework... to use an all-behaviors system.

mesh.addBehavior("diffuseTexture", { url: myUrl, vOffset: 0.2 } );   weird.    I think I am "stretching" the definition of a behavior, a bit.

Still... interesting thoughts (to ME, at least). 

Another part of me says that behaviors are a bad idea.  When helpers try to find a bug in a forum user's playground, and if the user has added many behaviors, the helper will need to KNOW the "traits" of each used behavior... to determine HOW and WHERE a node is acting abnormally.  (Where to find the problem/solution for the user's issue.)

A line like camera.useAutoRotationBehavior = true; ...could hide in messy code, and send PG helpers on goose chases, trying to determine why the camera is moving.

And are we going to see more granularity in the future, such as .useThetaAutoRotationBehavior, .useRhoAutoRotationBehavior, .usePhiAutoRotationBehavior, etc?

hmm.  Thoughts?  This seems like a way to get many many more properties on nodes.  There could be 25-50 .useWhateverWithWhatever  behavior properties... on a basic mesh.  My object inspector will need a bigger window. 

[GameMonetize]

The initial intent is to make everything more modular.

This way we can keep the core engine fast and easy to maintain. Behaviors are not different from what we have today except that the code is exported to a different class instead of having everything in the same class

A line like camera.useAutoRotationBehavior = true is not really different from camera.applyGravity(xxx). In both case you have to know the traits or be ready to open the code.

[Wingnut]

Yeah, I guess I understand that.  thx.  Re-usables.

But why add .useWhatever properties? 

Why not make behaviors be more like camera.inputs?  We don't see any camera.useMouseInput bool, or .useGamepadInput bool.

In a way, .applyGravity was a bad idea, too, and so was .showBoundingBox and possibly backfaceculling and wireframe.  Those are all behaviors, yes?  Will we be adding .useBackfaceCulling and .useWireframe bools... to material class?  Sometimes we use apply, sometimes we use use, sometimes we use show, sometimes none of those.

Are we getting messy and inconsistent in our property names?  (I've whined about this stuff before, haven't I?)    Sorry.

How is it determined WHEN a .useSomething is added to a class?  What is the criteria?  Programmer's choice? 

Can someone help clear-up my brain fog on this?  thx!

[GameMonetize]

Programmer's choice I would say  (mine most of the time). It adds a bit of poetry? (no? :D)

The reason behind useXXXBehavior is only simplicity as I did not want to force you to first instantiate a behavior and then attach it.

For inputs, as they are all enabled by default it made more sense (to me :)) to have then on a single entry point

[Wingnut]

*nod* thx.

'use', 'on', 'is'... strange prefix words.

In the old days...  .isSomething was ALWAYS read-only.  'is' stuff was for monitoring stuff.

But now it's all observers and 'on' stuff.  *beard-scratch*  onPrancerAtopOldSmokeyBesidePointWhileFlyingUnderInfluenceBeforeChristmas