• Content count

  • Joined

  • Last visited

  • Days Won


FunFetched last won the day on September 2

FunFetched had the most liked content!

About FunFetched

  • Rank

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
  • Location
    Seattle, WA
  1. Shell Shockers My first BabylonJS project is a whacky multiplayer first person shooter featuring, well, eggs, of course! It's in very early development and still fairly rough around the edges, but it's super easy to jump in quickly and play. It's just been made public, so finding people to shoot may be a little hit and miss (pun intended). Enjoy! Facebook: Twitter:
  2. ES6 everywhere yet or close enough?

    I think is pretty good for a birds-eye view. I've been tempted to go with ES6 myself, but IE11 has basically no support, and according to MS, it never will. Edge has excellent support, however. It's only taken Microsoft two decades to get off their high-horse and finally put some effort into supporting standards that they don't own. Give it a couple more years, though by that time, MS will probably be dragging their heels on ES7.
  3. Export animation blender

    You'll need to "bake" the animation before exporting. First thing; save your project, as the following steps will make changes that may not be easy to reverse. Then, select the animated object, make sure you have the action that you're working with active, hit SPACE, then type "Bake Actions". The option will appear as you're typing it. After you select it, you'll see the following menu: Make a note of the checkboxes that I have selected. This will create location, rotation, and scale keyframes at every frame of the animation between "Start Frame" and "End Frame", with the animated object in its proper orientation with all constraints applied. It's not the sexiest solution, but for right now, it's the only one that works.
  4. Hi there! I've been busy working on a modification to the Blender exporter and Babylon in an effort to support smooth interpolation natively, based on FCurve handles, as opposed to having to bake every frame of every animation prior to export, which can be rather time and space-consuming. So far, I have a system which works fairly well, feeding the "right handle" offset of each keyframe to Babylon which then packs that information into the inTangent and outTangent properties of each imported keyframe. This has smoothed out my animations considerably, but it's not a 1:1 reproduction, and I feel like I could do more. inTangent and outTangent data is currently fed to Babylon's Hermite interpolation equation, which is certainly better than the Linear default, but still not as sweet as it would be if it used Bezier just as Blender does. Unfortunately, my Bezier kung-fu is weak, and making the translation from X/Y handle coordinates to Bezier coordinates for each axis is confusing me. So, in summary, I'm now able to import the key and handle coordinates for each frame in Blender animations. I'm just having some trouble figuring out how to translate those into a contiguous Bezier curve at the time of animation. I'm familiar with the vector3InterpolateFunctionWithTangents() function, but inTangent and outTangent data doesn't seem to be enough for a full Bezier calculation. I could add more easily enough; I'm just a little fuzzy on how to go about it, and my experiments so far have resulted in some pretty crazy animations. Any thoughts? I would love to be able to wrap this up into a nice and tidy pull request.
  5. Orthographic camera fog (bug?)

    It is indeed! Wasn't sure what was going on with my UI camera until I realized that it was fading to my fog color. Easy enough to get around with fogEnabled/applyFog flags, but I thought it was worth a mention.
  6. BabylonJS 3.0 introduces an "issue" where fog is applied with a falloff aligned with the screen plane when using an orthographic camera. This wasn't the case in 2.5. In the playground example below, what was a completely black square in 2.5 displays a red gradient starting from the center in 3.0. Was this intentional?
  7. Fixed it here, and posted a pull request.
  8. Oof. This is also affecting animations that are played backwards. On line 656 in babylon.animation.ts we have this line: if (currentFrame >= this._events[index].frame) { Obviously, currentFrame is floating point, so we can't just do a simple == in this situation. Unfortunately, since it's looping through all of the events from start to finish every time, all previous events in the timeline get triggered right off the bat, even if we started the animation at a later point. In the case of backwards animations, the problem is exacerbated for the same reason. If we only supported forward animation, the solution would be a simple matter of changing the line above to: if (currentFrame >= this._events[index].frame && this._events[index].frame >= from) { ... but I guess it's not that simple any more. I'll keep digging.
  9. Found an issue with Animation/AnimationEvent where an event set for an earlier frame is immediately triggered when playing the animation starting at a later frame. Here's a playground example of the problem (you'll need to open your JS console): Edit: Taking a look at the code, I can already see the problem. I'll see if I can't whip this one myself.
  10. Found it! It is indeed in the exporter, and I've managed to fix it on my end. I've submitted a bug to github (#2416), but figured I'd post it here for @JCPalmer as well. line 104: append_range() introduces an issue where the scene's current frame is changed as the range is iterated through, but not restored upon completion. This leads to all animated objects being exported in their final positions/orientations, regardless of the current frame in the Timeline. I managed to resolve the issue on my end in I added currentFrame = bpy.context.scene.frame_current before the for action in loop on line 37, restoring the scene's current frame immediately after this loop with bpy.context.scene.frame_set(currentFrame).
  11. Alright; fooling around with the final frame, I've discovered that the problem is actually in the exporter. Regardless of what frame I'm on in the Timeline at the time of export, the position and orientation of the meshes are always exported in their final states. I'll take a look at that and see if I can make any sense of it.
  12. One of the first things I tried was to make sure I was exporting the file while everything was sitting at frame 0. It doesn't seem to matter. I'll see what I can do as to providing some files. I can't see anything in my .babylon file referring to anything resembling a starting frame, either. Weird. The only thing I can figure is that there might be a "current frame" counter in Babylon that gets incremented during the parsing of .babylon files, but never gets reset to 0 when its done. I'll do some more digging.
  13. I have a Blender file with some meshes with Actions assigned to them. I'm exporting it using version 5.3.-1 of the Babylon.JS exporter and loading the resulting .babylon file with Scene.ImportMesh. There are no bones in this scene; all animations are applied directly to meshes. I can trigger my animations without issue; everything behaves as expected (more or less). However, after loading the file, the orientation and positions of all of my animated meshes begin at the final frame of their Actions, as opposed to frame 0, as I would expect. My first thought was that the animations were playing automatically upon loading. I scoured the forums here and discovered the autoAnimate flag. I opened my .babylon file, but no such flag was present. I re-exported and checked autoAnimate intentionally, opened the .babylon file again, and explicitly set each autoAnimate flag to false. No effect. Next, I set breakpoints at all relevant beginAnimation functions in my babylon.js, but none were triggered. As far as I can tell, none of these animations are being automatically played, yet the problem persists. Any thoughts? I can work around this issue by making sure that the keyframes at the first and final frames of my Actions are exactly the same (and simply not play that final frame), but it seems there might be a bug in play here.
  14. In my case, it's a first-person camera, but one that is attached to the "eye" mesh by means of parenting. Here are snippets from a couple of different files so you can see what's going on: // Setting up the player's 'actor' mesh this.mesh = new BABYLON.AbstractMesh('player', scene); this.bodyMesh = Meshes.body.clone('body', this.mesh); this.bodyMesh.position.y = 0.32; this.bodyMesh.parent = this.mesh; // Head pivots with mouse look. this.head = new BABYLON.AbstractMesh('head', scene); this.head.parent = this.mesh; this.head.position.y = 0.3; // Separate, empty 'eye' mesh for attaching camera. // This is for controlling recoil and other 'shake' animations this.eye = new BABYLON.AbstractMesh('eye', scene); this.eye.position.y = 0.1; this.eye.parent = this.head; ... // Attaching camera to the player's 'eye' =; As you can see, there's some hierarchy here that puts a few layers between the camera itself and the world coordinate system. Since the camera's local coordinates never stray from 0, 0, 0, the audio listener's position never moves. FreeCamera was a little too "special purpose" for my needs, as I wanted to roll my own control scheme. I also didn't want the camera to control the player mesh; I wanted the player mesh to control the camera. I tried a few of the other built-in cameras, TargetCamera, ArcRotateCamera, etc., and attempted to make them follow my eye mesh, but couldn't get them to track smoothly and reliably. They all seem to be hard-wired to follow just behind their target with some interpolation, while I wanted the camera to be locked firmly to my mesh. Fiddling with the parameters to eliminate the interpolation just caused them to go haywire, so I decided to eliminate all the bother and set the camera's parent to my 'eye' mesh and be done with it. Ideally, I guess I'd propose another type of camera altogether; say, a "FixedCamera", or "MeshCamera". No fancy controllers or interpolators, just a means of locking its global position and orientation to a mesh (or AbstractMesh in this case). I might take a stab it myself at some point, but my work-around is doing fine for now, and I don't have quite enough time at the moment to dig in there and figure that out.
  15. Hi there! I'm relatively new to Babylon.js, but loving it so far! I'm currently developing a simple FPS, and had some issues getting the positional audio to work at first. I found FreeCamera's control scheme to be inadequate for my purposes, and decided to instead assign a parent mesh (representing the player's "head") to my camera, so it would follow along perfectly. However, the positional audio didn't work with this configuration, as I discovered that the engine uses the camera's local coordinates (always 0, 0, 0 in this case) to determine the listener's position. I changed the following line (#18730) to use the camera's globalPosition instead, and all is well. audioEngine.audioContext.listener.setPosition(listeningCamera.globalPosition.x, listeningCamera.globalPosition.y, listeningCamera.globalPosition.z); I would imagine that this could break some other projects, but it seems to me that there should be some kind of option to enable this behavior. Perhaps a check to see if the camera has a parent? Maybe a simple bool flag?