Selecting an object and moving it on the screen in X,Y,Z

[Alby]

Hi guys!

Again me with my lot of requests.

I "just" need to move a  selected mesh and all the meshes attached to it (but with those meshes remaining attached to the other objects they are bound with, hope to be clear in my explanations) in x,y,z : (http://playground.babylonjs.com/#12ZRI0#5)

I think a soluce to do it could be

• Picking the object I want,  so I can have the position (X0,Y0,Z0) of it (and the bounding point of all the other meshes attached to it)
• Translate this in canvas coordinates (http://www.html5gamedevs.com/topic/9584-converting-3d-vertex-to-2d-point-on-screen/?hl=coordinate#entry77509)
• move the object in mode canvas in X,Y plane with my mouse (http://www.babylonjs-playground.com/#12ZRI0#5) and in Z (using the 'Z'  key + mouse)
• Calculate and translate all those X,Y "canvas" moving (Xoffset and Yoffset - in mode just mouse) and Z moving (Zoffset - in mode 'Z'+mouse) back in 3D coordinates
• The initial coordinates become then X0=X0+Xoffset, Y0=Y0+Yoffset, Z0=Z0+Zoffset and all the others coordinates remain unchanged
• Redraw all the scene

Is my reasoning good?

First I tried to adapt in (http://playground.babylonjs.com/#12ZRI0#5) to suit my needs, inspiring from the demo (http://playground.babylonjs.com/?18)

But already there I encounter some problems and didn't understand very well the need of a ground  to operate it:

When I click by example on "a bedouin", all the tubes attached to it move but "disconnect" from others objects they are attached (sphere, box)
When I click on "Mona Lisa" the tube connected with "a bedouin" doesn't move and but the other tube disconnects too from the other object to which it is attached (sphere)
In those cases the text  move with the box picture

But When I click on the text under a picture box even it is a child of the box it belongs to, it has a strange behaviour when moving and the parent box doesn't move anymore with it.

So wondering what's happening?

Can somebody give me some light?

Thank you in advance!

[Wingnut]

Hi A!  Just a quick note... good experimenting!  I'm seriously impressed!  You're quite near success with drag positioning. 

 

I had some comments here earlier, but they were SO ill-informed and poorly-researched... that I erased them.  You won't miss them.  It was a crappy reply.  I'll do more research and then do a better reply.  Meantime, others will surely have things to say (in theory).

[Alby]

Hi Wingy, sure  you must be a legend in this forum, the Savior who rescues all the lost souls in babylon's city (In addition you are a time traveller, babylon is more 4000 years old, isn't it? in what version are we today, Babylon v352.5? )

 

Any way once more thank you for your precious advices!

 

Just another question for a newbie "developper":

 

http://www.babylonjs...d.com/#12ZRI0#5

 

Lines 91-95

 

I define a array of boxes containing all the data of my boxes : var TabBoxes=new Array;

Lines 112-117

 

I begin to read in my array of boxes to create "independant" boxes I can move, edit and so on

I say to my self I will create  at each read in my loop a box with a new name variable "box+i" ,( I mean var box1, var box2, and so on) but I seems I cannot create it dynamically that way (or maybe a wrong syntax?)

 

The problem lies in that I wish, to create interactions like draw, suppress tubes, labels between some of those boxes, or when all the editings of the boxes of my "little museum" are done, how to put them back to my array TabBoxes, each box must have a different name (var box1, var box2, and so on) and not  the same name : var box to be recognised as different.

 

On the screen, I can select those different boxes; it means babylon knows which they are even they have the same name (var box) or maybe on the creation of those boxes, when the label name changes, it knows it is a another box?

So how can I know the box on which it works  so I can handle it easily to put it back in my array TabBoxes.

 

Hope to be enough clear in my explanations. I m sure the soluce it is so easy that I didn't find it (where are my glasses?... oh they are on my face!) or maybe a little dump?

 

Thank you in advance, Wingy, take your time, I know you have other users in distress to rescue!

[GameMonetize]

Wingy is our Savior, I can confirm that!

[Wingnut]

hehe.  Oh geez.  Hardly.  Alby Alby Alby.  What are we going to do with you? 

 

Ok, step 1, do not try to change the VAR names dynamically in a FOR-loop.  In other words...

 

var box+i = blah;

 

Don't do that.  You're going to hurt Javascript. 

 

BEFORE the loop...  var box;

 

Then don't use var box inside the loop ever again.  Just use...

 

box = BABYLON.Mesh.CreateBox("box"+String(i), size, scene);

 

We don't care if the 'box' variable gets re-valued over and over with different boxes.  We care that each box.name is unique, and it will be.

 

But let's go on a little trip, Albs. WHAT IF... your FOR loop... looked like the one in THIS PG...

 

http://www.babylonjs-playground.com/#12ZRI0#8

 

No big deal.  Minor modifications.  BUT... look at the FOR loop.  The word 'box' has disappeared!  And look where the real bjs mesh is stored...  on the TabBoxes object... in its .mesh property.  We placed the BJS mesh... into the Boite object's pocket that we named .mesh.  With me?  WE made Boite's .mesh pocket and we stored a BJS box in it (in one line).  Easy.  When it's in Boite's pocket, it's handy... and it will travel along with Boite, and us.

 

You might also have noticed that I put a .owner pocket on a BJS box object!  Wow!  Overloading!  We took a BJS box... which already has properties (pockets with values/data in them) and methods (pockets with CODE in them)....  and we added our 'own' pocket called .owner with the value/data of that property... being TabBoxes...  a Boite!  (hell of a sentence, eh?)

 

So, the Boite knows its mesh... it's safe in its .mesh pocket.  The mesh knows its Boite... its "reference" is safely stored in the mesh.owner pocket.  Boite knows how to find its mesh... and mesh knows how to find its Boite.  Cooooool, eh?  We just made Boites... a lot smarter... didn't we?  (and we made BJS boxes a bit smarter too, by adding .owner).

 

(Notice that I said "reference".  That is simply to get you to read about byRef and byVal, someday.  Those terms have to do with the way in which certain programming languages... store objects in pockets and vars) 

 

You can still FOR-loop-thru TabBoxes[] array anytime you need-to.  You can do things to each TabBoxes.mesh... like set materials and change colors... anything.  You just don't call it 'box' anymore.  It is now called TabBoxes[somenumber].mesh.

 

Weird, eh?  The backgroundTitre for each box could be done the same.  Add line 29... this.backgroundTitre = 0; 

 

Then... inside the loop, likely just after you complete the setting of TabBoxes.mesh, you could (again) do...

TabBoxes[i].backgroundTitre = BABYLON.Mesh.CreateGround("backgroundTitre"+i, TabBoxes[i].size, TabBoxes[i].size/3, 1, scene, false);TabBoxes[i].backgroundTitre.rotation = new BABYLON.Vector3(-Math.PI/2, 0, 0);  TabBoxes[i].backgroundTitre.position.y -= TabBoxes[i].size/1.5;  TabBoxes[i].backgroundTitre.parent = TabBoxes[i].mesh;  TabBoxes[i].backgroundTitre.material = new BABYLON.StandardMaterial("background", scene);  TabBoxes[i].backgroundTitre.material.diffuseTexture = new BABYLON.DynamicTexture("dynamic texture", 256, scene, true);  TabBoxes[i].backgroundTitre.material.diffuseTexture.hasAlpha = true; // needed if you want a transparent drawText background  TabBoxes[i].backgroundTitre.material.specularColor= new BABYLON.Color3(1, 1, 1);  TabBoxes[i].backgroundTitre.material.backFaceCulling = false;  TabBoxes[i].backgroundTitre.material.diffuseTexture.drawText(TabBoxes[i].titre, null, 135, "bold 30px Calibri", "yellow", "blue");  TabBoxes[i].backgroundTitre.material.diffuseTexture.vScale = .2; // taller!

(mistakes likely)  Look at that!  We just made ANOTHER pocket on ALL our Boite objects (which are stored in the TabBoxes array)... and it is the .backgroundTitre pocket.  Inside that pocket is ANOTHER bjs mesh... a groundplane that is being used for the titre.  YAY!  Now our Boites are REALLY getting smart!  They carry their 'box' in their .mesh pocket, they carry their backgroundTitre in their .backgroundTitre pocket... and there is space for LOTS more smart, yet. 

 

Do ya FEEL it, Alby?  Do you feel the electricity starting to gather at your finger tips?  That is the start... of the "zen" of OOP!  (like I'd know?)

 

AND... what if... you added THIS line... as the LAST line of the CylinderBetweenPoints function...

return cylinder;

Then what?  Our stride/span/radial (tube) has been returned to us... after the call.

 

In the FOR loop, line 139....

 

TabBoxes.tube = CylinderBetweenPoints(redSphere.position, TabBoxes.mesh.position, "Tube"+i,1, scene);

TabBoxes.tube.material = blah;

TabBoxes.tube.showBoundingBox = maybe;

TabBoxes.tube.material.diffuseColor = whatever;

[...]

 

OMG!  Did we just make our THIRD new pocket on Boite, called .tube, and did we put a 'returned' BJS cylinder into that pocket?  Yes we DID!  Now Boites are getting REALLY smart, and have pockets full of things they will need on their journey!  Yay!  We don't want to send these young Boites out into worldSpace without preparing them, correct?  (they need proper beatings). 

 

Isn't it cool... how you can have a single Boite in your hands, yet you can use it to reach SO many other things... in its pockets?  We can reach TabBoxes[somenumber].mesh and .mesh.material.   We can reach TabBoxes.backgroundTitre and .backgroundTitre.material, and we can reach TabBoxes.tube and .tube.material.  We can GET values from those pocket objects (peeks), we can SET values (pokes), and we can run methods (calls).  (method = code stored in a pocket, remember?)

 

Can you think of another?  TabBoxes.sun = redSphere;

 

Notice we didn't create a redSphere for each Boite, but we set a "reference" back to the already-created redSphere.  Boite just got smarter. He now knows which sun he is orbiting.  Coooool. 

 

Ain't this fun?  A quick reminder;  I could be teaching you some TERRIBLE programming habits and I wouldn't even know it.  But this "feels" like Temechon code... and he's an OOPmeister, so I think we're headed in a good direction with this.  How's it "feel" to you, A-doggy? 

 

As a last note, you should understand that an object is a type of value.  AND... a value... is often/always an object.  A vector3... is an object.  The number 3.523   ...   is a floatingPointNumber-class object.  Try to keep your definition of the word 'value'... real flexible.

[Wingnut]

By the way, Alby, I don't know WHAT the heck you did to that poor ArcRotateCamera in #5, but it's broke REAL GOOD.  It acts like the whole scene (except the skybox) is parented to the camera!  How did you DO that?  I couldn't find a place in that demo... where you caused that.  Thus, it's still acting retarded in #8.  I couldn't fix it.

 

Interesting.  That ArcRotate is not acting ANYTHING like an arcRotateCam is supposed-to. 

 

How'd you do that?  I've never broken anything in such a cool way. 

[Dad72]

Hi,

 

Look from line 180 Wingnut for your question on arcRotateCamera.

This is done when clicked on ground, if you click on the sky, the rotating camera that behaves like it should. 

[Alby]

Really Wingy, you should write a book about "Babylon and object programming" for dummies, it will be a hit!

Thank you again, again, and again!

 

Just the time to digest it and I will go further... no more requests I promise!... (Waw, what's happening my Pinocchio nose is growing longer and longer!)

 

About the arcRotateCam , don't remember where I found it but surely I played with it like a sorcerer's apprentice, changing some parameters to see what's happening (empirism learning ! ) 

I noticed also like dad72 when I cliked on the sky it was working correctly; assume it was logical, isn't it?

 

So, see you on the next episode!

 

PS: By the way some more evolution in our plane label orientation by Jerome http://www.html5gamedevs.com/topic/14349-meshrebase/

It seems for me like chineese translated in arabish, but for you it will be like crystal water, isn't it!

[Dad72]

Je vais expliquer en français pour faire simple.

 

la cameraRotative devrais réagir comme quand vous cliquer sur le ciel même en cliquant sur le terrain. si cela na pas été un choix, cela n'est donc pas normal. je voie que vous désactiver le Control de la camera quand vous cliquer sur le terrain ce qui produit cela.

 

Bonne continuation.

[Alby]

Merci dad72, une lumière de plus dans ma lente compréhension de babylon.... on y arrivera!

[Alby]

Hey, Wingy, your nightmare is back!

 

This night I thought maybe another way to move an object in x,y,z in a more "simple" way (for the user, not for the developper... or maybe yes   !)

 

 

So lets'go, the party is on (I know you like babylon parties!)

 

 

I pick on a object... what's happening? it is frozen on the screen, I mean the coordinates in x, y in canvas remain blocked on the screen and so visually the object.

 

And now  when  I move my mouse like it was a  cam as usual ( zooming, rotating, and so on), it is  like  visually the objects   are   moving (relatively to the point of view of my frozen selected object) , except of course my frozen object (obviously all the objects bounded to my frozen object remain connected to it)... it is like the frozen object becomes the cam, but in reality it is the frozen object that is moving in space! - hope to be enough comprehensible!

 

When I feel visually ok with the new positions of my frozen object, I pick again on it.... and it is "defrozen" .

Now if I move my mouse all get back to normal (camera move)

 

So I moved  my selected object where I wanted in x,y,z even if visually it didn't move on the screen (moving without moving! ).

 

But what are the new space coordinates of this object?

 

 

I feel already Wingy brain is boiling.... first to understand my tangled explanations   and then to imagine how find a soluce to it .... Watch out not to be scalded!

 

 

PS: I think we could create an object in the same way clicking somewhere on the screen: we have then canvas position in x,y  and then we can extrapolate from the canvas coordinates the position in space  in x, y, z...of course one of this coordinates (y,z?) should be considered belonging to the cam plane perpendicular of the vector cam that goes from the cam to the point on wich the cam is focused, otherwise there will be endless of possibilities of the space position of the object I wish to create on the point defined by my canvas x,y clicked point, isn't it?

 

This way we could have" universal" "events functions" (move,rotate, create suppress, scale... any kind of object selected) usable for everybody wishing editing  a basic universe in  3d on screen...am I a dreamer?

[Wingnut]

Yeah!  Great ideas!  You are already seeing scene.detachCamera() calls.  That will kill camera drag-panning in the blink of a viewMatrix.

 

It all starts with learning what is happening in onPointerMove function.  Is it being called repeatedly as the mouse drags?  What value do you see changing as these repeated calls happen?  How can I use this value?  These are the things a person COULD ask themselves. 

 

And then there's Actions.  The ActionManager can do picks, but it picks BJS shapes.  I have never seen Actions used to drag anything, I don't think.  An ActionManager CAN do click and then-click operations, so it could do click on mesh, then click on ground, and if wanted, animate the position change with an interpolator/easing-func.  (automatic animation between startingPoint and moveToPoint).  Two clicks.  No dragging.

 

Yep, become a master of onPointerMove().  Become its best friend.  Last night, I worked on someone's issue... trying to replace the addInPlace with a moveWithCollisions.  This user wanted drag-positioning with collision (don't let mesh overlap).  I failed, so far. 

[Alby]

Night gives inspitation!

 

...Wingy, maybe another way for creation or moving an object  in space more easily could be  :

 

• in creation mode : the cam coordinates become the position of the object... we move the cam everywhere we want as usual; position of the cam seems ok  for the position we wish to create... right click on the mouse (or anything else,could be a key click) : Magic! all the scene is redrawn, the desired object  appears at the place of the cam and takes the same coordinates of the cam
• In moving mode : selection of the object we want, the came takes the coordinates of the object; after moving the cam its position seems ok  for the position ... right click on the mouse (or anything else, could be a key click) : Magic! all the scene is redrawn, our selected object appears at the place of the cam and takes the same coordinates of the cam

This done, the cam works as usual.

 

• The pros : we have not to torture our brain to elaborate a dance choregraphy of quaternions, rotations and other funny things     : all the moving stuff of the cam are already there
• The con :  First, visually it will a little disturbing in moving mode because after selecting the object the cam will jump instantly at the position of the object (or maybe we could do a slow motion from the cam to the object to avoid it?); second, when we approve the new position we will be inside the object when it appears (maybe we can  can give another space position to the cam, so it will be positioned outside the object at a certain distance - in%: if the vector cam -focus point is 100% then put the cam at the on the same vector but at 120%, also  in slow motion); third, we are always inside the object (even invisible when our camcreator is moving until we agree with its position), no stand back.

What do you think about it? More easy to develop? Or maybe did you find a more convenient way?

 

I love functions!

 

FunctionCreateObject(IdObject, type,x0,y0,z0)

FunctionMoveObject(IdObject, type,x0,y0,z0)

If x0,y0,z0 are null or type-0, it is our "camcreator" we use!

FunctionRotateObject(IdObject, type, DeltaX,DeltaY,DeltaZ)

If type=0 it is the mouse that manages our rotations

 

 

 

 

Have a nice WE, Wingy, God bless our Savior!

[Wingnut]

And, to the OTHER people who could ALSO answer this question... have a nice weekend, too.  (and you, too, Alby!) 

They (whomever the THEY are) make a program that allows "visual editing" for webGL scenes.  It's called Blender.  And there are 4 other scene editors that I know-of... but they are written in JS, so it's a challenge to SAVE scenes made with them.

I think you should test your ideas, Alby.  Here is a demo to test your theories, which you could make, too.

http://playground.babylonjs.com/#2EED66#2

2-eed?  tweed! 

In this demo, I have set cam speeds and inertia much lower, and I have set greenbox.parent to be the camera.  SO, the green box has the same .position coords as the camera.  Or does it?  Check your console.

The green box has its .backFaceCulling set to false, which means IF the camera goes inside the half-transparent green box, we will see the scene through a green tint.  Now pan that camera around, and see that the camera lens is sometimes inside the green box, and sometimes outside.  This makes no sense, correct?  If the green box is parented to the camera, the green box should position and rotate WITH the camera, and the camera should NEVER be intermittently in/out of the green box.

Is this a bug?  No.  This is nominal (normal) behavior, because... when parenting to cameras or lights, mesh only inherit .position but not .rotation or .scaling.  (What goofy person would try to scale a light or camera anyway, eh?) 

This unique behavior for parental lights and cams... is un-documented, and soon you will create or edit a wiki document and tell folks about this.  Right?  You bet. 

You can see in line 18 that the greenbox is sized VERY precisely.  The size of the greenbox... and the way the camera is inside/outside... tells us that cameras are about 1,1,1 in size, even though they are invisible.  The reason the camera is inside/outside during pans, is that the greenbox is NOT rotating with the camera.  It is only .positioning with the cam.

The greenbox IS positioned with the camera... even though the console says otherwise.  The numbers in the console don't match... because when greenbox gets parented to camera, its .position numbers are not changed.  BJS still says the box is positioned at 0,0,0.

cam pos: x:0.00 y:5.00 z:-10.00   greenbox pos: x:0.00 y:0.00 z:0.00

As you surely noticed, it is quite difficult to see the box... when the box is at the same .position coords as the cam.

Now activate line 25 and hit RUN again.  We'll move the box out in-front of the camera.

Hey, there's greenbox... and we can see it... badly.  Here's your chance, Alby.  Drive the camera until you have placed the greenbox... nice and aligned... atop the red box.  Ready?  Go!

(7 years pass)

Having troubles aligning greenbox to redbox, with only one camera angle and no help from mathematic auto-aligners (or snaps), Alby?

Ok, now let's see how long it takes CODE and MATH to place the greenbox perfectly on a corner and perfectly rotated 45 degrees (stand the greenbox on a corner).  http://playground.babylonjs.com/#2EED66#3   Notice lines 25 & 26.

Ready?  Set?  GO!  2 lines of code.  I win. 

How long would it have taken you to place greenbox in perfect symmetry like that, using trial'n'error 'visual' mesh positioning?  A couple of years, maybe? 

Your "mechanical arms on the camera to manipulate mesh" -idea DOES have merit, of course.  (ok, I bastardized your idea a bit, with that comment, didn't I?  We'll speak more of bastards... in a moment.)

This is a job for "modelers" and for "tools" built-with BJS, but these "scene layout assemblers" like you describe... are not supposed to be built-into the framework (by definition).  I'm not saying that the definition of a "webGL framework" might not change in the future... it certainly could.  But professional programmers and IT folk tend to keep their definitions rather strict, and they might call a modeler that is built into a framework... a "bastardization".  They might say "If there's a modeler or scene-layout tools built-into the webGL framework, then it is no longer a framework, by definition".  AND, they'll claim that the framework is unnecesarily bloated with crap that THEY don't want in a webGL framework.  They'll say we "overloaded" the framework.

You saw my TriGrid, right?  That's the start... of a visual modeler, with POSITIONAL snap/auto-align possible.  (snap to grid lines, as Dbawel and I were recently discussing).  This doesn't help rotation a single bit.  Rotational snap/auto-align requires something like TriRings, and a person could use the camera's mechanical arms to spin the object in 1-degree snap-graduations... and that MIGHT make visual rotation aligning easier.  I dunno.  Ask the folks who wrote Blender.    Visual rotation tools... ouch!  Jerome is experiencing that pain... right now.    (But I think he loves that kind of pain, thank goodness for us/team!)

Take a drive in Blender when you get a chance.  See how they use a combination of visual scene layout and math-based alignment and snap tools... to build a tolerable scene-layout system.  It's not easy (to code Blender).  MANY people are seeking better tools to do scene layout, and Alby, your idea is a fine idea.  You should build it!  Watch out for SAVE... that's rough water.

There is one last problem with your idea, and with advanced versions of Jerome's system, too.  Let's say... Jerome eventually perfected his aligner... and attached the TAB button to it.  Once you start his function(s), you just keep hitting tab until you get the alignment you desire (possibly 20+ tab hits). 

After a number of tab presses, Alby says "Perfect, this is EXACTLY how I want these text planes to be rotationally and positionally aligned.  Yay for smart auto-aligners!" 

And maybe Jerome's aligner (reBase()) is not enough of an off-topic-for-frameworks tool... to get labeled by mean people as a bastardization.  Yay. 

But now Alby needs to have the code lines... that CAUSED that perfect alignment.  So, while hitting those TABS repeatedly during Jerome's auto-aligner, Jerome needs to be printing-out code lines SOMEWHERE, so that when Alby finds the perfect alignment, he can install those lines PERMANENTLY in his project code.  Alby, you NEED that perfect-alignment code... printed to you... from Jerome's tool... so that when you SAVE your scene and run it again later, the alignment is still there and correct.

With me?  Now, Jerome's Choose-an-alignment tool (which is NOT what he is building, but could)... is starting to look like a bastardization, eh?  See any other BJS tools that need to report code lines back to the user, so they can paste it into their source code?  No... not even close.  So, now, the Choose-An-Alignment tool has become an "inappropriate" tool for a framework.  But again, it's not an inappropriate tool to build WITH the framework.

And none of this crap... helps Alby get an easier scene-layout tool, visual or not. 

Yep, you have great ideas, Alby, and the folks at Blender.org have apparently been listening to you, for they have built those tools into Blender, and it's darned free.    Do you dislike working with .babylon files?  If so, I'm with ya. But I must say that JcPalmer's Tower of Babel exporter... has helped relieve some of my dislikes.  He and other experts are SUPER-close-to allowing live-editing of BJS scenes... with Blender.  And Dad72 is right on the cusp of live-editing with his CastorEngine, too (but it needs a server for SAVES).  And, our very own playground is a fine editor, as well.  DB provided by DK, thx bud!

Your issues are common, Alby.  Your ideas are fine ones.  I'll help you code these tools, if you like.  So will others, if you include them in your posts/questions.  Be sure to put "(and others)" after every time you mention my name. 

The forum spanked me for too many smilies. 

[Alby]

Hey Wingy, you are too kind, sometimes I'm wondering if you sleep, seeing your activity in this forum, are you a robot (a BB-8 droid from star war?) or a human?

 

Would you not exist, somebody should invent you! you are a bliss for newbies (and why not for others too with your unique sense of humour!)

Thank you for your infinte patience to explain us (newbies) some arcana (and  often basic notions ) of babylon!

 

I'm just beginning to digest your previous intervention about arrays , now again some more to assimilate, waw, my brain is going to fire for a few days, fortunately I have a fire extinguisher just near me!

 

Really your are helpful to my project, it consists in a kind of 3d mindmap where every user will be able to put in a structural way the informations (s)he wants to save.

So no need of too much sophisticated 3d to manage it, but the most easy and natural way  to use it in 3d.

A child of 8 years should be able to manipulate it, so everything should be the most user friendly possible, creation, edition, and manipulation of his (her) 3d mindmap

And often the most easy it is for the users,  the most complex it is for the developper, isn't it?

 

That's why I want to create some 3d functions (events, manipulations, and so on) I can after easily assemble to make some macro function suitable to my needs.

I have some ideas (fortunately!) how to do it but not yet the level to create it without help of some big brothers , that's why I bombard you with my requests, hope you will forgive me my big brother Wingy!

 

So again, to ALL those OTHER people who could ALSO answer to my questions, wish you a nice WE (including Wingy!)

 

Be well!

[GameMonetize]

I can't agree more: Wingnut is a gift for newbies and people who want to learn babylon.js

[Wingnut]

 

That's why I want to create some 3d functions (events, manipulations, and so on) I can after easily assemble to make some macro function suitable to my needs.

 

That is an EXCELLENT object oriented (oop) thought.  Reusability.  Universality.  Generics.  Sub-Classing.  Toolbox.

 

Personally, I'm lousy at all those proper programming policies, but I still keep trying to apply them.  Yep, Alby's thinkin' he needs a toolbox of personal goodies to help him take over the world. 

 

I like your thoughts on your project, too.  Thanks for giving us a little more insight to the big picture.  It sounds perfect!  You'll need a database eventually, to store everyone's 3D MindMap, but... yeah... delicious idea/project.  I think there's a ton of folks using NodeJS as their server interface. 

 

To clear-up some possible confusion, NodeJS servers are NOT the same thing as the node-serving that I have talked about in other forum posts, (a cms/webserver combo which serves html 'nodes'... little pieces of data wrapped in an html document) 

 

Nope, NodeJS is something else...  and the best way to describe it is.... Holy Cow, Batman! 

[Alby]

I should say of course high level 3d functions! A few "lego" pieces to build a cathedral or a little house in a few hours, "Babylon's lego" for little children (but sometimes adult too... if they exist! )

I think some 20 little pieces will be enough, if you combine them together you can have a lot of macro pieces!

And of course simple pieces that can be used by everybody and remains public, it should be very selfish to privatize them!

Of course I'm aware such a tool has its limits if you want create some highly sophisticated objects, you have to create it with 3dmax and cie and import it afterwards, but, I think, they manipulations could be made more easy with these high level functions.

 

 

"Build your own 3d application in 3days! ;)" .... a technological showcase for Babylon!

Babylon is not just a tool to build games, but also sophisticated 3d applications, I'm convinced of it!

 

By the way an idea to avoid maybe that kind of joyfull rotations that make nearly Jerome mad , if when we select an object that we want to move, why not let him on his place but when we move the cam, a line is drawn from the object to the cam in real time, and when we agree with the position by trigging an "ok" event, slowly our selected object move to the cam position..., just an idea.

 

In a brain storming there is often somebody who knows nearly nothing about the tools and difficulties  to reach a goal, in french we say a "candide", and sometimes with his (her)" fresh" point of view (s)he find sometimes a trick never thought by the experts... I pretend not to have genious ideas, but the possibility to have one, beeing not conditionned by the tools

 

So, tomorrow, I will plunge again in Wingy demos, trying to decrypt them, fortunately we have .our beloved Champollion Wingy, the perfect traductor between babylon and  human language!

 

Be well

 

Candide Alby

[dbawel]

Sorry to recess, but I just read this post for the first time today.  I laughed out loud  when I read in Alby's code:

 

Var box+i = BABYLON.Mesh.CreateBox("box"+i, TabBoxes.size, scene);

 

However, when I thought about it, this was very amitious, and I wish we had this ability in JS as it would optimze the code and is very easy to understand.  I can also see the possibilities to write complex variables.

 

Well done alby. 

 

DB

[Alby]

@dbawel : I try to do my best!

 

Hey Wingy, could you not fulfil Dbawel wish? ... a little erffort here ! (Yes, we can! )

[dbawel]

Good luck with that...

[Alby]

Hi guys!

 

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

 

Here are my last "flights of fancy" in the evolution of my project with my trial and error learning process.

 

So, what I try to do is: changing the coordinates of an object and redraw all the scene with the new coordinates of the object and all the objects linked to it.

 

So I say to myself I will create a function that will redrawn a part of the scene of all the objects that are allowed to be changed in they coordinates x,y,z (var RedrawPartOfScene = function() - line 27)

 

In my naivety and ignorance I thought it could recreate the part of the scene I wish by changing the coordinates of one object - line 549 and calling after my redrawPartOfScene function.

But it but I noticed it just creates another one on the previous (using my ObjRotate  function- thanks to Wingy -  to note it) 

 

so I wonder how to solve that problem:

• erase the previous part of scene that can be redrawn and then using "my" redrawPartOfScene function  (or erase all the scene, then I have to redraw it all).
• another way to redrawn the scene with the new coordinates object AND the linked objects (because it seems it is only the object that moves when I change its coordinates not its linked objects - in this case some tubes), some help?

Any advices?

 

Thank you in advance to help a babylon puppy !

[Alby]

Another way I  thought for moving an object in 3d (in x,y,z) :

 

When we select (pick) an object we have its coordinates in x,y,z, no need to have its canevas coordinates.

 

Suppose when we click on the object we put somewhere in a var its position and the position of the cam.

We move the cam as usual plus draw  a line between the cam and the selected object in realtime.

After an event-triggered meaning we agree the new position  we add to the position of our object the DeltaMoveX, DeltaMoveY, DeltaMoveZ of the cam and we have the new.position of the object, isn't it?

 

Redraw with the future solution  of the post just before (hope! ) and the object is put in his new position, job is done.

 

irrealistic?