Luaacro

Members
  • Content count

    268
  • Joined

  • Last visited

  • Days Won

    5

Luaacro last won the day on December 5 2016

Luaacro had the most liked content!

2 Followers

About Luaacro

  • Rank
    Advanced Member
  • Birthday

Contact Methods

  • Twitter
    @luaacro

Profile Information

  • Gender
    Male
  • Interests
    3D.

Recent Profile Visitors

849 profile views
  1. Hey very good !! I'm on it ! I'll be the occasion to develop another extension I'll let you know the WIP
  2. Hi @Numa, Happy that you use the gltf loader =D Would be perfect if you can create a playground for it or, to go faster, share your gltf file as I can determine if the problem comes from the loader or not Thanks
  3. Thanks @Dad72 for this feedback ! The commit is available here https://github.com/BabylonJS/Babylon.js/pull/1684
  4. No no ! I meant that the gltf loader uses right handed as default (babylonjs is left by default but the loader configures babylonjs to use right handed) my sentence was badly constructed
  5. @cx20, it has been fixed in the latest pull request MakeYUP is now deprecated since we use the right handed system as default. Now you have nothing special to do it, will work alone
  6. Hi @cx20 The pull request for the default material is available here : https://github.com/BabylonJS/Babylon.js/pull/1666
  7. Hi @NinjaPigeon The pull request is available here : https://github.com/BabylonJS/Babylon.js/pull/1666 You can just set BABYLON.GLTFFileLoader.IncrementalLoading = false; in your code. Then you'll be able to retrieve the bounding infos and all other datas
  8. why not using animation events of @Temechon ? It is directly integrated in bjs
  9. Areyou doing it in the callback of the SceneLoader ? if yes, the loading process is incremental for the gltf loader so meshes are created but not their geometries Do you confirm that you are doing it in the callback ?
  10. I'm on it for the default material ! The animations and smoothing are related to the bug I have with bones animations and I'm also on it i'll let you know tomorrow the WIP
  11. Hi @cx20 The pull request can be found here: https://github.com/BabylonJS/Babylon.js/pull/1650 I got all the samples working. The back faces of meshes are culled, so be sure that your cameras focuses the loaded meshes, as I had to be sure ahahah
  12. Awesome !! Thank you for sharing I'll then be able to test with 1.1 gltf models to update the loader I'll let you know the WIP in this thread PS : I'm also on the bones issues in parallel
  13. good question, do you want to use the positions in js side ? Or want to use in a shader like a post-process ?
  14. Good catch !! I'll fix it asap and let you know btw, the Babylon.js Editor comes with a new version of the actions builder more clear and not concerned by this kind of bugs thanks
  15. Hi @meteoritool ! Here are my answers (not in the order) : 1. Deltakosh replied 3. Yes, the layer masks are a solution. In fact, the standard rendering pipeline is only a set of chained shaders which are post-processes applied on the final render of the cameras attached to. You have to manually exclude and include them from the cameras 2. This is a normal effect if we consider the existing depth renderer system. In fact, the depth renderer (which renders the depth in a texture) only works on opaque meshes and alpha test meshes (not meshes with opacity). Unfortunately, the only solution I see here is to update the depth renderer to be able to compute custom depth functions, and in this example the custom depth function the fire material should define because flames are animated using the pixel shader. This can be a possible evolution to get your set of effects working well 4. I see the delay you're talking about and I don't know why it is happening. @Deltakosh, any idea ? For the water which becomes invisible, it is a known possible bug. In fact, the water material uses the "scene.activeCamera" camera to compute the mirrored camera position (reflection) and set the clip plane. I add this to my todo list and will come back with a possible fix 5. Absolutely not a wanted behavior lol. When I deactivate the depth of field, I get it working well. I have to dig if it comes from post-processes pipelines, cameras, the pipeline itselft or the depth renderer (which is used to compute the depth of field) I come back with more answers soon !