Evolution for out of the box meshes creation

[GameMonetize]

Hey team!

 

following a great discussion with Jerome, please let me introduce the new CreateBox to you:

http://www.babylonjs-playground.com/#1UKBGC

 

In a nutshell, now you can do this:

var box = BABYLON.Mesh.CreateBox("box", { width: 2, height: 4, depth: 0.1 }, scene);

[Dad72]

It is expected that other primitive is created in the same ways? the sphere, cylindre, plan...

[GameMonetize]

yes sir!

[Ahiru]

Will the pivot-point always be in the center, or is it possible to define it when creating the box?

[GameMonetize]

now the sphere:

http://www.babylonjs-playground.com/#WRH6X

var sphere = BABYLON.Mesh.CreateSphere("sphere1", {	segments: 32, 	diameterX: 2, 	diameterY:4, 	diameterZ: 5, 	sideOrientation: BABYLON.Mesh.FRONTSIDE}, scene);

[jerome]

Damn Lucky Luke ! 

you code faster than your shadow !

[GameMonetize]

Pivot can be changed at anytime by updating mesh.setPivotMatrix:

 

http://www.babylonjs-playground.com/#WRH6X#1

[jerome]

This new signature (retro-compat with the current one) is one of powerful thing you ever added to BJS because we will be able now to extend quite infinitely the features of each mesh !

 

Can we have a different uvs management for boxes ? yes, we can (just hope there's no copyright on this motto)

Can we have a different normal behavior for spheres ? yes, we can

Etc ...

[GameMonetize]

lol

[Dad72]

now the sphere:

http://www.babylonjs-playground.com/#WRH6X

var sphere = BABYLON.Mesh.CreateSphere("sphere1", {	segments: 32, 	diameterX: 2, 	diameterY:4, 	diameterZ: 5, 	sideOrientation: BABYLON.Mesh.FRONTSIDE}, scene);

There must be a problem for the scene parameter is diameterOrScene but if you put a diameter (num) and the sphere disappears if you put true for updatable he told me that it is a szene I must put this:

 

var sphere = BABYLON.Mesh.CreateSphere("sphere1", { segments: 32, diameterX: 3, diameterY: 3, diameterZ: 3}, scene, scene, true); // on doit mettre 2 fois scene ici

http://www.babylonjs-playground.com/#WRH6X#2

 

Why put twice 'scene' ?

 

and this not work:

 

var sphere = BABYLON.Mesh.CreateSphere("sphere1", { segments: 32}, 3.0, scene, true); 

http://www.babylonjs-playground.com/#WRH6X#3

 

So diameterOrScene : "scene" work, "diameter" no.

 

I think there must be a bug?

[jerome]

The way to understand these signatures is this one :

 

1 - either you use the usual way you already know

2 - either you use the short way which is : CreateXXX(name, options, scene);

 

In this case, options is an object with its own properties.

These properties can be the same as the parameters used in the previous method signature (1) or others so the CreateXXX() will have a different extended behavior.

 

This means :

- if you use an object options, you must set all the parameter values you want as options properties (quite all have default values however) and then just pass the scene parameter : CreateXXX(name, options, scene)

- if you don't use the object options, then just keep coding as you used to with CreateXXX(name, param1, param2, ..., param3, scene)

 

You can't mix the object options and many other parameters in the method call.

 

 

What is allowed with the new CreateXXX() signature is :

CreateXXX(name, options, scene);    // => you can then specify the options.updatable and option.sideOrientation values if you want

[Dad72]

OK I see. So for example must be updatable add the options:

 

{updatable: true}, scene); => http://www.babylonjs-playground.com/#WRH6X#4

 

That's right ? Tthank you Jerome.

[jerome]

I just edited the previous post to give more details

 

[EDIT] edited twice to fix the edit ... ooopss

[Dad72]

Ok, thank you Jerome  for the clarification. I love this new signature. 

[jerome]

The goal is to port this new signature to every existing mesh :

This will be easier for people to code, especially for using current methods with 6 or 7 parameters.

This will allow to extend the mesh features withour adding extra other parameters in the signature.

This will standardize all the CreateXXX() methods in the same form with only 3 parameters : name, options, scene.

 

Standardized names are good things for users (simpler code) and newcomers (easy to learn).

[Dad72]

So we can add our own options. for example if I want to add a option "description", I can?

[jerome]

If you pass an option property that is unknown by the code that creates the mesh, it will just be ignored.

If you can ever add, once it is created, a property "description" to your mesh instance of course, that's just javascript.

 

