• Content count

  • Joined

  • Last visited

  • Days Won


Wingnut last won the day on February 17

Wingnut had the most liked content!

About Wingnut

  • Rank
    Advanced Member
  • Birthday 12/15/1957

Profile Information

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

Recent Profile Visitors

5,402 profile views
  1. Oh, thx dk. Ahh yeah, adam... hero to all ages... good coder, good thinker. Adam has made a GUI control, huh? *sigh* That rotten son of a guy is SUCH a hero of mine! I wonder if he has the only "outsider"-written GUI control so far. Bet so. Anyone remember when I was mapping ADT's onto spheres to create those round gauges/meters? Well... you know... "painting" arcs/circles (math stuff) is probably a much wiser way to make a circular meter... than... you know... Why am I still talking? Oh yeah... round-shaped GUI controls (with dragable center dot). hmm.
  2. Wow, look how similar a Babylon GUI Colorpicker is... to being your wanted ipod circle. ALL of it... is similar to a thing called a virtualJoystick. It is/was a drag-able touchscreen controller... graphical rings on the screen... drag them with your thumbs on a portable device. I wonder... if we bought @Deltakosh a new speedboat or something... maybe he would down-"hack" his colorpicker... into being an ipod circular center-draggable "thing". He's a great coder and darned nice guy, but this is a rather large request. 4 compass-point buttons around a drag-able center dot. Optional 4 more buttons (northwest, northeast, southwest, southeast). Back-lit, for easy nighttime usage. Wha-da-ya-say, Delta? (or any other coding madman) Have you the time/energy to make a GUI ipod 'thing'? Custom GUI controls. sigh. Look at those cool circles in that colorpicker. I put the colorpicker code... into the PG (remmed-out cuz I couldn't get it to activate successfully, yet) Sigh. A REAL MAN... could make a GUI ipod controller-pad... from pieces/parts of the colorpicker code. (a REAL man). Unfortunately, Wingnut is a scared man. But but but but... doncha think that an ipod control... would be a useful new GUI control and possibly be the basis for Babylon VirtualJoysticks v.7.0? Huh? Have we got ANY GUI virtual joysticks? Maybe they went obsolete. A reminder, Vikk. The virtual joysticks from the old days... are not like my red joystick. They are/were more like what YOU want... a drag-thing to control camera movement/navigation. They used an annoying extra canvas layer. Maybe they still exist. Let's hope not. For ME to modify colorpicker until it became the new ipod-like control... would take about 3 months, I predict. Ow. But... colorpicker sure is a nice, pretty, drag-able GUI controller, eh? VR headset-ready. But but but 2.0... an ipod controller COULD be "pieced together" from the currently-available GUI controls, and work just fine. I know it. So... THAT route could be taken, too... without the need to invent a brand new GUI control. hmm.
  3. Hey CB, congrats on having the longest thread title EVER. Let's see... about 7-8 secs for 200 ADT's? Actually, that's probably expected, considering the amount of work/code/measurements it takes to create an ADT for each mesh. Have you tried adding all 200 textLabel to a SINGLE full-screen ADT, and then using textLabel.linkWithMesh for each? Can you give me a report on your speeds... using THAT method? (thx)
  4. MEANTIME... for fun... let's look at my renderLoop at line 127 of the red joystick demo: scene.beforeRender = function() { animationRatio = scene.getAnimationRatio(); // the same speed all devices subRight = sub.getDirection(BABYLON.Vector3.Right()); subForward = sub.getDirection(BABYLON.Vector3.Forward()); sub.position.addInPlace(subRight.scaleInPlace(-xspeed * animationRatio)); sub.position.addInPlace(subForward.scaleInPlace(zspeed * animationRatio)); if (!stickInUse) { if (xspeed > 0) xspeed -= rampdown; if (xspeed < 0) xspeed += rampdown; if (zspeed > 0) zspeed -= rampdown; if (zspeed < 0) zspeed += rampdown; } } This is similar to the renderLoop YOU will use for your camera mover. See the green lines? Pretend you have changed each 'sub' to 'camera'. camera.position.addInPlace(cameraRight.scaleInPlace(-xspeed * animationRatio)); camera.position.addInPlace(cameraForward.scaleInPlace(zspeed * animationRatio)); renderLoops run continuously. The green lines run CONSTANTLY. When joystick is centered/unused, xspeed and zspeed == 0. SO, there is no camera movement, even though these two positioning lines are always running. Perhaps you can fix your issue more quickly than my slow work. xspeed would be the amount of left/right movement of inner circle. zspeed would be amount of forward/backward movement of inner circle. Right now, the submarine only goes worldspace forward/backward/left/right. It doesn't allow turning/rotation. But take a quick look at THIS PG that satGuru helped me with: First, let's see what the 'wingnut crap' does. You can turn this free camera in ANY direction, and then use mousewheel to go forward/backward along the z-axis. Line 31 is the code that gets the current camera Z-direction. Mousewheel moves camera in camera's Z direction (in camera space, not world space), no matter which direction camera is aimed. Good, right? You want your yellow circle to do the same, right? Go forward/backward along camera aiming direction, yes? Let's make some changes... try to find camera X direction for left/right moving. In lines 31/32, I have made BOTH camera directions... Z and X. In lines 35 and 37, I am using dirX instead-of dirZ. Try the mousewheel. Again, no matter which direction the camera is aimed... camera still moves perfectly left/right (in camera space, not world space). This is what you want your yellow circle to do... when dragged left/right, too, right? @satguru's lines 35 and 37 uses the very same .addInPlace as our two green lines above, eh? So... your renderLoop for your camera mover... will likely also contain two lines like 31 and 32... which are camera directionX and directionZ getters. This is so we can move your camera along camera-space X and camera-space Z, instead of worldspace x and worldspace z. Anyway, I thought I would show you these things, and perhaps... you would have enough "stuff" to fix your issue yourself... without waiting for my slow testings and jQuery problems. xspeed and zspeed can be positive or negative... no problems. Your yellow circular touchpad values can do the same. When dragged down, it can produce negative z values. When dragged up... positive z values. When dragged left... negative x values. When dragged right... positive x values. The secret is... constantly TRYING to move the camera... in the renderLoop (whenever an Xvalue or Zvalue is produced by the yellow circle drag). I will keep working on the playground version... hopefully with help from jQuery pros. You, my friend, now have everything you need to fix your own issue... if you wish. You might be able to do it faster than I. Good luck, if you try it. Sorry for long post. Update: Just for MORE fun, let's try a camera-mover renderLoop (lines 118-139) on our red joystick. Works ok, eh? We simply "feed" the beforeRender func... a positive or negative xspeed, and a positive or negative zspeed. My "rampdown system" isn't working perfectly, so you might see a little camera "drift" after joystick is released. But... this beforeRender function is essentially the same one you will use. It is constantly watching-for changing xspeed and zspeed values, and adding them to the camera position. If you can make your yellow circle... produce some xspeed and zspeed values, you are ALMOST done/fixed, yes? Good luck. May your horse be with you.
  5. Wingnut having troubles with .draggable. I'm not very good at jQuery. In your code, you are using a variable called 'ui'. I don't think I have that available in playground, so I just set it empty in line 162. Also, I changed #inner to #innerpad ... no big deal. Also, changed the document/scene isReady method... WAS line 165, now line 166. No biggie. Watch JS console. Line 167 working fine, line 169 working fine, but line 179 is dead. (see error dump in console). .draggable is not function. I'm not sure why it is broken, but I will keep working. Help from anyone... highly welcomed.
  6. Scale mesh during velocity

    Hi kraftwer1. Welcome aboard. Hi everyone else, too. Do you need smooth-scaling, krafty? Must the scaling be gentle, or can it be in distinct steps? Anyway, I had to experiment. Currently, the small gray ibox and its impostor... is attached via joint1... to the green player box/impostor. ibox does the moving, and green box is joint-dragged-along via forces passed-thru the joint. You can use up/down arrow keys to move the ibox along z-axis. (x-axis moving also works, but auto-scaling is not yet programmed for that axis). You can also turn-on auto-velocity by enabling the code in lines 93-102. The manual-moving is done in lines 116-136. Right now, I am NOT copying the linear and angular velocity from previous impostor... to the new impostor that gets installed automatically after a physics-active shape... gets scaled. Instead... I re-add the joint that connects ibox and green player - in lines 123 and 134. It works... sort-of ok. You can re-activate the oldImp->newImp velocities-copying... by activating lines 118-119, 121-122, 129-130, and 132-133. This makes things act a little differently for manual-moving. Remember that when a physics-active mesh is scaled, our plugins (actually, our physicsImpostor wrapper-code) automatically disposes the old impostor, and adds a new one. (it's called a forceUpdate, I believe.) You can see that activity... in this area of our physicsImpostor wrapper: It is a feature, and is the only way to make a rigid body act any-what "sane" after a scaling. It CAN be disabled via hacking the wrapper (over-riding some/all of our wrapper), but after that... troubles/challenges. But still, it would be a cool adventure. Your physicsBODY really needs to change from rigid, to dynamic. A gruesome challenge. No indication of allowed rigidBody scaling features.... is seen in either of the 3rd party physics engines. But, if you want to "go deep" and "go native" (dive UNDER our physics plugins/wrappers)... you might be able to use dynamic/soft bodies. I'm sure not qualified to talk about that stuff. I just make goofy playgrounds. Speak of which... In THAT playground, the entire BJS physicsImpostor wrapper/class has been "hijacked" into the playground (for hacking fun). Wow, huh? Around line 213... perhaps adjust-to: if (this.shape != player) { this.forceUpdate() } // tweak as needed. That would prevent a shape scaling... from disposing old impostor. But that would be only the START of the needed hacking to convert from a CannonJS rigidBody... to a dynamicBody. Greasy deep hacking. I hope this has been helpful, and I hope I didn't say any incorrect things.
  7. Oh is that right? Sorry. Well, I can't seem to determine HOW the yellow circle gets its position dragged-around, speak nothing of trying to get it active in the playground. (I'm not the smartest guy in the world, though... sorry). Can you help me with the yellow circle/square in the middle? Can you show me how to make it drag-move and produce values based-upon its position? Maybe others have ideas. I need that dragging to produce values, just like my non-DOM red joystick does. After I get the yellow circle (yellow square in my PG demo) to drag-position and return usable values to me, THEN I can try to use those values to move a camera. What I would do if I were you is... use BabylonJS GUI system... to create the keypad. Even then, I'm not sure that I can drag-around the yellow circle... unless we make it be a sprite. But... there IS paddingLeft and paddingTop on BabylonJS GUI controls, and a markAsDirty() which has been seen doing live-updating of AdvancedDynamicTextures (the basis of BabylonJS GUI). Would you entertain the idea of switching to non-DOM buttons on the keypad? If we do this, the GUI becomes usable for VR headgear, too. Conversely, if you use a DOM version of the keypad, VR headgear folk won't be able to see/use it. Thoughts? (from anyone/everyone, please)
  8. I think that's where that draggable yellow circle is done. I don't foresee me being able to reproduce that in the playground. Sorry. It would take me forever to learn jquery-ui. Perhaps there are others in the forum that have experience with jQuery UI that can help.
  9. Absolute positioning

    Hey, congrats, Topper! I did a little indent-adjusting on #25... so I could more-easily see your work. Your scene looks great. Nice work. I bookmarked its URL.
  10. Where are stored advancedDynamicTexture ?

    AdvancedDynamicTextures (ADT) have a cool .level property, too, just like ALL textures. It is like a brightness knob. Default is 1.0. Lots of people forget it exists. Great for fade-in and fade-out GUI.
  11. Yay, sparticles (sparkly particles) are working again. (Wingy dances around like a chicken). There was a little bug that DeltaFlyer fixed for us. Another, you say? (Recently updated to utilize the new non-offsetting setPivotMatrix feature.) (might be memory-leaky or somehow CPU-heavy) Fireworks junkies. That's what I and all glitter-addicts... really are. I love fireworks. Another one? Ok. 6-planes with PS emitbox covering entire plane, and using very short maxLifetime. PS sequences thru all 6 emitters, constantly. Activate line 185 to "freeze" the particles after 3 seconds. Fun stuff. Okay, time to get to work. In our last episode, we put a picture inside the GUI fonts... We also did some VERY SLOW color speckles inside the fonts. The real fun... is in mixing "sparticles"... with the GUI. Here is my first attempt. Just a plane-shaped 'emitBox" behind our message... I am still too scared to try repeatedly-painting a renderTargetTexture of the panel-o-sparticles... INSIDE the fonts. But a guy COULD (i think)! Back to our image of water rings... INSIDE the fonts. This time, I have turned-on line 304... which makes the image paint into the fonts over and over. Look at the frame rates. Pretty muddy, eh? *nod* Subtract another 10%, and we can predict the frame rate... IF we ever decided to grab the sparticles panel into a renderTargetTexture, and use THAT as our ANIMATED inside-the-fonts image. Sparticles... INSIDE THE FONTS! How cool would that be? Perhaps I don't care HOW SLOW that would be, I may need to see it done... out of pure curiosity. So, who is a pro at renderTargetTextures? Are there OTHER ways of showing the sparticles (sparkly particles) from PG#60... INSIDE the fonts ONLY? Layermasking or renderGroups or blendingModes or some other complicated thing? I would LOVE to see fully-animated sparticles... INSIDE the font volumes. Anyone want to try it? (please). I need to woof a bowl of Ralston and go do some snowblowing. We got a little snow last night, and the mailperson paths and driveway... need cleaning. Ahh, thank goodness spring is near. Snow is fun, but sometimes it lasts too many months. Snowblow on!
  12. CellShading post-process

    Ahh, that explains a lot. Good. You're probably going to be ok, then. Yeah, Naz has Shaderitis... a disease that affects people when they start understanding shaders. The whole world is worried about Naz, but he's pretty much a genius. Scary-level intelligence. Pisses me off. (just kidding, I love the guy and want him as my next-door neighbor) Cell shading... pretty cool effect. I PG'd the cell shading demo from the main website. I haven't tried to adjust/fix the texture paths, yet. Not sure how to do that. Let's see, if I may re-state the issue, Dad72 wants to have ONE cellshading post-process... but it "effects" all materials in-scene, and perhaps optional .includedMaterials array. Is that correct, Dad72? Fix me as needed. Yesterday... I was thinking that MAYBE... this is a camera effect. If EFFECT ALL MESH is wanted, then... this feature would be similar-to "sepia" and "black and white" post-processes. Not sure if cell-shading CAN be a camera effect. Not sure if this is objective. But, still, I report my thinking, because I am yappy.
  13. CellShading post-process

    @BitOfGold - that's one of the weirdest playgrounds I have EVER seen! Did you make that? What kind of beer do you drink? You must be reading the docs or something. I'm worried about you. I bookmarked that PG, but I'm afraid it will burn a hole in my bookmarks DB, fall-out on the floor, and my dog will eat it. Then my dog will be strangely lit for the rest of its life.
  14. I am having problems programming yellow drag square, though. I dunno how to do drag on that. Can you help? Others? I cannot find way to drag-move yellow square... and get values of drag amounts and directions. Right now I am stuck.
  15. Absolute positioning

    See, that's why @JohnK makes the BIG money. Thx JK!