Jump to content

fenomas

Members
  • Content Count

    501
  • Joined

  • Last visited

  • Days Won

    10

fenomas last won the day on August 6 2020

fenomas had the most liked content!

About fenomas

  • Rank
    Advanced Member

Recent Profile Visitors

2807 profile views
  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.T
  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,
  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
  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 th
  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!
×
×
  • Create New...