• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by fenomas

  1. I understand that! But with frustum culling there's no real way to be sure when a mesh has been rendered, right? If there's no way to definitely know when this is safe, and it doesn't help performance, should it just be forgotten about?
  2. Per the PG, isReady(mesh) returns true even for meshes that haven't rendered yet. Does that mean it's impossible to tell whether it's safe to freeze a material that is being used for multiple meshes?
  3. Hi, thanks for the response but it seems that things are more complicated than that. I managed to make a PG that (probably?) replicates my issue: http://www.babylonjs-playground.com/#8EMFCU As you can see it creates a bunch of meshes, which all use the same material, and then freezes the material later on. The meshes become visible at various delays. The transparent texture breaks for some meshes, but not always the same ones - it seems to depend on whether or not the mesh has been rendered at the time when mat.freeze() is called?
  4. I can't easily reproduce this in the PG, as it seems to depend on the timing of when scene.render is called. This looks promising, but mat.isReady() is never true - it returns false if no mesh argument is passed in. Do I need to check isReady(mesh) for a mesh the material is used for? Or all of them?
  5. Hi, I had some transparent textures that broke when updating to the current nightly build (from 3.2). After much searching, the problem seems to depend on the timing of when I call "mat.freeze()". Can someone confirm if this is a bug or not? Specifics: in my project I create and set up my materials and textures at init, and then freeze the material. I delay the "freeze" call, to give Babylon a chance to initialize, but this is while the game is paused so no renders are taking place. var mat = new BABYLON.StandardMaterial(name, scene) // set some colors... var tex = new BABYLON.Texture(url, scene, noMip, true, sampling) tex.hasAlpha = true mat.diffuseTexture = tex // freeze material after a tick setTimeout($ => { mat.freeze() }, 10) In 3.2 this worked fine, but in 3.3 my transparent textures are broken. If I delay calling "mat.freeze()" until after the scene has rendered at least once, things work as in 3.3. Bug or no? When is it safe to freeze materials? Thanks!
  6. Thanks folks, I think I have the general idea.. Lots o' lights: https://playground.babylonjs.com/#WJWSNL Follow up question for @Deltakosh: If a light has an includedOnlyMeshes array, and all of the included meshes are not rendered (e.g. due to frustum culling), that light won't have any performance impact on the scene since it's not bound to any meshes, right? Or in other words, if I maintain an accurate list of included meshes for a light, I assume there's no need to disable the light when its outside the view frustum?
  7. Hi, quick questions. I have a big scene (500+ meshes), over a reasonably large area, which uses octrees. My use case is, I'd like to add many short-range point lights to the scene - think fireflies - that have a small "range" property and thus only affect a small number of meshes. In other words, the scene would have more than 4 lights, but each mesh will be lit by fewer than 4 lights. My questions: Is it correct to assume that a light's range property does not interact with the "4 lights per mesh" limitation? In other words, if I add a point light with range=1 to my scene, every mesh in the scene is "lit" by that light even if they are far away, right? It looks like the correct/only way to do what I'm asking for is to add meshes to each light's includedOnlyMeshes array. Is this right? Is it correct to assume that includedOnlyMeshes doesn't know about octrees or parent/child relationships? In other words, if I want a point light to only affect the meshes in a particular octree, I need to add all those meshes to the light's includedOnlyMeshes array, and their children, right? Thanks!
  8. The scene object just keeps an array of all meshes in the scene. When you create a mesh it gets added automatically, but you can remove it by splicing it out of scene.meshes.
  9. Yeah, you're right - Cannon added proper contact events but hasn't done a version release since then. Probably the best answer is for people using Cannon in their project to do a local build and use that. I'm not sure it would make sense for Babylon to pull in a new build if the cannon maintainer isn't going to issue one..
  10. I think you have two separate categories of problem, and need two different ways of handling it. For things like tables and chairs, that have no parent/child relationship as far as the physics engine is concerned, you should probably remove any parent/child relationships from the meshes and make independent physics impostors for each object. For things like car windows, or a character's arms and legs that have animations defined in local coordinates, you should probably be retaining the parent/child relationship for the meshes, and making one big physics impostor for the whole object, rather than adding each car window and character arm to the physics engine. You don't normally want every single mesh to go into the physics engine, you want a capsule for each character, a couple of boxes for the car, etc. (Hence the term "physics impostor") Note that none of this should necessarily require you to change your authoring process or throw away your hand-made assets. But if the parent/child relationship is no longer useful at runtime (as with chairs) then throw it away at init, and if it is (character's arms) then retain it anc leave the child mesh out of the physics engine. (If you have child meshes that need to be in the physics engine - e.g. a player's sword that needs to knock things over, or car wheels that need to physically interact with the ground, then these are a third case and will need custom coding for each individual object.)
  11. As near as I can tell, that event is basically "contactStart", and there's no corresponding contactEnd, is the problem. Or rather, there seems to be "beginContact/endContact" events in the cannon codebase, but they don't fire in the playground and I'm not sure why.
  12. @Deltakosh Does the physics system take parenting into effect? It looks like it just copies every impostor's position/rotation onto the appropriate mesh each frame, even though the impostor's transform is in world coords and the child mesh expects local coords. Couldn't this issue be fixed if the "update physics object" function checked whether the target mesh had a parent, and if so transformed the (world) physics position into a (local to the mesh's parent) position using the parent's world matrix? @Ridge Batty I think the easiest fix would be to unparent your chairs from the table. The whole point of parenting is usually that you want the children to move along with the parent automatically - if you want each chair to move independently from the table then the parent/child relation doesn't make sense. If it's just an authoring issue, where the chair's initial positions are defined relative to the table, it would probably make sense to initialize them that way but still leave out the parenting.
  13. Cannon supposedly has beginContact / endContact events, but they don't fire for me in the playground - not sure if that's a cannon bug or a version issue or what. There's also a "world.collisionMatrix.get(body1, body2)" method, which seems to be undocumented, but works for me. But this only covers collisions between two bodies, so it's not really what you want. http://www.babylonjs-playground.com/#U4F9K1#4 In most engines (including Cannon AFAIK) they're identical, except that forces get multiplied by the timestep and impulses don't.
  14. @MackeyK24 Honestly, it comes down to what you want. I like using forces and friction because that's what I normally expect from platformers - whether it's super mario, Quake, or whatever, you usually don't go from motionless to full speed and back, you gradually speed up and slow down, and using forces does that. As for zeroing friction, again it depends what you want. I suspect that you probably don't want zero friction all the time though - e.g. if the player is standing motionless on a ramp, with no friction they'll start sliding down it, which may not be what you expect.
  15. STUCK isn't a specific enough problem to solve. My first guess is, the code to turn off friction isn't firing for whatever reason, and the friction makes it seem like the character can't move. But that's just a shot in the dark!
  16. Glad it's working out! It does both. In JS, null and zero are both "falsey" values - that is, they evaluate to false when casted to Boolean, so code like the above works fine. With that said, I only wrote it that way because for me it's idiomatic. If it looks wrong to you, by all means change it! If you're curious, here's the full list of falsey values in JS: false, null, 0, '', undefined, NaN All other values are "truthy" - i.e. evaluate to true inside an if statement. Oh, and please tag me if you post something you want me to check - I don't visit the forum that often, and miss a lot of threads.
  17. Setting a body mass to zero makes the body static, like a wall. The engine doesn't test for collisions between two walls! There would be a bunch of other problems as well - constraints would start working differently, any dynamic bodies the player collided with would bounce off as if the player had infinite mass, etc. The only reason to set a body's mass to zero is if you want the physics engine to treat it like a wall.
  18. I usually start out with masses of 1 and tune from there. For the most part it doesn't make a huge amount of difference, you can just pick a value for the most important thing and scale other things relative to that. Like I said, there are multiple ways to do most of this stuff. My sample code checked for any contact between the player and the ground. The sample code you posted checks for any contact on the player body with an upwards-pointing normal. The latter is probably what you want here, since then it will also work if the player is standing on other objects. If you want to find collisions between two specific things you want the former. Why don't you copy the code you're using into the demo I posted, so we can help? I have no idea what's going on in the sample code you posted, because it basically just calls "Vector3.RotateTowards", and Babylon doesn't seem to have a function by that name. If you haven't used the playground before, you can just open my link, change the code, hit "Save", and then post the URL here, and we'll be able to see and fix what you've shared. Precise control is not what you want. If the player is facing towards a ramp, and you move them forward by some precise amount, you'll just be moving them inside the ramp. If you want the player to have complete control over their movement just set the player velocity. (But keep in mind that the results won't feel "physical" - e.g. the player will have no inertia; no matter how fast they're moving in one direction pressing the a button will make them instantly move at top speed in the other direction.)
  19. That's cool and all, but the question was how to disable gravity Err, nothing looked wrong to me, but it's pretty hard to look at code in a video and figure out where the bug is, and I'm not sure I was looking in the right place. Instead, I whipped up a simple demo of the "naive" version of movement that I outlined in my first reply. It moves the camera with a player body, applies the right kind of movement vector, detects ground contacts, and so on. All these things can be done in other ways as well, but perhaps it will help as a start. http://www.babylonjs-playground.com/#U4F9K1
  20. Well, you fundamentally have two choices in managing the positions of things in a scene. Either you run everything, or you let the physics engine run things. They're completely different ways to work, and you have to figure out which one you want. If you run things, that means you're the one who knows every object's correct position. If your'e doing something where the character just runs and jumps around an endless plane, then you don't need a physics engine - just set the character's Y to zero at all times unless he's jumping, and move him around by changing the X/Z positions, etc. On the other hand, if your scene has obstructions or inclines or whatever, and you can't easily calculate how the character's position should change depending on which direction the player moves, then you probably want to tell the physics engine what constraints exist and let the engine decide what the correct positions for things are. But what you generally don't want to do is double-dip, and sort of use the engine to do this or that but also manually set the positions yourself based on some raycasting in certain situations, etc. Cannon tracks collisions as "contacts" between one body and another. The world object has an array of contacts, which one can look through to check if two bodies are touching, and you can also add event listeners to the world object for "beginContact", "endContact", and so on. Afraid I don't have any sample code handy for this, and I don't know if Babylon exposes any useful helpers that wrap whatever Cannon expects you to do.
  21. Gravity is basically a downwards acceleration of G, which is the same thing as a downwards force equal G * M (the object's mass). So the easy way to cancel gravity for one object is to apply an upwards force on it equal to G*M, and they'll cancel out. However, rather than canceling gravity and then re-applying your own custom gravity, it would probably be easier to just apply forces that result in the floatiness you want. E.g for some time period near the top of the jump apply an upwards force of (G * M / 2), which would make the jump more floaty but not completely weightless. (You then probably want to turn off this force if the jump button is released, allowing the player to control the height of the jump.) Some physics engines also have a gravityMultiplier kind of property, letting you make different objects more or less floaty, but Cannon doesn't. dude...
  22. Main thing that jumps out at me is, Cannon's cylinder primitive isn't a mathematically exact cylinder - it creates an approximation out of subdivisions, and Babylon passes in 16 for the number of subdivisions (which is probably overkill for your case). So anyway each coin in the simulation is a convex polyhedron with like 64 faces (?), so that's why it gets so slow. If Oimo has precise cylinder primitives, using it instead should be way faster. You should probably also search for coins that are on the bottom of the pan, or under other coins, and change them to static if they're not moving. That wouldn't be exactly physically correct, but it would limit the number of collisions and make things scale much better.
  23. https://doc.babylonjs.com/overviews/using_the_physics_engine#physics-joints A joint is anything that imposes a constraint between two physics bodies. E.g. a distance joint constrains the distance between them, a hinge joint constrains the angle, etc. Details of how to apply and tune them will depend on which physics engine you're using.
  24. This could happen in principle, but I haven't seen it - Babylon performance dies before physics is a problem. I mean sure, your scene with 1000 things will be slow, but if you profile it I think you'll find the bottleneck is Babylon doing mesh selection and calculating world matrices. As I've written before, moveWithCollision is fine if you are moving one thing and you want to detect collisions with other things which are all static. If you have two dynamic things that can collide with each other, use a physics engine.
  25. Side note: native-vs-JS has nothing to do with any of this. Getting natural movement with a physics engine is tricky, but it's not computationally expensive.