tube marketing

[jerome]

Hi people,

 

Here is some TubeMesh advertising before diving back into TS+github dark waters

 

Well, remember the tubeMesh.

You remind it needs just a radius and a path, in other words a series of consecutive Vector3.

So let's play with it :

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

 

As you can see line 22, I just construct a path following some simple sinus function (please forget the var a, just a scoria from copy/cut).

  var curvePoints = function(l, t) {  var path = [];  var step = l / t;  for (var i = -l/2; i < l/2; i += step ) {    var t = i  / Math.PI * 2;    var x =   Math.sin(t) + i;    path.push(new BABYLON.Vector3(x, i, 0 ));    }    return path;  };  var curve = curvePoints(40, 400);

If I "tube" it (line 46),

var tube = createTube(curve, 1, 60, null, scene);

nothing really new until now : http://www.babylonjs-playground.com/#1AC0MR#1

 

 

Ok so back to the first example : http://www.babylonjs-playground.com/#1AC0MR

Now, line 29, I just change the y coordinate of each Vector3 from i value to 0 :

path.push(new BABYLON.Vector3(x, 0, 0 ));

http://www.babylonjs-playground.com/#1AC0MR#2

It is still a sinus curve but flatten on x axis. Nothing to see really.

If I "tube" it, well, nothing more to see : http://www.babylonjs-playground.com/#1AC0MR#3

 

Right ?

 

Ok, now I define a radius function line 40.

var radiusFunction = function(i, distance) {    var t = i / Math.PI * 2 / 8;    var radius =  Math.sin(t) + i / 25;    return radius;  };

This function will return a radius value evolving with the i passed parameter. Simply the radius value increases with i and is moderated by a sinus function.

Nothing very complex.

 

 

Then I pass this function to the tube constructor method.

The radius function will be called for every vector3 in the path and be given the position number of this vector (i).

The returned radius will then be applied to the tube at this position.

Line 45

var tube = createTube(curve, 1, 60, radiusFunction, scene);

taanddaaaaammmm

http://www.babylonjs-playground.com/#1AC0MR#4

 

This is an illustration about the fact that the path carrying the tube doesn't need to be continuous neither regular.

It can be whatever you want (here a sinus curve) : you could have the next vector3 going back from the former one instead of keeping the same direction thru space, etc.

No need to have a maths curve either, you can set your own points as you like.

Or you can even concat many arrays : a maths curve, then imported points, then another maths curve, etc.

 

The tubeMesh is, well, a classical tube if you give its path as a simple line and a fixed radius.

As soon as you start to play with the way to set the path and the parametric radius, you easily get various shapes... far distant from a standard tube .

 

ex : line 29, I just add a y coordinate on the path, varying with cosinus

    var x = Math.sin(t) + i;    var y = 2 * Math.cos(t/2) - i ;    path.push(new BABYLON.Vector3(x, y, 0 ));

oooohhhh

http://www.babylonjs-playground.com/#1AC0MR#5

 

 

Have fun folks

[GameMonetize]

This is huge!! Looks like the hat in Harry potter:)

[jerome]

BABYLON.Mesh.CreateTube(name, path, radius, tesselation, radiusFunction(opt), scene)

Do you agree for this new simple basic/parametric shape ?

[GameMonetize]

Yes sir!

[jerome]

I checking the BJS file organization.

In the mesh.vertexData.ts file, we've got createXXX() methods returning a VertexData object.

These methods are called by createXXX() methods of the mesh.ts file. These last return a Mesh object.

Right.

 

I want to implement to new kind of mesh, the tube.

Its user public method will be :

BABYLON.Mesh.CreateTube(name, path, radius, tesselation, radiusFunction(opt), scene, updatable, sideOrientation)

This method will be quite different than the other createXXX() methods because it will juste reuse the public Mesh.CreateRibbon() method.

Actually the CreateTube() method will just do something like

