Wingnut

Members
  • Content count

    5,434
  • Joined

  • Last visited

  • Days Won

    113

Wingnut last won the day on July 4

Wingnut had the most liked content!

About Wingnut

  • Rank
    Advanced Member
  • Birthday 12/15/1957

Profile Information

  • Gender
    Male
  • Location
    Bessemer, MI, USA
  • Interests
    3D Web, CSS, HTML, Guitars, NORML, storytelling

Recent Profile Visitors

7,003 profile views
  1. FANTASTIC!! Bogged my browser a bit, but that's a personal problem. Well done! (Wingy dances around like an idiot) You're just "the cat's meow", JK! Early particle-from-pen tests... are being grumpy: https://www.babylonjs-playground.com/#1BTGPV#12 Line 166 seems to be forcing the playground into " Loading assets...Please wait " mode. Apparently, I forgot how to activate a particleSystem.
  2. Oh @JohnK, you do SO MUCH "other" work around here... I hate to see you grunt this. How about... do it ONLY if you think it would be enjoyable and ONLY if you have no other projects happening? You are too kind, and I feel I am using you. I could do the math stuff, too... but... I was hoping that someone could do it... who WOULDN'T go thru 4 nervous breakdowns on the way to success. Plus, I'm pretty loaded... remodeling a severely water-damaged apartment for/with a guy... in-trade for some free rent. (which MIGHT equate to enough $$$ to get a touch screen device to test VJ's upon) So, THANKS John! Only if enjoyable and only if nothing more important is happening for you, ok? If it feels like work, stop immediately, as you have already done MEGA-tons of work on/for BJS/team. (hug) No preset demos needed, either (ok, maybe 1). And I think... only one rotor needed... for MY sought, simple, 5-10 petal spiro-flowers. So, I'm thinkin'... yeah, no GUI = fine. As you say, can be added later, as wanted/needed. Imperfection ok, too. (in case you want to round numbers to hundredths or similar). THANKS!
  3. :) Thx, @Sebavan Perhaps, to keep from flooding the thread, maybe we should stick-with the "I Might Try It" comments, and shy-away from the "Why I Can't" Aww hell... "Why I Can't" posts are fine, too... at least it is commune-icating. heh. Thx for the consids, S! (ps. 3 month wait, no problems) Thx for pinging Jerome, too. Unfortunately, I currently owe him around 83,000 favors.
  4. Thanks guys! Those reports make me happy. I need to bail on those VJ's for a little while, so if somebody wants to advance it... go for it. Each VJ (combination drag-surface and drag-puck) needs to be a single control, and proper onValueChange observing wired-up. Then, it should probably be put into TypeScript. The new VJ control should follow the API used by other GUI controls. (For the foggy, VJ = virtual joystick. I have been experimenting with some simple ones, using BJS GUI, with reports chronicled in recent TWC posts.) ------------------- On another subject... I have a need for spirographs in BJS. Here's a nice starter pack: http://seedcode.com/SpirographN/sgn.html Ideally, all its HTML GUI should be converted to BJS GUI, and use linesMesh instead of context2d canvas-painting. BJS Path2d might work well for this stuff. I don't need as much power as that spiro app has, but it would be nice to match it (adjust-ability-wise). Even a linesMesh version with NO GUI... would be a huge help to me. I WOULD like the spiro-pen to be a mesh, sometimes. I would like to be able to turn-off linesMesh, and sometimes use no-gravity no-emitPower particles, emitted from the pen-mesh, to draw the spiro-flower. I would like to KEEP the "draw speed" feature. To go a step further, I want to modify a particleSystem so that particles have random weight/mass (custom update func). SOME particles fall fast, some slow, some non-dropping. Essentially, that will make the spiroflower be 3D... because it will get depth-ful (deep). If anyone would like to be MY SUPERHERO and build this thing for me us, that would be swell! Those circles/rotors... I don't care if those happen in the BJS version or not. The main two things I need to show in my project... are: - That the tip of each spiro-flower "petal"... is always a loop and never a point (mathematically). I believe this is true, and I need to show it... for a non-math reason. I understand that, graphically, it MIGHT be a single point, because the math might calculate a loop SO SMALL as to go below some epsilon value, and can ONLY draw a single point at a petal tip. - That... no matter the spiro-pen/rotors starting direction, clockwise or ccw, the pen ALWAYS, eventually, returns to the starting point. What goes around... ALWAYS comes around. So, I need a draw-direction setting... ebb spirography / flow spirography - just like the toy - start rotating the spiro-gears in either of two directions. My deepest thanks to anyone who helps me us with this. If someone DOES "run with it", they might want to tell us, here, so there is not any repeated/wasted efforts. I'm in no hurry at all, so feel free to create a thread in Projects subForum and form a campfire team... divide-up the project... have fun. Math-guts, GUI, and render-ways... that's a nice tri-sectioning for a 3-person team. Thx either way.
  5. Wingnut

    collision detection with holes

    Hi guys. SH, I don't have an answer for your last question, but ellipsoid and ellipsoidOffset [and moveWithCollisions()] were created for use-with a built-into BJS system... used for camera->object collisions... for first-person shooter games. When using intersectsMesh(), or actionManager intersection stuff, I have never adjusted .ellipsoid. I think actionManager intersect uses boundingBox and boundingSphere stuff (no .ellipsoid). I could be wrong. You might want to set anymesh.showBoundingBox = true; on some things... to help see what is happening. *shrug* Many of us are learning right along-side you, SH! Perhaps we will all assemble an "Everything you ever wanted to know about colliding" -document/tutorial, later, using your discoveries and whatever other knowledge we can find. ANYWAY... I built a playground version with basic CannonJS meshImpostor colliding. https://www.babylonjs-playground.com/#1ZQS9W#10 *shrug*. Something to play-with. Friction, for spheres... is almost non-operational, due to their near-0 surface-area contact with other surfaces. If you wish... you can reach deep into the CannonJS "native" (lower level) objects/classes, and do this... sphere.physicsImpostor.physicsBody.linearDamping = 0.4; (Found here: http://schteppe.github.io/cannon.js/docs/classes/Body.html You can also see the .fixedRotation property that I spoke-of earlier.) Automatic brakes for roll-forever spheres. Demo: https://www.babylonjs-playground.com/#OJVVA#18
  6. Wingnut

    collision detection with holes

    Hi SH, and welcome from me, too. Sebavan and I talked a bit... in a personal message.... about your issue. We (I) talked a bit about using a small invisible collider in center of hole. We (I) also wondered if your spheres would ALWAYS be spheres, which would allow CannonJS physics engine to use its 'meshImpostor' on the CSG mesh. This would give you sphere bounce-off (like a basketball hoop) IF sphere hit too much edge. SO, may I ask... Will your spheres... ALWAYS be spheres? CannonJS meshImpostor only allows spheres (sphereImpostors) to collide with it (and rebound/recoil realistically). And yes, your idea of making precise collision... using many little invisible colliders... is a good idea. It has been used for a few other BJS projects. Yes, that method DOES have some performance concerns, but still possibly worth testing. You are doing good thinking, SH. IF you decide to use the CannonJS physics engine and meshImpostor collider... there is a performance issue with that, too. Quite a few impact-angle and bounce-off angle math calculations are done by the physics engine. IF the sphere doesn't need to spin after edge-impact, we can remove SOME physics calculations (fixedRotation). *shrug* Thinkin'.
  7. Wingnut

    Camera Inertia Angle

    http://playground.babylonjs.com/#A22EAV Your code had a few non-standard characters in it... and the json parser in the SAVE... was getting indigestion. Now the forum friends can do some studying and thinking. Thx for the PG/code, Lary.
  8. Hi guys. A quick note, if I may: IS _this._deltaPosition an AMOUNT, or a worldSpace .POSITION? IF it IS a worldSpace position... then setting it to 0,0,0 will put the shape-mesh AT that .position... bad thing. :)
  9. Wingnut

    Camera Inertia Angle

    Hi guys! Interesting challenge. Lary... after a click happens, CAN you pre-calculate the needed amount of camera.alpha change... to make the camera point-at the clicked point? Maybe you could make a testing playground... and then we will try to find a formula to calculate that value. IF you can, then perhaps animate the camera.alpha to the new angle. Perhaps put the below function (untested) at the top of your code, which will add an ease-out camera.spin() function to all your created arcRotateCameras. We are attaching a little animation motor to camera.alpha. BABYLON.ArcRotateCamera.prototype.spin = function (radians, speed) { var ease = new BABYLON.CubicEase(); ease.setEasingMode(BABYLON.EasingFunction.EASINGMODE_EASEOUT); BABYLON.Animation.CreateAndStartAnimation('myanim', this, 'alpha', speed, 120, this.alpha, this.alpha+radians, 0, ease); } Reminder... I didn't test it. This playground has a bunch of little animation motors at the top of the code... added to abstractMesh. They could work on cameras, too, after some adjusting. You could make your animation be: spin(amountOfChange) ...or spinTo(newRadianValue). EASEINOUT is also an option. Just some Wingnut thoughts. Might help. Probably not.
  10. Wingnut

    Friendly competition

    Is the contest for... MOST words typed-on BJS forums? I win.
  11. Wingnut

    Stages of Atherosclerosis (Learning Project)

    Welcome aboard, Todd... a good looking scene, for sure. No need for F5 refresh when I loaded it, but I (and others) will keep thinking about WHY F5 is/was needed. There is a scene.executeWhenReady option. I'm not sure if that would apply here, or not. How was "loading..." message inaccurate? Is/Was it still being displayed after everything appeared to be loaded? (thx) Perhaps we should start a NEW issue for that... in the Q&A sub-forum. *shrug*
  12. Thanks. I wish I had a touchscreen mobile tablet or phone... so I could do a 2-thumb test on #55 PG... to see if both VJ's work at the same time (or at all). #56 PG is also here... 2 VJ, fullscreen canvas, no pointerLock version. C'mon, somebody with a touchy-tablet mobile device thing... 2-thumb test this for me and report findings, please? thanks. #57 is another version, in case 56 doesn't start full-screen. Still learning about full-screen and pointerLock... having some inconsistencies here (lines 4/5)
  13. Hi gang. Fresh left virtual joystick testings... for touch or mouse-drag (I hope) https://www.babylonjs-playground.com/#KX33X8#53 Click in blue box and start dragging immediately. A lot of observer code was removed from the "puck" and put onto the VJ's "surface" observers, instead. Mainly, this is because... when a HELD pointerDown observation happens upon VJ surface or upon a button/rectangle... no pointerMOVE observing can happen. We are sort of stuck in a pointerDOWN (which turns the puck ON). SO, making the puck turn ON, and instantly start being draggable (WITHOUT first lifting the initial buttonDOWN)... is pretty difficult. Also, lines 75/76... attaching the camera and/or setting VjSurface isPointerBlocker=true... can screw things up. Currently, in FF, it works pretty good. You can start dragging the puck after first pointerDown (which turns it on). Any pointerUP, after dragging or not, turns puck off. Currently, you can't pass clicks thru the blue-border VJ surface... which worries me. Clicking-of other (z-deeper) GUI or actionManager-ized mesh... thru the VjSurface... is NOT working well, yet. hmm. Allowing thru-the-surface clicking... changes the behavior/functionality of the VJ (so far). But... it might be possible/tolerable to toggle VJ surfaces/rects... ON/OFF in scenes... as needed. Unfortunately, ya need a button to do that... on tablets/phones with no keyboards. C'mon phone/tablet-manufacturers... I NEED a physical meta/control button... on the device case!!! I hereby make this a new world law. heh. Good fun, all in all. Learning learning learning. Branches and experiments welcome. Anyone who wants to corify this (add to GUI controls library)... go for it, please! But, first it needs clean-up and... well... there's still issues... like pointer blockers and attached-to-scene cameras. Oh yeah, and the "no pointerMove observing allowed... while stuck in pointerDown observation" -issue. *sigh* It almost feels like I need an onPointerDownAndMove observer... different/separate from standard onPointerDown and onPointerMove. Originally, this was all started to allow GUI buttons to be dragged around on-screen... until they are within comfortable thumb-reach. That is a slightly different application... than is virtual joysticks. Buttons must stay-ON after drag-into-position, and they must still work as buttons (a switch from surface pointerDown... to puck pointerDown). Erf. My brain hurts a bit, but it's a good hurt. update: PG #55 is a 2-VJ version. Both VJ's are hard-wired to some purple box properties, for testing. If someone would kindly test this on a touchscreen tablet/phone... and make sure both VJ's work AT ALL, and work simultaneously (do some 2-thumb-ing)... that would be swell. thx! Maybe I need a PG that forces full-screen canvas... at run time?
  14. Hi guys. Here's a PG to go with it... see lines 42-55. https://www.babylonjs-playground.com/#08KEYA#47
  15. Hi D. If I understand you correctly, you are talking about putting a container that is big (lots of menu items)... into a container that is smaller (so that the entire menu cannot be seen... just a little 'viewport window'). After you do that, you can adjust the .left and .top of the big menu container... to slide-it-around within the little viewport container. Keep in mind... that the ORDER in which you add controls and containers... matters. That determines which controls have higher/lower z-layering priorities. I have a new playground to introduce... sort-of experimenting with lower-half-of-screen GUI-based virtual joysticks/thumb-drag pads - discussed earlier with @MackeyK24. Lets look. https://www.babylonjs-playground.com/#KX33X8#48 Click once in the blue and red dragging areas... to activate their dragging-pucks/pads/buttons. Button-up, and then down again, and you can drag them. Numbers at console. Notice how they can drag a bit OUTSIDE-OF their drag areas... partially out of view? That movement is done with dragpuck.top and .left... and the reason they seem to "hide" when they go outside the drag area... is because of their addControl ORDER. I think order of adding... is somehow important, there. So, really, I don't have any answers... other than... it just happened that way. The areas were added first, and then the pucks are added to the areas. That COULD be important... to determine WHEN something is hidden behind something else. I hope I have been somewhat helpful. I kind-of new at this stuff, and it surprises me fairly often. Part of the fun! As we learn more, we can all add notes to the docs... little hints and secrets that we learn. A bit more: Dragging an entire container (your menu) that is full-of click-active controls... could be a bummer. You might need to leave a gap between each of your menu controls... where you can go pointer-down on the menu's CONTAINER and not accidentally go button-down on one of the menu controls. Once you can get your menu CONTAINER pointerDownObservable to trigger, then you can drag IT around (with menu container's .onPointerMoveObservable) ...within the smaller viewport container. That should move the entire menu. Don't confuse the menu container (holds all menu controls)... with the "little viewport" container which the menu container is dragged-around-within. You will be dragging the menu container. The little viewport container will remain stationary.