fenomas

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?

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?

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?

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?

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!

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?

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!

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.

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..

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.)

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.

@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.

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.

@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.

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!