public static CreateTube(name: string, path: Vector3[], radius: number, tesselation: number, radiusFunction: any, scene: Scene, updatable?: boolean, sideOrientation: number): Mesh {  var circlePaths: Vector3[][];  // computes many maths with path, radius, tesselation and/or radiusFunction() parameters  // to populate the needed circlePaths array  var tube = BABYLON.Mesh.CreateRibbon(name, circlePaths, false, true, 0, scene, updatable, sideOrientation);  return tube;  }

So I guess there is no need to put it in the mesh.vertexData.ts file (no vertexData returned), but just in the mesh.ts file even if it's bigger than the other Mesh.CreateXXX() methods

Am I right ?

 

And I'm wondering if it needs to be declared as a Tube class in the geometry.ts as well (no vertexData).

Please let me know as I didn't see any other basic shapes relying on another basic shape so far.

[GameMonetize]

KISS: Keep it simple and smart. So if CreateTube is only 5 lines long this is GREAT!

[jerome]

the maths needed is about 30 LOC

then only one line to create the mesh

[GameMonetize]

GOOOD:)

[jerome]

and I don't use Fernet formulas... else it would have been... pfiiiiouuuu 

[jerome]

well so ? 

only a static method in the mesh class ? 

do you confirm ?

[GameMonetize]

I confirm

[jerome]

ok, so tomorrow I'll start it

just hope noboby will come to disturb me : http://programming-motherfucker.com/ ! 

[jerome]

I maybe even simplify the call signature if I can :

BABYLON.Mesh.CreateTube(name, path, radius, tesselation, scene)

and the radius parameter to be passed would be either a number value, either a function (autodetection)... need to check if it's worth it

 

Another question :

 

As I said before the tube is just a particuliar ribbon, so I know now where to code it the the BJS architecture. OK.

The tube mesh relies on the notion of a 3D path : an object representing a path in space with tangents, normals, binormals computed in order to reduce number of rotations between steps and keep consistancy, total distance, point distances.

This object is about 20-25 LOC.

The tube is then just a series of circles set on this path, then ribbonized.

 

This object, let's call it Path3D, could be reused, for example, for extrusion along a curve (very same algo) or to animate meshes or even a cam along a given path : a road, a roller-coaster, a plane flight, etc. Whatever you want. It represents a quite realistic way to go from a point of the curve to the next point : it sets a local set of 3 orthogonal vectors (tangent, normal, binormal), each set evolving (rotatinf if needed) smoothly from the former one.

ex : if you set you cam at 2 x normal vector on each point, you could emulate a view from plane making loopings or a view from a mine car driving on rails

 

So my idea is to create a Path3D dedicated class :

new BABYLON.Path3D( [vector3_1, vector3_2, ... vector3_n] );   // returns a Path3D object with everything pre-computed

then use this object to construct the tube, so the tube constructor will be quite light :

var path3d = new BABYLON.Path3D( [vector3_1, vector3_2, ... vector3_n] );var circlePaths = [];// for each path3d points, set a circle, push each circle in circlePathsvar tube = BABYLON.Mesh.CreateRibbon(name, circlePaths, false, true, null, scene, updatable, sideOrientation);return tube ;

So my question is :

Where to code this new Path3D object ?

Is there still a class to gather 3D curves, objects, etc who aren't meshes, neither lines, but just 3D geometric point handlers ?

 

In babylon.maths.ts  file ?

[jerome]

Path3D done : http://logiciels.iut-rodez.fr/proto/weathermap/test2/path3D.ts

Where to include it now in the BJS modules/files ?

Then I code the tube using this object.

[Wingnut]

Pardon me, guys, and congrats on the new Path3D object, Jerome.  And good morning to all (per usa time).

 

Isn't a "path" actually NOT a path, until it's used AS a path?  At its root, a path is an array-o-vectors, correct?

 

