Just hit run twice
You really don’t want to ease the process right? 
1 Like
The same without lodash…
https://playground.babylonjs.com/indexStable.html#W2ZA5S#30
Seriously importing a lib for a for loop 
lol, actually I mispoke, hit run once, I know it’s difficult – It was for _.random, and I start all my playgrounds with it because it’s pretty much stuff I think should be built into js core (and some of it has with es6 but still not nearly enough) and I find myself missing it immediately without it. it’s not that I’m trying to make your life difficult
Well…at least I have a repro…So I can start helping you
1 Like
I’m gonna clean your code because it is impossible to test with your code changing the prototype all the time.
Give me a few minutes to get a cleaner repro
1 Like
And now I clearly see the bug! Will be fixed quickly
Stay tuned!
1 Like
For the record, in my previous post, I wasn’t asking for a fix, I was asking for understanding or ideas, and or hoping to trigger a “maybe it could be this” in you, if there was something – I totally get where you’re coming from based on many of the other posts in the forum where playgrounds are easy and people fail to provide a repro and say “help me”. But when I get stuck on really complicated stuff, sometimes it helps to throw around exactly what is happening, where I think it’s occurring etc, sometimes for my own sake or sometimes the conversation will trigger a, oh maybe this could be a problem in the other person. (especially when I can’t even figure out how to reproduce). So I understood you couldn’t directly help, I was looking more for insight as to how that value could be getting set to true and or if there was a way to work around it, etc
I was pretty sure it was a bug because it worked in 3.3. That’s why I was eager for a repro
anyway, you don’t have to explain or apologize, the only thing I care about is to unblock you
2 Likes
And here is a workaround for now
https://playground.babylonjs.com/index.html#W2ZA5S#34
Basically You must have your code that is going to freeze the world AFTER all the addition so I move the call to initializeFreezeCallbacks at the end so that it will be after the sphere instance creation that happens during the on after render
Now I’m gonna check why it removes all the instances if we do not use that sequence of calls
Simpler repro case for the records: https://playground.babylonjs.com/index.html#W2ZA5S#35
So, that was the unrealistic case though. I don’t think it will fix (the workaround) the action manager case. I.E. - In my actual app I was initializing freeze after scene loaded first time. But, if I triggered enough hovers, eventually it will fall apart same way. – Also worth noting the other time it appears, is any time there is an action where I update my full game state, as there is a decent MS skip generally, which causes it all to disappear everytime.
Here is action manager based PG on cleaned up version, click the sphere enough times fast enough, it still triggers it
I also tried another version of freeze strategy which thought might fix since it seems almost like a race condition, but this didn’t work either.
Object.defineProperty(BABYLON.Scene.prototype, "$$unfreezeAndFreeze", {
value() {
let scene = this;
if(!this.$$freeze_scheduled) {
this.$$freeze_scheduled = true;
this.onBeforeRenderObservable.addOnce(function(){
scene.unfreezeActiveMeshes();
scene.onAfterRenderObservable.addOnce(function(){
scene.freezeActiveMeshes();
scene.$$freeze_scheduled = false;
}, undefined, undefined, this);
}, undefined, undefined, this)
}
}
});
No worries I see what you want to do…I’ll find a good fix
1 Like
OK I have a fix
will be live in a couple of hours
Thanks for your patience
1 Like
Awesome! I look forward to trying it. NP, thanks for yours as well
@Deltakosh FYI I will try out the fix in morning if there is a nightly (and if fix was merged) – After that I will be pretty close to being off of 3.1 alpha, especially with the addition of transform nodes and ability to rely on transform nodes instead of blank plane wrappers, I am hopeful that performance will be even better than on 3.1.
BUT, I have 1 more strange underlying core issue.
So I put together a PG to replicate the basic zone structure of my game for easy truer to source playgrounds in the future. Note: I rely on alot of extended babylon methods / helpers in my code base, which rely on lodash methods, so your favorite library is included on this one, but keep in mind it’s so I can paste any methods I rely on directly in to demonstrate the actual behavior without losing anything in translation, or having to rewrite existing code and possibly screwing up in translation again. – Also fixed the prototype extending issue by adding configurable: true, so everytime you hit run it will update the extended methods as well. Point is I promise I’m trying to make it as easy as possible for you - You will need to hit run once however.
This PG has a bunch of animation helper code, you can mostly ignore (with one exception) as it should be obvious what they do due to named params, but the one exception, which may be related to my issue, is the $$absolute_position extended getter/setter near the top.
This is so I can access absolute_position as a property, which makes it work with babylon animations (and so I can control individual vector properties via animation, as you can see in PG) – The way I do basically all my position based animations, is via animating that $$absolute_position property, and it’s worked fine in 3.1, even if the node is parented to another node, it works out the positions correctly.
The issue I am seeing can be reproduced (sometimes takes a few times) by clicking the grey “card on board mesh”,which should then attack the hero mesh across the board. Click it again when it arrives so that it moves back to it’s position, and you can repeat. You’ll note that the mesh SOMETIMES ends up where expected, dead center of the target mesh, but you’ll also note that sometimes it ends up slightly to the left. In my actual game the difference is more noticeable (like it will hit to the side of the mesh entirely). I think probably will be easier noticed the larger the viewport.
https://www.babylonjs-playground.com/#QK5RD1#4
So my question is: Is this a bug? If not, do you know why the behavior changed since 3.1? I know there are more complicated ways of animating the parented mesh’s local position to translate to an absolute position, and that it might be the recommended way, but if that’s the case (and if the local position is the issue to begin with, I’m making an assumption), the simplicity benefits of doing it this way should still be obvious. And the meshes are still ending up CLOSE to where they should be, but most of the animations seem slightly off in 4+.
The reason I think the local position is affecting it, is if you change line #223 to positive 4, you’ll note that it starts hitting to the right instead of the left. Also, I slowed down the animation here, and I’m noticing it sometimes shakes when it’s playing (like it’s fighting another value), so it might be I haven’t noticed the shaking in my game due to the increased speed. – However, the shake/end position isn’t anything near the local position offset either, so I’m not entirely sure it is the actual issue. Any ideas?
Checking right now…
(by the way you do not need lodash in the PG…)