• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by Wingnut

  1. New Idea

    Wow... you guys are doing great! Shooooot, you're both better programmers than I am, so I'm going to steal all your code, okay? Cool. I don't think sprites can cast shadows, but I haven't researched that real well. I think a sprite is a "subMesh" in a way... like a single cell of a wireframed ground grid. So, you might have-to place the sprites onto panels/boxes. Those boxes... can cast shadows. Reminder: You don't need sprites AT ALL... as BJS boxes have the abilities to have an image on only one side, or only 2 sides, or all sides. You can put the .png images into the .diffuseTexture channel of the .material of each box. It might start with a boxmaking func... boxmaker(boxname, position, textureToUse, scene). Uncle Mezzorio's Sprite-Simulating Box-Generator v1.0 - the beginning of a legend. One of the determining factors for "wrapping" a straight line of panels/sprites... is the camera.fov (field of view) with a proper camera.fovMode set, too. Also, the camera-to-sprites distance is important. Camera distance and horizontal field-of-view... determines how many sprites are .isInFrustum (within camera view). Let's pretend we have 200 sprites in a straight row/line. Let's also pretend that... due-to current camera.fov and distance of cam to sprites... we can "see" 7 sprites within camera view ALL THE TIME. These numbers can be easily changed, late-in-the-project, no problems. When user has panned camera left (actually called dolly-left or truck-left) until #1 sprite is straight ahead, you need to have a copy/clone/actual sprites 198, 199, and 200... placed just before (left-of) sprite #1 in the line. This is so that... when sprite #1 is straight ahead, user still thinks they can truck further left, and are convinced that a wrap-around from #1 to #200 will happen fine... IF they continue to truck-left past #1. But code is "watching" them try it, and when they do, POOM, the camera is instantly re-positioned to the END of the line... looking straight-at sprite #200. See diagrams below. Same happens at s#200, at the end of the line. Even though the new camera position is looking-at #200, there are "fake", cloned/instanced/actual sprites #1, 2, and #3...placed to the right of #200. This gives the user the indication that they can continue trucking-right... and they can... but it will SNAP the camera back to looking-at sprite #1, as described earlier. In other words, when camera @ s1, and knowing the camera can "see" 7 sprites inFrustum all the time, then we must put a fake s198, s199, s200 on the LEFT side of s1. User can never truck the camera to the fake mesh, but we fake it... by snapping the camera to s200... SO fast and smoothly... they never even know it happened. Same at the other end. We can see 7 sprites at a time, when s200 is straight ahead. We need to put fake s1, s2, and s3 to the right of s200. Again, they can't truck the camera to those 3 fakes, but the user thinks they can, and when they try, code sees them try it, and we do that fast cam relocation to s1 again. User doesn't notice a thing. A cam relocation takes about what? 1/6000th of a second? (I have no idea, but I bet it is fast). Nice part about it? No need to change position of the panels, or their parent (if they have one)... at all, ever. It's all done with the camera, and/or with an invisible gizmo mesh that the camera is parented-to. The Sprite "line" sort of looks like this... s198, s199, s200, s1, s2, s3, s4 ... s197, s198, s199, s200, s1, s2, s3. \ | / \ | / \ | / \ | / \ | / \ | / \ viewing s1 / \ viewing s200 / User thinks cam truck-left User thinks cam truck-right is ok. It is, but faked. is ok. It is, but faked. Move cam to s200 view. Move cam to s1 view. Understand any of this? I hope so, because I'm just barely hanging-on. This is ONE way of doing it. There is likely more ways, but maybe not better ways. With this method, the "wrap" is FAST FAST FAST, and done with a single line of code, I believe. Putting a BJS animation onto the camera... might be the best way to move view from sprite to sprite. That way, we get the nice ease-up-to-speed, and ease-down-to-stop features of BJS Animation/Animatable class. That will be a smooth and nice way to move from sprite-to-sprite. Ground can re-position left/right using the same method, as needed. Ground MIGHT be parented to camera, and then perhaps that's all it needs. It moves left/right each time camera does so. *shrug* A spotlight shooting straight ahead of camera, parented to camera, might be cool, too. The light encircles the sprite straight ahead... and could cause another shadow. There are other ways to "highlight" one sprite, such as .showBoundingBox, highlightLayer, glow effects, you name it. But putting a single sprite "in-the-spotlight" is kind of cool, too. I might make one of these "sprite lines", later, if nobody beats me to it. But feel free to advance this idea, at will, everyone. I got a bunch of IRL crap to take care-of first, before I can get to this. Party on!
  2. Pardon my interrupt... I need to make a correction to an older playground. In a previous version, I was using scene.executeWhenReady... incorrectly (causing playground loader to 'hang'). Dummy me. I'm getting some good console reports, now, even in mainline. But, it seems Mythros will still be required to put most of his entire project... inside-of scene.executeWhenReady wrapper. Not sure. @SinhNQ - I think the objective is: load one model per call. Models are put into a 'library' (and possibly .setEnabled(false), temporarily), where they can be "looked-up" and enabled/instanced/cloned later. (I hope I said that correctly) Looks like M is building a little in-scene database-o-mesh-refs.
  3. No collisions working on blender model

    Hi there, welcome to the forum. No answers yet, eh? hmm. Ok, here's some things to try. - In Blender ensure your pivot point and ORIGIN... are set to center of mesh. Make sure there are no scene transformations... where the entire scene is off-set, even though the mesh has a nice origin. Sometimes, things can be learned... if you paste your .babylon file into an online JSON file viewer. - Borrow lines 1-33 from this playground, a badly-coded .showEllipsoid func. You can see how to call it... in lines 110 and 120. It might be handy... but no promises. About the PG: WASDQE moves the left cylinder, shifted-WASDQE for the right one. This playground is for an OPEN ISSUE where one collider climbs too high (in order to climb-over the other). This issue should not affect you, yet. Maybe later. heh - Dump mesh.ellipsoid (which is a size) and mesh.ellipsoidOffset (which is a distance)... to console. They are both Vector3-type values I believe. Give 'em a sniff. These values should also be "see-able" within the .babylon file (should you decide to sniff-around within its JSONic ascii stuff.) If you scale a mesh, the mesh.ellipsoid MIGHT need scaling, too. It might not be automatic. This is what setEllipsoidPerBoundingBox func is used-for (line 35). Borrow/use it, too... have fun. These funcs were coded by me, so they are almost SURELY weak/un-versatile/inflexible. heh I guess that's all I have, for now. Feel free to make more versions of that playground, possibly adding your mesh-importer into it, and trying to bring your model into that playground (if you have the .babylon file published somewhere, like a free github acct). Perhaps others will have more ideas. Stay tuned, and welcome again.
  4. syncBoneWithImpostor function help

    Hi @amo yeh No solution found, yet, but... Change 'false' to 'true' at end-of line 62. Does that cause it to start working? I'm not sure what "working" should look-like. Just experimenting... trying to discover something. You know... Wingnut = blind squirrel... sometimes finds acorn, but more likely, deer turd.
  5. @adam, doesn't the assetManager STILL leave Mythros stuck inside of an onSuccess func, unable to bring his/her meshes/library back to mainline code? Seems we USED TO be able to define a few variables at a VERY global level, and then NOT have-to be permanently inside-of any onSuccess or other callbacks. We could have a "get the load done" and then continue-on in mainline. Below, I can't even get scene.executeWhenReady to wait for the import's onSuccess to finish. Seems odd. Here, I've got a classic "hung" executeWhenReady happening (leaves PG stuck in ' Loading assets...Please wait'). I've got some real wide-scope globals up in lines 1 and 2, and I am trying to console.log the loaded meshes array... in about 3 different ways. It seems the ONLY way to get a decent scene.meshes or myMeshes... is line 19, WITHIN an onSuccess func. In line 20 I try to set myMeshes = meshpile (a wide-scope global), but that's not happening. This is definitely a scoping issue, but I tried using assetManager yesterday... on this issue, and I had the same problems. We're stuck inside an onSuccess and can't get out to mainline code. This might be normal, but it sucks. I'm not a very good coder, though... so... closures, etc... not well understood by us rookies.
  6. New Idea

    Not a problem, M-doggy. Doing that is a BREEZE with BJS... and in ANY of about 3-4 different ways. If you wanted, you and I could get the prototype for this done.... in about 10 minutes. Ready? It might be coolest... to make a huge circle of boxes (flat panels). Don't bother with sprites... they're boring. (just kidding) Then yeah, rotate the circle of panels past the camera, or pan the camera around the circle of panels. FUN little experiments galore! And, it need-not be a circle. It can easily be a straight line, too. No matter circle or straight line, it might be wise to parent all the panels/sprites to a central parent. Then moving ALL the panels at the same time... will be easier. Just move the parent, and all the kids come-along for the ride.
  7. Sprite Size

    Note: When I said, I meant console.dir(something). Sorry.
  8. BABYLON.Augmented Reality ... in AR.JS

    ...and sometimes mesh.visibility = [0.0 to 1.0] ...and sometimes mesh.setEnabled([bool]) is cool, too. These 3js folk... (I think JE is from 3js land, mostly)... they just don't know about the object inspectors that are built-into browsers, eh? Console.dir(anything) works pretty good. Certainly easier and faster than reading an API doc. Or, console.log(anything), then go to console and click on 'object' link. I LOVE OI's. Jet-powered learning curve flattener. Ok, hi/bye.
  9. Hiya F! Will your project allow you to set allOtherMesh.isPickable = false; ? Perhaps re-activate all picking when gizmo is closed. Maybe.
  10. You rock, @SvenFrankson! Cool code. Welcome vinhpt. I imagine you could get CLOSE-to sword "trails" by using particles. Kind of "strobe-ish", though - needs some tweaking.
  11. Sprite Size

    Oh... yeah... umm... console.log(staff) is put inside the scene code, and not entered at the console input line. There IS a way to view staff in the way you are doing, but its kind of complicated and not always very useful (it takes lots more typing, too). Instead, try this... var staff = new BABYLON.Sprite("staff", spriteManagerstaffs); staff.position.x = -1.4; staff.position.z = 0; staff.width = .5; staff.height = 3; staff.isPickable = true; console.log(staff); // do it here... good place in the code. After RUN, you SHOULD see 'object' at the JS console... and you can click on it... there. (Wingy crosses his fingers)
  12. Sprite Size

    Put it lower in the code. It must happen after staff has been created. If/When you ARE able-to view staff in the browser's object inspector, you can even type-in new values for its height and width and size. You can type values directly into the object inspector (after a click on the property name), and the sprite will resize on-screen... instantly. You cannot execute "methods" on the staff object... from within the object inspector. You can only change the values of "properties" (sometimes called "members"). In the "old days" this was called "live pokes" (and live peeks) Peeking and poking "live" properties - kind-of fun, high-speed learning. Soon, you'll get object-inspector disease... doing console.log(scene), or (window), or (document), or someMesh/someLight/someCamera. Those are all some big big objects, with lots of knobs and switches. heh. You'll start becoming a mad scientist of demented 3D experiments... trying to cause browser crashes and other good demented things.
  13. Sprite Size

    Yeah, that would be staff.height and staff.width One of my favorite "toys" is the built-into-browser "object inspector". When you open your f12 "dev tools" or JS console in most browsers, and then do console.log(staff); (within the scene code somewhere)... prints the word "object" to the console... along with some other stuff. IF you click the word 'object', an "object inspector" opens, and you can scroll down through a list of all the cool "knobs and switches" that are available on the SpriteClass object called staff. Others use console.dir(staff)... and that does cool things in the JS console, too. And some... go to the "classes list" in the docs, and find "sprite" in the list, and examine the sprite-class objects... in that way, too. Just various toys to help you hack-on sprites. Party on!
  14. Sprite Size

    Good to hear! Mark as solved when you get a moment, thx. (oh yeah, also show us your games when they are published)
  15. Sprite Size

    Hi Mezz Perhaps you are seeking the .size property? You can see it used in our playground's built-in sprites demo. See lines 34 and 43. The "1010" parameter is for setting the square area that each sprite is mapped-to... on the sprite 'atlas' texture. In our demo, it is set to 64, which indicates that each sprite uses a 64x64 square area of the sprite map/atlas. Hope this helps. Hope I didn't say anything incorrect/stupid. (I do that sometimes)
  16. Cutout shadows in custom shader

    Hi Mainequin & Team! I don't know if this applies, but a user once asked about something similar, and we made THIS playground. I'm not a very good coder, so mistakes and unnecessary settings are likely. If this playground is NOT on-topic, then feel free to modify it until it is so. Most forum helpers like to see the issue repro'd (reproduced) in a BJS playground scene. Then everyone can experiment with it, easier. Let me try to summarize/restate. You have an array of mesh, similar to a wall-of-monitors, with a single texture/image that spans all the tiles. You would like the shadow generator to treat this tiled mesh-array as a single mesh/texture, and cast shadows from the non-alpha parts of the texture. Did I restate that correctly? (I hope so) I think the above-reffed playground can show how to do that... perhaps. Without mesh-merging all the tiles, I think you will need to push ALL tiles into the shadowList. It might be the .useAlphaFromDiffuseTexture that is important, here. Anyway, we're rolling with a testing playground, at least. Sorry if I misunderstood the issue.
  17. A vertical shock-absorber-like thing? Spring-loaded? Yeah, I mentioned that in an earlier post, but it's just so boring. I think they are called SliderJoints. Daddy long-legs are so much cooler and offer lots of motion/action. Lots of spring-loaded, angle-range-limited hinge joints. Not sure I can do it, though. I "fought-with" lockJoints most of the day, and although they have excellent springy-ness, I can't seem to get them under control. They are IMPOSSIBLE to "angle". They always want to aim along an axis, and if they get impacted hard, they will actually bounce-around to a different axis (ie. suddenly the landing gear is on the OPPOSITE side of the main craft, where another gear strut is already installed). Keys active: x, y, z, shifted-x, shifted-y, shifted-z (all impulsing). Just one active lockJoint... sticking out sideways. The blue cyl (with boundingBox showing) is parented to the green box. And the joint is set between that blue cyl (bodyA) and the pink cyl (bodyB). Yet the pink bodyB is not rotating WITH the blue bodyA (but it IS rotating-around WITH the green box/blue cyls "group"). The lockJoint sort-of "detected" that blue cyl was parented to green box, so it "attached" itself to the center-point of the summed bounding-area defined by the green box and all 4 blue legs. In brief, it attached to the GROUP that happened when all 4 blue legs were parented to green box. The pink thing IS rotating with the green box, but it doesn't care about the animated rotation of the blue cyl which is directly-attached to the joint. Goofy. The lockJoint sort-of ignores (transform/orientation-wise) the attached mesh IF/WHEN that mesh is a child of other mesh. hmm. The joint's bodyA.shapes array contains 5 objects... a green box and 4 blue cyls. One end of the joint is attached to FIVE objects!!! Weird! I even tried "shifting" 4 of those shapes out-of that array, hoping that ONLY the blue cylinder would become the joint's lone bodyA.shapes[0]. And if you "pop" 4 objects out-of the joint's bodyA shapes array, you also need to pop other things, too. It's a long story, and not very exciting for TWC readers. See lines 458-469 if you're one sick puppy. LockJoints don't seem to allow ANY limits, either. (Can't prevent them from flexing TOO FAR during hard impacts/impulsing)... like stiffness/damping setting. They are a reasonably stupid joint. I only hacked just SO deep, and then bailed. But I was WAY down there, messing with the axes on the joint's rotationalEquations. This PG has a VERY MESSY mad-scientist workbench. Lot's of experimentation debris in there. heh. No joy. Love that springy-ness, though. Can't seem to use it for anything useful. Thx for input. Your idea is on the back burner, but still a good one. SpringJoint experiments are coming soon, but Cannon spring constraints have failed me, so far. Still testing. Even if I AM able to turn-on a Cannon spring constraint, they also look like a "stupid" joint... not having any built-in toys to keep the spring axis-aligned (like on the automobile shock-absorber). To make a spring-loaded "piston" move axially-ONLY, the piston might need "guides"... little physics-active bumpers to keep the piston from tipping/swinging. That should kill FPS rather nicely. One ugly question comes to mind. Can TWO joints be active at the same time, between the same 2 bodies? In other words, sliderJoint + springJoint = spring-loaded slider joint? hmm.
  18. Hi gang! Newbie Wingnut here again, hope everyone is well. Here begins a massive "chronicle" of "Stupid Stuff That Wingnut Talks About". It will get big and stale, but what the heck. 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!
  19. monaco editor folding?

    *nod* Good question. I had my IE in "compatibility mode" for bjs site... caused failed loads. Now it's working again. No signs of folding in IE playgrounds. Oh well. It's late enough in the day to start drinking heavily, so, let's go to the bar, P8, and dump our purses-upon (share our woes-with) some unsuspecting bartender. Maybe some pretty little thing will help me re-orient my lockJoint. heh (see TWC - The Wingnut Chronicles)
  20. monaco editor folding?

    I did a little testing. My IE won't load a playground at all, right now. Still investigating. As for the editor's CSS... A section-of prettified all mentions-of 'fold'... .monaco-editor .margin-view-overlays .folding { margin-left: 5px; cursor: pointer; background-repeat: no-repeat; background-origin: border-box; background-position: 3px; background-size: 15px; opacity: 0; transition: opacity .5s } .monaco-editor .margin-view-overlays:hover .folding { background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHg9IjBweCIgeT0iMHB4IiB2aWV3Qm94PSIwIDAgMTUgMTUiIHN0eWxlPSJlbmFibGUtYmFja2dyb3VuZDpuZXcgMCAwIDE1IDE1OyI+CjxwYXRoIHN0eWxlPSJmaWxsOiNCNkI2QjYiIGQ9Ik0xMSw0djdINFY0SDExIE0xMiwzSDN2OWg5VjNMMTIsM3oiLz4KPGxpbmUgc3R5bGU9ImZpbGw6bm9uZTtzdHJva2U6IzZCNkI2QjtzdHJva2UtbWl0ZXJsaW1pdDoxMCIgeDE9IjEwIiB5MT0iNy41IiB4Mj0iNSIgeTI9IjcuNSIvPgo8L3N2Zz4="); opacity: 1 } .monaco-editor .margin-view-overlays .folding.collapsed { background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHg9IjBweCIgeT0iMHB4IiB2aWV3Qm94PSIwIDAgMTUgMTUiIHN0eWxlPSJlbmFibGUtYmFja2dyb3VuZDpuZXcgMCAwIDE1IDE1OyI+CjxyZWN0IHg9IjMiIHk9IjMiIHN0eWxlPSJmaWxsOiNFOEU4RTgiIHdpZHRoPSI5IiBoZWlnaHQ9IjkiLz4KPHBhdGggc3R5bGU9ImZpbGw6I0I2QjZCNiIgZD0iTTExLDR2N0g0VjRIMTEgTTEyLDNIM3Y5aDlWM0wxMiwzeiIvPgo8bGluZSBzdHlsZT0iZmlsbDpub25lO3N0cm9rZTojNkI2QjZCO3N0cm9rZS1taXRlcmxpbWl0OjEwIiB4MT0iMTAiIHkxPSI3LjUiIHgyPSI1IiB5Mj0iNy41Ii8+CjxsaW5lIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlOiM2QjZCNkI7c3Ryb2tlLW1pdGVybGltaXQ6MTAiIHgxPSI3LjUiIHkxPSI1IiB4Mj0iNy41IiB5Mj0iMTAiLz4KPC9zdmc+"); opacity: 1 } .monaco-editor.hc-black .margin-view-overlays:hover .folding, .monaco-editor.vs-dark .margin-view-overlays:hover .folding { background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHg9IjBweCIgeT0iMHB4IiB2aWV3Qm94PSIwIDAgMTUgMTUiIHN0eWxlPSJlbmFibGUtYmFja2dyb3VuZDpuZXcgMCAwIDE1IDE1OyI+CjxwYXRoIHN0eWxlPSJmaWxsOiM1QTVBNUEiIGQ9Ik0xMSw0djdINFY0SDExIE0xMiwzSDN2OWg5VjNMMTIsM3oiLz4KPGxpbmUgc3R5bGU9ImZpbGw6bm9uZTtzdHJva2U6I0M1QzVDNTtzdHJva2UtbWl0ZXJsaW1pdDoxMCIgeDE9IjEwIiB5MT0iNy41IiB4Mj0iNSIgeTI9IjcuNSIvPgo8L3N2Zz4=") } .monaco-editor.hc-black .margin-view-overlays .folding.collapsed, .monaco-editor.vs-dark .margin-view-overlays .folding.collapsed { background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHg9IjBweCIgeT0iMHB4IiB2aWV3Qm94PSIwIDAgMTUgMTUiIHN0eWxlPSJlbmFibGUtYmFja2dyb3VuZDpuZXcgMCAwIDE1IDE1OyI+CjxyZWN0IHg9IjMiIHk9IjMiIHN0eWxlPSJvcGFjaXR5OjAuMTtmaWxsOiNGRkZGRkYiIHdpZHRoPSI5IiBoZWlnaHQ9IjkiLz4KPHBhdGggc3R5bGU9ImZpbGw6IzVBNUE1QSIgZD0iTTExLDR2N0g0VjRIMTEgTTEyLDNIM3Y5aDlWM0wxMiwzeiIvPgo8bGluZSBzdHlsZT0iZmlsbDpub25lO3N0cm9rZTojQzVDNUM1O3N0cm9rZS1taXRlcmxpbWl0OjEwIiB4MT0iMTAiIHkxPSI3LjUiIHgyPSI1IiB5Mj0iNy41Ii8+CjxsaW5lIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlOiNDNUM1QzU7c3Ryb2tlLW1pdGVybGltaXQ6MTAiIHgxPSI3LjUiIHkxPSI1IiB4Mj0iNy41IiB5Mj0iMTAiLz4KPC9zdmc+") } .monaco-editor .inline-folded:after { color: grey; margin: .1em .2em 0; content: "?"; display: inline; line-height: 1em; cursor: pointer } Boy, that was sure a pile of unnecessary pasting, huh? Looks like she's ready for folding, style-wise, eh?
  21. monaco editor folding?

    A possibility, I suppose. I'm not well-studied in Monaco. I just did a Googus search for Monaco editor folding and then started sniffing-around. Still, no matter how useful, I wish to allow it to be off by default. Something else cool? fo4o8 = (f)oldAll, (o)pen foldpoint (4), (o)pen foldpoint (8). Kind of neat for showing the exact code being spoken-of... for helping another user. That's a pipe dream, though. How about /h143h18? Highlight lines 143 and 18.
  22. monaco editor folding?

    Hi guys. I hope this is up for a vote. The folding glyphs (+ and -) eat-up 3 character spaces, and are annoying to some. This could be the secret to toggle-able folding (if it ever works at all). The folding glyphs/icons could exist by default (all opened, please), but they are not seen/usable until user selects "dark folding" or "light folding" themes (Each would have the CSS adjusted so that the icons can be seen/used). Default themes = not seen. Just some thoughts. I'd prefer they NOT be active, by default, though, on the public PG app. Sorry if I'm being a "stick-in-the-mud".
  23. RayCasting

    Tons of cool toys! Excellent! @Richard C yeah, bottom of sea is MORE THAN simply ground. Other stuff, too. Those other things affect depth-sounding values. Yep, good point. You need more than depth-to-ground. You need depth to whatever is below, be it ground, modeled reef, sunken ship, whale.
  24. Hi gang! Even more fun-with-joints Concentrating on joint1 in lower left corner of box. Lines 394/395 - I'm drilling all the way down to joint1 rotationalEquation1 (and 2) .maxAngle, trying to put some rotational limits on my motor-ready hinge joint. But it really loves to spin, spin, spin. Objective is to allow pink parts of landing gear... to change angle SOMEWHAT when they impact the ground... and the weight of the craft settles-down onto them. Joints don't seem to have a fixedRotation setting. Besides, I don't really want a fixedRotation. I am seeking a limited rotation... preferably with a minimum and maximum angle. hmm. Those 2 code-lines cause an odd pivot-axis angle adjustment. Disable both code lines, RUN again, and compare, if interested. Still learning... experimenting... having good fun. Anyone... join-in, if you wish. Make some playground edits/saves and show us your discoveries. thx. update: Version 18 - Line 331 activates a "lockJoint". When I first saw its name, I thought "How boring!". But, I decided to activate one. Click on the screen to see its wonderful springy-ness! It is exactly the kind of "bouncing" I was looking-for! Sinusoidal oscillation around a single axis, with a "centered" or "idle" position! COOL! YAY! As for WHY it is strangely positioned, I dunno. How to adjust? Not sure, yet. I did some unsuccessful experimenting in lines 319/320. *shrug* Oh what a nice bouncy discovery... the motor-enabled lockJoint! (lockJoints don't have motors, so its motor-enabled wrapper is not needed.) Fun! If I can get them positioned and angled nicely, it should make-for some good springy landing gear. PS: If you "time" your screen clicks well, and you can make the lockJoint switch sides/axes.
  25. Why does mesh with collision rise up

    Hi Mackey. I have no solution but I wanted to add a testing playground. WASDQE to move left barrel, SHIFTED WASDQE for RIGHT barrel. All keypresses use moveWithCollisions (in case you want to TRY TO force the barrels back to ground level - Q and shifted Q). Both barrels (cylinders with shown ellipsoids) are being auto-moved +z with moveWithCollisions in lines 218/219. Both are 12 units tall, and are position.y = 6.01 (just above ground). Ground.checkCollisions is set true in line 94. (disable == no climbing, problem gone). Both barrels climb to a position.y (height) of approx. 12.017 units. Related to barrel height? Both barrels also do an unwanted sideways move, just before beginning the climbing. Related to barrel width? Q and shifted Q can force-move barrels back to ground level... AFTER they are no long OVER the ground plane. I started doing some investigating... but I suck. If I had to guess, we should be checking boundingInfo and boundingBox/boundingSphere. Likely something with .centerWorld, .radius, .radiusWorld, similar. We COULD say that this is GROUND-related ONLY, but I don't think that is true. When colliding the two barrels with EACH OTHER (using provided keypresses), I have seen similar issues. For example, there are problems when the barrels collide from above or below one-another (turn OFF ground.checkCollisions if you do apropos tests). Generally speaking, collisions are off-by 50% of barrel height... or 100%.... exactly those values. That screams boundingbox/collider sizes... radius, center, extends, etc. But I suck, so I could be very wrong. Generally speaking, climbing is caused by two ellipsoids in repeated collision, where the climber.ellipsoid.position.y > engine.collisionsEpsilon-amount above collideTarget.ellipsoid.position.y. (wow, what a sentence) I believe engine.collisionsEpsilon determines how much difference in ellipsoid position is needed... before a 'rub-around' activates. Rub-around = climbs, dives, sideways work-arounds, etc. Axial-aligned .ellipsoids will not rub-around, no matter the amount-of repeated moveWithCollisions() attempts. (hold D key in THIS playground, to see it) I may hijack collision-related portions of abstractMesh and bounding objects... into the playground... and get some console readouts. But I KNOW we can "watch" this happening... numerically, in-console... IF we monitor the correct properties. I'll try to determine how/where, and ALL others are welcome do to the same, of course.