So... hmm... how is the pathArray filled?  (with math, duh wingy)  Can our current easing/tensioning and bezier stuff... be used during its filling?  Just the formulas themelves, I suppose.  Our current easing and bezier tools... MIGHT be somewhat dedicated to keyframe animation ONLY (I haven't investigated).

 

In the case of a Path3D that is being used for a flight path, the intrerpolators from a keyframe Animation would never be used, correct?  Instead, these easings (such-as slowings at the top of parabola) would be installed during the STOCKING of the path array, I suspect.

 

I have no idea where I am going with this post. 

 

Remember when I talked about jMesh having its own special section?  It is SO different from our basic mesh, eh?  Like your example, Tube relies-on Path3d which can be used by other things.  And Tube also relies-on Ribbon, which is also used by other things.  Yet both Path3D and Ribbon have uses... when not involved in other systems.  They stand alone, too.  Don't ya hate re-usables?  Geez, they're annoying. 

 

Strange.  "JMesh" is SO different from our basic mesh system.  (did I say that before?) 

 

To deltakosh and team, this probably feels like putting "alien code" onto Mesh and VertexData.. 

 

This 'jMesh' (quick, anyone, find a better name) is quite math-intensive, and so its code gets uncomfortably long, and COULD irritate DK's "make it easy" policy.  (only lightly-irritated, as dk is an emotional rock)  heh

 

And that brings us back to segregating (separating).  JMesh really doesn't "fit" the standard Mesh or standard VertexData devices. 

 

Like you said, no other Mesh primitive... requires a user to create a Path3D as a prerequisite, nor calls something like CreateRibbon to accomplish its goal.  Tube is a strange creature.  It's really one of many strange creatures that could happen... using the Path3D and CreateRibbon "system".

 

And now we're back to jMesh and jVertexData, where Jerome can make tools and toys and not worry about killing "make it easy" characteristics of DK's .Mesh address space.  Maybe?

 

Yes, BABYLON.jMesh.CreateTube is ugly, and can lead to confusion and lots of forum questions, but the alternative looks a bit ugly, as well.  I don't think Jerome will stop... at Tube.  I think Tube will have 20 brothers and sisters by year's end.  So, should we think about building Jerome Land, with a jMesh and jVertexData? (rename at will)

 

Maybe we could hijack some English word... like maybe "Plot".

 

Then, Jerome's meshes would still be 'mesh' in the loose sense, but not a 'Mesh'.  They are instead... 'Plot'-type meshes.  And to create a Tube...  BABYLON.Plot.CreateTube(...).  Jerome's mad scientist lab would not be within the Mesh domain anymore.  It would now be within the Plot domain.  His meshes are "plots".  *shrug*  How do they look?...

var my ribbon = BABYLON.Plot.CreateRibbon();var mypath = new BABYLON.Plot.Path3D();

Not too ugly, eh?  Jerome's Plot domain, and the Plot laboratory, with its dedicated vertexData repository of Plots.    The Mesh domain and the Plot domain... living together, growing together... just being together... la la la la la  (Wingy sings and dances while the neighbors pound-on the walls for him to stop). 

 

I dunno.  Wingy babbling. 

 

What the hell is a "Geometry"?  Why do we have that thing here?  When is it used?  Where am I?

[jerome]

I think I don't express very well.

 

The path3D is not visible to end users (unless they want).

It's just an intermediate tool, a re-useable tool. Like matrix : matrix don't exist in js, but we have a matrix objects we can use to construct higl level things for users.

Let's see it further.

 

Back to the tube.

The tube is intended to be as user-friendly as possible : a path (a series of vector3), a radius and a tesselation.

Nothing more than for boxes, spheres, etc (do you think it's not easy enough ?)

 

The path tube parameter is, well, what you want.

You can populate an array with a math function, you can just import points from a data set,  set them manually or a bit of all of this... It's just an array of vector3.

You even can concatenate  different arrays to have the final wanted array. Simple javascript.

I will make playground examples to show how it is finally easy.

 

 

Back to the path3D.

 

The path3D will be the internal skeletton of the tube and the ribbon its skin.

 

 

 

The end-user will never know this.

Whatever for him the way this mesh is internally constructed imho ?

 

Well, if I have had to recode from scratch a tube, what would I have done ? 

Nothing more than to implement once again a curve skeleton, then circles around it, then triangles between them, and finally a complete surface with normals, uvs,  then to instanciate a vertexData, set it up, etc.

In other terms, quite the same code, this time embedded in the object, as the one  I did for path3D and ribbon.

 

Actually, I first created Q&D the tube code (I needed it for my network weathermap webapp)... and only then realized, when cleaning it up, I could extract this re-usable path3D and this re-usable ribbon !

I confess I then discovered ribbons were so versatiles that I spent much time playing with them

 

So as the path3D object will exist as an internal tool, it would then be re-usable by contributors for another end-user function (to be coded) : extrusion along a curve which will be as easy to use as the tube for end-user too. Get a 2D (or 3D) shape and extrude it along a series of vector3 with just one function

 

Moreover, if someone wants to have an ready-made tool to easily construct a path into space to be followed by an airplane, it will probably need this kind of stuff : http://www.cs.cmu.edu/afs/andrew/scs/cs/15-462/web/old/asst2camera.html

A set of successive vector triplets : tangent, normal, binormal.

This is just path3D.

 

Then he will have, yes, to use interpolation to go smoothly (or not) from a stage to the next one on the path3D.

Those are just steps in space : where to pass thru  and in what rotation state to keep consistency (only if want to respect it, nothing is mandatory here) ?

Not how to get there and not how to get to next step ? speed, interpolation, etc ?

They really don't tell anything about how sliding from one to the other. Nothing at all.

 

Yes, interpolation is still needed !

 

 

 

I hope I am clearer this time

 

note: when talking about geometry, maths, etc, I talked about the BJS .ts files... asking DK where to put my code in.

[GameMonetize]

I suggest adding the Path3D in math.ts alongside path2D

[jerome]

Ok

I even didn't remark this path2D ! 

[Wingnut]

Thx J.  Can you ever foresee Tube becoming Duct?  I suppose Tubes automatically become square when "segments" is set to 4.  Distance between rings is "tessellation" you say?  Reverse that?

 

For now, I am going to call them lengthDivs (rings per tube-run) and diameterDivs (points per ring), ok? 

 

So, to make a tube/duct, one needs a stocked Path3D first.  I suppose many of those could be pre-made. (sharp-elbows, gentle-elbows, corkscrews, squares, triangles, straight, etc), all different Path3D's, but using the same CreateTube.

 

CreateTube(name, length, diameter, lengthDivs, diameterDivs, path, sidesMode, scene, updatable);

 

sidesMode = normal, inverted, doublesided, of course. 

 

A nice 9-ARG beauty. 

 

One more parameter could MAYBE be added (or maybe a special kind of diameter param).  A radius array... an array of floats... one per "ring"... that tells the radius of THAT ring. 

 

SO there would need to be as-many floats in the radiusArray, as there are lengthDivs+1 (or something like that).  *shrug*

 

Want to go crazier?  I knew ya did. 

 

Let's pretend that radiusArray is an array of arrays.  Then... if diameterDivs is 3 (triangle tubing)... and if the tube is 4 lengthDivs (5 rings)... then the radiusArray might look like this:

 

var radiusArray = [

   [three radius floats for ring 1],

   [three radius floats for ring 2],

   [three radius floats for ring 3],

   [three radius floats for ring 4],

   [three radius floats for ring 5]

];

 

Having a radiusArray would override the diameter parameter... because the array is telling every point... how far to be away from tube-center.  Now we're getting complicated. 

 

But a radiusArray is the only way to get rectangular tubing.  Rectangular tubing needs a width and height.  Also, so will oval tubing, I would think.

 

IF radiusArray is NOT an array of arrays, but simply a flat array of single floats... then still apply each radius float... to all points on that ring.  (the tube cross-section would be symmetrical).

 

And if no radiusArray is found, use diameter parameter.

 

Wow, huh?  Smart tubing.    Gotta analyze the crap out of radiusArray before any work can get done.  Yech, eh? 

 

Thinkin'    I'm quite the Mister Idea, eh?  Yikes!

[Wingnut]

Ohhhh... maybe Path3D takes care of setting the lengthDivs.  Maybe there is always as many rings in the tube, as there are points on the path.  yuh yuh yuh.  Path3D sets the lengthDivs... I bet.  Yuh. 

[jerome]

I repeat : path3D is just an intermediate tool for contributors. No need to use it for end-users.

 

Do you really feel the CreateTube() and CreateRibbon() functions are too complex ?

 

Well, maybe. I don't know.

 

If people think there are too many parameters, they always can set them to null or don't even pass them as many are optionals. 

It will cover the main cases.

Did you notice that the very basic shape construction signatures had many invisible parameters too ?

The mandatory parameters aren't numerous actually.

 

 

About the complexity ... well

 

Do we satisfy with only boxes, spheres, torus and planes ? I personaly don't.

I don't want to go to Blender and export a mesh just to design something else than a box, a sphere, a torus or a plane.

Moreover, I need meshes which can be computed within the environment because of the evolving values they could represent. Blender can't do this.

 

I understand I just said the words "I" and "personaly" in the former sentences.

But I guess other people may have the same needs. So why don't share the work done ?

 

Parametric shapes are not that exotic in a 3D library imho.

Threejs provides plenty of parametric shapes, so I guess many people want them and  use them.

 

Are by definition parametric shapes more complex than predefined ones ? of course.

 

Are they too complex ? question of point of view...

 

Since you can, with only one CreateRibbon() call, create something as complex as a SH, a helix, a vase, half a sphere, quite everything you want actually, I think it's worth it. Only my opinion again.

 

I repeat you can always set each optional parameter to null and get the default behavior which covers the main cases.

 

Let's now compare to the competitors.

Well, Threejs has no ribbon, but other parametric shapes. Probably they are needed since they exist.

 

Did you ever try to use them ?

You need at least as a end-user to first create a curve object with sometimes two callback functions (coded by your own : a constructor and an iterator), then instanciate a geometry object with this curve object, then create a material object, then set a mesh telling it associates this geometry and this material and then finally add this mesh to the scene.

Meanwhile you would have to set many properties to each intermediate objects : side (else the object isn't even visible), colors, type of light reflection, coordinates, shadows, etc.

 

So objectively our little parametric shapes are far more simple to use than Threejs ones : no complex curve object but just arrays of vector3, one single function call then.

 

Well, you could object we don't care about threejs, we are BJS here !

Ok, I agree.

 

So if features seems too complex to people, they aren't obliged to use them, nope ?

There are still workarounds : Blender, 3DSmax, etc... or merging cubes, spheres, planes, don't know.

 

I don't know anything yet about GLSL... so I don't code custom shaders. That's it. 

So since they look for now too complex to me, I just use what else BJS provides and I what can deal with regarding my skills. 

The same for many other BJS features ... 

I just say to myself that some days I'll take time to learn all these unknow complex things.

 

And if I can't achieve it, I'll ask Wingy on the forum 

[Wingnut]

Did I say "complex" anywhere in my post?  nooo.    I must have implied it, though.

 

It seems to me that to make a straight tube, it would require ONE certain path, and for a torus tube... a different path.  Both could be made from the very same CreateTube func.  *shrug*

 

But the end user never stocks a path object?  *scratch scratch*

 

Sorry, I'm not so good at understanding this stuff.   I'll get it, eventually.  And even if I don't, as long as somebody gets it, right?   I can steal code with (from) the best of 'em. 

 

"If you can't dazzle 'em with brilliance, dazzle 'em with brilliance you stole from someone else." 

[jerome]

I know I'm not very clear at explaining quite simple things in english

Wait and see... the createTube will be as easy to use as in the former playground examples.

 

And yes, with parametric shapes you can redo already existing basic shapes ... you can redo a torus or a cylinder with a tube, you can redo a sphere, a box, a cylinder with a ribbon, etc

But why entering the parametric world since these easy basic shapes are still available ?

 

I would use the BJS sphere to display a sphere.

And I would use a  ribbon if I want some complex version of a sphere, ex : 3/4 of sphere slightly stretched on its pole with double-side light reflection

[jerome]

both (createTube and Path3D) PRed