• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by satguru

  1. @Topper try this
  2. @psikoT Found a way by which you can make your model work without changing its orientation. Create an empty mesh, make it a parent of your model and pass that, instead of your model, to the character controller. Use character controller setAvatarSkeleton() method to set the skeleton to your model's skeleton Attached is an updated version of your index.html which works. index.html
  3. Hi @psikoT Thanks for providing the character. Found what the issue is. Your model has Z up and Y forward. Babylon (and the Character Controller) expects Y up and Z forward. Here is a screenshot of your character in babylon sandbox. If you can change that then it will work fine. Nice character and animations by the way
  4. @psikoT I am curious what the problem might be. Do you mind sharing your character Babylon file?
  5. @bghgary I see that this is fixed now. Thanks
  6. glad this is getting fixed. had me confused too sometime back
  7. @MackeyK24 Maybe you can use BABYLON.DynamicTerrain.CreateMapFromHeightMap function to get a data map from the ht map and then create sub meshes from the data map? @jerome might have some idea on how to do that.
  8. @Deltakosh Me too it seems that based on just the matrix the only conclusion one can definitely arrive at is i) one scale is -negative or all scales are negative or ii) one scale is positive or all scales are positive but not which scale exactly. This would be based on taking cross product of two vectors and then dot product with the third vector So if (Vector3.Cross(ux,uy).Dot(uz))<0 then one scale is negative or all scales are negative else one scale is positive or all scales are positive Maybe mathematically impossible to determine the sign of the original scale? If that is the case then should the user provide the information ? as optional params? Matrix.Decompose(scale,rotation,translation,signX?,signY?,signZ?); where signX,signY,signZ would be 1 or -1
  9. @tips4design nice to know. but I suspect some overhead to this approach. a quick google search bring's up some interesting discussion
  10. you cannot access "mesh._enabled" if your are programming in TypeScript. its probably defined as "private" in TypeScript. unfortunately JavaScript does not have anything equivalent to make a property private. so the only thing you can do is follow some convention like underscore to make the JavaScript programmer aware they are accessing a private property and let them know if they do so BABYLON cannot guarantee proper behavior.
  11. 3) One of the reason I was advocating converting to left handed system was to avoid adding extraneous nodes. In other words keep things as close as possible to the original. We don't want users scratching their head wondering "from where did this node come from? I didn't have this in my gltf file". So I was thinking that there should be something like a "fast-left-handed-load" option which should be off by default. That option would come with the caveat that if the user turns it on then they would get faster load time but at the cost of having to deal with an extra nodes called "__root__" and -ve scaling.
  12. @Deltakosh @bghgary check this playground example wherein I am printing out the rotationQuaternion using different methods I get different results If i comment out line 12 (thus removing the negative scaling), I get correct results.
  13. 1) won't we have to iterate through each of the elements anyway, to move them from gltf data structure to babylon data structure? Or is the gltf data structure so similar to the babylon data structure that that won't be an issue? 2) by offline I did mean creating a .babylon file 3) not sure about making the option off by default. In a right handed scene I am assuming we won't be adding a "__root__" node. So by default in right handed scene the meshes would show up without "__root__". Whereas, if the default is off, then by default in a left handed scene meshes will show up with "__root__" node. Potential for confusion?
  14. Release 3.1.0 (01/22/2018) * planar guides always rotate to face camera. makes it easier to pick them * mesh with parents or childs are properly supported. see * constructor now has an additional optional parameter called "pickWidth". This determines how close the pointers need to get to an axis before the axis can be picked up. The default is 0.02 * constructor "scale" parameter has been made optional. Default is 1. * code refactored. private properties are prefixed with underscore "_". This warns JavaScript coders from using those as JavaScript does not honor TypeScript's "private" keyword. Underscore also helps with property name mangling and thus reducing the minified size. * added additional demo file (demo-parenting.html). The long term intention being to use these for tests.
  15. An option would be nice. How expensive can it get? Also what about an offline converter?
  16. @bghgary The more I think about it the more I believe you are right about "Once a scale is composed into a matrix, the information on which component is negative is lost ". It seems you can find that one of the component is negative but not which one and maybe just knowing that one of the component is negative is good enough to figure out the correct rotation. what about getRotationMatrixToRef()? needs to be corrected?
  17. @Deltakosh I am not sure how to fix it. Don't think the previous solution would have worked either. That relied on the signs of each co-ordinates of the unit vectors. I think that would only be reliable if the rotation was zero. We might also have a similar issue with getRotationMatrixToRef(). Won't m[3],m[7],m[11] always be zero? Anyway It is an interesting problem and I will keep looking into it.
  18. @Deltakosh The matrix decompose returns wrong scale value when scale is negative see Here scling.z is being set to -2, decompose returns +2 I think the bug got introduced by this change Fixed matrix decomposition with negative scaling
  19. @bghgary __root__ and a scaling of -z doesn't seem right. A quick way to bring gltf to babylonjs perhaps but not sure if it is a good long term solution. It makes gltf feel like a special case. People will have to take special care to handle it. They will have to remember that in babylonjs each gltf mesh comes with am extra parent node of __root__. Every time they scale they would need to make sure scale in z is -ve. Rotation around z would be counterclockwise , baking seems to be an issue and so on. A gltf mesh will feel different from other babylonjs meshes. Not a good idea if we want to make gltf native to babylonjs.
  20. @bghgary What if there are multiple meshes in the file and I want to import just one mesh? Also I tried using right using BabylonJS using right handed system but ran into a problem. see this post Also, with right handed system I still see __root__ nodes.
  21. So how do I import glb file into my scene if my scene uses righ handed system?
  22. Here is a simple playground which loads a small box into the scene Uncomment line 4 to make the scene right handed and run. Notice the faces of the box have been flipped.
  23. I see that the babylonjs loader does not convert the glb or gltf meshes from right-handed system (their native format) to left handed system. Instead it seems it parents them with "__root__" nodes to handle them in a left handed system. Is it not possible to convert them entirely to left handed-system?