HoloLite

Members
  • Content Count

    221
  • Joined

  • Last visited


Reputation Activity

  1. Like
    HoloLite got a reaction from MackeyK24 in GearVR and Occulus Go   
    I would consider a full VR device as one with 6DOF for both the headset and controllers.The standalone Go/GearVR is only 3dof, but it is still very important vr device imo because of its low price which makes it more available to the public.
    Since you have lots of experience in 3d web, moving to webvr should be easy imo.
    You probably need to learn only a few concepts to get started:
    VR platform specific controllers handlers/callback
    Babylonjs already provides abstractions for this. Afaik, the standard libs are sufficient.
    As each controller has its own unique buttons etc, the handling is a bit different for each controller. GUI for VR.
    Babylonjs also provides the UI layer for VR.
    You want to get used to the input methods via the controller Performance is harder to achieve than browser 3d apps. Depending on the complexities of the scenes, getting 60 fps or higher on webvr can be challenging, especially on low end device like Go.
    As far as build and packaging, it is separate from bjs. It's true this is not covered by bjs docs as this is not considered core bjs stuff. But this gives you flexibility to choose whichever webapp framework you want to use. I personally use the angular with bjs npm packages, it's really easy to debug and package the app. I am sure the same is probably true with others.
  2. Like
    HoloLite got a reaction from MackeyK24 in Using the GearVR controllers   
    I am also still learning this stuff.
    Here are  a few pointers to get you started.
    https://doc.babylonjs.com/how_to/webvr_helper
    Excellent articles by DavRous
    https://www.davrous.com/2017/12/22/babylon-js-vrexperiencehelper-create-fully-interactive-webvr-apps-in-2-lines-of-code/
    https://www.davrous.com/2017/07/07/from-zero-to-hero-creating-webvr-experiences-with-babylon-js-on-all-platforms/
  3. Thanks
    HoloLite got a reaction from Deltakosh in Using the GearVR controllers   
    @MackeyK24 Hey! I thought this was the very idea of webvr itself! No plugin, no install, no store!
    You only need to run the oculus browser that comes with gear vr and oculus go and point to your website where you host your webvr app.
    Check this sample app: https://hololite.github.io/CityExplorer/?speed=10
    It runs at ~30 fps on the Go or Gear. Decent but can be improved imo.
     
  4. Like
    HoloLite got a reaction from Deltakosh in GearVR and Occulus Go   
    I would consider a full VR device as one with 6DOF for both the headset and controllers.The standalone Go/GearVR is only 3dof, but it is still very important vr device imo because of its low price which makes it more available to the public.
    Since you have lots of experience in 3d web, moving to webvr should be easy imo.
    You probably need to learn only a few concepts to get started:
    VR platform specific controllers handlers/callback
    Babylonjs already provides abstractions for this. Afaik, the standard libs are sufficient.
    As each controller has its own unique buttons etc, the handling is a bit different for each controller. GUI for VR.
    Babylonjs also provides the UI layer for VR.
    You want to get used to the input methods via the controller Performance is harder to achieve than browser 3d apps. Depending on the complexities of the scenes, getting 60 fps or higher on webvr can be challenging, especially on low end device like Go.
    As far as build and packaging, it is separate from bjs. It's true this is not covered by bjs docs as this is not considered core bjs stuff. But this gives you flexibility to choose whichever webapp framework you want to use. I personally use the angular with bjs npm packages, it's really easy to debug and package the app. I am sure the same is probably true with others.
  5. Like
    HoloLite got a reaction from Deltakosh in Latest alpha build on npm   
    Oh sorry about that. I do have full trust on both of the bjs heroes
    Thanks! And can't wait... 

  6. Like
    HoloLite reacted to JohnK in Demo with Ammo.js Physics Engine   
    @RaananW you probably are well aware of the following information but in case you are not you may find what I have learned useful.
    Info on using BJS with Ammo
    Threejs demos with Ammo from this github
     
     
  7. Thanks
    HoloLite reacted to Deltakosh in 3.3 Feature list   
    Here we are: https://github.com/BabylonJS/Babylon.js/milestone/9
  8. Like
    HoloLite got a reaction from waverider in Babylon.js vs. Three.js... Choosing a WebGL Framework for Sony   
    So glad to hear this great feedback. I was in similar situations where I had to decide between aframe vs babylonjs.
    It's true there is still a lot of silly anti Microsoft sentiments in the IT world, but yes we have to be smart to see through (the dirty) politics. 😃
  9. Like
    HoloLite reacted to dbawel in Babylon.js vs. Three.js... Choosing a WebGL Framework for Sony   
    Hello,
    I thought to place this on the demos and projects thread, however I decided to post this here as it is more a topic for which framework to use and why. I was hired by an elite software development group at Sony Electronics to help them navigate through WebGL to build a pipeline to deliver content for the South By Southwest convention and to create a foundation to quickly develop games and online media for future projects. In short, I was tasked to escape the limitations of 2D media and help Sony move forward into 3D content taking advantage of the WebGL rendering standards. 
    This was no esay task, as I was hired Dec. 11th, and was given a hard deadline of March 5 to deliver 2 multiplayer games which were to be the focus of Sony's booth at SXSW in Austin Texas. But first I had to run a quick evaluation and convince a very proficient team of Engineers which framework was the best fit for Sony to invest considerable resources into for SXSW and which was the right coice to take them into future projects. Yhis wa a huge consideration as the WebGL framework which was to be chosen was to play a much greater role at Sony Electronics considering the group I was assigned to works well ahead of the rest of the industry... developing what most likely will be native intelligent applications on Sony devices (especially smartphones) in the near future. These are applications which benefit the consumer in making their day to day interactions simple and informative. Thus the WebGL framework to be chosen needed to be an element in displaying information as well as entertainment for a greater core technology which is developing daily in a unique tool set used by the software engineers to build applications which allows Sony to remain the leader not only in hardware technology, but in the applications which consumers want to use on Sony devices.
    But as I was working for Sony, I also had a greater task as there were existing expectations in developing a game on Sony devices which needed to be on par with what consumers already were experiencing with their Playstation consoles. As unrealistic as this might initially appear, that had to be the target as we couldn't take a step back from the quality and playability the consumer was already accustomed to.  So back to the first task... selecting the WebGL framework for Sony Electronics to use moving forward. Rather than telling a story, I'll simply outline why there was little discussion as to which framework to choose. Initially Sony requested someone with Three.js experience as is more than often the case. So when they approached me for the position, I told them I would only consider the position if they were open to other frameworks as well. They were very forthcoming to open their minds to any framework as their goal was not political in any way - as they only cared about which framework was going to provide them with the best set of tools and features to meet their needs. And one might certainly assume that since Sony Playstation is in direct competition with Microsoft Xbox, and Microsoft is now providing the resources in house to develop babylon.js, that Sony Electronics might see a PR conflict in selecting babylon.js as their WebGL development framework. However, I'm proud to say that there was never a question from anyone at Sony. I was very impressed that their only goal was to select the very best tools for the development work, and to look beyond the perceived politics and to develop the very best applications for the consumer and to fulfill their obligations to their shareholders in building tools that consumers want on their smartphones and other electronic devices.
    So once again... Three.js vs. Babylon.js. This was a very short evaluation. What it came down to was that three.js had far more libraries and extensions - however, this was not the strength of three.js since there is no cohesive development cycles with three.js and although many libraries, tools, and extensions exist, more than often they are not maintained. So it was easy to demonstrate that practically any tool or extension we would require for the SXSW production would require myself or the team updating the extension or tool to be compatible with the other tools we might use on the project. This was due to the failings of the framework since each developer who writes an extension for three.js is writing for a specific compatibility for their own project needs... and not for the overall framework... as this is not within the scope of any developer or group of developers. Thus I find that it requires weeks if not months of of maintenance in three.js prior to building content, just to ensure compatibility between all of the tools and extensions needed to use for most projects. As for babylon.js, the wheel is not generally re-invented as it is with three.js, as most extensions are quickly absorbed into a cohesive framework quickly - provided they have universal appeal - and this integration ensures compatibility as there are fewer and fewer extensions to use, but instead an integrated set of tools which are thoroughly tested and used in production revealing any incompatibilities quickly.
    The bottom line is that there are no alpha, beta, and development cycles in three.js, thus no stable releases. Whereas the opposite exists with babylon.js. There is a cohesive development of the tools, and Sony is smart enough to see beyond the politics and to realize that having Microsoft support the development of babylon.js is a huge bonus for an open source framework. And if anyone had to choose a company to support the development of a WebGL or any framework, who better than Microsoft? With practically every other useful WebGL framework in existence spawned by MIT, most all are barely useful at best. And why would anyone pay to use a limited WebGL framework such as PlayCanvas when Babylon.js is far more functional, stable, and free? This baffles me and most anyone who chooses one project using babylon.js. The only argument against babylon.js is that the development of the framework is now supported in house by Microsoft. But for myself and others, this is a positive, not a negative. I've been assured by the creators and lead developers of babylon.js that they have secured an agreement with Microsoft ensuring the framework remain open source and free. This ensures that anyone is able to contribute and review all code in the framework, and that it remains in the public domain. Sony gets this and we quickly moved forward adopting babylon.js as the WebGL framework within at least one division of Sony Electronics.
    At the end of this post I'll provide a link on youtube to a news report of not only the games we built for SXSW, but the exciting new technology on built on Sony phones which uses the phones camera to capture a hight resolution (yet optimized) 3D scan of a person's head. This is only a prototype today, but will be a native app on Sony phones in the future. So our task was not only to develop multiplayer games of 15+ players simultaneous in real-time, but to have a continuous game which adds a new player as people come through the booth and using a Sony phone, has their head scanned. This was an additional challenge, and I must say that I was very fortunate to work with a group of extremely talented software engineers. The team at Sony is the best of the best, I must say.
    All in all, it was an easy choice in choosing babylon.js for the WebGL framework at Sony Electronics in San Diego. Below is a news report from SXSW which shows the new scanning technoogy in use, as well as a brief example of one of the games on the large booth screen. And using Electron (a stand-alone version of Chromium), I was able to render 15 high resolution scanned heads, vehicles for each head, animation on each vehicle, particles on each vehicle, and many more animations, collisions, and effects without any limitations on the game - all running at approx. 40 fps. The highlight of the show was when the officers from Sony Japan came through the booth... which are the real people we work for... gave their thumbs up, as they were very happy with hat we achieved in such a short time. And these were the people who wanted to see graphics and playability comparable to what the Playstation delivered. And they approved. 
    Link:
    Thanks to babylon.js.
    DB
  10. Like
    HoloLite got a reaction from jerome in //Build 2018   
    It was last week... but felt like yesterday.
    It was my pleasure to meet the 2 David's and other members (trevor, sebavan, gary, saurabh, szeyin, et all) in person!
    I am using this pic for the Wikipedia page I am working on.
    From spare-time development 5 years ago to having its own official booth in msbuild 2018.
    What a journey! Congrats again. And... keep up the good work. 😀

  11. Like
    HoloLite got a reaction from waverider in //Build 2018   
    It was last week... but felt like yesterday.
    It was my pleasure to meet the 2 David's and other members (trevor, sebavan, gary, saurabh, szeyin, et all) in person!
    I am using this pic for the Wikipedia page I am working on.
    From spare-time development 5 years ago to having its own official booth in msbuild 2018.
    What a journey! Congrats again. And... keep up the good work. 😀

  12. Like
    HoloLite got a reaction from inteja in //Build 2018   
    It was last week... but felt like yesterday.
    It was my pleasure to meet the 2 David's and other members (trevor, sebavan, gary, saurabh, szeyin, et all) in person!
    I am using this pic for the Wikipedia page I am working on.
    From spare-time development 5 years ago to having its own official booth in msbuild 2018.
    What a journey! Congrats again. And... keep up the good work. 😀

  13. Like
    HoloLite got a reaction from trevordev in //Build 2018   
    I had the fortunate opportunity to meet the babylonjs team at msbuild. Wonderful team! 
  14. Like
    HoloLite got a reaction from davrous in //Build 2018   
    I had the fortunate opportunity to meet the babylonjs team at msbuild. Wonderful team! 
  15. Like
    HoloLite got a reaction from RaananW in //Build 2018   
    I had the fortunate opportunity to meet the babylonjs team at msbuild. Wonderful team! 
  16. Like
    HoloLite got a reaction from Sebavan in //Build 2018   
    I had the fortunate opportunity to meet the babylonjs team at msbuild. Wonderful team! 
  17. Like
    HoloLite reacted to MackeyK24 in Babylon.js v3.2 is out   
    Babylon Toolkit 3.2 is out too
    Note: Some System Are Still Under Construction:
    1... Animation State Machine
    2... Shuriken Particle System
    3... Terrain Builder System
    4... Level Of Detail System
    5... Navigation Mesh System
    All the rest of the toolkit should be working smoothly. 
    Including my sweet Built-In Local Multiplayer Support and Microsoft Xbox Live Development Tool Chain
     
  18. Like
    HoloLite reacted to Deltakosh in Asset compression questions   
    - I guess this should help: https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Khronos/KHR_draco_mesh_compression
     (There is a js lib for that)
    - No compression in bjs format but you can still use gzip 
  19. Like
    HoloLite reacted to Deltakosh in Babylon.js v3.2 is out   
    It's celebration time!
    I'm so thrilled to announce that Babylon.js v3.2 is now out. Once again this could not have being possible without all of you (contributors, testers, bug hunters, doc writers)!
    Thanks folks! We have a wonderful vibrant community. So feel proud, share it, love it, use it
    Here is the release notes: http://doc.babylonjs.com/whats-new
    The blog will it the social network at 10am PST!
    And the announcement video:
     
  20. Like
    HoloLite reacted to Deltakosh in How to use custom mesh for vr controller   
    The best way is to use attachToMesh: http://doc.babylonjs.com/how_to/webvr_camera#attaching-to-a-mesh
     
  21. Like
    HoloLite got a reaction from Deltakosh in Specular lighting is gone after upgrading from beta5 to rc1   
    HEHEHE no wonder you cannot reproduce it. You did it with rc2 and apparently it was fixed in rc2. I just updated my app to rc2 and the issue was gone.
    The issue was indeed present in rc1 though.
    Thanks for looking into this anyway!
  22. Like
    HoloLite got a reaction from Sebavan in Specular lighting is gone after upgrading from beta5 to rc1   
    HEHEHE no wonder you cannot reproduce it. You did it with rc2 and apparently it was fixed in rc2. I just updated my app to rc2 and the issue was gone.
    The issue was indeed present in rc1 though.
    Thanks for looking into this anyway!
  23. Thanks
    HoloLite reacted to trevordev in Reliable way to get webvr device id   
    Babylon can only expose what the browser makes available and to my knowledge the webVR spec does not provide any way to do this, I believe by design(spec). 
    If you are trying to figure out the capabilities of the device currently connected you could use display.capabilities otherwise if you are trying to show a different ui for a device type HoloLites solution seems like the best option at this time.
  24. Like
    HoloLite got a reaction from trevordev in Reliable way to get webvr device id   
    If your app forces the user to use the controller from the beginning then you can call BABYLON.WebVRController.controllerType to get the enum which is defined like the following:
    enum PoseEnabledControllerType { /** * HTC Vive */ VIVE = 0, /** * Oculus Rift */ OCULUS = 1, /** * Windows mixed reality */ WINDOWS = 2, /** * Samsung gear VR */ GEAR_VR = 3, /** * Google Daydream */ DAYDREAM = 4, /** * Generic */ GENERIC = 5, } But again this will work only if your app always uses the controller. 
  25. Thanks
    HoloLite reacted to Deltakosh in Call to scene.freezeActiveMeshes causes vr controllers not to show up   
    This function will freeze the list of active meshes (this is different from freezing mesh worldMatrix). So even if you add more meshes in the scene they will not be displayed
    To make sure you have the controllers in the list, just call the scene.freezeActiveMeshes in the onControllerMeshLoadedObservable observable