• Content count

  • Joined

  • Last visited

  • Days Won


Wingnut last won the day on August 27

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

4,257 profile views
  1. Ok, thx. Umm... do you NEED to use a property on the shaderMaterial... as your fade-in/out adjuster? Is that a requirement? How about mesh.visibility? (line 50 again) See, post-processes are far downstream from depth/alpha blending/testing, so they are not affected by those things. (hehe, like I have a clue.) Could be true, though. Hopefully, smarter people than I... will comment soon. Hopefully, Wingnut will quit giving bad suggestions and be quiet long enough for an expert to answer, eh?
  2. Hi @thrice and Naz and everyone. Umm, could you gently lower the texture.level? Line 50. You know me... I take the easy way out, whenever possible. This lowers the entire texture level. Perhaps you just wanted the EFFECT to go away, but still maintain display? I would need to turn-on a light in the scene... to accomplish things like that, and the light switch is WAY across the room.
  3. Hi guys... sorry to interrupt. JLH... are you using a ground? Is the ground set .checkCollisions = true? Was the ground created with .createGroundFromHeightMap? (thx) I did a little experimenting... I am unable to reproduce the stuck camera symptom, so far. JLH's camera settings are in lines 55-61. I added two badly-Wingnut-coded funcs at the top... that I have used for other projects... .showEllipsoid() and .setEllipsoidPerBoundingBox(). After activating them in the lines 88/89, I realized they were failing... particularly the .refreshBoundingInfo() in line 6. Anyway, I learned very little... still testing... but in this version, line 98 reports (-infinity, -infinity,-infinity) and that concerns me. Activating line 91 is still causing errors, unless I ALSO activate line 90. hmm. Code: That's all I have. I can understand why .checkCollisions = true on a heightMap ground... might NOT use a standard mesh.ellipsoid. FreeCams with .applyGravity would act very strange if an .ellipsoid was used as a heightMap collider. FreeCams would never fall-to the ground in valleys between mountains.... because the .ellipsoid would span across the valley, mountain to mountain. Just testing, testing, testing, seeing what I can discover. Fellow forum helpers... join-in freely with comments and more playground tests. thx.
  4. Hey @Pryme8, you like cloth physics. Have you seen this: 3JS and Ammo.js. It's pretty smooth. I think you should convert this to BJS, still using Ammo... and then we'll weigh/discuss whether to build an ammoPlugin class. Perhaps Oimo is already a renamed Ammo, eh? All in all, that's pretty nice cloth.
  5. Child meshes don't work with physics?

    Ahh, it's a child of a child. (line 89) yuh, yuh, yuh. That might not work. Make both cylinders be child of handle, no probs. hmm.
  6. Child meshes don't work with physics? test pg. Four non-physics green cylinders... parented-to physics-active red box - zero-G. Screen click fires applyImpulse at red box, red box moves, kids go along. *shrug* Feel free to make changes and do more saves.
  7. Child meshes don't work with physics? phew. For each child impostor... we're headed for line 229 _createShape, which is an extendSize festival. All that extend/extendWorld bbox stuff changed about a year ago, yes? Are we still cleaning-up FRR (far reaching ramifications) (fallout) from those mods to bbox/binfo? I think the boundingBox extends/extendsWorld mods were fairly benign/harmless, though. I found one minor problem with center/centerWorld in the Cannon heightMap code, but DK and I both searched for other impacts within the Cannon physics system, and found none. Still, I think Raanan's words about rotations being a factor... should be thought about. There's lots of child-processing code in that cannonPlugin. Gruesome. I suppose a guy should hijack that code into a playground and start messing with it - near line 97.
  8. Canvas and CSS properties

    Good deal, Mezz! I'm NOT "Mr. Finishing Touches". (There are others here who are REALLY good at packaging, though) I don't place my projects in a "released" or "not released" condition. I'm anti-ownership-ism, so, my stuff is released from the first day of dev, and never with any finishing touches. I doubt I have skills for making a project "finished". But, I'm pretty good-at wrecking things, removing blinders, and pointing-at morally-ugly and stinky things. Got any use for that skill-set? (few do) ANYTIME that ANY project... is deemed to have "advanced" a step... I'll pour whiskey, though. If you have a motor vehicle, I'll help you play with it in a mud-hole, too. I love gettin' muddy. Some of the best times of my life... involved mud... and a lot of laughing. Congrats on the advancement, Mezz. Don't be too quick to label it as "done". The "ongoing development" label is much more fun. Yeah, you have visited "shadows" but have you visited "godrays"? (VLS - volumetric light scattering). Popup HTML panel? Ohhh... Mezz... that is SO boring. Sure, you have good CSS, overflow, scrolling, containment, form widgets, events, etc... but what fun is that? Why not FLY that plane into position, with a "swooosh" sound, and a trail of sparkly particles behind? Wow! Then it rocks a little... bleeding-off its final energy, like an old tin road sign rocking back and forth in the desert winds. A little rusty squeaking sound, maybe. Coooool. Not HTML. A BJS plane with an AdvancedDynamicTexture painted-onto it. Yeah! Then you can come-along with us Babylon GUI experimenters... who are attempting to re-create HTML form controls... using Babylon GUI custom controls. (we're trying to expand Babylon GUI's toolkit) It's a really painful process - I know you would LOVE IT. You have a BIG BIG future here, Mezzy! Much more pain fun ahead! heh.
  9. Child meshes don't work with physics?

    Deltakosh and Raanan (and others) are probably thinking "Wingnut, you are SUCH an idiot"... about now. There's some fancy boundingBox.extends work that happens in the physicsPlugins and physicsEngine-class objects. Kind of scary for an old geezer like me. heh
  10. Child meshes don't work with physics?

    Ahh, ok, yeah, we have seen this before. Impostors out in space, with no mesh near them. Have you tried doing the parenting AFTER all soon-to-be-children... have their impostors installed? Parenting after impostoring. *shrug* (this is the last of my ideas) By the way, when the chairs and table are parented together, and then the parent is impostored, the impostor MIGHT be the extend-sum of all parts. In other words, it might become one big box impostor, not irregularly shaped whatsoever. This giant box impostor "encompasses" itself and all the child parts. It might be one big box. I think it is. I dunno if that matters. Helicopter boy... who was that? Search forum for 'helicopter'... find that forum user. I think he had his helicopter tail-boom... able to take hits... so he must have figured out how to do an irregular compound. But... he might have "jointed" all the parts together, like Deltakosh suggests. Just to add MORE hell, I wonder how child.bakeCurrentTransformIntoVertices() affects the impostor placements. Generally speaking, a bake... leaves the mesh alone, but "resets" its origin .rotation to 0,0,0, its .position to 0,0,0, and its .scaling to 1,1,1. Yuh, yuh, yuh, we're chasing geese, now. See this post by @RaananW, physics god? " this is happening due to a new way to calculate the extend size of the object. So far it worked correctly, the problem here is the rotation (that should be supported, of course). " That thread was about an impostor in mid-air, with no mesh nearby (same issue as Ridge Batty). Rotation, says Raanan. So, if your children have been rotated at all... then try child.bakeCurrentTransformIntoVertices() immediately after setting the child's rotation. Bake them before parenting, or after parenting, try it all.
  11. Child meshes don't work with physics?

    Hi guys. There is confusion here. Although joints can be used to place mesh positionally-relative-to each other in what seems to be a compound structure, compounding via parenting is also honored IF it is done correctly (I think). If I remember correctly, the ORDER of impostoring is important. Try setting impostors on all the CHILD mesh first, and lastly... impostor the parent. Try some tests with that, RB, if you would. Report findings if you would be so kind. thx
  12. Hi gang! Well, today I did some more TRYING... to constrain/restrain (with nativeParams min and max, or any other way I could think-up)... a Cannon hinge joint. It seems these Cannon hinges don't accept min and max like Oimo hinges do. Min/Max are tried in lines 94/95... and seem to do nothing. I decided I wanted to "see" what joint1._physicsJoint.rotationalEquation2.maxAngle does... for Cannon hinges. So, I animated/decremented that value... in line 198 render loop. It isn't the setting I was looking for, but it DID gently rotate the hinge axis, and I got to "see" it. Yay. Then my neighbor "art" came over, and he said "Hey, let's put a sparkly particle sprayer on the end of the pendulum so we can watch its trail." I said "No... no art... this is purely a technical testing playground!" Well, art still got his way... and turned my technical playground into an art-istic playground. Friggin' whimsical neighbors... pfft. (active keys X Y Z, and SHIFTED X Y Z - to impulse pendulum) Classic problem with BJS. Right in the middle of doing work, the playing takes over.
  13. Physics Movement

    Yeah, I don't, either. Are you still mixing physics engine impostors... with mesh.ellipsoid/.checkCollisions? Something to try: After a "jump-upon" collision, down-scale your ellipsoid collider for a moment, and then return it to normal size. No promises... but it MIGHT get your collider un-stuck. A nice test might be... onCollideWithJumpedUponThing... register a new beforeRender... that VERY SLOWLY down-scales/reduces the Y-height of the jumpedUponThing.ellipsoid. See if your player starts sinking into the jumped-upon mesh, or slides off edge, or some other ugly thing. This would tell us IF the size of the collision ellipsoid is being live-updated, even while in a possible "stuck" condition. You might even have to down-scale/up-scale the player.ellipsoid or jumpedUponThing.ellipsoid... in tiny steps... but still in a fast for-loop. You might not need to down-scale very far, though. In other words, if you are collider-stuck, reduce the height/size of ellipsoids by .5%, then another .5%, then another .5%, and then back to normal size. It might only take 1-3 of those .5% reductions... to get UN-stuck. This is hard to explain, but, you can do a FAST down-scale, but the up-scaling back to normal scale... might need to be done in smaller steps. Know why? When player jumps on box, it can land "too deep" into the ellipsoid collider (gets stuck). Then you reduce the size of the jumpedUponThing.ellipsoid, and IF your gravity is still active, player will begin sinking into mesh. Then, if you SUDDENLY go back to ellipsoid full size, you have caused the two ellipsoids to overlap even worse than the original overlap. The player ellipsoid didn't have time to get out of the way of the suddenly-expanding jumpedUponThing.ellipsoid. I would highly-recommend using/improving the .showEllipsoid func from the barrels demo. Seeing your colliders... is rather handy. So... the secret here might be... reduce ellipsoid size fast, but bring it back to normal-sized... somewhat gradually. Not necessarily slowly, though. Do it as fast as possible, but do it in small steps, so the player has time to rise... with the expanding jumpedUponThing.ellipsoid. No promises, just thoughts. Report findings, if you do experiments with this, ok? (you usually do, thx for that) I'll shut up now. byee.
  14. Physics Movement

    I smell something. Smell it? It's like... self-blown ass-smoke. I think Mackey blew some smoke up his own ass. heh. You KNOW what you REALLY want, doncha, Mackey McWhacky? Two legs, each with ankle, knee, and hip joints - full physics. You want to fire an up/forward impulse under the left foot. It launches the shoe... up/forward, bending at ankle, knee and hip joints a bit, and then the shoe's mass drops it all to the floor again. Then the other leg. Then the first again. Pulse, pulse, pulse, the ol' locomotion begins - baby's first steps. Box rocks back and forth just a little... and Mackey's BiPedophile comes to life! Errr... maybe that's not a good name. C'mon Mack... you know you're not satisfied. The gloss-over will come back to haunt you. Truth is, the Unity mover and the BJS mover... both suck, right? You'll need to code up new ones for both systems. No? (I'm just having some fun with ya, M... but I'm right, right?) Jiggle the camera.pos.y a bit when each foot hits the floor? You bet! I'd work on it with ya... in a playground. BiPed Imperial Walker 1.0. Yay! I need the same thing for some landing gear for a flying machine... but the hinge joints need... springy-constraint... just like real knees. I haven't learned to do that, yet. You got time for a 6-month tangent-from-main-project, right M? Winter is coming... let's build legs over the winter.
  15. Hi guys! I see this too, Firefox. Not a problem in IE. Step by step, in playground, in Firefox. 1. Depress left mouse button on canvas 2. Still depressed, "drag" left... until arrow is atop editor area 3. Lift mouse button 4. Mouse-over the canvas again (with no buttons depressed). The canvas thinks the button is still depressed (it pans the camera) There is something strange... regarding mouseOut of canvas... while a mouse button is still pressed. It ALSO happens when canvas-dragging onto the top or bottom menu bars, and releasing the drag... atop those. The canvas thinks the mouse button is still pressed, even though it was lifted when pointer was atop the editor/menu areas. I think the effect is called "pointerLock" and it is seen/normal when playground is in full-screen mode. It is not normal when using split-screen mode. It is somewhat annoying for Firefox pilots, but I have always "worked-around it"... re-clicking/releasing over the canvas... to stop the un-clicked camera panning (pointerLock). It has been this way for quite a long time, afaik. It is likely a Firefox bug or anomaly. Possibly, a point of disagreement between browser makers - about Events Specification interpretation, legacy-honoring, or compliance-with new ways. I have no solution... but perhaps I have verified it, and provided a step-by-step way to repro. Again, I see this in FF only, not in IE. Not tested in Opera, Chrome, Safari, Amaya, etc.