Box rotation

[Alby]

Hey Wingy. Good news!

 

http://www.html5gamedevs.com/topic/14209-dialog-extension-finally-released/

https://244a9fff025c7296f2ddf7c036e4d41ea347a953.googledrive.com/host/0B6-s6ZjHyEwUfjlzYXJKMC1zLXdIaV81REJhbjdfRmczQTJFOEpjWWg2SUIwZVRRS0VsR28/

 

Sure we can surely use it... but if I read (and understand) good , input mode not available

 

... so Wingy.html always needed !

[Wingnut]

Hi Alby!  You're too funny!!

I'm a bit swamped right now... trying to clear and sell my parent's house.  (Can you say near-continuous yard sale?).

Take a look at a modification of my latest Wingnut Chronicles demo... http://playground.babylonjs.com/#1VXHZA#3 

Lines 66 thru 84 put the input box into the BJS scene.  Somebody recently taught us (in the forum) how to use "vec3.project" to get the screen x/y coords of a mesh.  That could be used to set the top/left setting on that input box.

(Please ignore/remove line 68.  It's for iframe, img and maybe embed DOM elements)

(embed? as in BsPlayer?  As in... let's watch an episode of Green Acres while we code?  hmm.)

Back on Earth... um... we have ActionManager to do click-trigger/executeCode-action (put an actionManager on every picture)... and in the executeCode... create a "dynamic html" input box... just like the demo above.

Now, to GET the .value of the input box... and DO something with it (after the user hits enter)... is anyone's guess.  We'll talk about that later... I suppose.

And remember that DOM nodes such as input... use their top left corner as their location reference point.  So, input boxes will appear down and to the right of the picture... unless you establish an offset based on the input box width and height.  (duh?) 

Ok, that should get the juices flowing.  Get your picks (clicks) working, learn pickingInfo objects well, and start feeding values to inputbox.style.left and inputbox.style.top... see what happens.  You will not be using percentages, so remove the '%' and instead use 'pt' or 'px'.   I'm not responsible for explosions.    Remember to kill all the html you create... using the scene.onDispose() function.

You'll KNOW if your onDispose() is working... when you choose a pre-made demo scene in the playground (such as Basic Scene).  If some of your html is still on the screen after choosing a pre-built scene, you haven't done enough disposing yet. 

Good luck!

[Wingnut]

Geez, I didn't really want to go here, but I had too much coffee this morning.

 

Ok, um... think about this, Alby.  A BJS plane... is an object.  Once you create one, it displays in the scene.  But WHAT IF... you made your own createPlane function.  YOUR createPlane function is an object factory... sometimes called a wrapper.  You have "wrapped" the creation of standard BJS planes... with your own createPlane function.  It is an AlbyPlane maker.

 

Let's say that the FIRST thing your function does... is create a standard BJS plane, and then does plane.setEnabled(false);  (or plane.visibility = 0;)

 

So, you have this object in your hands... a non-displayed BJS plane object, and in the next line of your function... go crazy:

object.actionManager = new BABYLON.ActionManager(scene);object.makeFrigginInputBox = function(name, styleObject, DomAttributes) {    blah blah foo;    destroy(planet);};object.isHTMLShowing = false;object.getValue = function(node) {    [...]};object.AlbyReport = function() {    this.createGiantHTMLTableReportAboutThisPlane(this); // TOO smart?  nod.};

etc.

 

This is called "overloading" an object.  Some call it "value-added".

 

All of the BJS source code... uses this method.  Make an object (sometimes fresh, sometimes a pre-stocked starter, like yours)... and start adding methods and properties to customize this "plane factory".  You want your plane factory to produce SPECIAL planes that know how to make HTML on themselves!  Wouldn't that be COOL!?

 

This is a OOPy Temechon-ish way of thinking... (he didn't invent it but he is a worshipper of smart objects like this).  Of course, it's also a Deltakosh-ish way of thinking... just look at the structure of BJS.

 

AlbyPlanes... your ONE STOP for over-powered ridiculously smart BJS-grade planes.    A good candidate for your new library-o-functions, eh?  Library-o-objects?  hmmm.  Be well.

 

PS: Next year, when Microsoft Paris finishes our BJS-Scene Virtual Reality server/mud (in the cloud), we can take my jetboat over to Overloader's Bay and check-out all the retarded BJS objects and functions that folks have created thru the years. (ahem)  We can pipe data through them... via pipe connectors in the front yards of our VR homesteads.  AND, I have pipe connectors on the jetboat!  Cooooooool.  You've NEVER seen code "includes" that were THIS much fun!    "Everyone... look up!  I'm about to totally screw-up the skybox!"  (Messing-with the weather and the community-wide skybox... is one of the funnest things to do in the new Babylon Bay Virtual Reality Worldserver.) (dream and drool)

[dbawel]

Hey Guys,

 

Wow, I can't believe this topic is still going!  Although I haven't read through all 4 pages, it appears you have moved on from the topic of box rotations.  I did finally get around to working with some of the posted scripts, and came to a couple of conclusions: I can't see how Billboard mode as a function in BJS can provide the behavior in which alby is seeking; and I dont see any modifications of any other scenes posted here which will provide the desired behavior by the boxes.  I would also avoid setting a camera limit, as I don't believe it's a solution, but simply a band aid and a limitation to any scene.

 

What is required is a directional constraint.  I requested this on the requested features pages, but am the only one asking for this so far.  Perhaps alby might be the 2nd which would be great.  If I have time, I'll get around to writing this, as it's an essential tool I use often.  Once it's written, I would expect it to go into the BJS framework as a function.  It's reasonably simple: define a vector between the local axis of the mesh to be contstrained (the box,) and the local axis of the source object (in alby's case the camera.)  Then using quaternions to define rotation, align an single axis of the mesh to this defined vector.  

 

Again, when building scenes in 3D software packages, I use this constraint more than any other.  It is valuable in so many cases such as controlling gimple lock in cameras and other objects, and to keep bones from flipping by aligning them to a child of the bone's parent (called an up vector constraint.)  So I hope someone builds this in the near future, otherwise, I'm sure I will when I get time - as I'll certainly use it often.  It's not that difficult, so if anyone else wants to spend a couple hours building this, I'd be grateful.  Otherwise, I'm sure I'll write it soon.

 

Cheers,

 

DB

[Alby]

Thank you, dbawel, to have taken time to think about "my" problem, you seem to have a particular good 3d mind developed (like other guys who haunt this forum!... ghost Wingy is one of the  most terryfying   )

For experts it surely easy to grasp the sequence of rotations, quaternions, around different axis but it gives me dizzy, too many rotations and quaternions !

 

I'm still in the grade school in babylon's discovery... but "Think big, but start small", I hope to be able in few months to follow easily your explanations, so forgive my present dump mind

I feel happy  that you find it very useful for you (and so for others too) even thinking to transform it in a function for BJS.

 

By the way I try to collect functions  : http://www.html5game...eated-by-users/ so if you have some in your pocket you find useful, feel free to add them on that post so  everybody could benefit of

 

I wish I could help a bit in the elaboration of such a function but now I feel a bit overwhelmed, just observing and trying to understand...

 

Anyway, thank you to give the way to the soluce!

 

PS: Is it possible to change the name of the post, because as you noted it, it doesn't speak just about box rotation!

[Wingnut]

Ok, let's get serious about box (text plane) rotation.

 

First, for fun, let's look at the pictures that arrive... when we do an IMAGE search for "Spherical coordinate system".

 

http://tinyurl.com/opaby7x

 

Now let's look-at and then ignore the Wikipedia definition of "Spherical coordinate system"...

 

http://en.wikipedia.org/wiki/Spherical_coordinate_system

 

Now let's look at my goofy star globe...

 

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

 

Particularly, let's look at lines 405-427

 

See the getCart (cartesian) and plot1 funcs?  Sure you do.  These convert spherical coordinate, to cartesian coordinate (and do a point plot).

 

Think about each point on the sphere...as one of your pictures, Alby.  Then envision a line traveling through each picture-point... back to the center of the sphere.  Now do you see why I say that the pivot point (or at least one end) of your text planes... should be located at the center of the sphere (even though the text planes currently don't extend to the sphere center)?  In a way, we could say that the "invisible part" of the text planes.... needs to extend all the way to sphere center. 

 

This is why I once questioned placing pivot points of planes... anywhere in space (Do pivot points on planes need to be within the mesh's volume/area?)

 

This question is not yet answered and I have never tested this... because Gwenael's pivot point tutorials were done on JsFiddle's that never worked for me.  (pinned thread even).  There's things to be learned, there.

 

Back to our story.  That invisible line extends from the sphere's center, through every star on my star globe... and beyond... out into space.  Each of these "star rods" has/is a "direction" vector... and it is those direction vectors that can be used to align your text planes.  We need to figure out how to apply spherical coords to your project... and the code in lines 405-427... hold the secret, I suspect. 

 

Essentially, you would no longer place the picture somewhere in space, and then try to hook a plane between IT and the sphere.  Instead, you will tell a function the rho, theta, and phi... of the "picture-rod", and the function would create a textplane rod at some angle and extend some distance from the center sphere, and place a picture at the far-end of it. 

 

rho, theta, and phi.  Get to know 'em. 

 

Alby, you present us with a GRUESOME challenge, not bad for a newbie.    How long has this baffled us?  Nearly forever now?  Yep.  It's a big dog challenge.  Maybe we need to say goodbye to MOST-of the somethingBetweenSomething() function... and try to use SC... spherical coordinates. But if dbawel has an easier solution, that would be great.

 

If not, let's all have tea and talk about SC.  Only 200 more posts and we'll have a solution. 

[Alby]

Hi Wingy,

 

I Hope the "clearing" party of your parent's house is finished and that you are not too overwhelmed with administration papers, Kafka seems to be an universal symbol everywhere in the world!

 

And now ,poor Wingy,  your are trying to clear the ignorance of a nearly blind mind, really I admire you for your courage!

 

But ok, be not desparate, now  I begin to understand the complexity of my request, sure you were a good teacher (before your were 153 years old), if not in this life in a previous one!

I feel now a bit sadistic, surely I will burn for ever in hell for such a perversion!

 

 

Now I'll try to grasp a little bit your html input demo... don't worry I have pill box against headache just in front of me, I'm not afraid!

 

 

Well here I end my post, now only 199 posts before the soluce will flow, I prepare a pot of tea (10 gallons?) !

 

Wish you a nice WE!

[Alby]

Hi Captain, good news...again, yeah! :

 

http://www.html5gamedevs.com/topic/14197-bgui-a-gui-extension-to-babylon/    thanks to Temechon

 

Bab's is growing better and better!  ("Longue vie à Babylon"!)

 

Just now to find a way how to simulate an input and pass the parameters to bab so we could create by example an  object in real time, nothing is impossible, especially when Wingy is there !

[Wingnut]

You're too kind to me, A-man.

To be frank, you don't want to use Temechon's FPS-killer, nor any derivative of JcPalmer's Dialog system.

Take a look at Jc's monster...  http://tinyurl.com/lmnetyw

Choose the Look and Feel button (and wait an hour for the text to change).  Now start panning and zooming on the text.  Look like crap?  Yep.  Using dynamicTexture for gui text is fun to experiment-with, but it still sucks.  (sorry, Temechon and JC, its not your faults, it's webGL)

Let's take a look at Temechon's gui demo...

http://temechon.github.io/bGUI/

The Vault11 text is a picture... so its nice and clean.  But take a look at the un-highlight-able no-copy/paste no-wordwrap, no \n-allowed ... text in the upper left.  On my machine, those fonts are furry and fuzzy.  Maybe on the newer boxes, things look better, and I'm sure folks will soon tell us, after this brutal critique of mine. 

The best angle to view ANY gui... is straight-on, in a 2D fashion.  No jaggies, and the text is clear and consistent.  Notice that Temechon's text, though fuzzy, still looks better than the Dialog panel... because there's no rotation (or any other 3D stuff) involved.

So if you're going to have gui, don't bother making it in 3D.  Keep it 2D.  That means using a canvas overlay and the power of context(2d) (like our debug layer), or use html.  That's my opinion.  (And I'm correct, and we all know it)  hehe

I think, what we REALLY need... is an easy way to add html to a scene.  This was my idea with:

http://playground.babylonjs.com/#1VXHZA#4

Yep, that's the babylonDocs website in the iframe down there.  No CORs issues, any webpage can be put down there, including a panel of html buttons and readouts used to control the scene.  BUT... iframed documents are security-isolated and I have not tested button click events or setting .textContent on readouts on the iframed document.  Chances are, they will be permission-denied... so I might have to think-up another way. That "other way" will likely hit CORS issues, though.

And look how well the text in that webpage... highlights, copy'n'pastes, does full CSS styles including the ever-popular round-corner borders, it sizes with control-mousewheel, it scales and wordwraps nicely, just plain delicious.    PLUS, we can use the object tag...which allows us to embed media players (and many other things) into that lower 'webpage' panel.  So, we can watch Babylon 5 episodes (on a small screen) while we tour a BabylonJS scene.  Coooool.

Ok, my brain hurts now.   Be well, guys.

[Temechon]

 

 

So if you're going to have gui, don't bother making it in 3D.  Keep it 2D.  That means using a canvas overlay and the power of context(2d) (like our debug layer), or use html.  That's my opinion.  (And I'm correct, and we all know it)  hehe

 

Yes ! bGUI is created for Cocoon and/ord mobile platforms, where no DOM element is allowed. If you can create your GUI in HTML/CSS, do it, it's the best way (for example, the new http://flightarcade.com/ GUI is made in HTML/CSS)

 

 

 

 But take a look at the un-highlight-able no-copy/paste no-wordwrap, no \n-allowed ... text in the upper left.  On my machine, those fonts are furry and fuzzy.

It's the same on my machine, but this furry/fuzzy won't be visible in a mobile screen.

[Wingnut]

ohhh... yes, I guess I knew that, but forgot.  Thanks T!

 

This is interesting.  If we use html in our scenes... we lose a substantial group of scene viewees.  Darn.

[dbawel]

Hey Guys,

 

As Wingnut might be unconsciously promoting, beyond the specific application alby was asking - it's really good for everyone to always consider the position of a mesh's axis in world space.  And more specifically (or non-specifically,) to never be constrained mentally by a mesh's vertices or faces in the placement of it's center. In practically every production I've worked, I would never have been able to achieve the desired performance from an object if I wasn't able to move my object's center wherever it was required for referencing its transforms.  In platforms other than BJS, parenting is often the best method.  However, I haven't found transform functions on an object in a hierarchy all that simple in BJS.  So placing an object's center wherever necessary is often more efficient in BJS - if it generates the correct performance in all required conditions for the mesh.

 

The advantage to parenting is that you can have multiple centers to reference for an object's tranforms - as you're able to switch to multiple centers within the same function and/or script.  But as we're working with scripts and not in a graphic tool where the math and higher functions are hidden, it takes considerably more effort to work with hierachies.  I thought that Wingnut brought up an important point to consider, so I thought I'd re-emphisize this as an essential element in working with and animating a mesh.

 

As for building GUIs in BJS, I'm currently building an application using the bGUI script.  It's often much more efficient to build 2D overlays, however, I can tell you that I'm working with new AR and VR display technology in which all elements are essentially 3D.  2D content is displayed on a 3D plane in space, and GUI elements are all 3D objects.  I wish I could offer more information about this, but I can tell you that when this new display technology is released in 2016, it will change the way everyone views games and entertainment, as well as every facet of life such as how we shop, communicate, and receive information.  So in he near future, we will all be working in 3 dimensions, and 2D will quickly be seen less and less.  bGUI is somewhat basic for version 1, but I'm finding it much faster and easier to build the GUI for my current app than if I were scripting a 2D overlay.  My hat's off to Temechon, as he's taken the first step to a valuable tool.

 

Cheers,

 

DB

[Wingnut]

  Frankly, I hadn't considered parenting as a way to set an out-of-volume pivot point, but sure, that would work just fine.  Unfortunately, we are still at the point of PLACING the spoke/stride (the space station arms) and aligning things to it. Spoke?  Stride?  Arm?  Star rod?  Radial?    What should we call it?

 

If the picture is placed in space first... (currently so), then a "stride" is derived somehow.... to connect picture to center sphere. "stride" = a crossing... so stride would be a good term for that bridging.

 

With an SC (spherical coords) method, the space station arm angles are derived first (phi and theta), and then a picture (node) is placed rho distance from the sphere (on the spoke).      Here, "spoke" is a good term because no bridge is being built between two things.  No thingBetweenThing().  With SC, we make the invisible direction "rod" first (a spoke), then use it to align all sorts of things, both for .rotations and .positions.  A guy could place ANYTHING on the spoke, and it would act correctly... in theory.  The arms could even be cylinders or rectangles... more like a space station... and smart dynamicTextures would keep re-mapping themselves differently onto the cylinders, depending upon current viewing angle.  (working-with the camera's view matrix).

 

(Did that hurt your brain, Alby?  Me, too!) 

 

Notice that I'm trying to stay on "box rotation" subject, even though this thread has promoted all sorts of tangent discussions and thoughts.  Poor Alby is probably wondering WHY and HOW his forum question caused a social club to form.    I tend to talk most when I haven't got a solution to an issue... and if the amount of talking I've done in this topic is any indication... I'm stumped but good.  heh

 

I started doing SOME work yesterday on Alby's Space Station, mostly clicking on Alby pictures and pondering a small html menu opening near the picture, with a choice for text input.  But, I spent 3 hours trying to get ANY actionManagers placed on ANY mesh.  *scratch scratch* 

 

It didn't help that onPickUpTrigger is not documented and also required a fresh BJS framework version.  (curve ball.  Apparently onPickUpTrigger is very new.)  I was trying to turn-on the same picking code as what Temechon used in bGui.  Then, I tried many variations and things from the docs.  Failed.  Not sure what I'm doing wrong or why Alby's Space Station of Art... would be killing Actions.  I had the actionManager playground demo... open in another window... copying code word for word.  Fail. 

 

I might have to bring the issue to the forum, for help.  I need help being a helper.  Pathetic, eh? 

 

On another subject... and to be fair, Davrous possibly did the "first step" of BJS 2D gui... with virtual joysticks.  And then Deltakosh did the 2D debug layer, and then JcPalmer did his 3D-with-2D-option Dialog, and then Temechon did his 2D-with-3D-option bGui.  There may have been others, too.  Dad72 was likely working with various gui for over a year, though he never released a gui system.  CastorEngine likely has MANY forms of gui.  It's html is nothing short of perfect, but that's another subject.

 

It's all good.  Lot's of great minds and great inventions happening on the forum and in BJS land, lately.  I love it!

 

AR.  Augmented reality.  Hot subject, lately.  Our debug layer could be called AVR...  augmented virtual reality. 

 

Also, societally, AR might fail, due to vision headaches caused by Oculus-like devices.  It's "hot" now, but may be a short-lived fad.  Those who are pouring massive dev funding into this tech... may be in for a bittersweet surprise... from a society/consumer-base that refuses to bite on AR.

 

Long enough post?  Cool.

 

The future big money... is in batteries. 

[Alby]

Ok, listening to you, experts,  I think I will play back in my sandbox! I never thought my innocent request lead to a kind of "revolution"!

 

But It is very interesting to have an idea, thanks to dbawel, about the future in AR and VR displaying and surely babylon will follow the evolution, isn't it?.

[dbawel]

Hi Gentlemen (and perhaps Ladies,)

 

I like Wingnut's "visually" descriptive writing.  It's the next best thing to building a dimensional diagram - which I should look at doing to help define the 2D, 3D, and 4D dimensional systems we use in creating, animating, and drawing (rendering) objects and meshes.  As I noted more than a week ago, this post has taken many tangents and explored areas far outside of "box rotations."  But that's OK by me, as its been an enguaging discussion - and most likely the longest daily post I've seen since joining the forum.

 

As for AR and VR, I believe that display systems such as Oculus and the Microsoft Halolens are fads, and will die a quick death in the next 2 years.  The founder of Oculus was my PA at a company I was CTO - named Emersion Software and Technologies, and I've got to give him credit for building a 2 billion dolar company in just the last 4 years since he left.  I assume he got his inspiration (and technology) from the work we were doing, as we were developing AR headsets for the military through a Lockheed Martin contract.  So I understand the technology, and optics in general.

 

It was a bold statement to say that new dispay technologies will change the world basically, but I have to share that the new technology I'm working with will definately do so.  The compay's name is Magic Leap, and they are incredibly seretive - as they need to be.  I'm also very limited on what I can say, and they prefer I don't say anything.  But imagine a device that is not glasses or a headset, weighs less than 5 ounces and rests on your head similar to the top support rim of light eyeware.  There is a tiny projector for each eye which projects natural waveforms of light directly onto the retina - not in scanlines, but in radials (circular,) so the device is actualy resolution independant and covers the full 160 degrees of human sight with no distortion or falloff on the periphery.  

 

2D displays are biomechanically un-natural, and there are already several people who have reported both eye and neurological disorders from using the Oculus Rift for an extended period of time.  And the Microsoft Halolens has the same issues, as it's a very un-natural way to trick the brain into comprehending that there is an object in 3 dimensions which your eyes can see.  It's important to look at display technologies from a neurological point of view - since the eye is simply relaying light patterns in which the brain is "tricked" into believing there are objects in 3 dimensional space.

 

Magic Leap has recieved so much capital investment because using this display technology, the human brain cannot differentiate between light from objects in the real world and the projection of natural wavelengths of light directly onto the retina.  So for those few people who have been fortunate enough to use one of the 2 prototype devices, they've all told me that when an elephant is displayed in the room, they cannot sense in any way that it is not there.  I'm fortunate to have Richard Taylor who owns Weta as one of my good friends.  He was one of the first investors in Magic Leap 2 years ago, and has one of the 2 devices at Weta Workshop in NZ.  They are building the first game for the device, and it's a project I've been involved with for the past 6 years.  We started designing the game 6 years ago, and I'm really happy that I'm able to continue to work on this game since it's now being built natively for the Magic Leap display.  

 

Here's a lnk for a 2D demonstration of what the game REALLY looks like as close as can be displayed in 2D:

http://www.theverge.com/2015/3/19/8259561/magic-leap-weta-workshop-augmented-reality-game

 

The room that you see in the demo is in the facility we built for Weta Productions, which is now where the devlopment of the Dr. Grordbort's game is in production. The gentleman playing the game and who's voice you hear is Greg Broadmore who created the Dr. Grordbort's universe - and a good friend also.  Please watch the video and trust me that what you see is almost exactly how it appears to the the player when playing.  Now imagine what our world will be like when you can meet with family across the world and your mind will truly believe they are sitting next to you on your couch.  And when you want to buy a car, simply place the car in the middle of your living room, and walk around it and really get a first hand view of the car as it appears in real life.  They are also building the first cinematic experience which places you in the middle of the battlefield in 360 degrees - where you are emersed in the action - not viewing through a window.

 

So, I just wanted to reinforce my very bold statement that Magic Leap technology will change the world, and any of us who are currently creating games will most likely be working in this medium if we are still doing this in 5 years time.  And there will be as great a need outside of entertainment; for communication, exchanging information, and everything you use the internet for today.  I've probably provided more insight into this technology than I ought to, but I didn't want to make such a difinative statement and not back it up.

 

There are exciting times ahead, and everyone working in HTML5 and WebGL are on the forefront, as the technology may be brilliant, but it has to rely on content to exist.  And I can promise you that this (currently HTML5) is the platform in which all content will be delivered.  The work we're doing now is laying the foundation for all media in the future.  I have meetings again with Magic Leap on Wednesday, and will keep this community up to date on this technology if anyone is interested - at least as much as I am permitted to discuss, which right now is very little.

 

Cheers,

 

DB

[Alby]

Waw!..... Hey Wingy, ready for the future?

[dbawel]

If you're interested in Magic Leap technology, I found this news video on You Tube:

 

[Dad72]

it's all just amazing. breathtaking.

 

But what is what the future still holds for us? Portal teleportation as 'Stargate' 

[Wingnut]

Phew.  That's deep stuff.  Can you imagine that military AR thing?  Ground troops, drone pilots, forward air controllers, black ops, secret service, etc. Lockheed Martin.  Erf.  We got budget.  Lockheed Martin checks NEVER bounce.  The software is probably MUCh smarter when its live-communicating with a command post server... but when out-of-touch with the server, that's when the belt pack-o-knowledge might take over... solid state drive,  of course. 

 

Sigh.  That would be SO fun to work-on, except for the killing-folk part.  I don't like that part.  Jungle paintball, anyone? 

 

Cave exploring might change a bit, with wearables, too.  Doppler-to-BJS, ya think?  nod.  Your headset "pings" the cave as you walk along in the dark, and then the cave ahead is live-modeled in 3D and hippy-bus textures adorn the cave walls.  And there's GIRLS!!  And... oh wait... I can't touch them.  Nevermind the girls, then.  Can I watch Fireball XL-5?    While I cave explore?  YES!

 

Thanks for that insider look, DB!  Very cool!  When folks have the overlayers blasting (Magic Leap active)... and they blink... do others see that car (from the middle of the living room)... momentarily... project on the outside of their eyelids?  Bet so.  FUN!

 

"Close your eyelids so I can see what you are viewing."  hehe  funny.  Ok, I'm off to try a SC demo. Wireframe sphere, make up a phi, theta, and rho, plot a point, draw a bjs line to the point, and see if I can derive a direction vector from it.   Jerome can do this in his sleep, I bet. Temechon can do it sleeping with one hand tied behind his back.  Deltakosh can code it... using another person's mind, while sleeping! 

 

DB, you are so cooool!  You are right there in the bullpen, with poop on your hands!  Fun!  Good luck with your project!

[dbawel]

I like your sense of humor Wingnut.  I'm lucky to be in the bullpen, as I never thought I'd get the opportunities I've had and currently have.  Work has become interesting again, as I was getting bored with technology and with my work until about a year ago.  The great news is that this technology will be in your hands within 1 1/2 years.  Magic Leap aren't providing any release dates just yet; as they don't wan't to take the chance of missing a release date as this is very bad for a new consumer technology company.

 

You had picked up on my work for the military.  This was very interesting work for a while, as I got to work on new drone technology, and with the Lockheed Martin Virtual World Labs on the AR headsets for the joint strike fighter.  And you're correct, a Lockheed Martin check has never bounced.  It's a facinating company, and I got to see some amazing new tech such as the first quantum computer when they purchased it about 3 years ago.  It's incredible to see how fast tech is evolving, and most people working in technology today really have little idea how exponetially fast.  

 

I'll keep poop on my hands as long as I can.

 

Cheers,

 

DB

[Wingnut]

Fun!  Ok, back to business...  http://playground.babylonjs.com/#1HLSBC

I didn't play with SC (I lied), but I DID get the little html menus to work.  Just click a box.  And click it again. (tiz a toggle) Type-in some text... hit enter... see what blows up.

I turned-off the pictures and skybox... while this "dirty stuff" is being worked-on.

I put ActionManagers on each box, each with a registered PICK trigger, executing checkHtmlState().  That function looks at the "isHtmlShowing" flag, and does the right thing.  For now, don't try opening menus on two boxes at once.  My endMenu() function isn't very wise and it will get confused.

The super-fat new func... is buildMenu(), of course.  Hey, if ya want good CSS styling, ya gotta wang some chung, right?  You bet!   heh.

25% transparent on the buttons.  Just wanted to see it.  No onClicks set on the buttons yet.  And no, the html will not follow the object around on the screen if you start panning the camera.  To say it differently, there is no live-poking of style.top and style.left happening within the animation loop, yet.  That tumor-causing challenge is for later versions in later days.    Party on!

[Alby]

Wingy, you didn't put  ActionsManagers but WingyActionsManagers, a step further for the future!

 

Thanks Wingy for the time you spent again to find soluces to my neverending requests... long life to Wingy!

 

Now I'm trying to manipulate, create, delete, move all the objects.

 

Fortunately there are some examples from wich I can take some inspirations!

[Wingnut]

Aw shucks, Alby, it was nothing. 

http://playground.babylonjs.com/#1HLSBC#3

Newer version... but still done sloppy.  I had three mistakes in checkHtmlState() ... not healthy to use 'this' in a global function.  I did something different. 

And, I put a scene.onDispose() into operation.

Wanna see what can happen WITHOUT a scene.onDispose() for playgrounds that use html?  I knew ya did.

- un-comment line 219

- press RUN

- click a box to open an html menu

- leave it open, and choose Basic Scene from the PG button labeled 'Custom'.

Our little menu is still there, even though a completely different PG scene is being used. 

With HTML and PG scenes, it is exactly like bathroom duties.  It is best to wipe before leaving. 

Also, Alby, this is NOT a "smart objects" (overloaded objects) way of doing things, yet it is to SOME degree.  When we put an .actionManager on each box, we made the box smarter.  Also, when we added a .isHtmlShowing flag to each box, each box got a little smarter, too.  (lines 306-307 area)

Remember we talked about AlbyPlanes... special planes you create by wrapping the BJS createPlane inside a CreateAlbyPlane function?  Well, you could do the same with AlbyBoxes.  See line 268 where you createBox?  Instead, you could do...

var abox = AlbyBox ("box"+i, TabBoxes.size, scene);

abox.addMoreCrap = function() { anycrap };

abox.setEnabled(true);  // done abusing this poor, smart object?  Ok, SHOW it!

 Then, write yet another function...

 var AlbyBox = function(name, size, scene) {

    var box = BABYLON.Mesh.CreateBox(name, size, scene);

    box.actionManager = new BABYLON.ActionManager(scene);

    box.actionManager.registerAction(
       new BABYLON.ExecuteCodeAction(BABYLON.ActionManager.OnPickTrigger, checkHtmlState)
    );

    box.isHtmlShowing = "false";

    box.material = blah blah;

    box.position = whatever;

    box.whatever = anything else ya want;

    box.setEnabled(false);  // just MAKE the box, don't show it yet... but anything goes.

    return box;  // send the box back to whomever wanted it.

};

 The AlbyBox Factory - adding smart to already smart BJS boxes.  It makes boxes with actionManagers already attached and they are click=>executeCode smart.  Nobody does boxes... like AlbyCo boxes! 

 Fun, eh?  Overloading.  Careful, it's addictive.  Keep in mind that its better to add universal smartening objects to your object.... to make it smarter.  It need not make all of its own smartness.  The actionManager is a universal smartening object.  A proxy.  It makes BJS objects... action-smart... FOR them.  Cooooool.

 TabBoxes[0]=new Boite()... perfect.  Temechon-ish... making a completely fresh object, and then setting it's .mesh property to a BJS mesh object.  Two-piece object... no need to overload the BJS mesh... because all your add-on stuff is on the fresh object.  Wiser than overloading, but, sometimes requires planning, so I always fail at it.  hehe.

 What's that?  You want to start a library that contains every customized JS object that anyone ever made?  And you want to log and document the cool functions folks have installed on those objects, or sent those objects TO? 

Your cool stuff library might get a little full.     But that is good.  That is your toolbox... to become RAD and modular like the big dog OOPmeisters.  One of those cool reusable functions might be called...

 putPickingAndExecutingActionManagerOnMesh(mesh, scene);

 ok, maybe just actionize(mesh, scene) 

 That function would be handy on THIS project, right?  And it seems to be quite a reusable function, too.   Yum!

Ok, I just wanted to re-visit smart-objects and say that this latest demo COULD go much further in that direction.  If you think about buttons and inputBoxes, they are a html FORM, correct?  So it would not be all that unusual to have a .HtmlFormManager object placed in each box.formManager property.  The HtmlFormManager... much like an ActionManager... would be packed with handy properties and methods for working-with html forms.

 If you think about it, adding an actionManager to a box... made it a MUCH smarter box, but without needing to add many properties or methods on the box itself.  We "borrowed" the massive picking/executing intelligence of the ActionManager...by simply "instantiating" one, and putting it into box.actionManager.  One could call that "snap-on brain power", eh?    Be well, gang.

[Wingnut]

Yet another version.  Click a box, opens a html 'container' with 4 buttons and an inputbox inside it.  Pan the camera, and the html should follow the box.  YAY!

 

Thanks to RaananW and his post about 'project'... we have successful tracking!  Folks can examine the .registerBeforeRender function in the demo above... to learn how I used his code.  Thanks R!  Piping his data to our .left and .top... easy as pie, piece of cake, and eat it, too.

 

And yes, I've been messing with the text planes with zero success, so far. 

[Alby]

WingyActionsManagers strkes a blow once more!  

 

Ok, but  to follow you in your jungle babylon expeditions is a little difficult for me at my present level, nearly 14 months in advance makes the difference!

 

But really thank you, Wingy, one day surely I'll be able to understand what you're doing, be confident, just be a little patient!

 

I'm sure what you do, in addition to be useful for me, will be very useful to others! you are the best! ( many best in this forum!)

 

 

By the way no idea how to change the name of this post? it could be "box rotation, text orientation, html menus, data input"....