Jump to content

New feature: Behaviors


Recommended Posts

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

Link to comment
Share on other sites

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.


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

Link to comment
Share on other sites

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;


    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.



Link to comment
Share on other sites

4 hours ago, Deltakosh said:

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


In the demo


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?

Link to comment
Share on other sites

You can write it like this:

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


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 :)

Link to comment
Share on other sites

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().

Link to comment
Share on other sites

  • 2 months later...

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.  :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...