Wingnut

Members
  • Content count

    3,535
  • Joined

  • Last visited

  • Days Won

    72

Everything posted by Wingnut

  1. 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!
  2. Oooh, new "settings" pulldown! Sweet. Gettin' fancy.
  3. I worded that badly and slightly incorrect. I should have said... Only FreeCameras (which is not a mesh) can have physics-engine-less gravity automatically applied to it... by the BJS framework. Only FREEcamera class has .applyGravity. BUT, particles are (sub)mesh, and they also have applied gravity from scene or from particleSystem.gravity property. Sometimes, I am not very thorough in my info-passing, sorry. And last I knew, freecamera. _needMoveForGravity = true ... is the way to make the cam start falling at scene.isReady. (secret private _property info) Otherwise, it takes one arrow-key move of the camera... to make camera start falling. Don't forget .checkCollisions = true for both ground and falling cam, or else it will never stop falling. Perhaps someday, we will have a contest for "Best motion sickness in a playground scene". This is all non-physics engine stuff, of course. Scene.gravity is for built-in stuff (freecams, particles)... but it is ALSO used for 3rd party physics engines IF no gravity is set on the physics engine itself. Your question is still a good one, though. (Why mesh have no .applyGravity? [loose quote]) I have no answer. Perhaps we can coax @Deltakosh or other core Gods... to visit and explain. You sound like you have much technical expertise. It seems I (and others) have PLENTY that we can learn from YOU. Coooool! I'm glad. If you wish to tell me/us YOUR STORY... brief or detailed (or if you have website with "about me"), I sure would be willing and honored to read about you. (thx) Yes, cloth demo is a bunch-o-joints ( distanceJoints hung-from stead-points )... and the cloth uses "particleImpostors". I never knew particleImpostors (point impostors?) existed... until @RaananW used them. SO much to learn, SO little Wingnut brainpower. heh
  4. Hi Hans! I was just talking, recently, about the inconsistency of registered physics onCollide... with @Jack Morris ... over in the Wingnut Chronicles. You must have heard me talking. Too bad it is inconsistent. I suspect that the inconsistency is related to the physics "timestep" which Fenomas recently taught us some things -about. I don't have the exact syntax handy... for how to set a physics world's timestep, sorry. AND, timestep will affect all the physics motions, so, I don't think that is the answer to our inconsistent physics collide-monitoring. I'm still looking for ANY demo... that changes the color of a mesh... EVERY TIME it collides, high or low velocity... with another physics-active mesh. Perhaps "workers" are involved, too. I'm quite sure that "workers" are involved in our non-physics intersection/collision, but I'm not sure about physics intersects. I doubt they are used, there. As for getting the exact FACE or POINT of first-contact... phew... I dunno. Thinkin'. hmm.
  5. My pleasure, JM, I have enjoyed our conversations to date, and you have a fun and inventive personality. I predict that you will quickly become a BabyonJS superstar. You seem like a really cool person... I'm glad I got to meet you. Perhaps we have many fun adventures ahead. I hope so. If you get a chance, I would like you to do a forum search for 'getHeightAtCoordinates'. It is a function on mesh-class objects, and when used on heightMaps, it can be used for terrain-following WITHOUT physics or gravity. (thx @jerome) http://jerome.bousquie.fr/BJS/demos/getHeightAtCoordinates.html There's been others who have used Rays for terrain-contour following, and behind the scenes, mesh.getHeightAtCoordinates(x, z) might use a ray, too. All I know... is that it is useful at times. It can keep "things" stuck to the ground when moving across bumpy terrains. You and I talked briefly about terrain following cars and mesh. When using getHeightAtCoordinates, there's no hassles with CannonJS meshImpostors ONLY interacting with spheres. Your car won't be doing any parabolic car jumps off-of the mountain peaks, though... unless you are calculating your own flight trajectories. But take time to study Jerome's stuff, if you feel so inclined. There's nobody better at making mesh act like they are using a physics engine... without using a physics engine. (Okay, okay, there's likely others nearby who can do it as well. But Jerome made demos with great in-code comments... and wrote fine docs.) Generally speaking, only cameras (not a mesh) can have physics-engine-less gravity (unless you calculate your own gravity movements for mesh - fairly easy). So, keeping your character or vehicle on the ground in bumpy terrains... is an issue. Our friend Jerome saw the issue, and many more geometry improvements... and "smoothed" as many as he could (he's a hero of mine, like SO MANY around here). The solid particle system is his, meshBuilder is his, ribbons, tubes, extrudeShape, parametric constructors, spherical harmonics, on and on. Ever seen a spherical harmonics shape, JM? Take that link to some playgrounds and do some touring. Jerome has even been known to morph the SH shapes from one to another. GOOD GOOD stuff. We got godrays (volumetric light scattering) involved, too. Fun fact: Since Oimo does NOT have a meshImpostor, but still likes to use physics-active terrains, the folks at Oimo have showed us how to do it. Although I have not investigated, rumor has it that the entire terrain is "covered" with invisible sphereImpostors (you can see the spheres do a little "hopping" as they roll across slightly-bumpy invisible sphereImpostors). Cool, huh? A bit like Raanan's cloth demo. (wireframed by Wingnut) One more thing... @Temechon's tutorials/projects. T-doggy does everything great, but especially... he is great at getting a user started toward a project... with OOP in mind (object oriented programming). When using OOP, many of your functions and classes... are re-usable, project after project after project. If you want to learn how to do coding/projects the right way, visit that link just above... and study his way of doing things. HIGHLY recommended. These guys are just a few of the MANY excellent coders and thinkers around here. They ALL have taught me things... and I am glad to pass those tips on to you and others, as best I can. The few things that I know about... all came from "team"... and I really like ALL OF THEM, including you, JM. You're going to fit-in just fine 'round here - welcome to the team. I hope you can hang-around with us for a few... decades.
  6. Oh crap, I forgot. Cannon's meshImpostor only reacts-with spheres. Well pffft. I guess you better use a box-ish or sphere-ish model, so you can use a more standard impostor. (Wingnut kicks the meshImpostor, just for fun) It's mostly for heightMap terrains... and rolling spheres around (sometimes used as vehicle wheels) ...in the mountains and valleys. Rocky Mountain bowling and Himalayan golf. heh The "r" key (remember cam) on the top of the flyer window... is somewhat interesting. Pressing that (or pressing 'r')... stores the current camera rotation and position... into the browser's "sessionStore" system. Then you edit some scene code in your programmer's editor, save, and hit control-r in the browser... (to reload the new scene). The flyer scene can/will use that previous camera orientation... as the starting cam orientation. This is handy for when you navigated a camera to a certain precise close-up place, examining something carefully, and you want the camera to begin at that SAME location after the reload. It's all Wingnut code, so, it is naturally 3-8 times more code than necessary.
  7. The black area under the flyer? Yeah, it is a landing pad. But during some BJS or browser version, the lighting changed or something, and it lost its texture, and went backface-culled. So did the plane in the center of the flyer, which has a helper picture on it (these issues are MORE-likely a wingnut mistake). So, I have two "broken textures" on those planes. I should fix that someday. It is likely fixed in the zipped t28 version I linked earlier. Correction: go.flyfr.handle is currently invisible and it is the same size as the entire flyerframe. That is the only reason it bounces off the walls semi-nicely. So, if the model you want to fly... is not square-ish, it will not bounce off walls "correctly". If you want the model you parent-onto the flyer... to also have physics (perhaps on a very bumpy model), then you will need to activate Cannon's meshImpostor on your model. If your model is a more-standard shape, use one of the simpler impostors... for higher performance.
  8. Oh, for the flyer? oooh, well, that would require adding an AssetsManager task or SceneLoader call... to load a .babylon or .obj file... with a model in it.... into the flyer28.htm code. Then... umm... myModel.parent = go.flyfr.handle; Then do rotation, position, scaling adjustments on the Winnebago until it hides the bed frame's poles and rails.... and SAVE! Bed frame is dynamic, too... easily sized, without any joint gaps (I made it before I learned about mergeMeshes() - haha) 'go' - global object (because Wingnut was confused about JS scopes, back then). flyfr is the flyer frame. Handle... is the central gizmo parent of the frame (a sometimes-invisible box dead center of the frame). Master parent. SO... you can actually completely REMOVE the flyerframe (the bed frame)... and keep go.flyfr.handle. IT is where the applyImpulses are thrusted-at. There is no applyImpulse force happening at the thruster ports. That's fake. It COULD be done, but... it would take tight joints between thruster ports and flyer frame. I was too noob, back then, and haven't de-noobed much since. That flyer... that's... quite a mess. But there's some knowledge in there. No promises. Actually, controller09.js (inside the t28 zip) is the meat and potatoes. It really ONLY controls physics on a single box... go.flyfr.handle. So, a guy could just make a normal BJS box, do a few adjustments to controller09, and the box would fly just like the flyer, except without particle emitters.
  9. Take your time, goof around, have fun with it all. Um... I noticed that you are pondering... "upAlign", and things like that. Don't over-think the "motor". Remember Fenomas saying that you should move a "more-static" no-collide mesh (likely invisible)... with your keys, or even with your applyImpulses. Then use a joint between THAT impostor, and your real player's impostor. Depending upon the type of joint/motor/whatever... perhaps your "steadfast mesh" (the firm, yet moveable, non-colliding invisi-mesh at one end of the joint)... is sometimes directly above your player, or perhaps in same place as player (when motor/spring starts), or behind. (Fenomas also reminded me about STARTING the motion on a PAM... with a spring. Good idea, I've never tried it.) Anyway, your stead-mesh might need orientation-adjusting for each joint experiment. The mounting pole. Ever play tetherball? I actually call them "steads" in my code. https://www.babylonjs-playground.com/#14VFYX#30 There's a pile of... everything, eh? I tried to convert this from setPhysicsState to... the new way. I think it's almost converted... but... got a non-console error. Might be a typo in my conversions or something. Canvas2D made some changes in its positioning methods... since I coded this about 6 months ago. Things aren't lined-up real well... but it's all fixable. When everything is working, clicking on a button... makes the "chain-of-buttons" swing back and forth a bit. Each button is a PAM (physics-active mesh)... suspended from one another by physics joints. That green "pole" at the top... a "steady" place to attach one end of joints-to, you ask? That's my "stead". Yay for steads! A guy could turn-off collide on that, and applyImpulses to it, and move the whole cascade-o-buttons from place to place. It could be invisible (hint hint). I don't think there's a real word "stead", but it works... you know... homestead, bedstead, steadfast... all things with "steadiness" I have a small town near me... named Springstead (Wisconsin). Remember the long coil spring that was used to close gramma's porch door? Well, the little "eye-screws" on each side of that long spring... are called spring steads. The town is named after those. You're not buying that story, eh? Yeah, me neither. Carry on.
  10. Does this thing work for you, JM? http://urbanproductions.com/wingy/babylon/thruster/t26/flyer26.htm [zip, slightly fresher] It's an older BJS version, but, it can give you a "feel" of keypress auto-repeating (held key) cumulative applyImpulse. Unfortunately, cumulative thrusting starts slow... and gains speed as inertia accumulates. Braking does the same. It appears to do little... but slowly counteracts the momentum. All the buttons in that scene... can be quick-clicked OR held-down. The thrusters are a little "hot" compared to a NASA Spartan satellite, but, it's all adjustable.... later. (within controller.js) Keys active: control + arrows and control + pageUp/pageDown = rotation shift + arrows and shift + pageUp/pageDown = translation control + NumKeyPad 2,4,6,8 and control +/- = rotation shift + NumKeyPad 2,4,6,8 and shift +/- = translation Two complete sets of control keys! WOW! There's actually ANOTHER complete set of control and shift keys... around the "L" key. Goofy. And, I was VERY new to physics when I made this (before I knew about setting linear and angular velocities). So, this is ALL applyImpulse... including DUAL applyImpulses for every rotation (mesh twists). Holy crap, huh? What a festival of incompetency! But version 29 of "the flyer" will be MUCH better. I'll code it using lots of joints, but none in the physics code. heh. (I'm going to wring every last drop of laughter out-of Fenny's Funny) Grab zip, steal code, even put your name on it, I don't mind. It's all bad programming. heh The flying bed frame is somewhat modeled after a NASA "SAFER" unit, which is a cold-thrust safety device that spacewalkers wear, in case they become un-tethered. It is VERY EASY to parent ANY model to this "frame". That was its original purpose... a universal physics flyer. Import-in a Winnebago camper, parent it to the flyerframe, and start flying your Winnebago. YAY! This flyer has 24 thrust ports, and each thruster has FOUR particleSystems available (fire, smoke, soot, ice particles) for a grand total of 96 particleSystems. (only 16 can be active at any given time) WOW, huh? Talk about your over-kill, eh? heh. LOVE IT. This "thing" is/was targeted be used for Space Taxi 3D, a 3D version of an old Commodore 64 game I used to love. Project is... well... back-sliding, like all my projects. heh JM, are you going to make some tests... trying out every kind of physics joint that can be connected between two physics-active mesh? There's about... oh... 4-7 pre-made joint types available, in both physics engines. These joints... have "constraints" and "springyness" as their parameters/settings. For example, you can set minimum and maximum rotation limits on a standard hingeJoint. And a distanceJoint is simply a hinge joint with a stand-off distance. You need to make a few mesh, hook them together with various joints, and start attaching some keypresses to some applyImpulses... thrust them puppies around on the ground a bit... watch how they "act". FUN! Refer to that non-working train wheel demo... for some nice modern joint code... thanks to RaananW... who once "updated" the train wheel demo FOR me.
  11. The smart function was a "retarded wingnut idea" and was superseded by constraints and springs and similar. Wiser, especially for punching bag/bop toy. I think these physics engines have MOST of the tools to cover our wildest physics imaginations - already built-in. Familiarizing and experimenting... I think that's what you and I both need, JM. I DO really like your spirit, though. Hey JM, are you using a keypress to move the player/mesh? Or... click'n'go? Touch/gamepads? Keypresses do that auto-repeat stuff, so they are somewhat good for repeating tiny impulses... which can be cumulative (mesh goes faster, the longer the key is held). OnKeyUp, crank-on the friction, but maybe not mass... as mass == inertia, too. Mesh might become MORE difficult to stop at keyUp... if mass gets increased at keyUp. Test test test, you know. Try it all. I imagine you are finding TONS of broken physics playgrounds, though. SOME may begin working if you choose version 2.5 (at top of playground). I should go on a physics playground updating mission. Big job. I would probably make about as much progress on THAT... as I have with my labels tutorial (which is actually getting FURTHER from completion each day, quite an accomplishment for a project). I am making good progress toward non-completion. heh. Some of our best physics demo-making people... are actually MISSING. There's rumors that they are all in mental institutions, now.
  12. Cool, thanks. Yeah, even if we needed a "custom constraint", start-with a base constraint-class object, and customize from there. Even use equations (force rules) for it... that start-with base equation-class. The engine is already familiar-with (and likely optimized-for) those things. Yep, yep, yep. Good tips. (Above links are for CannonJS. I haven't seen an OimoJS api, yet... but I have an older "thing" that helps.)
  13. hahaha... ahhh... rolling your own. Oh yeah, I completely forgot about constraints! Yep, yep, yep. And yeah, I sort of understand steps... because of particle update speeds for particleSystems. But, for others... nice explanation, thanks for that. Well-worded. A fine on-the-fly tutorial writer. Constraints. Sure. SliderJoint with constraint... moves a set distance. You bet. Good reminder! Invisible stoppers? pffft. Old school, eh? It's a miracle my computer doesn't use vacuum tubes. Or worse - steam powered.
  14. VERY cool pinball thingy! hahaha... excellent! I forgot to tell you ONE thing... in my last barfing. Physics engines have a "step" speed that can be adjusted. It is my "theory" that this step speed changed... when the 'new' term was removed from that Oimo constructor. (not a ghost) heh All in all, I don't know very much about this step speed... but keep an eye-out for it... as you tour physics playgrounds. You can also cause a step... with physics world.step()... inside the render loop. Tweaking the physics engine step speed... has been known to have powerful affects. (Wear safety gear, please) So... umm... have you thought about HOW to replace the non-physics-engine-based moveWithCollisions() ? In theory, you should be able to translate your mesh to any position, using applyImpulse or linearVelocity, within a "smart function" - a continuously-position-monitoring function. Essentially, computer-controlled thrust management. This function would thrust HARD, and brake HARD, too. With some serious mass on your character, you will get automatic ease-in/out motion, too. Perhaps, in a continuously-updating func, keep adding more forward linearVelocity... until half-way to destination. Pseudo: var changeAmount = new BABYLON.Vector3(xAdditionalThrust, yAdditionalThrust, zAdditionalThrust); linearVelocity.addInPlace(changeAmount); // until halfway When half-way... changeAmount = changeAmount.negate(); linearVelocity.addInPlace(changeAmount); // until all axes are zero - mesh stopped. In theory, the mesh should come to a stop at the destination. That's one way to do a mover. No stoppers and no joints needed, but you need great thrust management. See our light.setDirectionToTarget for a line of code that creates a directionVector between two worldspace Vector3 .positions (it's a vector3.subtract thing). Good luck.
  15. Hiya B! No replies, huh? I happen to KNOW that we have the tools to do this, now, using WorldSpaceCanvas2D. Perhaps YOU are the one who does this integration. There's what? About 8 different kinds of "widgets" used for dat.gui? Produce the same 8 classes of worldSpaceCanvas2D "things", and you are on your way to superstar land. Probably avoid allowing "drag" on the worldSpaceCanvas2dNode (which is the mesh that worldSpaceCanvas2d stuff is painted-onto)... for the time-being. That would be difficult. But, you can create +/- value-adjuster buttons, current value read-out, checkboxes, input type-in, etc. Later, you can group-together instances of those 2D-within-3D widgets... into panels of GUI. Easy! (sort of) Could you have that on my desk by Monday morning? Thanks! heh. Again, sorry for the slow replies. You asked a GOOD question. I'll keep thinkin'. Be well.
  16. Heya N! Sorry for the slow replies. Is there ANY chance that you could reproduce this issue... in a playground? Or, how about creating a version with no laser and stripped-down core, common, and Game object? Let me make sure I have the symptom correct. Click-on any purple sphere. Then click somewhere on ground grid. There is a "flash-glitch" that happens as animation starts, right? It is ONLY happening on the green box, yes? What does a console dump of green box anim keys LOOK LIKE (dumped just before anim start)? They look correct? Anyway, we have now "bumped" the topic back onto forum page 1. Not easy to troubleshoot... kind of big. Simplify and de-webpack if you can. I'll keep thinkin'.
  17. Hi again, hunts... I see you are working hard. Beautiful scene... nicely done. Are you seeing some errors on the console? Error: Error status: 404 - Unable to load /src/Shaders/glowMapMerge.vertex.fx Error: Error status: 404 - Unable to load /src/Shaders/glowBlurPostProcess.fragment.fx Error: Error status: 404 - Unable to load /src/Shaders/glowMapGeneration.vertex.fx ??? I am. https://github.com/BabylonJS/Babylon.js/tree/master/src/Shaders They seem to "be there", but... something is amiss. We'll pingulate Admiral @Deltakosh and/or Professor @Temechon and other core Gods. They'll get this fixed soon, I know they will. Sorry for the inconvenience... and thanks for the report.
  18. Hi again @Jack Morris, thanks for the kind words. It sounds like you understand these systems quite well. Good job. Force-moving a mesh that has a physicsImpostor... has been a problem for a long time. I say "force-moving" because... previously, there was only two ways to "position" a Physics-Activated Mesh (a P.A.M. ? heh) 1. .applyImpulse(directionAndMagnitudeVector3, contactPointUponMeshVector3) 2. impostor[.body].setLinearVelocity(directionAndMagnitudeVector3) But recently, BJS superhero @davrous made some changes and told us about it... here. Now, it appears that we CAN force-move the PAM shape/mesh, and the underlying physicsImpostor will obey. Keep in mind, though, that the PAM's impostor... could STILL have linearVelocity and angularVelocity AFTER the PAM-positioning. It might start moving again, after re-position... due to residual stored energy/inertia. In this forum topic, I do some minor repairs to a physics playground. Click on ground to tilt it, and start the ball rolling. User issue was... ball is "violent" (out of control) after it is returned to starting position... after falling-off ground. When the ball falls-off the ground, it has angularVelocity (rotational roll), and as it fell, the gravity caused it to highly-increase its downward linearVelocity, too. It had LOTS of energy remaining upon the impostor... when it was re-positioned. SO, look at the render loop... lines 43-56 in that playground. See lines 50 and 52 killing the impostor's energy? It works. When the ball returns to starting position, it falls straight down with no spin. Yay! Physics pro @fenomas had an interesting idea for force-moving PAM's... too. I've never tried it. He said... loose quote... "It might be best if you use a physicsJoint to attach the PAM's impostor... to another .visibility = 0 PAM (possibly positioned directly above the PAM you want to move). Then move the invisible PAM (not the visible one), and let the joint pull the visible PAM... to the new position." This could be considered a "soft move" as opposed to a "hard move", because.... joints have some flex (slop in their bearings). I thought his idea/info was interesting and worth consideration. It has ALWAYS been difficult to make a PAM... move a CERTAIN DISTANCE with setLinearVelocity or applyImpulse. When tried, they usually start with a fast velocity, and then the PAM's mass and friction slowly bring the PAM to a stop. - REAL slowly, depending upon mass (which can be adjusted as a PAM nears its move-destination). I repeat this... mass values can be changed WHILE the PAM is linearVelocity-moving. THIS might be easier for you... than creating "gravity wells" around the PAM at move-time. ALSO... consider this. A PAM with a continuous applyImpulse or linearVelocity from the bottom ... can LIFT the PAM a bit, and thus... reduce its friction against ground. *shrug* AS the PAM nears its move-destination, reduce the bottom-side thrust, and the friction will start increasing (but not for spheres... see below), bringing the "slightly-floating" PAM to a stop NEAR its intended destination. No promises, though. Davrous' new move-the-PAM modifications... MIGHT change all this. In OTHER situations... SOME users have placed invisible PAMs at the destination point, and the moved PAM collides with them, and stops (sometimes with a small amount of bounce/restitution/recoil, unfortunately). Stopper mesh. But sometimes, the users "register an onCollide function" on the impostor. THEN, when the moved PAM collides with the invisible "stopper PAM", they immediately kill energy (in their added onCollide func)... to minimize recoil from the impact (and to sometimes change mesh color upon impact). UNFORTUNATELY... we have seen indicators that these registered onCollide wedge-in functions... don't trigger on EVERY collide. SO, we have seen inconsistency in using the registered onCollide. A recent ping pong table/paddles project was undertaken by user @Abdullah, and you can find my posts about THAT onCollide inconsistency problem... by doing a forum search for 'onCollide'. (Just read the first 5+ returns that were posted by me.) In that project, we could easily see the inconsistency of the physics-registered onCollide... as the ball bounced across the tabletop. SO... I'm not sure if a physics-registered onCollide is a good way to determine if a visible PAM has collided with an invisible (movement-stopper-) PAM. (or for any other reason to monitor-for physics collisions) Perhaps, setting restitution to ZERO on the moving PAM and on the invisible stopper-PAM... would eliminate any "recoil" from the collision, with no need to register an onCollide on the impostor. No color-changes-upon-impact that way, though. There's one last thing you should know, which was also taught to me by Fenomas. Spheres do not have enough surface-area-contact with the ground or other flat surfaces... to have any significant friction. Then physics pro @RaananW taught us that we can do something like... rollingball.setLinearVelocity *= .99 ... INSIDE the renderLoop. There's more to it than that... but perhaps you understand. You want to slowly reduce all three Vector3 linearVelocity values... by a small amount in each renderLoop... until all three axes-forces are at 0. The ball has stopped... due to... "fake friction" or "wind resistance". Otherwise, them darned sphere impostors roll and roll and roll, no matter their mass, and no matter their friction. Okay, how's that for a pile of TOO MUCH INFO? Do you have a brain tumor, yet? I hope not. The good thing about all of this... the experimenting is usually pretty fun. But these "anomalies" can sure cause hell for a production team on a budget, eh? Sorry. We're still blazing webGL trails and discovering new horizons, and perhaps YOU could discover the "breakthrough" that changes it all. Please share your discoveries, when/where you can. Thanks! Make suggestions (and actual edits) for the physics docs, too. We can use all the documentation and test-case help we can get. And of course, write back, here, or in new forum threads... we're here to help. We don't ALWAYS have the answers, but we usually have some ideas. Be well, party on! @Jaskar - thx for the likes. It's good to see you again! I hope things are going good for you.
  19. Hiya JM, nice to see you, and thanks for reading my ramblings. Yeah, a few of the links have gone dead over the years. I guess that is to be expected. Sorry. The two physics issues you mention... got broken recently in "The Great Deprecated Command Hose-Down" - SetPhysicsState is gone in the newest BJS versions. It is now done like... sphere.physicsImpostor = blah blah blah. Here are lots of examples... from our playground searcher. - compound impostors went deprecated and eliminated, too. You can still build compounds, but you do it with standard BJS parenting/childing. The secret... is to put the impostors on the children FIRST, and lastly, on the parent. This might change, someday. When in doubt, read the book. We have also seen some indicators that scaling the parent should be avoided... but that needs testing. You may have noticed that sometimes... it is BABYLON.Mesh.CreateBox(), and sometimes it is BABYLON.MeshBuilder.CreateBox(). The MeshBuilder version allows you to enter parameters inside the constructor, such as width, height, depth... so you can create a box (and many other basic shapes)... with the precise dimensions that you wish (and therefore no need to set any mesh.scaling). This is good policy for creating parents... for these "families" of physics objects (formerly known as compounds). Let's see, I once made some particle PG demos using LOTS of custom code, and those playgrounds went stale, sorry. I have made new versions of SOME of those. Umm... I had a demo of some particles... radiating god rays (volumetric light scattering), but due to some changes in the depth rendering system (i think), particle materials can no longer produce godrays. I'm sure there are more bad PG links... sorry for the inconvenience. I guess I would suggest... don't read TOO FAR BACK into this topic thread. Perhaps no older than 1 year, eh? There will be less stale playgrounds, that way. heh. Holler if you have more questions. In a day or two, I will repair the train wheel demo, unless you beat me to it. The de-rotated white wheel hub... has me a bit worried, considering recent work happened in our physics plugins... regarding rotation (uh oh). Investigations ahead. Hope this helps. I'll keep you posted on what I discover, and you feel free to talk about anything you like, anytime, here in this thread, too. As you can tell, it is a yap-a-thon. Thanks for pointing out the broken stuff. Now you know a bit of history behind it all. Our two 3rd-party-authored physics engines... CannonJS and OimoJS... are not always easy to tame. They have been "grumpy" at times. PS: Want to see an unusual little secret... about OimoJS? I knew ya did. Here is a basic modern physics test-playground, currently wired for OimoJS. Notice the motion is sort-of slow-motion? *nod*. Now remove the term 'new' from line 29. RUN. Did the motion get faster? It does for me. Quite a bit faster. Cause: Most people think it is The Ghost of Archimedes... who has built a small cabin in our Oimo physics plugin.
  20. Hmm, no talk about the blurry 3D when HTML scaled-up, huh? ooookay. Put it in Q&A instead? *shrug* I suppose if we REALLY hit the controversial stuff... like the Netlify ad on the bottom of the playground... I'll get DOUBLE silence on THAT subject. Some kind of contractual obligation? hmm.
  21. Hiya @abhip96, welcome to the forum. From the description you give, it seems you might be needing a "2-step solution". I think you needed to BOTH produce the mesh as a BACKSIDE, AND do a material.backFaceCulling = true (to cull the FRONT side). How does THIS playground demo... look? http://www.babylonjs-playground.com/#LG3GS#148 Adjust as wanted, edit, RUN, SAVE, you cannot hurt anything in the BJS playground. See how I back-sided the mesh constructor AND backface-culled the material? *nod* I hope this helps. Write back, perhaps with a few more details, as wanted. Ask anything, and have fun.
  22. Object.defineProperty(GroupInstanceInfo.prototype, "transparentData", { get: function () { if (!this._transparentData) { this._transparentData = new Array(this._partCount); for (var i = 0; i < this._partCount; i++) { var zoff = this.modelRenderCache._partData[i]._zBiasOffset; this._transparentData[i] = new TransparentGroupInfoPartData(this._strides[i], zoff); } } return this._transparentData; }, enumerable: true, configurable: true }); There it is, the zoff line. Hey @Nockawa, first of all, welcome back! I hope you had some fun "out west" in the west. We sure miss you when you're gone. Someday, you may actually get to play with BJS, instead-of always working on it. Immutable, huh? That means... unchangeable. hmm. If we had a function... sprite.setInitialTexture(someTexture, hasAlpha, etc)... that function COULD re-initialize the sprite as if it were a new sprite, yes? The 'Initial' part COULD indicate to users... that the sprite is being re-created to accomplish this. I think you agree, this issue is going to arise again, because... making a new sprite2d with rect2d and text2d (like the #29 PG demo)... is a substantial amount of code lines. There will be future others who will try to re-use a sprite2D, instead-of making a new one (esp if they ONLY need to change the texture or atlas). So, I'm thinking about ways to make it APPEAR as-if they changed the texture, when actually, they re-created/re-initialized... using the new texture/atlas. Not sure if that would work. Just thinkin' and inkin'.
  23. Hi gang! Fresh bobsled. http://www.babylonjs-playground.com/#PBVEM#112 As you can plainly see, this one is sponsored by SCRABBLEĀ® Bobsled Racing Team, Inc. Remember how I mentioned that the three bobsled BODY parts (nose, cockpit, tail) could be adjusted to LOOK LIKE it is one continuous texture, even though they are 3 separate mesh with 3 separate materials/textures (and no shared UVs)? I thought I could adjust the texture offsets and scales... to make things "align", even though each mesh had UVs for an entire texture. Well, as you can see, careful texture offsets, scaling, and angling... allowed me to get "in the vicinity" (fairly close). Nose/cockpit "seam" is looking fairly good... with only SLIGHT issues on the bottom of the sled. Looks tolerable. The texture seam between the cockpit and the tail section... still needs work. And the foils/fins need some adjusting, too. They MIGHT use a completely different texture, anyway. But... the beast is coming along fine... looking better every version. Quite a "grind", but I wouldn't have it any other way. If you don't bleed enough on a project, there's no sense of accomplishment... in the end... while bandaging all the wounds. Later, I may be able to formulate some formulas... to mathematically square-up the bobsled's pieces. The sizes of the pieces... should match perfectly, somehow. Currently, I have some slight size differences... piece-to-piece, and that affects my texture aligning. Some of these texture offsets and scalings are super-sensitive. Micro-adjustings. It takes forever, doing it manually. I think I can "derive" (calculate) these scalings and offsets, sooner or later (based-upon values used to "generate" the bobsled pieces). My dog seems nervous.
  24. That dark theme is... pretty nice. My eyes like it. Thx for that... very good. Have you... umm... control-mouswheel'd over the PG GUI... kicked it up to OldPeople/HappyMeal font sizes... and watched the top button-bar NOT wrap? But, it IS cool how it keeps the PRIMARY buttons, and eliminates the added-features buttons. Almost like it was designed that way. Perhaps, not supposed-to wrap. (Control + and control - ... also scale the HTML) Notice the "fuzzy" mesh edges... when we do that control-mousewheel geezer-zoom? That doesn't seem right. I wonder why that happens. Stuff. Stuff to investigate. Stuff that makes ya go "hmm". (thx) http://www.babylonjs-playground.com/#PBVEM#112 Would anyone agree that the black-on-white numbers along the borders of the scrabble board plane... have their best clarity and resolution... when control - (unzoom) is at its smallest (when the html is scaled tiny)? Seems like that to me. But the canvas IS also zooming a bit, as I downscale the HTML. Perhaps THAT is changing the canvas clarity. Likely, this has nothing to do with the new PG features. It has probably been this way for over a year, and it might be unavoidable. *shrug* Use The Wingnut Chronicles for replies, if this topic is deemed to be the wrong place for this tangent topic.
  25. I'm thinkin'... hmm... umm... rendercanvas-within-a-flex-box... has more troubles ahead. JLH, after "troubles went away", were you able to RE-test all those other devices (that each acted differently), again? If you can, that would be cool. I bet you find troubles, if you do (even with 3.0). Another question... When you could NOT repro the issue in a PG, did you actually "hack DOM" and change the CSS of the PG canvasZone container (to flex-box-ish)? Perhaps it already IS so, or the x-splitter element is. I haven't checked. If so, did you then packed other elements "around" the render canvas (siblings)? (all ALSO within the flex-box-styled canvasZone container) If so, did you then use sin and cosine crap inside the renderLoop... to cycle the borderWidths of those canvas-siblings... fatter and thinner? (make them breathe) You know what I'm getting-at, yes? We should make a playground, which has flexy styles on the canvasZone (canvas container) and then do ANYTHING to make canvasZone need to continuously resize (such as swell and shrink borders of adjacent html nodes). (This SHOULD simulate a user continuously drag-resizing a container or window). THEN... once we have canvasZone flexified... and something causing it to re-flow and re-size constantly... ONLY THEN can we really see how well our scene.pointerX and pointerY are maintaining accuracy. Not an easy playground. No React.js... just a playground-based flexi-CSS torture chamber. Probably easier in JsFiddle. Adam gave us a nice little starter-fiddle... https://jsfiddle.net/nzexh6a6/4/ I suppose nobody wants to search for trouble... if nothing is obviously wrong. But... hmm, I also don't trust "it fixed itself". heh. If we DO make a test scene... we should probably aim-for small canvas in upper-right, the situation where JLH reported seeing problems most-often. *shrug*