When talking about the possibility to extend the meshes, I meant that BJS developers (these who do the internal code of BJS, contributors) could add new features without changing the signature as DK did :

he changed the CreateBox() method what could until now just create a cube to something able to create now a cuboid (different size for width, depth and height).

 

We could imagine to have a property allowing, for example, to stretch a texture on the whole cube surface instead of repeating it on each side. This would be a new feature (new code about UVs settings under the hood) added while keeping the signature unchanged : CreateBox(name, options, scene)

[Dad72]

Ok, I understood perfectly. Thank you again and sorry with all my questions. It is a very good thing this signatures for adding new functionality without breaking compatibility. 

[jahow]

Great job! Will it be available for ribbons then? Like, for example, if we want to add caps to them, you know...

[jerome]

I will add this to my backlog !

delete on line, add another one ... Danaids sieve

[GameMonetize]

Plane done:

var plane = BABYLON.Mesh.CreatePlane("plane", {width:6,height:10}, scene);

Ground done:

var ground = BABYLON.Mesh.CreateGround("ground1", {width:6, height:6, subdivisions:4}, scene);

[Wingnut]

But this is NOT ok...

var matPack = {    name: "groundmat",    material: "standard",    diffuseColor: "red"};var paramPack = {    shape: ground,    name: "ground1",    tags: [],    isFlatShaded: true,    material: matPack,    width: 6,    height: 7,    subdivisions: 4,    scene:  scene,    updatable: false};// create any mesh - a ground in this case...var ground = BABYLON.CreateMesh(paramPack);

Right? 

 

I took it a few steps further, eh?  *scratch scratch*  One BJS command... can create ALL meshes... and do auto-material, and ALL params/args are inside-of the constructor's paramPack.  Why not allow ALL the params to be set inside-of the options object?  *shrug*

 

Ok, maybe that's out-of-control, huh?    It sort-of ruins the re-usability of options (paramPack) objects, eh?  nod.  They get specific when a "name" and "shape" are defined inside.  But options objects are only re-usable on the same mesh shape anyway, because each mesh will have different option/parameter names.  I wonder what cylinder's parameter names will be.  diameterTop, diameterBottom, etc, I suppose.

 

Is the public allowed to suggest different parameter names?  Is this the time to carefully scrutinize the parameter names, because they will get locked-down soon after this? 

 

Or... cope and deal with whatever the boss wants?  errr. 

 

Are SHORT parameter names important...  like dTop and dBot for those cylinder diameters?  Or do we not care about those name lengths?  Thoughts? 

 

Something like isFlatShaded might be both a parameter name AND a property on the mesh, so we probably shouldn't hack those names.  WHEN will a parameter name match a property name?  Often?  Hardly ever?  Should we weigh the future potential of how often that happens?  Too deep?  I'm scared!

[GameMonetize]

I like this uber function Something really interesting to add definitely.

 

For new parameters naming: Yes this is the right time as we are still in the beta process. BUt keep in mind that diameterTop is far better than dTop for a newbie

 

To answer "Why not allow ALL the params to be set inside-of the options object" I have the following rule of thumb: the parameters are easy to discover when using the playground thanks to intelissense. So they have my favor but sometimes it could be interesting to have both (like for out-of-the-box meshes)

[jerome]

As a coder I like also this über function.

But I don't think it's good thing to have it in BJS.

 

Why ?

#1 - Because we can't give it a default behavior. What would be the shape of a default general mesh ?

When you use CreateSphere() for instance you expect to get a sphere, even if you don't give parameters to customize it. You could then object that with CreateMesh(), only one parameter at least would be required, the shape, what is not a big real difference.  Ok, a point for you.

 

#2 - Because it would be really really confusing in terms of parameters.

Ex : question on the forum

"I did  :

CreateMesh({shape: box, topDiameter: 10, stretchTexture: true });

and it doesn't work. Any thought ?"

there Wingy would reply a 8 km (or 6 miles) long post  to explain to this newcomer that the topDiameter parameter isn't pertinent for the box, but the stretchTexture one would work, only if the shape has many faces (say, a box, a pyramid but not a sphere). Etc

 

So keeping a function name per shape type is, imho, a good way to keep pools of pertinent parameters together in the code (BJS code and user code), in the documentation and in the forum funny debates.

 

I agree the parameter names are important, so it is a good idea to submit them to the community before implementing them

[Wingnut]

Thanks for the replies on that, guys.  Yeah, my idea was a goofy idea.  I wanted to get some feedback on it... and did, thanks.

 

