• Content count

  • Joined

  • Last visited

  • Days Won


fenomas last won the day on February 25

fenomas had the most liked content!


About fenomas

  • Rank
    Advanced Member

Recent Profile Visitors

904 profile views
  1. I'm just using the packaged scripts from the github repo - in "/dist/preview release/babylon.js" and so forth. Are your changes not in those builds yet, or where should I be looking?
  2. Hey, looks awesome! Is there some magic required to test this locally? I tried updating to the latest BJS preview and running "scene.debugLayer.show()", but I get this sort of error: ReferenceError: __extends is not defined at http://www.babylonjs.com/babylon.inspector.bundle.js:408:10782 at INSPECTOR (http://www.babylonjs.com/babylon.inspector.bundle.js:408:11433) at Object.<anonymous> (http://www.babylonjs.com/babylon.inspector.bundle.js:408:11464) at __webpack_require__ (http://www.babylonjs.com/babylon.inspector.bundle.js:21:30) at Object.<anonymous> (http://www.babylonjs.com/babylon.inspector.bundle.js:49:19) at __webpack_require__ (http://www.babylonjs.com/babylon.inspector.bundle.js:21:30) at http://www.babylonjs.com/babylon.inspector.bundle.js:41:18 at http://www.babylonjs.com/babylon.inspector.bundle.js:44:10 This could be an artifact of my local build process, but with the inspector bundle minimized it's hard to tell what's going on.
  3. Super cool idea! As some folks may know I've been making a voxel engine on top of Babylon for about two years now (project here), and any plugins that work well with it would certainly be welcome! If I can offer some advice/caveats, it would be: try to be really careful with versions and dependencies and coupling between plugins and any engines they know about! The reason I wound up not using the voxel-js ecosystem of libraries is that, although there were a lot of great plugins for it, the plugins were all made at different times, for different versions of the core voxel-js engine, and in general no two plugins seemed to work at the same time unless they were made by the same person. The root cause of this was that voxel-js plugins depended on the core engine, and on one another, as peer dependencies, so nothing got fulfilled (or even tracked) automatically - you had to basically know what every module expected to be where. So while I'd be really happy to see any plugins that know how to interoperate with noa, I'll be even happier if they aren't tightly coupled to it. And of course please open issues for any questions! (Also, @Nesh108 - for questions on any given plugin, be sure and ask in the Questions subforum - that's where most of the action is around here )
  4. You'll need to use your browser's profiling to see what's slow. It could be excessive GCs, or functions getting de-optimized, or it could be a content problem (like meshes not getting disposed, so that the scene builds up a bunch of invisible junk), etc. No way to fix it until you know what's slow!
  5. a.physicsImpostor.physicsBody.material == b.physicsImpostor.physicsBody.material // true For some reason both physics bodies have the same material object. Not sure if that's a bug on BJS's side or not.
  6. Actually, having now typed that all out, it occurs to me that it would be a lot simpler to just create several static, invisible anchors above the ship, and attach the ship's corners to those anchors by spring constraints. In physical terms the results of this would be mostly similar to the demo I linked, but using springs would make it a lot more straightforward to fine-tune the demo - to get more wobble by increasing the spring's stiffness, or less oscillation by increasing their damping, etc.
  7. Hey, I don't have a particular reference for quaternions, but the short version is that a rotation quaternion is an arbitrary unit vector paired with an amount of rotation around that vector. Basically they let you represent any arbitrary rotation as a single thing, rather than as three separate rotations that add up to the desired rotation. (The reason they're useful is that quaternion-based rotations combine and commute with each other the way you expect, which is not true with Euler angles). To skip over all that though, here's a minimal example of the other idea I mentioned - it models the ship as having engines at all four corners, and applies an upwards force at each corner depending on whether it's higher or lower than some target height. http://babylonjs-playground.azurewebsites.net/#1FXV44 It also applies occasional random perturbations to make things wobble, and some damping to make sure things don't just oscillate forever. Note of course that I'm not suggesting you need to model things this way. I just mean to demonstrate that it might be simpler to model a system that's inherently wobbly, rather than take a stable system and figure out how to perturb in just such a way that it appears to wobble.
  8. Hey, really interesting problem! I haven't thought deeply on it, but here's my first blush advice: Before anything else: does the wobble need to be at the physics level? If the wobble is basically to make the ship look the way you want it to, but it doesn't affect gameplay, then it would probably be better to just wobble the mesh without doing anything in the physics. If that doesn't apply, then I think you're taking the right approach - for wobbling you usually want some kind of occasional perturbation, and some constant spring-like force countering the perturbation. It's not clear to me whether your counter force is working right though. For the simplest case you'd want to be applying a constant torque that's equal to the current rotation times some negative constant. I doubt this can be made to work with Euler angles though, it would probably need to be done with quaternions. With that said, it usually helps to keep in mind what kind of physical thing you're modeling - i.e. what's perturbing the ship, and what's making it wobble? One answer could be, it has a gyro that keeps it level but it occasionally gets struck by little asteroids or whatever. If that's the idea, then I think what you're doing makes sense, but make sure your counter-force is doing what it's meant to, and you could try making the perturbations occasional, rather than constant. Or a completely different approach could be, suppose the ship is a square box with rockets at all four corners, and each rocket independently applies an upwards force (torque) on the ship, and the ship wobbles because the engines do an imperfect job of deciding how much force to imply. For example if they decide how much force to apply based on whether their corner is below the ship's center, then there'd be a time lag in their response, which would create a wobble. Either way, for problems like this I think it usually helps to shy away from thinking "well I'll try applying a force here and an impulse there and see what happens", and instead focus on what kind of physical system you want to model, and whether your engine is really modeling that system or not.
  9. I'm just guessing out of context, but my guess would be yes I mean, in the narrow sense: it only makes sense to recursively walk through a data structure if that data is a tree of some kind. If I understand you right, you have one set of objects where that's the case, which are being managed together with some BJS objects? However since BJS objects don't live in any kind of tree structure, probably they need to be managed separately from other stuff that is. But more generally, a given object's dispose function should internally dispose any other assets that that object is responsible for, right? I think (but haven't confirmed in any detail) that most Babylon objects behave this way - so calling mesh.dispose() should already dispose any assets that can be safely disposed with that mesh. So that's what I meant about recursively walking through a data structure disposing everything sounding like an iffy thing to do. Not meaning this as criticism of course - naturally you could have good reasons for doing it that I don't know about.
  10. I don't think there's a robust way to do this. You can check for specific cases, like: myMesh instanceof BABYLON.Node ..because meshes all inherit from Node, but there's no single root that every BJS class inherits from. Alternately, you could check for property names like foo._scene or foo.__serializableMembers because many Babylon objects have them, but there are many others that don't. If those aren't enough, this seems like a bad code smell - there's probably a better solution than introspection.
  11. As a second data point, I'm working on a big project with lots of dynamic meshes getting created and disposed, and I've profiled for memory leaks and not found any so far.
  12. That chrome profile is showing that the CPU is almost entirely idle. I wouldn't worry too much about the mac book heating up - in my experience they heat up pretty much any time the GPU is running, even for trivial amounts of work. Just how they're made, I think - partly caused by the fact that Apple doesn't like fan noises, so the fans stay off until the machine gets really hot.
  13. @wo997 Well, I didn't mean it would necessarily need to derive from your scene. In fact I think it would be better not to, as a minimal reproduction is ideal. I mean, if you started with a minimal scene, like this: http://babylonjs-playground.azurewebsites.net/#24QL2E#0 what is the minimum that needs to be done to show the behavior? From your scene, I can't really guess if the bug is with how joints work, or how the motors work, or how the friction force gets transmitted through constraints, or what.
  14. Can you please post an example of this happening for just a cube sliding on the ground? It sounds to me like some kind of nasty anisotropic bug inside Cannon.
  15. It's not as simple as just whether the code is eval'ed or not. Basically, all the code samples in this thread probably should get fully optimized, and the ones that don't can probably be considered bugs for the JS engine. But realistically, compiler bugs like that are going to happen more often when everything is being dynamically created and eval'ed and whatnot.