• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Wingnut

  1. Hi guys. Also remember... when dividing big maps into little ones... the STARTING row and column of ANY "next" section... is an exact COPY of the row and column... from the ENDING row and column of the previous section. In other words, at any "seam"... the ending/starting row/col of verts, needs to be an exact copy. To do this, when cutting up the big map, make your ending row and column... be ONE row/col more (longer and wider) than you'd expect. The ending row and column of any section... must be an exact copy of any beginning row/column. Wherever a seam happens, there are two identical vertices: the ending one from previous section, and the beginning one for next section. (version #55 closes the gaps, but you can still see the seams, due-to lack-of normals-averaging across the seams.) See how the seams... have the exact same row and column of verts... on each side of the seam? That's needed... to make them match at the seams. Now look at lines 239-251 of my "cutter". See all the col+1 and row+1 stuff in there? That's for ending the row/col of PREVIOUS section/cell, with the exact same verts as the starting row/col of the NEXT section/cell. I also have "showNormals" activated (the white sticks), and as you can see, the lighting normals across seams... can be a challenge. I was never successful at averaging the two normals on each side of the seams, or with averaging FOUR normals at every 4-way corner. But, I didn't try too hard. Most people have gravitated toward "infinite" terrains... instead of tiling. (use arrow keys) (see line 48 - BABYLON.DynamicTerrain) I don't know much about infinite terrains... like if they are a good alternative to tiled terrains. All in all, I think you have positional mis-match at seams... due-to NOT "going one row/col further-than-expected" when cutting-up your big map... into cells/tiles. But I could be wrong. Remember...ONLY end your cell-cut... one row/col longer/wider than expected. Start your cell-cuts exactly where you would expect. Threads of interest: Rare forum visitor Kostar111 once did some tiled ground work...élian-garcia-kostar111-home-website-unknown
  2. Wingnut

    Constraint Moving

    Hi NRA. Here's a basic box-stacker... using an actionManager on the bottom box. It uses boundingBox info... to know where to stack the next stacked box. Keep clicking the bottom box, instead of a button. I was too lazy to make a GUI-based button. Saturday morning cartoons make me be lazy... wearing my pajamas until after-noon. heh How about a little random Y rotation on each stacked box... Anyway, that's a good testing playground to start-with. Maybe this is enough help, or maybe you could describe your wishes... in more detail. Does that mean... you would like to "mouse-drag" the newly-stacked box... upward and downward along Y axis? I think that can be done, too. There are some BRAND NEW pointer-drag tools laying around here somewhere... might be fun to try-out... if I can find them again.
  3. Wingnut

    Demo with Ammo.js Physics Engine

    Yep, that'll work. Note: I made a mistake in an earlier post. belongsTo and collidesWith are IMPOSTOR parameters/settings, not for joints. My point with these discussions COULD be: How is it determined... WHICH settings get a plugin wrapper-method, and which don't? For example, friction was a parameter chosen to be one of the allowed constructor parameters... for Oimo (and Cannon). There are late-call functions such as setFriction and getFriction, and friction is a member of impostor._options. Why didn't Oimo's collidesWith and belongsTo... get included in those? What made them somehow lesser, and thus determined/relegated to be native-set ONLY? You see, there is a pattern emerging. SOME things are honored by the plugin, and SOME things are blown-off, and native-set only. The more "features" that get blown-off and relegated to be native-set only... the smaller the plugin.... and the less that can go wrong/be bugged... with it. Plugins start to get LESS "effective", and Tools.AmmoNativeCommandHelper becomes MORE "effective". Maybe. What is a plugin? Is it already a AmmoNativeCommandHelper? Maybe. But users might want to "see" the native command that is being issued, and our plugin methods are not coded to do such things. They just issue the native commands, behind the scenes, for the user. No teaching of native commands. Can't see the native commands that are getting issued/sent. I think only setNativeParam() and makeNativeCall() allow the user to see the native text... because the user/programmer needs to type it into the parentheses. Really, does a plugin NEED anything MORE THAN setNativeParam() and makeNativeCall()? IF we had ONE plugin that had only those two calls, BJS gets to wash its hands of ever-evolving physics engines, and instead... delegatesd the physics engine learning... to programmer/user. Just one plugin... does it all... because it is a very thin layer. Just thoughts. Back on-track... How do plugin authors determine WHAT gets handled by native, and what gets plugin support/wrapping? Is that done via "educated guess" of usefulness? Sorry if I'm off topic. I'm sort-of talking about plugin dev, and not about John's Ammo demo. *shrug* But hey, I gotta follow my curiosity. It helps me learn things. Sorry if it seems that I have a "pushy" mannerism/personality. Not my intent. In my now-predominently-broken physics LEG-WORK demo... you can see me actually add collidesWith and belongsTo into the Oimo IMPOSTOR (lines 125/126)... and into the PLUGIN (lines 984-996). What was so difficult about allowing those... from the start? I bet I know. If CannonJS doesn't use/understand belongsTo and collidesWIth, then the adjustyed-for-Oimo BJS PhysicsImpostor base class... can't be used by Cannon. BJS PhysicsImpostor class becomes non-universal. We'd need to separate... OimoPhysicsImpostor class, and CannonPhysicsImpostor class. And now, we might need AmmoPhysicsImpostor class. I dunno. I'm just trying to find a policy... for what/how-much to dumb-down things... in order to make them re-usable/universal. The BJS physicsImpostor was dumbed-down so it could handle both Cannon and Oimo (and thus lost its collidesWIth and belongsTo). The BJS physicEngine class might also be dumbed-down to make it universal for both Oimo and Cannon. Will we need a BJS AmmoPhysicsEngine, now? Or are the plugin programmers trying to bang Ammo with a hammer until it "fits" our current BJS PhysicsEngine class? Should our PhysicsEngine class... have a native-setting portal as well, so we can get max power/features from Ammo? Our physicsEngine class is currently coded for Oimo and Cannon. Because of this wobbly mess, super-thin plugins start to make sense, with almost everything done via native. And it is/could-be the user's responsibility for learning how to talk native to whatever engine they are using, and not BJS's duty to wrap some of the functionality of each particular engine. It's just a theory. A FULL POWER Ammo plugin... could take a year to code. Maybe two. This is because we MIGHT need a "proprietary" (special) BJS PhysicsImpostor and PhysicsEngine class... to accomplish that "full power". At what point... do we stop hand-holding the physics users with fat full-power plugins, and instead.... teach users how to talk native to all of our engines? (and then de-power the plugins) Maybe I should stop thinking so much, eh? But I actually ran-into the situation... needing belongsTo and collidesWith in my project. I could have used them via talking native. But instead, I decided to modify the BJS plugin and impostor classes. I have actually SEEN the impact of two important Oimo properties... ignored by the plugin and relegated to native-use only. Now others have seen it, too. Thoughts?
  4. Hiya S! In lines 43-46, I waited until scene ready (til after the panel rendered for the first time)... and THEN did the rotation. I don't know if it's operating correctly, but at least we know a work-around and a bit about the reason for the problem. update: PG #55 tries to eliminate the "flash" of un-transformed button-text... using a contorted button-by-button isVisible loop.
  5. Wingnut

    Demo with Ammo.js Physics Engine

    Likely off-topic, but there's two more impostor parameters: move and density. I don't know what their story is, but I've seen them laying around in various playgrounds. Just another interesting parameter. As you can see by these lines in the Oimo plugin, we sort-of quick-bind them... to the mass parameter. When we see things like these "safe default values", we can lightly assume that CannonJS doesn't have comparable/similar parameters. These two parameters could be an Oimo-only thing. density likely becomes more-pertinent... in soft-body operations. @trevordev - are you attempting to make the Ammo plugin... have the same basic API... as the Oimo and Cannon plugins? That "universal API for basic physics" is a good idea, but Ammo is the first physics engine at OUR JS level... to offer soft bodies. So, the Ammo plugin's API really CANNOT mirror the other two plugin API's. The other two have no soft-bodies. So now, Ammo plugin coders try to mirror SOME of the API from the other two. In doing that, does it FEEL like we are needing to de-power the new Ammo plugin API... simply because of this "pull" to mirror the API of the older/long-established plugins? Does anyone think about that? Yes, the nativeParams "portal"/feature... allows us to dive as deeply into the engine as we choose... but... hmm. When someone experienced with Bullet or Ammo... views our Ammo plugin for the first time... they might say... "Oh wow, this is Ammo LITE. It looks like they have a stripped-down plugin, and are not honoring the new powers of Ammo." The user got this first-impression attitude, simply because we tried to mirror the API's from older, established plugins. For example, let's say the new Ammo plugin... has no soft-body calls/tools. That's likely how it is right now. Let's say ammo plugin developers NEVER add any softbody tools, and ONLY allow softbodies via nativeParams and nativeCalls options. What if? Now... the Ammo plugin CAN mirror the Oimo and Cannon plugins... tightly/accurately. The Ammo plugin devvers have FAR less work to do, and everyone who uses the Ammo plugin... understands that we MUST crawl beneath the floor of the plugin... to exploit Ammo's full power and newest features. In other words, the plugin doesn't hand-hold the user AT ALL, as far as the new Ammo features/power. It is understood... that the Ammo plugin is basics ONLY. To get-to the "big beef", programmers MUST talk directly to Ammo native level. I think tDev says to himself.. "How in the heck can I honor ALL the possible configs/options of the new Ammo features?". And then, he asks "How can I do some basic syntax and type-checking to help the programmer use this command?". Likely, it gets a bit overwhelming. Instead... maybe... anything beyond basic physics... ya GOTTA go native. Thoughts, anyone? tDev.... IF you were to honor/cover all the "power" of the Ammo engine... wrap ALL its tools in your tool... the plugin would be what? About 3 times the size of the Cannon and Oimo plugins? Maybe more? And in 2020, the new WAMMO engine arrives. Oh no! I dunno my point, as usual. Maybe, there is a "point of diminishing returns". At some point... maybe we do less in the plugins... keep those basic, always. Then... maybe write our own tutorials about "How To Talk Native" to ANY of our physics engines. THEN... perhaps... hire some SERIOUS physics expert... to write those docs... even in sloppy form. Cannon is the only one of our big 3 engines... that has a published API docs, right? But it's a JsDoc-generated thing, so it doesn't teach. For any engine, if we seek to teach how to talk-native to it, we also need to describe the way the engine does what it does. What are 'lc'? What are 'r3c'? What are solvers, islands, broadphase, narrowphase, etc. What's the rules for allowSleep? Guess-timate of the tutorial length for teaching how each physics engine works, and teaching how to make native calls to it: 8 miles. *sigh* (2 million LBS of text + 300 gfx/diagrams) Ammo could go obsolete in 2 years... especially if "physics engine in hardware" becomes available to us, here in JS land. Is WASM an indicator that we are reaching with all our might... for more physics speed? What happens if some idiot invents a physics sub-processor for $12... that plugs-into a USB 3 port, and suddenly makes JS physics... quadruple in speed and with no need for software physics engine? What if? TrevorDev would start crying and have a nervous breakdown. Be careful, tDev. In my opinion, don't break your brain trying to honor all the newest, coolest Ammo stuff... in the new plugin. Just point the advanced-features idiots to the nativeParameters portal, then go get a meal and some sleep, eh? The plugin already looks pretty damned nice... thx for your work! Don't kill yourself on/over that thing. It's called "Ammo" for a reason, ya know?
  6. @Deltakosh This sub-forum is still mis-named a bit, isn't it? (Feel free to ignore this comment, Brean. Or comment, if you wish.) hmm. "Hired Help"? Unfortunately, "Hired Help" or "Hired Guns" doesn't imply that it's BOTH shoes, buyer and seller. - Could be experts, looking for work. - Could be non-experts, looking for expert help. - Could be experts looking for more experts. - Could be noobs looking to hire other noobs, but unlikely. I was the one that whined about using the word "business", but... I dunno. It might need to come back. hmm. Anyone remember where the thread is at... where we talked about naming this sub-forum? I should probably take my worthless yammering... there.
  7. Wingnut

    Jetpack Particle to Follow Avatar

    Hiya M, welcome to the forum. That might be the problem. Bones, as in skeleton/armature bones? Parent the emitters to the root or top-most mesh/transformNode... of the avatar (if possible). I'm no pro at these things, but try that. You'll still need to position-offset the (invisible) emitters so that they are at the avatar's hip-level and width. Once the emitters (fountains) are positioned and rotated as-wanted, you might wish to do some emitter.bakeCurrentTransformIntoVertices() calls on them. Notice that AFTER you do that, each emitter's .position and .rotation will be set to 0,0,0, yet the mesh didn't move at all. Sometimes a handy thing. Keep us posted on things learned, if anything. thx.
  8. Wingnut

    Demo with Ammo.js Physics Engine

    Thanks tDev... nice work. Thx for the links, too. lo-th? That's the folks who made Oimo, right? Interesting. We're among friends. Note: If you are "on" the Firefox "ESR" update channel, like myself and other Firefox Quantum haters, you'll need to update to FF... oh... v60.0.3esr... to get your WASM activated (for the above lo-th links to work). Their ragdolls are doing exactly as I described. The mesh on each side of the joints are SO CLOSE TOGETHER, that the mesh impostor collisions make them "stiff". None of the joints flex as well as a real human. Hinge angle limits caused by colliding impostors - suck. The International Rag-Doll Society would give them a C- rating, at best. Smuck those ragdolls with a high-speed train, and we would probably yawn to death. About as flexible as a Pillsbury Dough-boy or Stay-Puft Marshmallow guy. Generally speaking, if a fast-tumbling ragdoll carcass can't kick itself in the head a few times... before wrapping itself "around" a telephone pole, it hasn't met my stringent flexibility requirements. When that dragon grabs that medieval guardsman by the head... and starts SLAPPING his body repeatedly onto the brick floor, we need some limbs floppin' and bouncin'... violently. And sounds, too. We need to HEAR them bones bangin' on those bricks... SO morbidly demented!
  9. Wingnut

    Demo with Ammo.js Physics Engine

    Hi girls. I just wanted to keep this thread alive and bother ya'll. Been thinkin'... 'bout physics. I hear a rumor the @trevordev has jumped into the ammo.js "fire"... along with @JohnK and other ammo-testing pioneers. Good to have you, t-dev! @RaananW has been a bit real-life busy, but I'm wondering if any of you know about his "BJS Ammo Plugin" progress-so far? Tdev... are you building an ammo plugin... that started with his? Just curious. I'd love to hear a report about what you've been doing with Ammo, @trevordev. Thx. Have you guys seen this? Looks a little stale, but... hmm. Anyway, based upon names, I think Oimo is a basic clone of Ammo. It's not important, but I wanted to talk about two parameters that we do not "honor" in our current Oimo plugin: - collidesWith - belongsTo There is a guy over in another thread... wanting info about how to physics-activate a skeleton. I know @Raggar was doing some playground work on activating @Samuel Girardin's ragdoll. It's a good one. Its joint work pretty well. Rags' demos are currently broken. Maybe he'll visit and teach us stuff. Raggar is not scared to "go native"... talking-around the BJS plugins, and speaking in native rigidBody and joint language. belongsTo and collidesWith - it is no problem that they are not DIRECTLY supported in the Oimo plugin. @RaananW installed an easy system to send native calls directly to physics engines/objects. SO, you can set collidesWith and belongsTo... just fine. Now let's talk about collidesWith, which allows "belongsTo groups"... as values/settings (in hex). Let's imagine a knee joint on a skeleton... and its bend limits and hinge type. Let's roll-up a joint: ----------------------------------------------------------------------- var myJoint = new BABYLON.HingeJoint({ mainPivot: new BABYLON.Vector3(50, 0, 0), connectedPivot: new BABYLON.Vector3(-2, 0, 0), mainAxis: new BABYLON.Vector3(1, 0, 0), connectedAxis: new BABYLON.Vector3(1, 0, 0), collision:false, // this might be same as collidesWith 0x00000000 (nothing) nativeParams : { limit: [0, Math.PI], // not sure if same thing as min/max. min: 0, max: 100, // radians? degrees?, who knows? // belongsTo: 0x00000010, // collidesWith: 0x00000011 }); source.physicsImpostor.addJoint(target.physicsImpostor, myJoint); // late settings preferred? Like this: myJoint.setLimit(10, 10); myJoint.setMotor(10, 100); myJoint.setNativeParameter(xxxxxx); // research this myJoint.executeNativeCall(yyyyyy); // research this ----------------------------------------------------------------------- When thinking about an upper leg and lower leg - connected by a hinge joint, we tend to want to make the mainPivot and the connectedPivot... NEAR each other. We want a "tight hinge". BUT... if your leg meshes are rectangular boxes(-impostors)... with some significant thickness... bending the hinge will collideWith the OTHER leg mesh... easily... due to low (vertical) distance between upper and lower leg (impostors). (in humans, same as: limited knee bend due-to too much thigh and calf fat) (vomit) See how the amount of allowed hinge-swing... was limited by a "tight hinge"? (pivot points vertically near each other). The upper/lower leg mesh... collided with each other... after very little knee-bend allowed. CollidesWith and grouping-tool BelongsTo... start becoming important properties/parameters, eh? Lots of ragdoll makers... are happy using these collisions... as the motor limits (angle limits) for their ragdoll hinges. Unfortunately... if another user comes along one day, and makes the upper and lower leg mesh be REAL SKINNY, all of a sudden.... the joint becomes very wobbly and unable to "stand up". OR, if a future user decides to increase the distance between the two pivot points, ragdoll knee will ALSO go wobbly and faw-down-go-boom. The only way... to ensure that the knee joint ALWAYS acts like a knee joint... is to use setLimit calls (or, likely, min/max params)... and NOT depend upon collidesWith (lower leg mesh to upper leg mesh) to do your bend/rotation limits. With setLimits on the joints, future users can spread the pivots apart or closer, or change leg mesh diameters, and the knee still acts like a knee. It has math-set bend-limits and not impostor-collide bend-limits. Heavy, eh? So how do we turn a skeleton into a physics-active "jointed" skeleton? Lots of friggin' work, I suspect. A joint-add at the end of each bone, right? Ow. No real purpose or point to this post. Just thinking about (Oimo) belongsTo and collidesWith... two parameters that, likely, we will ALSO see... in AmmoJS. Just thinking about how to keep ragdolls standing on their own... without having car-sized feet. In Sammy Girardin's Old Man ragdoll, I think he held them upright with an invisible mesh above their heads... and a single hinge2Joint dangling-down to their head-impostors. The arms hung naturally, the legs did the same... setLimits or min/max on each joint.... and careful mainAxis and connectedAxis settings (natural limb-hang angles). Phew. Magical. In humans, a joint's allowed bend-angles and upper/lower limits... are set by bone locations and/or muscle-extension abilities. I haven't talked much about setMotor... but... setMotor calls are how you get a stretched muscle... to return itself to natural limb-hang. Gravity on the limb impostors CAN do all the work... but a SWEET ragdoll... will keep increasing setMotor back-force IF another force is trying to move the hinge-angle beyond a limit. In fact... the motor should start counter-forcing well-before the motor limit or hinge angle limit (same thing?). Muscle stretch-ability. Elasticity. GRUESOME! Constraints. Everything is a "constraint". Mesh are free to fly anywhere, unless they are constrained by forces such as impostors and joints. FUN! Mesh wrangling and roundups! Mesh corrals. Cowboy stuff! I got cow poop on my boots! Ki-Yi-Yippi-Yi-Ay, lil dowggies! (spit) (toothless grin) And we're still NOT talking about skinning and weighted vertices. This is ALL armatures. BLECH! SO MUCH to think about, eh? Good luck with the AmmoJS progress, guys. I cannot find an API/docs for that thing, but I'm going to assume that it has some belongsTo and collidesWith stuff inside... along with setMotors and setLimits. Should be a GOOD TIME! PARTY! Thanks for your work, guys! Warning: There's still a guy/gal out there on the forum... asking how to physics-up his skeleton. QUICK, EVERYONE HIDE... PRETEND NOBODY IS HOME!!! heh Somebody was doing SOMETHING... here: Found it with playground search for mainAxis. Its PG metadata has "Walker" in the name. hmm.
  10. I think... you can also use your CURRENT SpinTo animator... to animate the Just change the whichProp to 'target'. An ArcCam target is a vector3 value (like invisibleMesh.position). An ArcCam lockedTarget is EITHER a mesh or a vector3. Animating arcCam targets and lockedTargets... is often used for "click on mesh to make cam look at clicked mesh". When user clicks a mesh, you can animate to clickedMesh.position. It's not really a "spinTo" in the classic sense, but it still works. It's more like moveTo(), eh? *nod*
  11. Wingnut

    Debugging physics with the inspector

    Ahh, see, there ya go. Genius! (hug) Thank goodness you are on OUR team, DK! Update: Just took a little tour... using Use arrow keys to move little box, which drags-around green player box, using a joint between the two. (This config is for avoiding over-powered collisions, which happens when keypresses DIRECTLY move a physics mesh and cause a physics collision. There is too much impact power, when not using a "buffer joint" to absorb some impact shock.) Looking good. I wonder what physicsBodyBoxViewMesh is. hmm. It won't view-toggle, or has no affect when toggled. hmm. It's a mesh... on a different render layer... me thinks. If so... that's still messing with the scene graph. Added a mesh, whether a different layer or not. Same scene graph. You thought you could slide that one past me, eh? (Like I have a clue whatsoever). -------------------- When picking is ON, pick SOMETIMES picks the mesh (good) but sometimes picks the physicsBodyBoxViewInstance. Can pBBVI be set to isPickable = false? Also, when picking is ON, and the PHYSICS branch (pulldown) is open, showing mass/friction/restitution/type, then picking a DIFFERENT mesh... does not update the values. We need to close the PHYSICS tab, and then re-open it... to get the values for the newly-picked object. Minor issue. Said in another way, PHYSICS values... do not get updated... if Inspector picks a different mesh. Need to collapse it and un-collapse again. It sure is a pretty inspector, though. Nice! Remember 4 years ago, when you said "Yeah, I want to keep the playground really clean and not add a lot of extra stuff to it." ? FUN! Now, its a full-fledged scene-layout application.
  12. Wingnut

    Debugging physics with the inspector

    @Deltakosh Are you querying/copying mesh.physicsImpostor.physicsBody.position... to set position of wireframe? Are you querying/copying physicsBody.quaternion... to set wireframe.rotationQuaternion? In other words, are you checking the position of the rigidBodies? Are you using the ACTUAL physicsBody values... to transform the displayed impostor-proxies? Just curious. If not, you/we may not know if/when an impostor goes out-of-sync with a mesh. (We'd probably know by the way it physics-acted, anyway, though.) *shrug* I could be wrong. Often am. Same is true with joints. Seems we (you) need to query world.allJoints, and then query which mesh-shapes are at each end of the joint, and do some fancy bone-looking wireframe connectors. And we'll need name-labels on those, of course. Could right click the joint's name-label, and a big panel of info ABOUT that joint... pops open. Physics World Sniffer... 1.0 I once thought... the showImpostorsAndJoints()... might need to produce a Babylon.Layer or auxiliary (extra) AdvancedDynamicTexture. If ya think about it, we don't really NEED to show a wireframed mesh... when we want to see an impostor. We actually just need to see a circle... similar to those used on GUI link targets. We spin the camera 360 around the mesh, and if the dot/circle stays in the center of the mesh, that means our impostor is in the center of the mesh, too. No added mesh to the scene. All done with Babylon.Layer or GUI layer... or "The Physics Inspector ADT"... a 2nd layer of advancedDynamicTextrure. I know... goofy idea. But if we can build the physics inspector on a HUD... that would be pretty nice... and not need mesh, ever. To show a joint on this "layer"... its just a slight variation of a GUI link-line. New control, called a "joint line". Clickable... brings up info about the joint, including click-links to exam impostors attached to each end. No 3d. All layer. HUD. The Physics Heads-Up-Display... looks like a fighter jet HUD... overlays the scene.... easy-toggle blocking/non-blocking. What a dreamer I am, eh? But I think there's merit in keeping our fingers OUT OF the 3D world... when inspecting physics. No mesh-adding. Leave scene graph alone, and get special X-Ray (physics) glasses to look at screen-with... see the scene's under-warez.
  13. Wingnut

    How add ring in disc?

    You're a God, Jeromino! WELL DONE! I goofed-around with vertexData.createCylinder a bit, yesterday, bringing/pasting that entire func into local playground. 34 kg of code weight! My desk monitor kept trying to tip-over, because the playground editor was SO HEAVY! I bailed on it. You make it look SO EASY. *sigh* Someday, J. Someday I'll be a pro vert-wrangler, like you. (maybe) (doubtful)
  14. Hi Nogalo! Yeah, this is a common problem. Our virtual joysticks are a bit out-of-date, and I don't know what the big-wigs plan for its future. I started SOME work on virtual joysticks that use the BabylonJS GUI system, and thus use no add-on HTML vjCanvas that blocks all other screen-clicks. (That uses a 1/3 screen-width/height for the thumb/drag "zones". #55 (and #56/57) use 1/2 - which blocks more screen area.) Barely tested, but seemingly ok. Two "thumb zones" are color-bordered in the lower corners. Their borders can be turned-off, as needed. Lines 72/73 & 180/181 change the size of the thumb zones (think of the values as percentages). IF you change the zone sizes, you will need to tweak the little values at the end of lines 88/90 & 194/196... to make the drag puck be centered on the thumb-touch location (or pointer location at pointerDown time). Someday I will formulate a formula that automatically performs those puck-centerings, no matter the zone size or zone screen-placement. GUI controls like these... often have a .isBlocking and other helpful click-thru-me properties... but I think I tried it once... and it was trouble. Not only can the thumb-zone rectangles cause mesh-pick blocking, but so can the drag-puck rectangle/image that happens on thumb-down. So, expect some issues if trying to click "through" the thumb zones. Depending upon which touch devices you are targeting, you MIGHT be able to keep these thumb-zones smaller, and thus... not in the way of mesh-picking. Not sure. I think this is the first attempt at GUI VJ's, and I'm far from a good coder. But, just for fun, let's ping @adam, because it seems to me... he had another GUI VJ... and he's better at coding GUI controls than I am. Adam, if you visit, can you point us to your GUI-based VJ... if indeed you built one? Thx.
  15. Hiya JS. I don't have solutions to your issues, yet... but I wanted to show you...élian-garcia-kostar111-home-website-unknown Kostar111 isn't around much anymore, but he kept his tiled terrain map tutorials on-line, so there might be something to be learned, there, in his 3 links. I goofed around with some tiling and displaceMaps, once. Not very exciting. :) Also, although I know almost NOTHING about multiMaterials, it might be worth a forum search and playground search. Here's a quick demo I found, laying along-side Babylon Blvd. Stay tuned for more/better comments/answers.
  16. Wingnut

    Debugging physics with the inspector

    Nice! Next step... being able to "see" physics joints? Perhaps a slightly-different wireframe shape for each TYPE of joint? (phew, eh? I hear ya.) The video is sort-of fast. If some of the boxes have sphereImpostors, would we see wireframe spheres inside those? Does the wireframe indicate the impostor type/position? If a user moved the mesh itself, so the impostor gets left-behind (impostor out-of-sync with mesh)... would we see that? I bet not. I bet it would take some serious "querying" of the physics "World"... to build a wireframe "layer" that showed impostor types, transforms, and sizes. Still, though, good progress and I hope I didn't "rain on the parade" (I hope I didn't ruin the celebration).
  17. Hi Guys! I once did some mesh "spin" and "spinTo" funcs, and they work for arcCams too. Lines 2-6 temporarily adds spinTo() onto this-scene-created arcCams. Some demo calls are in lines 75-85. I'm not a pro coder, so there could be tweaks needed. I think there are 10 types of easing available in BJS. I used CubicEase cuzzzz... it seemed to work nice. You might run into SOME issues... for camera.alpha... in regards to WHICH WAY TO SPIN to get to new target-alpha value. Possibly, spinTo() needs a 4th parameter, a "positive" or "negative" to indicate which direction to rotate to new target. Sorry if I ruined the adventure-fun of writing an arcCam spinTo() animator. Note: Internet Explorer may dislike the ()=> usage in lines 75-85 demo calls. If problems in IE occur, use this format: setTimeout(function(){camera.spinTo("beta", 1.2, 20), 1000});
  18. Want a bootleg way? Something greasy? Try this. Slimy, but seems to work fine. Lines 60-67.
  19. Yeah, Eisha... thx. Umm.... JohnK meant that you should paste the createScene() function from your home/zipped code... into the playground editor. Not paste into forum. But it's ok, we move ahead. As John says, play with the playground... make some edits and more RUNs... more SAVES, goof around. Try to show us, tell us... things you are having problems-with. Learning to do some coding in the playground/editor... will become super-handy. It is the best friend of many BabylonJS developers. I love it. I would be lost without it. it takes a little time, patience, and practice... to learn to operate it well. I think, if you just goof around with the scene for a bit, you will get better and better at driving physics. I put physicsImpostors on all 3 spheres. If you want to pass-thru a sphere, you must NOT have a physics impostor on the passed-through sphere. As an alternative, I think there is also a "NoImpostor"... which is like a fake impostor that does nothing. Try "NoImpostor" in-place-of "SphereImpostor"... should work. Maybe. Also, you might want to look at "ActionManager" for a different/more-modern way to watch-for mesh-picks. (no needed window event listening/unlistening). You can easily put an ActionManager on each ball. The whole scene can have an actionManager, too. It is a nice tool.
  20. Well said, @JohnK! Making a playground that shows the problem... is ALWAYS the best way to help the helpers. But, I was in a good mood, and Eisha is working with physics, which is difficult by itself. Sooo... I treated us to a playground example. Lots of changes... lots of comments to learn-from, but really, Eisha did a good job! See how I sort-of pasted the entire createScene() function from your zip... into the playground? Just like JohnK stated. Eisha didn't know that mesh often don't accept .position settings... AFTER they have gotten a physics impostor. The mesh sometimes re-position fine, but their impostor stays in the previous position. SO, the mesh becomes impostor-less, and won't do physics collisions anymore. After a mesh gets a physics impostor, the impostor (a ghost beneath the REAL mesh)... likes to have FULL CONTROL over the mesh. That way, the physics impostor/engine can TRY to make it act like a real-world object. Generally, we only use applyImpulse or applyForce or setLinearVelocity or setAngularVelocity... to position/rotate mesh that have impostors. In this playground, all balls fall to the ground. Click on any sphere... causes one of the balls to start shooting at others. They all roll and collide well. In lines 86-99, I DO force some positions. If ANY sphere goes more than 20 units below ground, we move all three spheres back to starting positions, and "reset" (forceUpdate) their impostors (which removes any residual linear or angular velocity). This should be a good playground to play-with, and I think Eisha might be moving full-speed ahead, once again. Feel free to ask questions and share your progress/issues, Eisha. I hope this is helpful. Hello and thanks to you, too, John! I hope you (and all forum users) are doing well. Note: There is one ODD thing happening to me.... in this PG. After an edit to the playground code, and RUN again, I get a.. Active camera not set - babylon.js:1:424738 E.prototype.createPickingRayToRef E.prototype.createPickingRay E.prototype.pick createScene Not sure why. hmm.
  21. By "placeholder", do you mean the PS emitter mesh? PS emitters CAN be a vector3, and need not be a mesh. Emitbox settings still work fine, so a "shape" of particle emission can still be used. Need particles to evenly-emit along a long rectangle? Can do, even with a vector3 POINT as the emitter. *shrug* Not sure if useful for you/this... just thought I'd remind of a cool feature. Be well. Good to hear about your success.
  22. Hello HyHy, and welcome to the BJS forum. What an interesting project you have! Cool! I don't have any answers to your issues, but I want to show you a neat system that our friend @jerome built. (at least I THINK he built it) It's called the Solid Particle System, or SPS. It's useful-for-you features are: - SPS is a very performance-optimized system - Particles/Pellets have basic collision-detect - Pellets have auto-calculated gravitational force, or disable gravity - Pellets have adjustable frustum/spread - Pellets have adjustable muzzle velocity - SPS systems allow a manual emit-count... a "pulse" of particles, and then go-idle, as wanted (a shot) - SPS pellets have easily-adjustable pellets-per-shot (pellet cluster-density) - SPS pellets can have multiple and odd shapes, in case you want to shoot rock-salt instead of BB's - Pellets can be deleted (recycled) upon collision - Pellets can fall to the ground or just disappear, at a certain distance, after they have missed the target/collision In my opinion, the SPS system is PERFECT for your "upland game" game/sim. I think you should give it some thought/consideration. Stay tuned... others will comment soon, I think. Meantime, SPS experimenters - let's create a basic SPS shotgun for/with HyHy... to see how well he/she likes it. (okay, okay, I would like to see/play-with an SPS shotgun, too. Sounds like fun!!! Let's see, we have an "explode-the-mesh" thing laying around here, too, yes?)
  23. Wingnut

    Adding a Roof to a House Built from Plans

    My pleasure. I tried some miserable plotting of woodgrain.... on some flat-shaded mesh. I got a brain tumor. Flat-shaded mesh are weird because they have more than one vertex... at the exact same location. SOMETIMES... 5 of them at the same location (see the stacks of blue boxify markers?) This is needed so that more "normals" data is available, so light reflections can show that "faceted diamond" type of rendering. Plotting. erf. UV's can be treated like percentages. For example, 0.3, 0.8 means... 30% rightward on X-axis ... and 80% upward on Y-axis (starting from lower left 0,0 corner of texture). Staple/clamp/tack THAT point OF the texture... to THIS vertex.
  24. Wingnut

    Adding a Roof to a House Built from Plans

    Hi TK. Everyone is scared to answer. Reading that vertices-manipulation code... is like trying to read Klingon text, eh? I think you'll need to be more patient. Possibly, this PG was coded by @JohnK. I could be wrong - happens often. He stands pinged, so he'll visit us. But you must admit... that teaching somebody that code... could be a very time-consuming task. Let's take a slow start. Do you understand what happens in lines 170-179? It's almost easy to see... that we take the data stored in some arrays on a "vertexData" object, and we apply it to a blank mesh. The 4 arrays... are positions, indices, normals, and UVs. Colors is another, but not used there. A bunch of junk about "plotting"... (shaping your own mesh)... can be learned in this plotting demo... It is using a colors array instead of a UVs (for texture mappings) array, but you can still learn lots and do experiments. Tour-around in the entire 1UHFAP series... see all the plottings people have done. (Yes, I DO wish we had + and - buttons on the playground GUI, to go-to next/previous playgrounds.) Positions - they are the positions of the vertices in 3D space... always 3 values.... x y z. Pretend that verts also have a WHICH ONE AM I number. It's often called an index. Indices - imaginary lines often used to delineate a "face"... which is a triangle. Usually/always they are 3 values. The values are vertex indexes... the WHICH ONE AM I numbers mentioned above. Indices drawn in ONE clockwise/counterclockwise direction... causes the triangle's "face" to have its "front side" in ONE direction. Drawn in the other direction, and the face "faces" the other direction. Used heavily in lighting and "backfaceCulling" ops... performance stuff. These are all things you can learn-about/experiment-with... in the #60 demo. Ain't it cool that the #60 demo has a boxify helper func... to display the "WHICH ONE AM I" vertex index number? Yeah boy! Normals - are a direction vector3, often used to calculate lights/colors. Sometimes they are also used for bounce-angles for physics collisions. Colors - BJS has a color-per-vertex system. It is well-activated on the #60 demo... showing a nice color-dithering effect. UV's - UVW is exactly the same as XYZ, except it is for textures. SO, UV could be thought-of as TEXTURE XY axes, yes? And that's exactly what it is. Each is only two values (per vertex) and the values are always between 0 and 1 inclusive. Textures ALWAYS have their X:0 and Y:0 point... in the lower left corner. So if you set a 0, 0 UV on some vert, that means that the lower left corner of the texture... will "clamp" there. If you set it to .3, 0, then the texture would clamp to that vert... 30% of its width inward along X axis. Textures can stretch, they are latex-ish. UV's can be thought-of as HOW TO STRETCH and WHERE TO STAPLE IT (clamp it) to a vert location. With me? Goooood. You are rolling into the world of the Vertex Masters. Most of the (Klingon) code in the #110 playground... is vertexData array manipulations. One of the most important things for professional vertex wranglers... is knowing how the arrays are formatted. How to "lookup" the position, normal, indices, UV, colors... of ANY vertex. Where are the commas in the array data? How are the values stored? This... takes practice... and some greasy Klingon-looking math-wrangling. Ok, from this point onward, I'm just as confused as you are. I'm far-from being a pro vertex wrangler. I failed Algebra 1 three years in a row, but I did manage a "D" grade for "Introduction to Algebra" in my freshman year. We make webGL frameworks 'round here, and not modellers. We don't teach modelling, either. But we got a few demos that can help you teach yourself modelling/plotting... using the BJS vertexData geometry-storage system. VertexData objects have some powerful tools on them, thanks to the fine core-coders for BJS. Many of those tools are there to help learn the system. Anyway, I hope I didn't accidentally tell you wrong things. And I hope others will visit and give advice, but be patient... especially with yourself. There's really no shortcuts to vert-wrangling, other than using a modelling software app. If you want to grapple great roof-plotter funcs like those seen in #110, ya just GOTTA "grind it out". The variable names you see in the code... ARE applicable and wise... but are severely abbreviated. Once you learn the terminology used in plotting, they will make more sense. It just takes time... and patience. But I think you can see WHY folks use modelling software. Plotting-by-math... is certainly no "walk in the park", is it? Sorry. You picked a GRUESOME playground to ask about "How does this thing work?". MANY of us are wondering the very same thing.
  25. Thx. I just merged two older demos... into a workable demo for us. Notice, I also "snuck-into" our forum posts... with my moderator's license, and changed the url's to #65. I wanted to rock the ship back and forth a bit... to show that all 4 of our render-target-textures... was live-steaming to their monitor windows. (add some continuous movement) I did a quick tour of RTT source code. It's amazing. The amount of coding work that was needed to honor particles, sprites, post-processes, stencilBuffers, etc... is astounding. Friggin' geniuses! Thank goodness JS has good circuit-breakers. Otherwise, the JS in RTT source code... would surely be a fire hazard. We would have VERY expensive framework insurance. Somebody COULD put a highlightLayer or glowLayer on the ship, now, so we can check if post-processes are being rendered on RTT's. LensFlares, shadows, blurs, there's bunches of post-process things to torture. Somebody should check sprites, too. Knowing if THOSE are ALSO failing/not, might help the code troubleshooters.