Wingnut

Members
  • Content count

    3,257
  • Joined

  • Last visited

  • Days Won

    62

Everything posted by Wingnut

  1. Hi guys. Pinging @Nockawa for this one. I've been working him hard, lately, and I want to thank him for all the recent help. Today I am thinking about borders. Well, I HAVE been thinking about borders for quite some time, but those borders were international borders. Now, about Canvas2D primitives borders. Currently, I think there are only a few ways to make a Canvas2D based border. 1. Rectangle2D 2. Shape2D 3. Sprite2D. Each CAN be used to place a border around a Text2D, or just about anything else. But none of these bordering methods... automatically size-to-fit their contents, right? Perhaps that is reserved for a layer above the currently-completed "base" of Canvas2D. At what point do we "assemble" the FitBorderedText2D and FitBorderedGroup2D? In fact, for maximum-easy bordered tracked-node labeling, I could use a FitBorderedTrackingText2d. It seems strange and clumsy to need Group2D for node tracking, Rectangle2D for text border, and then Text2D... just for a single label. Anyway, I saw mention-of allowing trackNode for WorldSpaceCanvas itself (future feature). That is allowing trackNode on a "higher level" than Group2D. (WSC2D is higher level than a Group2D child of it.) What are the chances of allowing trackNode on LOWER level things... such as Text2D or Rectangle2D? What are the chances of allowing border on Text2D and Group2D? You see, a FitBorderedTrackingText2d... would have a border and trackNode... without needing any help from Rectangle2D or Groupd2D. Potential lines-of-code savings across 10 years of Canvas2D usage - 2 million metric tonnes. Am I de-primitiving the primitives? (i.e. FitBorderedTrackingText2d is a "combo" of primitives, and therefore would be offered on the next layer - the GUI Lib currently under dev?) Perhaps part of a Canvas2D Tools thing... programmer assistance? Of course, programmers can do this "combining" themselves in a little makeLabel() function. But still, I'm curious if Noxxy has any plans for "SuperText2D" features like this. Thoughts, anyone? Thx.
  2. canvas2d

    Okay, so, while I have your ear... um... ...the reason the playground slider and other canvas resizing... is screwing up the proportional placement of the buttons... is because none of the values... use percentages, correct? (sizes, x, y, origins, etc) Would that be a programmer-calculated thing? For example, if I could place left button x: "5%" and right button x: "85%", then we could do a nicer canvas re-size/re-scale, and have it be cool, right? Nockawa... is "allowing percentages" (and thus nicer canvas re-scales)... planned? Is it part of the "primitives phase" of C2D dev? Any thoughts? Thx. Sorry if you already told me and I forgot.
  3. Pivotal! Truly pivotal! Hi guys. I have been doing a little reading in pursuit of silhouette things. (okay, okay, that link was for FANCY silhouette things) Can you imagine drawing-on three Shape2D and having it create a model from them? Cooooool. But that's for smarter people than I. My quest... is somewhat more simple. I want to have an extrusion or displaceMap... that follows the outside edge of a transparent-background image. Like this... https://c2.staticflickr.com/4/3037/2404820566_c56d3492c9_b.jpg (truly pivotal) Doors, flat hockey players, what's the difference, right? Create a mesh... extruded/displaced the same thickness across entire surface... and the outside edge "shape" follows the outline of an image (non-transparent part). Cool! SO, I went experimenting. (uh oh). I took the "birdData" from our PolygonMeshBuilder feature... and I stuffed it into the "shape" array of a @jerome extrusion thing! I had to fiddle with the string, a bit, but it's working pretty good! http://www.babylonjs-playground.com/#165IV6#34 NASA, we HAVE EXTRUSION! (At my age, extrusion is rare... ahem.) ANYway... set line 73 to 1, 2, or 3... to turn-on the extrusion "caps". I think this shape is a little too complicated for the extrusion's capping system... but it gives it one hell of a try, eh? Notice that the capping system is attempting a wagon-wheel-type of capping, from a central hub-point. Our bird says "You'll have to do better than that, if you want to cap ME, buddy" That's a different issue, though. Would anyone like to build an image "outer edge detector"... that creates arrays of vectors... that approximate the "outline" of that image? Vector2 would be fine, but Jerome's extruder uses Vector3's with 0's in the z-component. All in all, I would love to have an "image-outline-to-extrusion-shape" thing... converter... shape generator... you know. Something that makes bird shapes from transparent background bird pictures. Transparent colors in the middle of an image... can be ignored. I just need that outer edge of the image... converted to extrusion shape data. THAT... would be cool. A bottle of whiskey (not too expensive, please) to anyone who can do it for us. Party on, everyone.
  4. Hi gang! Newbie Wingnut here again, hope everyone is well. I've been playing with the multiple-basic-object (primitives) demo in Tutorial 02. After firing it up... I found that the PLANE involved in that demo... starts on edge to the camera, and is black (textureless) on one side, and invisible on the other side (backface culled). AND, the plane is too big in my opinion. AND the camera too far away. A few tweaks and things got closer to looking like the demo picture... but no apparent default material is on the plane. And I suspect that we can make cones with a correctly-argged createCylinder. All in all, I think BABYLON.Mesh.CreatePlane should create a plane that is more see-able by default, via positioning it as a 'floor' upon creation, with its non-culled side UP, and via putting a default material on it like the other primitives/basic-geometry. But, that's really not what I wanted to yack about. I can foresee a time when we will have LOTS of procedural (dynamic) geometry-making routines in babylon.js. So many, in fact, that I think a 'procedural geometry pack/lib' might be considered as an add-on library to BJS. So I ponder this... Instead of things like... BABYLON.Mesh.CreatePlane(blah, blah, etc) We/you instead have only one geom-o-generator command... BABYLON.Mesh.CreateGeometry([word or number], blah, blah, etc) In the first arg/param... a word/name or a number. IF its a number (say 12), a dodecahedron (12-sided polygon) is created like any other of the basic shape primitives. IF the first arg/param is a WORD, such as cube, sphere, cone, box, etc... it works like it does now, using the rest of the parameters as beginning settings FOR that object. That first word could also be the NAME of a procedure/method that might be inside the geometry generator lib mentioned above. IF the first arg/param is a word that is NOT defaultly recognized, such as "octagon", the call looks in the 'shape generator library' for a procedure of THAT name, and if the right amount of added args/params are set to satisfy the call... it uses the code in the 'generator' to make said geometry(s). Now lets go back to the NUMBER as the first arg/param. Lets say that number is 8... which means produce a octagon-ish 8-side polyhedron with either a builtin BJS procedure, OR call the addon geometry generator's octahedra method. This way, we/you could essentially eliminate all the createWhatever commands (there could be lots someday), and use one instead. The command would sometimes/always defer the action to the add-on primitive/shape generator. I goof around in 3dMax a bit, and I've seen their massive 'library' of procedural primitives/shapes, and one would think that BJS is destined to have every one of those, plus a few hundred more. Thoughts, anyone? Thanks!
  5. Hi J! Yes, that is perfect. But viewport2 will go behind html... because... you know... we can't make a viewport in one corner only. Or, HTML section could be covering a viewport 3. It doesn't really matter. Having it cover the bottom part of viewport 2... would be less work. I think you understand this. (it's because of how viewports are positioned) Another problem might be... keeping absolute-positioned HTML... "docked" to the right screen-edge. Resizing screen can cause problems for absolute positioned HTML. It is important to set sidebar.style.width, .height, .top and .left... with percentages, and not "pt" or "px" values. Margin settings are ignored for absolute-positioned HTML, I think. Thanks for info about RTT on Canvas2D prim. You tried it / thought-about it, huh? Cool! Likely, it would need to use a special Sprite2D or Shape2D with constant update from RTT. Probably not yet invented. Wouldn't it be great... if we could "feed" an html <img> element... with a renderTargetTexture? Then, the whole right sidebar would be HTML stuff. No viewports or canvas on the right. Perhaps mon1 could be a HTML <canvas> element (with context-2d, not context-3d). hmm. That would also allow us to have an ALL-HTML right sidebar. Perhaps, doing that is a security issue. Not sure. I think I might have tried that before, and failed. But I fail often... and sometimes unnecessarily. Ok fellow forum helpers... here is "The Juan & Wingnut Challenge of the Weekend"! Use a camera view or renderTargetTexture... to fill an EXTRA context2d HTML canvas. Essentially... we need another HTML canvas (or <img> element)... below the renderCanvas area (for our tests). That <canvas> or <img> must be constantly updated from a renderTargetTexture. CAN IT BE DONE? I dunno. Here's a starter playground with 4 HTML <canvas> "monitors" under the renderCanvas. http://www.babylonjs-playground.com/#1WROZH#17 First person to get a RenderTargetTexture... continuously displayed on one of those context2d canvas (canvai?)... gets... A BRAND NEW ROLLS ROYCE! everyone's love and appreciation. Alright! Thanks for all attempts, comments, successes, miracles, etc. I think what we are trying... is a browser security violation. So even if someone DOES do it successfully, we would probably need to report it to the W3C, and then they will change the browsers... and make it quit working.
  6. Hmm. Ok, if you set... scene.beforeRender =()=> { - set all scene.meshes to .setEnabled(false); - activate background layer - delete/null scene.beforeRender; } - wait however long you wish - setTimer - set all scene.meshes to .setEnabled(true); return scene; I have no idea if that would work (or why you want this). But, after the very first run of scene.beforeRender, we delete it... clear it out, null it to nothingness... so it doesn't run again before the next frame. During that one run, it disables all mesh, activates background layer, and self-destructs. Then you can fiddle around with timers or whatever else you want to do... and re-enable all mesh at your leisure. *shrug* Again, not sure. Might explode and kill the cat.
  7. haha. Yuh, keeping a plane (mon1) that is parented to camera... docked against a screen edge... no matter the viewport size... is a serious challenge (somewhat difficult), I suspect. I'll need to think about that issue for a while. That's a brain challenger. I suppose we could use an extra viewport along that right side. With the added along-right-screen-edge viewport, the right side "menu" would be a PERCENTAGE-of-total-screen-width... wide. For example, right viewport could be 20% wide... but... I don't think it could "mix-in" with any HTML sidebar you have over there... UNLESS... that HTML sidebar was absolutely positioned. In other words, you MIGHT have a viewport along the right side of the screen... that is 20% wide... but it will likely be 100% tall (because of the way viewports are defined). SO... let's say you wanted mon1 at the top of that area. With viewport camera and RTT positioning, you could put it there, at the top of the new viewport. And then if you want HTML stuff UNDER that (including things like datGUI panel)... then that html would be absolutely positioned ATOP part of the new viewport (perhaps below mon1). The HTML part of the right side menu (if there IS HTML on that menu) would sit atop part of the canvas of the new viewport. I don't think you can add a viewport like this... ******************************** * * * * * * * *********** * * * * * * ******************************** So, instead... and because of the way viewports are defined/placed, you might do this... ******************************** * * * * * * * * * * * * * * * * * * ******************************** and then absolutely-positioned HTML area covers bottom of new viewport, for example... ******************************** * * * * * mon1 * * *********** * * * * * HTML * * * * ******************************** HTML area covers bottom canvas area of added viewport. *shrug* Might work okay. IF menu is NOT HTML, but instead Canvas2D primitives, then no problems at all. Lower section of new viewport can be filled with Canvas2D buttons, labels, dials, knobs, everything, and no absolute positioning of HTML needed at all. There would be no HTML. In fact, even mon1 might not be a plane anymore. It might be a Canvas2d primitive such as Shape2D or Sprite2d. You might be the first person EVER... to use an RTT (renderTargetTexture) on a Canvas2D primitive. WOW! ---------------------------- Now, about the specularColor on mon1. It is likely NOT mon1.material.specularColor causing the unwanted specular shine. It is likely the mesh.material.specularColor of the scene item that the camera is SHOWING a picture-of. Check out http://www.babylonjs-playground.com/#1WROZH#15 Mon1 is SHOWING a huge amount of secular shine coming from the grass plane. But it is NOT caused by mon1 plane .material, or by camera1 (well, camera1 viewing angle IS a factor). But mostly, it is caused by materialPlane.specularColor and light.specular (both are not user-set, so are currently set to default values). With me? Probably not caused by mon1.material. It is likely caused by the material on the mesh that is doing the specular shine. Weird, huh? *nod* Easy to get confused. Now you have a ton of new things to think about, and so do I. Perhaps others will comment. Be well. Oh, you want to see a multiple viewports demo? Okay. http://www.babylonjs-playground.com/#13TVWJ#2 Believe it or not, there are FIVE viewports, there. Even the thin blue lines are in thin viewports. Lines 26-49 carefully divide-up the canvas into sections... all measured from lower left corner (0,0) to upper right corner (1,1). Notice that the upper viewports each use 50% of screen width, no matter how wide the screen. Percentages. Viewports are kind of strange, but very useful in some situations.
  8. canvas2d

    Thanks guys!!!
  9. canvas2d

    Ok, very good, thanks. Good reminders (relatedTarget, isPickable, etc). I forgot that Text2D is "generating" over/out events, even if I'm not observing any Text2D. Its parental rect2D observer was hearing Text2d's bubblings... as you stated. Yep, yep, yep. New demo: http://babylonjs-playground.com/#UAG5H#12 It's all working perfect, and just like you said it would. New enhanced console loggings on this one... showing more info. ONE minor thing... I thought I should mention. Currently, (in the new demo) the left button Text2D is NOT producing bubbled overs and outs, and it is caused by line 13. Line 13 is a size setting on the rect2d. You'll notice there is also a size setting on the Text2d in line 21, currently disabled. ONLY when there is a sizer on the rect2d... does the text2D fail to bubble over/out events to rect2d. Here's the truth table: Line 13 active ONLY: no Text2D over/out bubble to rect2d. Line 13 & 21 active: Text2D bubble - > rect2d okay Line 21 active ONLY: Text2D bubble - > rect2d okay Line 13 & 21 disabled: Text2D bubble - > rect2d okay Okay, that's it. I could be mistaken. No big deal... just thought I'd tell you about this interesting sizing thing. Again, good work. I'm having a blast torturing this. It's pretty solid. I'm having difficulties making it screw-up. Don't drag that playground editor/canvas divider bar, though. I probably need to find a refreshAfterResize() or something. I should read the docs someday. :/
  10. Oh yeah! It bangs off the wall real good. I managed to land it atop the wall, butt-first. The tail rotor is on one side of the wall, the skids on the other, and the heli is looking almost straight up. The tail rotor is whackin' on the wall, making everything shake. Too good. ALL the small animals have run and hidden. I wonder if it will fly out of this situation. Congrats on the decent impostoring!
  11. Lime juice? How uneventful. (Wingy adds a big pile of whipped cream... atop his lime juice, and sprinkles-on edible glitter) Yeah, um... me thinks you need to move the rtt cameras... to a .position just behind each window. Maybe? Your vision is so damned big, my brain is having a difficult time holding it in view. Maybe the rtt camera for a given window, should be just outside that window (aiming at skybox). But yeah, .fov and .fovMode could be important here. .fovMode is used to determine if .fov should be applied to height, or to width... I think. Forum search link. Also, I don't know what happens when a camera is set to orthogonal mode, but that might be worth studying, too. In general, though, there's all sorts of trickery and foolery available. There's some extra things that you would need. For example, as player moves around inside the house-o-fake-windows, what do the rtt images do? Do they scroll a tiny bit? Do you need to slightly rotate the rtt cams... so they show a slightly different section of the skybox images? Little things... calibrating. That's how you would get the best fakery. And, you can make your windowed walls out of 4 planes, so there's a REAL hole in the middle. Or use CSG and boolean-subtract a hole into a wall. But, there's still something cool about fake windows that are actually big-screen TV's, eh? Don't try to stick your head out-of one, though... and avoid spitting chewing tobacco out of those fake windows. heh [fun!]
  12. Hi S! My comment here... is off-topic a bit, but if you can make adjustments to DOM things on your platform/system.... you have some more possible options. Consider this. HTML <img> or <canvas> elements... have a .style (CSS stylesheet)... and CSS styles have fun things like .zIndex, .display, .opacity, .visibility, etc. Soooooo... You could build your initial HTML doc... so that an <img> element is sitting atop the renderCanvas <canvas> element. Then, when the "blocked" scene is finished, you could adjust the zIndex of <img> and <canvas> ...within scene.executeWhenReady() ...hiding/removing the image and bringing the canvas to front. I don't know if this would work for you, but there are some options, there. There may be other options for custom loading screens... if that is what you seek. Other comments are sure to come, but I wanted to remind you of the possible HTML/CSS-based options. Other forum helpers... this issue is still open... help at will. (thx)
  13. canvas2d

    Excellent! New test playground: http://babylonjs-playground.com/#UAG5H#11 Zones look good, well done! Test buttons: - Over/out on the left button/label (canvas.children[0]) - Enter/leave on the right (canvas.children[1]) . Watch console and color changes while passing mouse across buttons (for new followers to this test). A few questions if I may: #1: Over/out events... happen on the Text2D prims (left button only?), even though no observers are assigned on Text2 prims. Normal/expected? #2: The .isContainer settings (lines 76/77) have no effect-upon the Text2d being event-active. Normal/expected? I'm having a difficult time understanding that. Sorry. #3: Should .isContainer affect the automatic or inherited over/out/enter/leave events on Text2d prims in this example? #3b: Should I NOT BE concerned about .isContainer now, because it does not apply to anything in this demo? I've changed this post 5 times now. I was having some problems making the SAVE option work correctly in PG, when trying to save #11. Sorry for temporary bad link. I wonder if lines 63 and 70 are suppose to be mouseEnter and mouseLeave, not pointerEnter and pointerLeave. hmm. Off to the primitivePointerInfo doc to learn. (It's pointer, not mouse. All is cool.) There's SO MANY event names to remember... in my life.
  14. I think you are correct about the instances, G... but I'm not sure. Makes sense. Clones... are different, though. Clones don't inherit their master's material, though. Instances do. *shrug* Ya know, mister G... that there is some HUGE star-field images... laying around on the web, free. If you used a BABYLON.Layer image with .isBackground = true, and... screwed-around enough, you could pan that... well heck... here's a bad version I once made. http://babylonjs-playground.azurewebsites.net/#1XQKP1#11 Potential poor-man's starfield. But then... there's these equi-rectangular things... special images used as single-image skyboxes. http://www.babylonjs-playground.com/#11GAIH#11 That's really something, too. If you could find a public-usable equi-rectangular starfield image... perhaps you could save yourself a few thousand mesh. But real mesh stars/planets ARE cool, eh? SPS (solid particle system)... or ANY particle system... would get you real mesh stars... for minimum byte/load costs. Both solid and standard particle systems... have a function in them... something like startPositionFunction(), and you get to replace that with your own function. Easily. Well heck, I got a "star dome" that I once did... with standard particles... using a custom startPositionFunction(). http://www.babylonjs-playground.com/#J6ZLH#2 See the custom startPositionFunction in lines 11-16? It uses a couple other functions stolen from the web... to plot (start) particles in a spherical shape, and it has some anti- pole-clustering features, too. Works sort of ok. See the updateFunction at line 20? That is the OTHER function in particle systems... that folks often "customize". The one in that PG does nothing... but lets go look at version #4. Version 4 (starts at line 21) (myUpdateFunction) still doesn't do much... except... lines 34 and 35... which cause star twinkle extraordinaire. Try changing that *10 to *50 ... in line 35, and RUN again. WOW! Custom particle placing, and custom particle updating. FUN! Particles are low vertices... better bang-for-the-buck than instances, I suspect. But one sad note. Particles don't do godrays. They once did, but that feature was lost in the depth-rendering wars, I believe. Anyway, thought I'd tell you of a few more ways of doing stars... in case you wanted to go experimenting.
  15. set ground.isPickable = false ? *shrug* Ground is intercepting picks? Maybe.
  16. http://www.babylonjs-playground.com/#11GAIH#11 http://www.html5gamedevs.com/topic/27338-avoiding-a-mirrored-360-panoramic-view-fixed_equirectangular_mode/ Nobody mentioned HDR in that PG or thread, so I hope it is on-topic. It was mostly about flipping left/right. Equirectangular was used, though. It is an interesting way to do panos. That's all I got. (a reasonably good memory of previous discussions)
  17. canvas2d

    Thanks N! Ok, .isContainer is events-related, and not anything related to scaling children to fit, or wrapping, etc. Roger that. I should have read docs about it. Good news about S9S, too. Sounds fun! One text2d even if the text wraps tons of times? Nice. Re-wrap on resize/re-scale? I hope so. That's gonna rock! Scrollbars on overflow? Or... stretch height to hold all text? Or... heh. I've been down this curiosity trail before, haven't I? I have some kind of obsession/fascination with containers, I think. thx agn for the work/info, N-man.
  18. canvas2d

    Cool. That dynamicTexture wordwrapping demo I mentioned/showed in my last post... really doesn't work very well. context2d.measureText() is not perfect, I read. I guess it is very important to set the font on the context FIRST, and then call measureText(), or else it calculates lengths based on default fonts. And I think YOU mentioned that measuring text length was not easy for Canvas2d things, too. Yesterday, thiendv asked about background images/textures for labels/buttons, and I didn't know if Sprite2d was allowed to have rect2d and text2d children. Later in the day, I tried it, to make a background-textured label. Worked great. In my studies, I noticed you had .isContainer property, and wondered about its purpose. All this made me think about word-wrapping text2d prims... or possibly using a word-wrapping container which dynamically creates more/less text2d children... depending upon how it wraps. If this container was scaled in size, it could add/subtract text2d prims as its children... in order to display the entire "paragraph". I don't know if your .isContainer would ever be used for that stuff... but... I was thinkin'. Or, maybe power-up the Text2D itself, allowing IT to have multi-lines and do its own wrapping? Nah, that probably wouldn't be a good idea. That would be similar to textNodes inside of HTML divs/spans/buttons. Text2D would need to have sub-text objects, and to do wrapping, it would need to adjust its own sub-text children. (It would be a mini container, itself. A container of sub-text objects.) Weird. Word wrapping is such a pain, but for a Canvas2d word-wrapping "smart container", it would be a double-strength pain, I would suspect. But I think users will want it. Have you (or anyone else) heard-of a user request... to use a single Text2d... to display an entire paragraph, yet? I haven't heard one... but it's coming, I'm sure. Be well.
  19. canvas2d

    Ahh, there you are. Hi Loic! Thanks for all your hard work, and for teaching me stuff along the way. I appreciate that. Ya know... that c2d.createCanvasProfileInfoCanvas(); ... that's a pretty nice "force-assembled" panel. It's cooool. c2d.fastLabel(name, size, text, bordered, clickable, trackNode/origin, scene); ...would sit nicely, right next to it. createCanvasProfileInfoCanvas() needs a friend, right? (ahem) I know, I know, I'm pestering you. But, one section of my new "Labels Tutorial"... would go from "big fat code example"... to one line code example... IF I had that fastLabel thing. My hope for the labeling tutorial... is make simple labels... fast and easy, of course. (I might even try wordwrapping in dynamicTextures) Any chance? I suppose fastLabel() might become a "bootleg" way of doing it, and later, folks would be reluctant to change. They could get addicted to fastLabel, instead of learning the "proper way" of doing it... with the gui lib. I can understand that. *shrug* Any thoughts? Am I being annoying? Hope not. But yeah, you're right. I see the pointer leave rect2d and enter text2d... while slowly moving inward (from bottom). Upper half of rect and text... seem to be pointer-numb... as if a bounding area was only half-height. *shrug* No hurry. Well, I have an itchy hinder to finish Labeling Tutorial, but that can pull into a rest area, too... no problems. "Making it clickable" is a little sub-section of each type of labeling. Mouse events ARE pertinent to the Labels Tutorial... because of that planned sub-section. The Labeling Tutorial is a bit off-topic, here. We could go back over to Tutorial Talk for that crap, I suppose. In this thread, I was essentially hoping for a combination group2d (for tracking), rect2d (for border), and text2d (for label text), all in a single prim2d (with almost all settings... auto-defined). (To cut down the amount of code it takes to make an ssc2d clickable bordered label).
  20. Hey @JCPalmer... wouldn't you crap a log if Jim's last name was "Student"? [ link ]
  21. http://www.babylonjs-playground.com/#1GL6RR#7 Here I changed the moveCamera function a bit. Lines 62/63 ... slewX and slewZ can be thought-of as left/right throttle setting, and forward/backward throttle setting (perhaps -5 to +5 on each). These are WORLD coordinates, so it doesn't matter how the camera is aimed. (Y-rotation ignored). Down in line 77, I changed variable name to "movement" because it is not camera-forwards anymore. It is world-directions... so... I changed name. Now you can look sideways, and still go over ramp... because camera/camMesh is always going to move along WORLD +/- X, and WORLD +/- Z... or both at same time. Camera aiming direction (y-rotation) doesn't matter.... because of major changes to line 77. Hope this helps. Write back.
  22. Hi Matriax. Ahh, Deltakosh beat me to it. Oh well... here's more: A little playground demo... where a "camMesh" box is created, and then the free camera is parented to the box, and then the box uses a handy little moveCamera() function, to get the job done. In this demo, the camera (camMesh) is always moving forward... slowly. (Notice .moveCamera() is called repeatedly from inside the renderLoop at line 63) The reason it is able to climb the ramp... yet not climb the SIDES of the ramp... is based upon the size and elliptic shape... of camMesh.ellipsoid (a vector 3 that determines the scale of a mesh collider). You can play with camMesh.ellipsoid values... while raising the ramp height. If too much raising of ramp, camMesh will not be able to climb it anymore. The edge gets higher than the center of its .ellipsoid size. Remember the camMesh.ellipsoid is the RADIUS of the invisible collider, not diameter. You can view the collision .ellipsoid on cameras and mesh... by creating a sphere of the same size, and parenting it to camMesh. It might help if it is .visibility = .5; (so you can see-through it.) Gravity is also handled... by moveCamera() function, too. Later, when you want to use jetpack cam, simply turn off scene gravity, and use moveCamera() again (with some keypress/gamepad eventListening to determine thrust directions). The only reason camera.applyGravity is not used in this playground demo... is because moveCamera is doing that FOR us. You can do camera moving and gravity work just fine... without using moveCamera() and camMesh. You can control the camera itself.
  23. Cool. The headache part would come... when you decide to make the helicopter body... from 20 spheres (or more). (such as requiring 10 spheres on every propeller blade) As long a you are happy, I am happy. Just.... hurry up and give us a cargo-hook helicopter game to play! Let's go flying! Watch out for those evil down-drafts! We just barely have enough lift... to lift this cargo... and we need to take it across a river, and over some trees... and around the side of a small mountain, cuz we don't have enough lift to get OVER it. Wow! The adventure begins! Oh man... wind-drag on the load, too! "Oh no! It's flying like a ton of bricks". Yep, that's right ladies and gentlemen. It's Wo997's World Famous "Ton Of Bricks" Helicopter Simulator... Gold Edition! YAY!
  24. Cool! Perhaps put Sprite2d behind Rectangle2d/Text2D (with no background fill). Sprite2d is image. hmm... I wonder if Sprite2D can have text2d or rect2d as children[]. Wow. Sprite children! Funny! Needs researching. Update: (for @thiendv) http://www.babylonjs-playground.com/#14IJD3#5 Sprite2D can have children! (like rectangle2d and text2d). Therefore, sprite2d works great for image/textured background for button or label. PARTY!!!
  25. Hi again wo! I saw you talking in the other thread. I have a playground that uses a meshImpostor ground... and then assembles a "pad" (a platform of spheres), hard-jointed together via the old, deprecated scene.createCompoundImpostor() method. This playground was part of the XMAS bobsled/sledding-hill adventure that we tried... for the holidays. The noise-genned ground is ready for animating, too, but I just call its animate function once... to "derive" the initial ground shape. It doesn't work very well, physics-wise, but it might be something fun to play-with. It also has Raanan's cloth code... remarked-out in there. His cloth maker is likely more efficient than my nest for-looper thing. Anyway, might be something useful. I wonder what createCompoundImpostor DOES? hmm. Could it "assemble" a group of many box impostors... into the shape of a helicopter? hmm.