In post #16, dad72 asked about adding our own parameter fields (good question).  Jerome, in post 17, mentioned that the shape constructor would ignore the extra parameter(s) if they were not pertinent to the mesh creation.

 

I have thoughts.  (oh crap, huh).  It seems to me that there could be creation options... the standard shape parameters... and post-creation settings.  Dad72's "description" would be a post-creation setting.  Maybe any key that starts with an underscore... is added after the creation.  PCS.  Post-creation settings. 

 

_rotation, _position, and _scale... could be PCS's.  They would be done to the mesh AFTER (post-) creation.  IF underscored keys exist, the creation code calls processPostCreationOptions() before returning from the user's creation call.  But that could get really messy. 

 

Maybe we could allow a post-creation options object, but maybe it should be done in a separate step.... by the user.

 

sphere.processSettingsOptions(MySettingsOptionsObject);  (this is all done AFTER creation, so it doesn't complicate the creation construction at all - safer - better error reports)

 

Doing it that way, we can now eliminate this potential issue from the mesh creation phase.  As Jerome points-out, if it isn't one of the creation parameters... it will be ignored. 

 

But after creation, Dad72 could make another "settings" object... similar to an options object, and get .description set... as well as potentially setting rotation, position, scale, isFlatShaded, showBoundingBox, edgesRender, smWireframe, smBackFaceCulling, etc etc.  The processSettingsOptions() func could be very powerful... including adding a standardMaterial to the mesh.material property... and setting colors or wireframe or backFaceCulling on that material... per the things found in the settingsOptionsObject.

 

Yep, post-creation settings are cool, but I think you guys are thinking right.  Creation is one thing, post-creation settings is a different thing, and they need to remain separated. 

 

So, yeah, I need to stay on-topic of creation, and maybe later we can talk about a mesh.processSettings(settingsObject) feature/nightmare.

 

That was a good question, Dad72!  It made my brain organization go mushy, (more mushy than normal). 

 

--------------

 

Back on subject... these creation options objects COULD make finding parameter mistakes... easier or harder.  We often see non-descript errors such as d is undefined when a parameter mistake has been made.  If we are doing helper duty, we might need to search-around in people's code to find their options object for that error-generating constructor line... to see what parameter they forgot.

 

Reworded, if the user is using options objects, we won't be able to simply look-at the createTorusKnot() constructor line to see what parameter the user missed.  Instead, we need to find the options object they used, and look in there for the problem.

 

We could see spelling and typing mistakes in the keys of the options objects.  Using the old way... the user needs to get the values correct, and the parameter order in the constructor... correct, but they don't need to concern themselves with the parameter names.

 

With the new options object, they no longer need to worry about parameter order, but they are now dealing with English words with mixed case... inside the options object declaration.  Does this increase the chance for user mistakes? 

 

AND... are we shoving English up the users' butts... possibly unfairly? 

 

Yes, the options object is optional.    The old method will still work, right?  But... I think we all can see that... those who speak very little English... will be forced to deal with English if they want to use an options object.  They have to get the key names correct... or else the construction fails. 

 

Are we being unfair and imposing?  Maybe there is no way around it, eh?  But I think we should keep in mind that we are "locking" these parameter names... to English words.  Maybe we should consider using a language bindings system so that users DO have an option to use key/param names that are in their own language.  Being American, I have no sense of how much... other countries are pushing English in their school systems.

 

I had an experience, once, based on language.  One time, in a Minneapolis convenience store, I heard two Arab-like men speaking a really interesting language... it was beautiful... and I had to ask them about it.  They told me that the language was over 2000 years old, and... wow... that's a HOLY CRAP for mister Wingnut.  How can anyone ignore a 2000 year old language? 

 

And thus, here I am, talking to my BJS friends about honoring "golden" languages.  Only non-native-English-speakers can give me a sense of the feelings behind this, because the language I use... is the default BJS language.  I have no native language that is being left-behind.  Others DO have beloved languages being left-behind.  Are we being unfair to them... unless we try to let them use parameter names that are for THEIR native language?

 

I still like the idea of an options object.  I guess I'm just trying to figure out the long-term ramifications, and trying to predict some of the user problems that could occur.

 

------------------

 

As for the names of these keys... I have no issues EXCEPT... tessellation and subdivisions.   Do these two terms mean the same thing, as far as BJS is concerned?  Maybe we should drop the term tessellation... and always use 'subdivisions'.  But maybe that is a bad idea.  Thoughts on this?  Thanks.  Be well, everyone.  Sorry for the long post.