Jump to content

Evolution for out of the box meshes creation


Recommended Posts

But there is quite some price for the new method: The playground does not help you any more to create a geometry - it does not show the old method, but only the "option:any" one - so it will not help you to fit in the numbers like before, and even if you decide to use the new version and open the bracket, there will be no help there what values to set :(

Link to comment
Share on other sites

Hi again.  Ok, back to parameter namings.


var knot = BABYLON.Mesh.CreateTorusKnot("knot", 2, 0.5, 128, 64, 2, 3, scene, false, BABYLON.Mesh.DEFAULTSIDE);

Parameters are: name, radius, tube, radialSegments, tubularSegments, p, q, scene, updatable and the optional side orientation


I assume 'tube' is supposed to be 'tubeDiameter'.  And I imagine 'side orientation' will become 'sideOrientation', similar to parametric shapes.  


- But, what about p and q? 


From https://en.wikipedia.org/wiki/Torus_knot ...


The (p,q)-torus knot winds q times around a circle in the interior of the torus, and p times around its axis of rotational symmetry. If p and q are not relatively prime, then we have a torus link with more than one component.


- Should we consider using pWindings and qWindings or something similar?  Maybe pTurns and qTurns?  Or should we stay with the "industry" who, apparently, have decided not to give these variables a more detailed name?  Thoughts?


 And then there is length vs depth... and a few other issues.  Let's look at DK's sphere demo...  http://www.babylonjs-playground.com/#WRH6X#1

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

Here, we have left-behind the width, height, and depth/length completely.  Instead, the term 'diameter' was applied.  Diameter is a circle-based term.  It doesn't apply well to anything non-circular.  But things like sizeX or ySize or [width, length, depth/length]... DO apply to multiple shapes.  Should we give these names some deeper thought?


Also notice... "segments".  Now we have THREE terms to describe granularity...  segments, tessellation, and subdivisions.  Cylinder got a height subdivisions not too long ago, and that could be an issue, too.  Maybe...    hSegments?  segmentsY?  hDivs?  We have some inconsistencies that might need to be dealt-with.


Lastly, let's talk a bit about Blender's influences upon BJS.  I once questioned WHY Texture defines... uOffset, vOffset, uScale, vScale, uAng, vAng, wAng, and baseTexture defines wrapU and wrapV... two names that do not match the established convention.  Someone informed me that Blender set the wrapU and wrapV conventions... and that we were following Blender's lead on those. 


The history of those two terms (wrapU and wrapV) may extend much further than Blender.  These might be LONG-established terms, but it's a big ol' pain-in-the-butt for our goal of making BJS easy.  (imho)


So, I guess I'm asking...


- How many of the parameter names that we are now debating... are being influenced by Blender's names... and/or influenced by historical names? 


- How much SHOULD we try to honor historical terms and terms from modellers? 


- Should we set examples of BETTER naming conventions, and then lean-on Blender to make changes to THEIR system to match ours? 


- Should we consider changing the names of Blender properties... to OUR preferred names... during exports?


- In general, what things are influencing the parameter names? 


- Should DK be allowed to "run with this" and we'll trust his "big picture" knowledge?  Should we trust that he will mind his P's and Q's?  


(Ain't that funny... considering we were talking about the torus knot P and Q parameters?  That's just good comedy, there, kids.)  :)


And then there is the property names that I mentioned earlier. 


- How often... will our parameter names... also be property names?  Ever?  Should we avoid matches, or try for as many matches as we can accomplish?  Thoughts?


SO many questions, huh?  Sorry if I'm over-analyzing or otherwise being a turd in a mud puddle.  If we stopped to analyze every turd that Wingnut dropped, we'd never get ANYTHING done, eh?  :)  I live there.  heh.  Be well, everyone.

Link to comment
Share on other sites

Thread killer Wingnut!  Yay!


See the way Oimo does options?   { size:[400, 40, 390], pos:[0,-20,0], world:world, flat:true }


No diameterX or xDiameter stuff...  no width, height, depth/length stuff, just plain size.  Easy. 


The same format could be used for segments/subdivisions/tessellation.   segs:[xsegs, ysegs, zsegs].  zsegs is ignored on everything... EXCEPT grounds (ysegs is ignored for grounds).  Also, zsegs is not ignored for boxes... IF we allow segments on boxes someday).


Have I ruined the fun?  I hope not... but it seems so.  Sorry about that. 

Link to comment
Share on other sites

Hi Wingnut,


This is the explicit naming convention wingunt. eg a variable my_castle will be clearer than m_c or diameterX will be clearer than dX.

By putting the name of clear options, we know directly what it is and what the option is.

I'm not sure what bothers you. Sorry also not understand.


Good day




Link to comment
Share on other sites

Hi D!  Thanks for your comments.  Yep, maybe you are correct.  I was trying to find some common names that could work for all options objects, no matter which shape.  But that is not so easy.  English is just a screwed-up language.  :) 


Currently,  parameter names are not very important, as long as they get the message to the user (in our docs).  But we are about to enter (an optional) world where... these names are very important.  Maybe I should be concerned, maybe I shouldn't.  I don't see "team" being very concerned over naming conventions, so, maybe I shouldn't be concerned, either.


Maybe I only IMAGINED that there was a concern, here.  :)  widthSegs for one kind of mesh, xSegments for another, tessellation for another, subdivisions for another... maybe it all just doesn't matter.  *shrug*

Link to comment
Share on other sites

Is it only me (and my ISP serving an old BJS-Version?), or do others also don't see the property-list when typing a curly bracket?

I can manually have a look at the 2/2 page, but whenever typing a letter the 1/2 box is shown - including typing a curly bracket, so I can't get a result like DK in Post #35.


** how can I past screenshots in here by the way - image only allows an URL and MyMedia is empty? **

Link to comment
Share on other sites

  • 2 weeks later...

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