• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by Wingnut

  1. Me not smart enough, either. I think it is a boundingBox issue... but I've said this a few hundred times before. It is FAR-reaching... affects physics, affects the collision ellipsoid issue that I'm wrangling... it's a big and important bug/issue. None of the big dogs seem to be losing any sleep over it, which I totally don't understand. Even the little guys should be "on this", right now... but it seems few care. As you know, the people sitting around this campfire... none of us have our "Class-A Pyro-Technics license" and so... we stir the fire with our sticks... fairly aimlessly. heh. We're just stirring and staring and drooling in fascination... with the campfire. There is a type of mesmerization that happens... when campfires are stared-at. Sometimes there is more drinkin' than thinkin' My best skill is in building playgrounds that test/prove stuff. What to do after something is proved... well... that scares the hell out of me. I could make a mistake that would burn down Babylon.
  2. Latest: This PG is for climb-over/dive-under testing. Only barrels. Left barrel is the "mover" and its Y position is precisely set in line 270. See info in line 269. Hold down the D key. Keep holding it, and eventually see barrel (left) "climb-over" barrel2 (right). Clearance height is 36 - an interesting number (see more below). Needless to say, things are way way wrong. Mesh are far apart from each other... and still causing collision. Set line 270 Y value to 24.0, (RUN, then hold D key) and we get "dead stop" collision. Set line 270 Y value to 11.9, and we get "dive-under" (hold D key for a long time, it will dive). Let's see... 24.0 - 11.9 = 12.1. The barrels are 12 units tall. Hmm. All console reports are ellipsoid sizes, not positions. Right barrel (barrel2) is at Y-position 6, half it's height (line 292). No barrel .ellipsoidOffsets are set. Actives keys are WASD (laterals) QE (altitude) R (reset mover) I think... we got trouble... right here in River City. Continuing tests. I'm too scared to try a 2.5 version. hehe I have a collide observer on barrel... at line 282-285. It is working, but its red text colorizing... is over-ridden by line 187 which happens every keypress. De-activate 187 to see text change to red on-collide. Unfortunately, there is no barrel.onCollideClearedObservable ... to change text back to yellow when collision has cleared. I guess I could TRY to code one.
  3. Thanks guys... these look very interesting. At least some folks are thinking about it, eh? Unfortunately, there is no mention of MIDI in the html5 spec. Not that there SHOULD be... but... I think the audio element is not being considered AT ALL... for playing midi files. That's sad. This probably means that only <embed> and <object> can play midi, and they will hand-it-off to system... guided by the .mid mimetype to find a player. Compared to an .mp4 or .wav source for an <audio> element... umm... I don't know how it compares. The <audio> element seems to have quite a few limitations for the allowed file/mime types, (.mid apparently isn't one of them). <audio> probably uses a player built-into the browser, or something like that. "Stream-audio" (samples) like .wav, aiff, mp3, etc... don't need access to the wavetables on the soundcard/on-board audio. Only midi needs the wavetable... to get its instrument sounds. hmm. Thanks for the responses and research, guys. Reading reading reading.
  4. Hi gang. Question: Has anyone thought about sync MIDI to scene events? MIDI sequences allow insertion of SYSEX messages... and often these SYSEX messages (among the note on/off data)... contain something called MMC... midi machine code... used to automatically turn knobs/adjust settings... on certain midi playback gear (such as soundcards and midi synthesizers). But we demented experimenters... would LOVE to access those sysex messages... and make our 3D mesh do things... at that playback time. We (I) want to make my mesh... dance to the beat of the midi song. If I insert sysex messages into my midi song, and IF I can "see" those events happen with a scene observer... that would just TOTALLY ROCK! (literally!) I know @davrous is a musician/composer, and he knows some seriously-advanced stuff about JS audio. I hope I can "entice" him to come aboard this cause. Also, I don't want to use code to play the song, noteON-by-noteOFF. Ideally, I want to insert an HTML <audio> element into the dom tree, and if the song contains sysex messages of type-BJS, I want them to activate sysexMessage observers in the scene. Would THAT be cool, or what? You ain't NEVER seen "Mesh'n'Light Shows" like the ones Mr. Wingnut could produce... if that "choreography system" was operational! YUM! UberYUM! Ok girls... can it be done? Is there a wall to cross? A river to ford? Do we have the bridge-making gear? Thoughts welcome... any thought from any one. Thx! (Again, let's NOT make scene code play (poke) each note, step-by-step. That type of system will not stay in-tempo. Let's avoid that idea.)
  5. Hi D. Yeah, thx. Actually, hmm... in MS land... I think there is a midi-mapper thing. The only part I would be interested-in... is "intercepting" the midi OUT data. I have no need to trigger mesh with midi-IN device, but others might, someday. Users are allowed to select which "player" handles their .mid mimetype, I guess. Do all these players... use a "mapper" of some kind? (asking anyone). Wouldn't it be great if the JS object... could interface to these mappers... AS IF the JS object were a midi hardware device? Perhaps read-only, from the mapper? hmm.
  6. Realtime song gen, right? Can't do it. Outlawed in the first post. Song won't stay in tempo... latency problem due to morphing spherical harmonic that Elderwolfy put into the scene. Gotta get sysex messages from midi file... real time, while being played. No cheating. The midi port or soundcard... is the boss... sets the pace.... stuff like that. If song tempo-slips at all, we're all gonna be arrested for interference with hardware.
  7. LOL! What a great helper you are! (Wingy hands you a broom) Here... keep the thread clean. And don't molest the girlies. But yeah... asking JS to reach-across into... soundcard-land. Or... into midi-port land. hmm. Or asking soundcard-land to yell at JS when you see a JS-targeted SYSEX message roll-thru. But this is important. This opens up... webGL movies.... all based upon LONG midi file. Could be a 24 hour song... if your webGL story takes that long to present. FUN! Some events... could be told to start .wav/mp4/whatever files... too. Want your mesh talking to each other? No problems.
  8. Latest... is #28, now. I'm doing some measuring in lines 23-25, making sure dude's sphere is exactly the same size as dude.getBoundingInfo.boundingBox.maximum.scale(2). It is. I also activated line 4... this.refreshBoundingInfo(); SOME forum users might have noticed that I have been "chasing" an elusive "difference" between BJS 2.5 boundingBoxes and 3.0 boundingBoxes.... for over a month, now. So, just for fun, I fired-up #28... in BJS 2.5 mode. vs. Differences! Positioning differences, not sizing differences. hmm. I'm still looking at stuff done in this commit, but I'm not sure of the purpose of these new "world" methods... introduced in 3.0 (centerWorld, extendSizeWorld, maximumWorld, minimumWorld). ---------------------------- Off-topic stuff ------------------------------- Is BJS going out-of-business? Seems sort-of ghost-town-ish 'round the forum. Maybe everyone went GearVR coding. :x A special thanks to @jerome for doing some fairly-recent inside-the-ts documentation. Way to go, Super-J! Don't shoot yourself if the BJS ship is going down, J-man. It's all for the greater good (I hear). (Wingy chains-open the Gates of Babylonia, affixes padlocks to prevent the doors from closing, and swallows all keys.)
  9. Hi gang. While I'm waiting for anyone else to verify this physics/boundingBox issue, I wanted to point-out something else. User @ben_a_adams, who kindly refactored our vertex buffers... making them "interleaved" (sounds scary), once provided a nice link to an English talk about networked physics. Worth a view, I think. Thx Ben... and Glenn. That Glenn Fiedler guy says "Quaternions" really fast! Listen carefully. heh. Also, when he says "at-rest"... that is the same as our "isSleeping". He also says "at-rest" very fast. Fast talker... but... Glenn has definitely done some comprehensive (meticulous/detailed) tests about networked physics. He summarizes the different methods... real nicely. (~ 1-hour video presentation) I even understood some of it! Wowzers, Penny!
  10. 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!
  11. Alright, as predicted... mesh.getBoundingInfo().boundingBox.maximum (and .extendSize) are reporting better values. Line 43 this.ellipsoid = bb.maximum.scale(2); ...does a pretty good job at setting our spheres to match boundingBox size. this.ellipsoid = bb.extendSize.scale(2); also works. Not sure which is wise way. Perhaps STILL keep ground.checkCollisions = false; I tried applying dude.ellipsoid.scale(number)... but no success yet. Likely a Wingnut mental problem. To be safe, perhaps adjust .ellipsoid and .ellipsoidOffset (if needed) BEFORE creating clones, and before calling our custom funcs. This got us VERY close, eh? YAY! Easier than adjusting manually. Player is still Z-thin, though. Depth-thin. Not sure why. More soon. Possible issue: Are red spheres SOMETIMES below ground and SOMETIMES above ground? hmm. The red conestack spheres seem too tall. Merge-related, I think. Testing. Latest: [link] I did some gruesome stuff in lines 89-95, trying to get a thicker ellipsoid for dude. Also activated collision. Active keys - WASD to move laterally, Q/E to move up/down, Z/C to Y-spin for no real reason, and R to reset player. Issue: Hold W to back-up player into wall (or travel behind wall then collide from behind). Collision happening too soon. There is still a gap between player and wall... when collision happens. Problems. Possibly, invisible dude.ellipsoid is bigger than my dude.ellipsoidMesh sphere. Not sure, yet. Lots of dive-unders. Still learning. Perhaps time for a break. Need to examine dude.refreshBoundingInfo(); too. Not sure what its purpose.
  12. Okay, I did some "bakery tests". Time to make the doughnut holes. Geez, what a beast. But better. Better butter makes a batter better. (never mind me, I'm trying comedy, and failing) heh Lines 92-96. Phew. First the scale-up 10x in line 92... then I bake THAT. Cooool. Baking sort of makes the 10x size... become the mesh's "natural size". After any "bake", the mesh .position, .rotation, and .scaling values... are "nulled" to zero. "Naturalized" SO, I baked-in the scaling big-ness, then I dropped him into the floor halfway, then baked him AGAIN ("naturalized" origin and pivot points to waist-level). Double bake! Then I brought him back to floor level with line 96. He's looking pretty good. Line 122 x-rotate test... rotates him at waist-level. SO... baking worked well, and it makes the house smell great. I am still working on .setEllipsoidPerBoundingBox(). I HATE bounding boxes... but... I think I will get better values from boundingBox .maximum and .extendSize and .center... now that I "baked the scaling". I was getting really small numbers from bounding box measuring tests... but I think that is because the 10x scaling wasn't baked-in. The boundingBox wasn't updated after I scaled dude 10x. No 10x scaling on your player, so no issue for you... about baking-in a .scaling. But you can use that "sink-into-floor bake"... for your player, I think. More soon.
  13. Hi Tom, thanks for doing tests. Good ideas (using parenting and scene). Parenting CAN be an issue IF the sphere changes position when parented to player (non-moving player). Is sphere/ellipsoid at player's feet, no matter parented or un-parented? Should be so (before moving player). I think this happens because player origin or player pivotPoint is set at player's feet (possibly settings in modeling software). See [#20]... line 115. I put tmp rotation around x. We can see that "Dude" has his pivot point LOW. Origin is LOW, too, because when I scaled 10x in line 95, he got ONLY taller, but his legs did not extend thru floor. He ONLY scaled upward. YOUR player might do the exact same thing... when adding simple rotation animation like my line 115. Your player will likely x-rotate around pivot point at his feet. We PROBABLY want him spinning around his belt-line/waist... but maybe not. Look at line 92. That is a setPivotMatrix command that you can play-with. It moves pivot points but not sure about origin. Not sure if useful, but it is something to test. This is ONE method to try/test. --------------------- There is another method you can try. Do this BEFORE any calls to showEllipsoid(scene) or setEllipsoidPerBoundingBox(scene)... 1. Position player half-way into floor (so player legs are below floor). 2. Call player.bakeCurrentTransformIntoVertices(); 3. Return player position to original position. RUN. After that, is sphere in center of player? Maybe. Pivot point might also move to center, and without need for setPivotMatrix. Experiment and learn, and then report discoveries, so everyone can learn what we learn. (thx) If that sucks, maybe need some changes in modeling. Not sure. I think, in Blender, pivot point and origin are not same thing. You might need to learn about these... in Blender docs. -------------------- Another method... maybe the BEST method... Set player.ellipsoidOffset = new BABYLON.Vector3(0, halfHeightOfPlayer, 0); I haven't learned how to calculate player boundingBox height, yet, sorry. But you can probably just use your eyes and guess half-height of player. This should move collision sphere upward.... and WITHOUT needing to bake, or setPivotMatrix, or do modeling changes. I think this is .ellipsoidOffset purpose. I am still learning, though. update: Tests look good - line 93. -------------------------------------------------------------------------------------------------- Now let's talk about this... game.scene.registerBeforeRender(function () { if (!mesh.intersectsMesh(game.gameScene.ground, true)) { mesh.position.y -= 0.1; } }); Good fake gravity, but it ends too low. This finishes with player boundingBox intersecting ground. No good. Constant collision.... bad performance. I think you can fix by doing this... var oldPositionY; game.scene.registerBeforeRender(function () { oldPositionY = player.position.y; if (!mesh.intersectsMesh(game.gameScene.ground, true)) { mesh.position.y -= 0.1; } else { mesh.position.y = oldPositionY; // exit intersect condition/state } }); IF there IS intersection, we move player BACK-TO previous position.y. This sets player OUT-OF intersection, and should improve performance during player moves. We never want constant intersect or constant collision. IF you change origin in Blender or use bakeCurrentTransformIntoVertices() method (if that works), you will need to increase player.position.y to get player feet at ground level. No problems there. This fake-gravity code should still work fine. It is best to set player.position so that feet are 0.21 above ground. This will prevent our "fake gravity engine" from accidentally leaving us in boundingBox intersect state. Avoid constant intersects with ground. If ground.checkCollisions = true, avoid constant ellipsoid collision with ground, as well. Okay, again, thanks for doing tests and reporting info. Nice work. Keep going... you are becoming collisions expert. We will add our information to BJS collision docs, alongside @Dad72's demo (section 4), which is good, but it doesn't answer our big questions. (WHEN/WHY do moveWithCollisions() ellipsoid colliders... climb-over, dive-under, go-around-to-left, go-around-to-right, or dead-stop with no go-around at all.) I want to know that answer. I think ALL collision-ellipsoid users want to know that answer. We will soon learn when/why. Maybe Dad72 already knows answers to that question. He has done MUCH work with .moveWithCollisions(). I think that function... was HIS IDEA... about 2.5 years ago. VERY useful func. We MIGHT be able to add some features to moveWithCollisions()... that prevent various types-of "glance-off", especially climb-over and dive-under. More soon.
  14. Latest Update: [#17] - Not much progress on setEllipsoidPerBoundingBox(). All it does is make all ellipsoids be sized 10, 10, 10 in line 48. But showEllipsoid() has sphere.position PERFECT. None of the mesh have .ellipsoidOffset setting. The only mesh that needs one is dude (name = Man). He was scaled-up 10x in line 87, and his cyan sphere has not yet been re-centered for that. Red spheres are the conestacks (tree limbs)... and inside the reds, there are slightly-down-scaled white spheres (the tree trunks). I will continue efforts on setEllipsoidPerBoundingBox() func. Lots of playing-with boundingBox properties/measurements... needed inside THAT func. I am not very good at that. All help welcome. It won't be long until we can SERIOUSLY torture moveWithCollisions(). I'm looking forward to it. Merged meshes and clones both seem fine, but instances aren't working, because instance.showEllipsoid() and instance.setEllipsoidPerBoundingBox()... NOT FOUND on the instances. Instances seem to be "dumb mesh" to a degree. We could force those funcs onto the instances, if need-be. I can probably include the trunks in the conestack merges, but, for now, let's KEEP the trunks having separate ellipsoids from the cones/limbs. More soon. (I'm SO SLOW, huh? sorry.) Reminder: We have no .setTarget() or .lockedTarget on our arcCam, so control-dragging should allow moving its target (for easy viewing of stuff).
  15. Alllllllllrightythen. Trudging-on... New .showEllipsoid() func... somewhat operational in lines 2-22. New .setEllipsoidPerBoundingBox() func... barely/badly operational in lines 24-42. I'm not testing any movements or collisions, yet. Still trying to get nice ellipsoid sizing and alignment without hard-coded (manually-set) values. I want to derive/calculate ellipsoid sizes/positions, automatically. Then we can kick some butt... learning about .moveWithCollisions(), eh? (such-as WHEN does it dive-under, when does it climb-over, when does it go-around, and when does it stop dead.) We might even learn WHEN does it get stuck, eh? Lines 39 and 40... bad code. Still, it made dude's ellipsoid (or ONLY it's yellow sphere) be same height as dude boundingBox, and ALMOST same width, but not near same thickness. Ellipsoid is too flat. Also, yellow spheres on wall, barrel, and tree trunk... bad height, so far. Better code needed. Warning: Maybe only my yellow sphere is too flat or too short. Still testing/learning. Don't trust yellow sphere to match mesh.ellipsoid size or position, yet. Sync not yet proven/tested. I'm still working on that, and can use advice/thoughts/code. .showEllipsoid() and .setEllipsoidPerBoundingBox() are not working on merged mesh, so far. Might never work on them... not sure. Also not sure about clones and instances, yet. More tests/reports soon. Anyone... feel free to advance/experiment... all knowledge/info warmly welcomed. (thx)
  16. No fellow testers/helpers/experts, huh? Darn. Oh well, my weekend gigs are done, now, so I'll get back to work after some rice krispees and some sleep. Maybe I should dress-up the thread like a Jacob's Ladder, so we can get some participation, eh? Phew. Cya tomorrow.
  17. Wingnut has a dumb idea, as usual. Use a decal. Unfortunately, decals are not really dynamically updatable, and they are square/rect-only, at this point. If a decal could be shaped by the shape data of an extrudeShape, we might have a chance. But decals are a clipping festival inside their code, and I'm not sure if they can handle being ANY shape with ANY number of shape-points. They would HAVE TO match shape and size perfectly, or else they might wrap onto sides of mesh, too. John... this reminds us of Neshville, again, eh? (No, NOT the country music town in Tennessee USA). Nesh 108. Overhead cam, black background, screen-grab RTT frame, send it thru Nesh's image thickener, use as cap. [Wingy slides a texture into the gel-frame of a spotlight, and tries to use this "slide projector" to project an image onto a cap, but then laughs at himself. Then he accidentally stares into the spotlight and burns his retinas.]
  18. Hi Tom, thanks for good investigation and report. Good info... but... ... you had boxImpostor on player, yes? That should be fine. But maybe it was too thin and too tall, in some way. More mass needed? *shrug* BoxImpostor should AUTOMATICALLY avoid tip-over because of flat bottom. Perhaps too tall and too small X & Z. Like un-sharpened pencil.. not enough flat area? Perhaps too much restitution power (rebound power) on player or on collided things? Not sure. Just thinking. Did you try Fenomas' idea... player.physicsImpostor.physicsBody.fixedRotation = true; ?? Perhaps you could not turn your player anymore. Your situation might require physics rotational "constraints" on X and Z rotation... but still allow Y rotation, for player turning. I think that can be done... but not sure how... at this time. (well, I know 2 bad renderLoop ways: 1. constantly set physicsBody.angularVelocity.x = 0 and .z = 0, or constantly set physicsBody.quaternion in some way. Pure force. heh.) Perhaps invisible box mesh with boxImpostor and fixedRotation... positioned above player's head. Then physicsJoint connected downward into player's head, and that joint would ONLY allow Y rotation, and have constrained X and Z rotation. I think that would work... somehow. Fenomas taught me... that there are MANY advantages in using a physicsJoint to connect the thing you are FORCE-moving with keypresses (the invisible box above player's head)... to the moved-by-impostor mesh. You could consider it a "soft connection". It has some "flex" that you can highly limit/constrain... but not stop completely. It also allows springs and motors. hmm. This "use-a-joint method"... is physics-engine-friendly. It allows the physics engine to do its math, and better stay in-sync with its impostors. (I hope I worded that tolerably, heh) Talk soon.
  19. Hi Tom. If I understand correctly, intersectsMesh() uses boundingBoxes (either loose AABB or precise OBB). Unfortunately, I think .showBoundingBox = true... ONLY shows loose (AABB). There is no .showBoundingBox for OBB/precise, I believe. None of that is important... except for fake gravity in renderLoop. For fake gravity (an intersectsMesh/ground, so far)... there is a problem. Fake gravity-adjusting (forcing Y positions) likely affects ellipsoid position used for .checkCollisions and .moveWithCollisions(). Really, there's two things we might need to "force". Return player to ground-level... after player climb-over something, and after player burrow-under something. AND both actions could/should be disallowed. Many games DISALLOW burrow-under, and require spacebar-tap to climb-over. Let's deal ONLY with ellipsoids at this time (no talk of intersectsMesh, yet). Unfortunately, we are dealing-with collision ellipsoids bumping into collision ellipsoids. Burrow-under, climb-over, and move-around... is natural (round things against round things). If burrow and climb is not wanted, we must somehow restrict it, OR... the center of the two colliding ellipsoids must be positioned at EXACTLY the same worldspace Y-height. If they are, I believe the collider will be forced to use a move-around, which is better for us, right? But... ellipsoids often extend to ground or below. SO... no ground.checkCollisions = true; (yet) When the player's feet are on the ground, player.ellipsoid COULD BE below the ground... no good. But we might discover that we can prevent the ellipsoids from touching the ground... with precise sizes and offsets. We will learn more about you/we run more tests. I am not very experienced in collisions, unfortunately. I did some tests... with another user's model. The yellow sphere represents dude.ellipsoid. One thing I noticed. See dude.scaling 10x in line 33? Well, dude.ellipsoid does NOT scale WITH IT. I needed line 37 to make the dude.ellipsoid big, like dude mesh. This would mean... that you need to change all mesh.ellipsoid and perhaps "center-ize" all ellipsoids with mesh.ellipsoidOffset... in your scene. Again, try to keep your ellipsoids from dragging against ground, or set ground.checkCollisions = false. Anyway, I wanted to build a test scene (url above), but I'm only halfway done. I have one tree trunk made... with no collisions active. I want to code a... BABYLON.Mesh.showEllipsoid = function() {something good}. I think this is called "overloading" the Mesh class. Doing this (very early in code, or even global level) would put a .showEllipsoid() on EVERY mesh in your scene. Cool, huh? We could use that helper. There MIGHT be a way to automatically set mesh.ellipsoid EXACTLY FIT into mesh.showBoundingBox. Possibly, it would be another "overload" of the BABYLON.Mesh class... like BABYLON.Mesh.setEllipsoidPerBoundingBox = function() {something really good}. Now, every mesh in your scene would have .setEllipsoidPerBoundingBox()... another very handy function, perhaps. I/you/we just need to code these funcs. And, I want to make some more trees, and some barrels, and a wall... in this PG scene. Then we can "see" all those ellipsoids (with yellow wireframe spheres). We can set ellipsoid heights and widths, if needed, or use our new automatic ellipsoid size-setter function. Then, more tests, trying to keep collided mesh from climbing-over and/or burrowing-under each other. Remove ground.checkCollisions, and instead... use our fake gravity and check intersectsMesh in the renderLoop, like you did in your scene (and reported console.log(1) if intersects). But we have to be careful while preventing/adjusting the burrow-under or climb-over condition, because if we use the renderLoop to force the player down (fake gravity) or force player UP (avoid burrowing under walls/barrels/trees, etc)... we could be causing or "jamming" an ellipsoid collision. Jamming = "stuck", same as we see in your scene. I need more time, Tom. If you (or others) want to help with my test scene and/or code-up .showEllipsoid() or .setEllipsoidPerBoundingBox()... that would be great. I must test slow, and in playgrounds, because it is just TOO DIFFICULT to find things in your big project code. I must keep things simple... just so I can learn. I am not a very good coder, and I learn rather slowly. Sorry. Hopefully, you and/or others will help advance my ellipsoid collisions tests. Feel free to edit that playground, run, save more, grab zips, make trees and barrels, help/play at will. I'll visit again soon.
  20. Hi guys. I was thinking of one other way. Use a standard BJS plane (.isPickable = false), parented to camera (in a way where plane area == renderCanvas area)... then apply empty BJS dynamicTexture onto plane. (Like a piece of clear glass... placed precisely atop the renderCanvas. Similar to a ScreenSpaceCanvas2D, but not one.) Then use .getContext() to get the context2d of that dynamicTexture, and start making "strokes" on it. Remember to update your dynamicTexture after each change. "Pattern" is a type of fill, there. pattern = context.createPattern(image, repetition) "image". Yay! Could be possible. Wear your hard hat... things might blow up. (probably won't) Some crazy playground-maker was doing something weird... here. Looks pretty fancy. I found that PG ... while I was searching-for a simple playground that showed .update()... like this playground... line 32. Party on, guys.
  21. Hi gio. Ummm... in this case, you could/should use CannonJS "MeshImpostor" only. No other impostors will work correctly (unless you build a complex parent/child structure). With CannonJS MeshImpostor, "holes" will be ok. Note: CannonJS MeshImpostor ONLY interact with sphereImpostors. So, even if your player is a box, you must use sphereImpostor on player. (or MANY little sphereImpostors connected into a structure/shape, possibly connected with physics joints). I stole a little testing playground. MeshImpostor on "Bonehead"... but he seems to interact with boxImpostor JUST FINE! Maybe I lied about "sphereImpostor only". Anyway, make edits, do RUNS, make saves, see what is learned. It LOOKS LIKE... um... the "concave area" (hole area) in back of skull... has invisible impostor blocking it. Need to test... perhaps try pouring many little balls and cubes into inverted skull... see what happens. heh. Notice line 36... automatic Bonehead drift-along rate... adjustable. Oh how I wish I could mesh.showImpostor(). Someday, maybe. Meantime, we cover it with little snowballs... so we can see impostor shape/size.
  22. hehe. Good job. YOU made it. I simply watched genius Nesh at-work. Well done! I think it needs to be added to framework, somehow. It would be a cool add-on feature for @jerome's extrudeShape (I think Jerome coded that, but maybe not). Hmmm... perhaps Babylon.Tools.getShapeDataFromAlphaImage(URL), and then THAT can be used as shape data in extrudeShape. It is probably much more complicated than that, though. Thoughts, anyone? It is a pretty cool accomplishment, I think. Maybe we celebrate and party, first. I'm thinkin' 3-day party.
  23. Somehow I misunderstood that as... "Already works in 2.5". hehe. Serious Wingnut confusion on that, sorry guys. @fenomas the only pertinent demo is WASD keys to walk player into barrels. Barrels roll-over like sphereImpostors with low-set pivotPoints. And, they sink into ground. I didn't ask Tom if he has adjusted any pivotPoints on the barrels, and I never searched the code for that. His barrels use cylinderImpostors, ground is boxImpostor, and player is... I forget. Tom is changing to non-physics and is creating a new URL for physics demo... soon. I tried a basic playground... but could not repro issue with it. Cylinder impostors acting well, there.
  24. Hiya Tom. Just doing a little testing. Click canvas, then WASD. There's definitely some problems with the ellipsoids or something. Redbox Y position is already high (line 14). Ellipsoid is small (line 19). Click on canvas and then hold "d" key. See redbox climb-over greenbox? Goofy! Ellipsoids are tall for some reason. hmm. Objects staying in air is normal. Only cameras have .applyGravity, not mesh. But you can create fake gravity for boxes... in render loop. But first, we must fix these ellipsoid heights. Perhaps I am making a mistake in this testing demo. I am old geezer and forget things. For all future tests, let's keep ground.checkCollisions = true (so we can check ground-redbox collisions, too). If we set redbox.y to 1.5 in line 14, WASD moving... struggles/climbs a bit. If set to 1.0, WASD starts failing... ground-to-redbox collision problems. Perhaps intersectsMesh (using boundingBox instead of ellipsoids) would be better. Not sure. Tom, there IS an "observable" called abstractMesh.onCollideObservable. (See docs for that.) Two playgrounds use it, it seems. Might be a good direction to experiment-with. I made another demo... with redbox.onCollideObservable added in line 65 area. It returns greenbox object when colliding with greenbox. It SHOULD also return ground object when redbox collides with ground. So, it might be handy for testing or other things (like fake gravity). I wonder if onCollideObservable uses boundingBoxes or ellipsoids. hmm. I have SO MUCH to learn. I'll keep testing, maybe turn-on wireframe spheres to show collision ellipsoids, eh? Help welcome from all forum users, as usual. Thx gang.
  25. Yeah, a maze-maker's toolbox-o-Blender-pieces! 100% Blender-made! Assembled in Mexico Babylon.