• Content Count

  • Joined

  • Last visited

  • Days Won


FunFetched last won the day on September 2 2017

FunFetched had the most liked content!

About FunFetched

  • Rank
    Advanced Member

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
  • Location
    Seattle, WA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Update: I'm using the full-on Babylon Null Engine on the server-side now to handle collision detection. The maps are divided into 3D grids, and every occupied cell contains a reference to an arrangement of one or more AABB or OBB bounding boxes for quick collision calculations, all loaded from a .babylon file exported from Blender. The game supports all sorts of map elements of all shapes now. Also, kudos to everyone who worked on Babylon v3.3. I'm making the transition now, and I'm seeing huge improvements in some key areas. A number of animation problems have disappeared. SPS mesh building is orders of magnitude faster than it was, which is great, because that's how I build the maps at run time. A number of other smaller items that I had clumsily patched up myself no longer need to be. Good stuff!
  2. I just updated my app the other day, and started getting reports of some users' Chrome browsers refusing to download and update .babylon files in their IndexedDB. Other browsers seem to have no problem at all, but Chrome, as I've learned, can be especially stubborn when it comes to caching. Before you ask, yes, I updated the version number in the associated .manifest files to no avail. After investigating the XHR requests in Chrome, I noticed that the .manifest file checks use a date-based query string for cache-busting, which works great. However, the .babylon file requests themselves were not. I changed the following... Database.prototype._saveFileIntoDBAsync = function (url, callback, progressCallback, useArrayBuffer) { ..."GET", url + '?' +, true); ... and now all is well. Apparently, Chrome (and only Chrome) was loading a cached file to put in the IndexedDB; putting a cached file into another cache, essentially. Nuts.
  3. Will do, but I doubt I'll be able to get to it before the merge. I'm going to continue to stubbornly stand by my opinion that this should be the default behavior, though :). I could be swayed if someone were to lay out a scenario where this would break something, but I can't for the life of me think of one myself. I have, however, witnessed first hand how the current behavior does.
  4. While it may not be technically consistent with a version system, I would argue that it's actually vital to a versioning system. All versioning systems allow the ability to roll back changes, which in this case breaks the operation of the engine if those rollbacks include important changes to scene files. It would be like Unity insisting that it load the absolute latest version of all assets, regardless of which version/branch/fork of the game you happen to be working on. Also, I have thousands of users who sometimes test new versions of the game, only to return to the old one while I make changes. They need a way for their browsers to seamlessly retrieve the appropriate assets for both, regardless of which way they're moving through the versioning chain. It would be essentially impossible for me to explain to all of them that they need to open up their developer console, search for the babylonjs IndexedDB and delete it when they're done testing.
  5. I'm currently working on a project that has both a live and development version, utilizing offline storage and .manifest files for all of my Scene objects. Everything works as expected until I run the old project after having just run the new one in Chrome, specifically. The latest versions of the .scene files are always loaded from the cache, despite the older version number in their .manifest files. I did some digging, and found this: Database.prototype._loadVersionFromDBAsync = function (url, callback, updateInDBCallback) { ... transaction.oncomplete = function (event) { if (version) { // If the version in the JSON file is > than the version in DB if (_this.manifestVersionFound > { _this.mustUpdateRessources = true; Notice that the version number comparison operator is >, not !=. Shouldn't the comparison be != to cover any changes to the .manifest file version, regardless of its age? I've changed this on my end, and all is well now.
  6. This function disappeared in 3.1. Was this intentional? Edit: You know... I may have actually added that myself in 3.0., and forgotten all about it. However, there's a SceneOptimizer.stop() (lowercase 's') that's referenced in the documentation, but I don't see it anywhere in the code.
  7. Oh, great; I'll do that! Edit: Works perfectly!
  8. Holy moly. I had been having problems with this as well. I un-parented everything, cleared all transformations, confirmed that everything was indeed 0 and W was 1. Re-parented, re-weighted, tried the abs() solution and STILL got this error. Finally, I logged the actual rotation data stored in the mesh in question. Simply logging self.rotation showed nothing of note: 0, 0, 0. THEN I decided to get specific and log each component (x, y, z) by themselves. Here's what I got when I hit Y: 3.552713678800501e-15 That's right; 0.0000000000000035527blahblahblah. Ridiculous! So, Blender has a rounding problem when it comes to clearing transformations, and clearing them is no guarantee of anything, apparently. SO, in addition to the abs() solution that JCPalmer proposed, I added round(n, 3) to each one of them, and it finally worked. I'll issue a pull request when I get a chance. Edit: Actually, I don't think abs() is entirely necessary. Every Python version I have access to throws True when I compare -0 to 0. Maybe it's best to be on the safe side?
  9. No problem! You'll notice that every time you trigger the spin animation, it always ends facing inward, so it is actually following the direction of travel, in a manner of speaking. It just needs to be turned 90 degrees.
  10. Check out This mostly implements what I'm talking about in regard to the AbstractMesh. It's mostly working at this point. The spin animation is off by 90 degrees, but you'll see that it now behaves in a consistent manner when you click on it. Note that I reset the position of the helicopter mesh itself to 0, so that it would be positioned in the middle of the container.
  11. Ah! The Playground does help. Check out . The issue with the glitch in the middle is that you were using Euler rotation instead of Quaternion. Euler sometimes doesn't handle full rotations very gracefully, flipping around madly when the sign of the angle flips; that is, jumping from PI/2 to -PI/2 from one frame to the next as it passes the half way point. Quaternion, on the other hand.... well.... it just does handle that situation, but I couldn't possibly explain why. As for the spin, you're blending two animations together that share the same mesh. So, say we're at the halfway point again, and you're facing 180 degrees the opposite direction. You want the spin to end at 180 degrees, but the spin animation wants to start and end at 0. These are two separate animations, and the spin animation doesn't inherit anything from the orbit animation. What you'll want to do here is actually create an empty AbstractMesh to contain the helicopter. Apply the orbit animation to this AbstractMesh, and apply the spin animation to the helicopter mesh directly. That way, your spin animation will affect the local coordinates and orientation of the helicopter mesh only, while the global position and orientation will be controlled by the orbiting animation that controls its parent.