Benji Posted October 14, 2016 Share Posted October 14, 2016 Hi I am very new to Babylon.js and to coding in general... i've been looking at the tutorials on pixelcodr.com and played around a little with that. Now there is this tutorial "play with physics". Works fine. But when I replace the Oimo.js and Babylon.js that comes shipped with the tutorial with the most recent, I get this error message: TypeError: undefined is not an object (evaluating 'this.body.body.linearVelocity‘) Any ideas how to get that fixed? Thank you! Quote Link to comment Share on other sites More sharing options...
dbawel Posted October 14, 2016 Share Posted October 14, 2016 @Benji - I just spent most of last week discovering that there are many broken functions in using Oimo.js with the babylon.js physics - and all is well now that I switched back to cannon.js. Most all of my code is fully compatible, so there is little further work for you to change to cannon.js. So I hate to say, but there is no current way to use oimo.js with babylon.js v2.5 (unknown with ealier versions), as I exhausted evry possible method of integration. And as there are issues with restitution, scene.physics.newBabylonVector(), and other key foundational attributes, there is no way to currently use this in your project. I spent considerable time looking at oimo and BJS for what might be causing the problems, but after much time, I simply am not the right person to solve what appears to be more than one serious bug - but many incompatabilities currently. I want to file a bug report, but haven't had time yet due to a tight schedule on my current project which I lost most of a week trying to integrate oimo.js. It only took a couple hours to switch my entire scene to cannon.js - so I recommend you take this direction before spending another second trying to integrate oimo.js - unfortunately. If you need more specifics, I can try and provide these, but it's also been onfirmed by many in the BJS community now. But you'll be just fine with switching to cannon.js as suddenly everything will work as expected previously using oimo. Cheers, DB Quote Link to comment Share on other sites More sharing options...
Benji Posted October 14, 2016 Author Share Posted October 14, 2016 Thanks a lot, DB for taking the time to explain that. For me, cannon.js will be just fine I gess. I haven't written much code that I'd have to rewrite now - unlike you... I actually only went for Oimo because people seemed to like it for its performance - and I have a little project in mind that involves several k colliding objects... Benji Quote Link to comment Share on other sites More sharing options...
dbawel Posted October 14, 2016 Share Posted October 14, 2016 @Benji - The good news is that you won't need to change much code - if any - other than to assign the cannon.js plugin in place of oimo.js. Otherwise, the callbacks are the same in babylon.js for both cannon and oimo; as well as setting up impostrs and vectors - so there maybe little else to change other than the syntax to declare imposter positions - and you also have additional forces you may want to use in cannon which are not available in oimo - so it may be a better choice for you project from the start. It certainly is for my current project. If you have any further questions or require additional help, don't hesitate to ask - and as we always do - Welcome to the babylon.js forum! Cheers, DB Benji 1 Quote Link to comment Share on other sites More sharing options...
adam Posted October 14, 2016 Share Posted October 14, 2016 If "this" is referring to a mesh, then try: this.physicsImpostor.physicsBody.linearVelocity Quote Link to comment Share on other sites More sharing options...
Benji Posted October 15, 2016 Author Share Posted October 15, 2016 @dbawel I did change to cannon.js now. There also was a typo problem in my code regarding Impostor vs. Imposter. The code is running fine now: http://www.babylonjs-playground.com/#1BKBBK#19 but the speed??! Dunno if its due to my old Macbook (2009), but frame rate goes down to 10 per sec. with 150 colliding objects. Is that normal?? Is there a way to improve that? I'd happily trade in some accuracy for speed, if there is a way. Somewhere I read about instances - could that maybe help? (The objects falling are all the same) Thanks again! Seems to be a great community here! Quote Link to comment Share on other sites More sharing options...
dbawel Posted October 16, 2016 Share Posted October 16, 2016 @Benji - First - you'll find that your fps should impove by at least 20% once you move your scene from the PG to your server due to the additional overhead in the Playground. Otherwise, it's simply your hardware as I'm on a Windows 10 laptop almost 3 years old which never drops below 40fps running your last PG scene. Also, it's not slowing your framerate, but I'm not a fan of declaring variables for functions within the WebGL framework such as you're declaring with your variable "V3". In y opinion, this can get messy and over complicate scenes - especially once you begin adding complexity. I would avoid this yet comtinue to declare literals when possible for both complexity as well as memory overhead you simply don't need. But again, that's an opinion, and if you see topics on vatiable declarations online, they are usually shut down by administrators quickly as they generally lead to arguments between site users. So to any other users on this forum please take this as simply my own opinion - except for my recommendation to use literal declations for variable when possible to avoid the high potential to loose track of variable decllarations in your scripts. Also, I highly recommend setting vectors for your physics engine (especially cannon.js) as I've personally experienced better compatability with both older and newer vrsions of WebGL and the babylon.js and other frameworks. This will also provide you with additional control over the physics in your scene. Check out the PG scene below: http://www.babylonjs-playground.com/#1BKBBK#20 Otherwise, I tried every "trick" I know to improve your framerate and maintain similar behavior for your meshes, and could only improve your framerate by perhaps 1 or 2 fps - but not consistantly throughout the simulation - so for me any other changes I made we're irrelevant. The only "tip" I might provide would be to play around with scene.getPhysicsEngine().setTimeStep() as this function comes in really handy for me quite often. Good luck, and in my useless opinion you're doing great for only 3 posts. And no kidding... I'm certain you'll be answering questions posted from me soon. Cheers, DB Quote Link to comment Share on other sites More sharing options...
Wingnut Posted October 16, 2016 Share Posted October 16, 2016 http://www.babylonjs-playground.com/#1BKBBK#21 Spheres sure go faster, huh? hmm. Even cylinders using sphere imposters... is lots faster. Cylinders using box imposters = SOME speed increase, but... spheres... phew. LOTS faster. Not sure why. Possibly because of less "laying atop each other". hmm. Boxes? Ok. http://www.babylonjs-playground.com/#1BKBBK#22 Slow again, and it is a Brownian-jitter z-fighting festival. Makes me want to iterate thru all the imposters and see how many .isSleeping. We have seen some issues with imposters sinking into the ground... in other playgrounds. I think these box imposters have done that. It is not normal to see z-fighting on the bottom of a .isSleeping imposter. Benji 1 Quote Link to comment Share on other sites More sharing options...
Benji Posted October 16, 2016 Author Share Posted October 16, 2016 @Wingnut @dbawel thanks for optimizing the code and checking out different imposters. I'm on mobile right now but will play around later on. I encountered boxes sinking into or falling through the ground in earlier versions of the code. Actually I haven't yet figured out why that is now ok. Anyway, my vision of seeing several k objects falling and colliding while keeping a decent frame rate is somewhat weakened right now. Is there a totally different approach maybe with massively reduced accuracy? I didn't have the time to try out setTimeStep() yet though... Quote Link to comment Share on other sites More sharing options...
Benji Posted October 16, 2016 Author Share Posted October 16, 2016 Checking back with Oimo: http://www.babylonjs-playground.com/#MCCDC#4 Phww, its fast!! The Vector3s apparently have to be divided by 10 to get proper results (like -0.98 instead of -9.8 for gravity; rotation likewise). As soon as velocity goes up, those sticks start to smash through my impenetrable ground. I played al little with the values, but couldn't get it to work properly. It works better with box imposters, but results in some strange looking stick-moves... Quote Link to comment Share on other sites More sharing options...
adam Posted October 16, 2016 Share Posted October 16, 2016 Yes, the default gravity for OIMO in BJS is set too high. Quote Link to comment Share on other sites More sharing options...
Benji Posted October 16, 2016 Author Share Posted October 16, 2016 16 hours ago, dbawel said: First - you'll find that your fps should impove by at least 20% once you move your scene from the PG to your server due to the additional overhead in the Playground. strange - its massively slower on my local MAMP server than running it from within the playground?!! Quote Link to comment Share on other sites More sharing options...
dbawel Posted October 16, 2016 Share Posted October 16, 2016 @Benji - I assume it's an issue using your local MAMP server. If you host remorely on an optimized Apache or node.js server, you should find an increase - as you loose all of the additional unused overhead associated with the Playground. At least this has been the case with every scene I've moved from the Playground to either my Apache or Node server which are both hosted remotely. @Wingnut - I always clear my cache as a first step - especially using Chrome as it is a cache and memory monster. So I'm still trying to figure out why I cannot load any of the scenes associated with the subject on this post, but will keep working at it. Also, You found something that I have seen for a long time - that sphere imposters often perform better than any other - with the exception of box imposters. However the increse in fps using box imposters vs. sphere imposters is minimal, so I use sphere imposters more than often. If you find that box imposters are slower than spere imposters at any time, it is only scene dependant based upon the setting driving the simulation; as I find a slight improvement in fps using box imposters over 90% of the time. But again, it's such little improvement generally, that I generally use sphere imposters by default. But it all depends on the target performance, and sphere imposters don't often provide the required result for animation of the object which the imposter is driving. @adam - Oimo does function, however it has such little control currently available as so many of the settings don't currently respond in any contrlable way except is very specific hysics simulations where detailed control is not necessary. So I highly advise everyone to avoid Oimo for now, until it is working and controlable as expected. DB Quote Link to comment Share on other sites More sharing options...
fenomas Posted October 17, 2016 Share Posted October 17, 2016 Looks like it's time again for me to post my three rules of performance optimization: Profile Profile! Profile! Remember folks, your browser includes super-advanced tools that tell you exactly which part of your code is slow. (Unless you use Safari or something ). Trying to optimize a scene without profiling it is like sorting your laundry in the dark. Don't do it. In this case, profiling the cannon example shows that it spends tons of time in narrowphase collision testing, in a function that mentions "convex polyhedrons". So it appears that the physics impostors are not being handled as cylinder primitives, but as arbitrary meshes, which are extremely slow. From peeking inside Cannon it looks like it doesn't have a collision type for cylinders, so there's probably no easy fix for this. As for Oimo, profiling there shows that time is spread out more evenly, and there isn't any huge spike in narrowphase collision tests. Also there are references to "cylindercylinder" collision testing, suggesting that here the cylinders are being handled as primitives. Takeaway: as things stand, Oimo will run this scene much faster than Cannon. If you want to use Cannon and you need more performance, I think your options are (1) don't use cylinders, (2) use fewer cylinders, or (3) fork Cannon and add Cylinder collisions, . PS: Your server being MAMP/Apache/Node is not affecting your front-end code performance. If you want to know what is, profile! jerome, Benji and Wingnut 3 Quote Link to comment Share on other sites More sharing options...
Benji Posted October 17, 2016 Author Share Posted October 17, 2016 @fenomas Thanks! That is a great hint! Looks like I have to switch to a different browser then (Safari now... ). Strange that Cannon has Cylinder-Imposters defined by name but not implemented a function to tread them as primitives. So since I'd like to stick to Cylinders and rather want to increase their numbers, there are two options for me right now: stay with Oimo or fork Cannon to add Cylinder collision. Even though @dbawel spend some kind and encouraging words in the beginning, I don't see that second option at present - wouldn't even know where to start... So, if I stick to Oimo: Somehow I have to get my ground impenetrable. Any ideas on that? I tried a box instead of a plane but it didn't make a big difference. Maybe scaling everything up by factor 10 or 100 helps? I'll give it a try... Next step will be including air friction. I'll see what you guys have already found out and written about. But in case someone can already tell that it will be (nearly) impossible with Oimo, I'm happy for advise...! Benji Quote Link to comment Share on other sites More sharing options...
fenomas Posted October 17, 2016 Share Posted October 17, 2016 @Benji Glad to help! Adding cylinders to Cannon would basically be a bunch of math. I know where you'd need to add it, if you want to try, but I wouldn't fancy it for a bit of light entertainment. For impenetrable ground, for a start I'd use a Box with some nonzero thickness: http://www.babylonjs-playground.com/#MCCDC#5 (Even then, cylinders will still penetrate if they go fast enough. There are settings to tune if you need to but for normal sized objects and normal speeds it probably won't be an issue.) For air friction, there have been threads about it here before, which should be searchable. My recollection is that neither engine has a built-in property for it, but the easiest thing to do is loop through your objects once per frame and multiply their velocities by 0.99 or so. As for Safari - well, it has a profiler of some kind, but whenever I've tried it, the browser either crashed or slowed down so much that measuring performance was meaningless. Chrome's profiler is the best around right now. Edge is good too - as good as Chrome's for general web development, but not as good as Chrome's for pure JS. Quote Link to comment Share on other sites More sharing options...
dbawel Posted October 17, 2016 Share Posted October 17, 2016 I'm happy to hear that @fenomas is having luck with Oimo, however, it only works for simple simulations currently and is not controllable - as restitution is entirely broken. So I highly advise against Oimo. Please read the post below: Otherwise, if it does what you need it to do, then I would still worry about future compatability and behaviors - as well as adding any other physics to your scene in the future - at least until Oimo is fixed. Cheers, DB Quote Link to comment Share on other sites More sharing options...
adam Posted October 17, 2016 Share Posted October 17, 2016 @dbawel restitution seems to be working in this demo: http://www.babylonjs-playground.com/#2JY0P0#24 I've been trying to figure out what's going on with that demo of yours where it is broken. No luck yet. Edit: Sorry, that demo is using Cannon. Quote Link to comment Share on other sites More sharing options...
fenomas Posted October 18, 2016 Share Posted October 18, 2016 @dbawel Just because a bug affected your project doesn't mean Oimo "only works for simple simulations". It's a powerful, fully-featured engine, and for Benji's content it appears to be technically superior to Cannon (by virtue of having the needed primitives). With that said, I also don't know why restitution isn't working with it. It seems to work in Oimo's non-Babylon demos, so the bug may well be on the BJS side - or maybe somebody just needs to update a dependency somewhere. adam 1 Quote Link to comment Share on other sites More sharing options...
adam Posted October 18, 2016 Share Posted October 18, 2016 The default world scale of 100 in oimojs seems to be the problem. I set it back to 1 in the plugin's constructor here: http://www.babylonjs-playground.com/#2JY0P0#28 Benji 1 Quote Link to comment Share on other sites More sharing options...
Benji Posted October 18, 2016 Author Share Posted October 18, 2016 @@adam Awesome! Great that you found the culprit. I'm curious to see how much of Oimo's sometimes erratic behaviors that will cure. Quote Link to comment Share on other sites More sharing options...
dbawel Posted October 18, 2016 Share Posted October 18, 2016 @fenomas - As I mentioned in a previous post, I am grateful to have Oimo and would prefer to use it over cannon. If @adam has truly fixed the restitution and other issues due to a default setting that has somehow changed because of new versioning of WebGL and/or BJS, then I'll be using Oimo again. But I feel justified in warning others not to spend several days as I did trying to solve what @adam hopefully figured out - as without a fix, it truly is not currently usable other than with simple physics simulations - and this has been proven in several scenes on the playground as well as my time trying every possible simulation to discover that most all control is currently lost in Oimo - and just recently. I simply don't want anyone else to discover this by losing time on a production. Please don't take it personally. DB fenomas 1 Quote Link to comment Share on other sites More sharing options...
Benji Posted October 23, 2016 Author Share Posted October 23, 2016 On 18.10.2016 at 1:57 PM, adam said: The default world scale of 100 in oimojs seems to be the problem. I set it back to 1 in the plugin's constructor here: http://www.babylonjs-playground.com/#2JY0P0#28 Hi Adam I'm really a newbie here and not sure whether I got things straight. My understanding is, that the preview version of babylon.js on Github is the one that incorporates all the recent changes (also your plugin correction?) and that the online resource at babylonjs.com/babylon.js is that same version...? I tried a new scene: http://www.babylonjs-playground.com/#1XCJRB#1 which doesn't look too good. The gravity seems to be to little now (98.1 seems ok) and the stick somehow prefers to stick around... I don't know whether my code is corrupted, or the changes to the plugin haven't been made yet, or whether a new problem has surfaced??! Any help is much appreciated! Quote Link to comment Share on other sites More sharing options...
adam Posted October 23, 2016 Share Posted October 23, 2016 This looks like an OIMO issue. I just looked at the code for BoxCylinderCollision in Oimo and it could use some work. I might take a stab at my own BoxCylinderCollider in the next few weeks. I'll let you know if I have any success. Quote Link to comment Share on other sites More sharing options...
Benji Posted October 23, 2016 Author Share Posted October 23, 2016 @adam thank you. Do you happen to know anything about energy.js? I saw it beeing announced and I wonder whether it will be published anytime soon. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.