Leaderboard


Popular Content

Showing most liked content since 08/23/2017 in Posts

  1. 9 points
    jerome

    SPS experiments

    Hi, People usually love the Solid Particle System (aka SPS). Some of them sometimes ask for new features like the ability to extend it once created (coming soon) or for some extra speed by the ability to disable some computations. I made some study about how things could get faster. The short answer is : go to a lower lever in the implementation (replace the arrays of objects by typed arrays of floats, for instance), then use if possible other processes (GPU or workers). Well, here are the current status of my prototypes, so you can compare on your computer and browser the differences. The SPS of reference is really big, filled with 40K (yes, 40, 000 !) boxes and tetrahedrons. It's far more than we usually ask to a SPS with animated solid particles in the PG examples you could find in the forum posts. So your browser may suffer a bit ... Reference legacy SPS : http://jerome.bousquie.fr/BJS/test/spsReference.html Then comes the lighter typed array based version : http://jerome.bousquie.fr/BJS/test/spsBuffer.html As you can notice, it's a bit faster. Not only because of the usage of buffers/typed arrays, but also because it has less features than the legacy SPS for now. Let's go on... [EDIT] (from here, your need to have a browser with sharedArrayBuffer enabled) Here comes his new friend, the worker based SPS : http://jerome.bousquie.fr/BJS/test/spsProtoWorker.html This one is really faster. In this version, the particle logic (what the user want them to do) is still in the main thread and the worker only computes the transformations (the final vertex coordinates from the particle rotations, positions, scaling values, etc). At last, here's the second worker version : http://jerome.bousquie.fr/BJS/test/spsProtoWorker2.html It looks faster ... at least on my browsers. In this last version, the particle logic is deported in the worker. The main thread only carries for updating the mesh from the vertex buffers. In both worker versions, the worker computations are decoupled from the render loop. This means that the worker computes, then answers the main thread it has finished and this one just order it to compute again, whatever the render loop is currently doing at this moment. The render loop just reads the data currently updated by the worker in a shared buffer (shared between the worker and the main thread) Next study step to come (not soon) : the GPU based SPS Please wait for a while until the frame counter stabilizes to the current average value if you run the tests.
  2. 9 points
    Hi beloved community, We're proud to announce that we've got a full support of the Windows Mixed Reality headsets AND Spatial Controllers in v3.1 : We even have very cool animation of the controllers to enhance immersion. We're also working on simplifying a lot the creation of WebVR experiences in Babylon.js via the VRHelper. Stay tuned. But using only 2 lines of code, we will soon be able to cover 80% of use cases David
  3. 9 points
    FunFetched

    Shell Shockers

    http://shellshock.io 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: http://www.facebook.com/ShellShockGame Twitter: https://twitter.com/eggcombat
  4. 8 points
    rich

    Phaser 3 Beta 1 Released

    I'm glad to announce that Phaser 3 Beta 1 is now available. There is a Getting Started guide: http://phaser.io/phaser3/gettingstarted which details how to download it and get up and running. Once you've got it running I'd urge you to check out the Phaser 3 Examples. Click 'Edit' on any demo to see the code and learn from it! There are no docs for Beta 1 as we've been delayed by various issues, but they will start to arrive in Beta 2 in a few weeks time. Nearly all examples up on the Labs will run under Beta 1 as I spent a good while tidying them up. You will still find some that don't run but they should be in the minority now. Any questions - post here! Cheers, Rich
  5. 7 points
    JCPalmer

    Talkies, finally! (Improved)

    It has long been the potential of the QueueInterpolation animation system to be capable of speech using shape keys. The difference between potential & actual ended up being a couple of years, though. The "Talk" button on the Automaton QA scene, now says a half dozen sentences.
  6. 7 points
    Deltakosh

    New depth pre pass rendering

    Hey team!! To help fighting alpha sorting issue, we've just introduced support for depth pre pass rendering. The overall idea is to render depth value first to fight against self mesh sorting issues. Here what it looks like when facing the issue: https://www.babylonjs-playground.com/#1PLV5Z#1 And here is the fix with the pre pass rendering: https://www.babylonjs-playground.com/#1PLV5Z#16 Documentation: http://doc.babylonjs.com/tutorials/transparency_and_how_meshes_are_rendered#depth-pre-pass-meshes
  7. 7 points
    adam

    GUI - Input TextBlock

    Here is the start of a GUI keyboard: https://www.babylonjs-playground.com/#QB1XB8#1 https://www.babylonjs-playground.com/#QB1XB8#2 https://www.babylonjs-playground.com/#QB1XB8#3
  8. 6 points
    ozRocker

    3D netball outfits

    I just finished off a website for a company that creates sports uniforms. They wanted something specifically for netball uniforms. They originally had a 2D dress designer but I convinced them to go for 3D http://dyo.100netball.com.au/
  9. 5 points
    Deltakosh

    GUI - Input TextBlock

    And here we are thanks to the wonderful work of @adam: https://www.babylonjs-playground.com/#S7L7FE Documentation was updated: http://doc.babylonjs.com/overviews/gui#virtualkeyboard
  10. 5 points
    Deltakosh

    GUI - Input TextBlock

    This will work PERFECTLY with that: http://doc.babylonjs.com/overviews/gui#inputtext It could be awesome to add your control to the InputText control
  11. 5 points
    javalang

    PBRComposer V1.02 beta released

    Hi, as announced, PBRComposer V1.02 is now ready for boarding. Last changes: 15 studio environment hdrs included, material and environment completed, tests, tests, tests. Project: GitHub Docu: User Interface , Examples , Presets Livedemo including 20 presets: PBRComposer @Deltakosh If you need files for BJS-HPage, let me know or peek/link it from GitHub
  12. 4 points
    Deltakosh

    GUI - Input TextBlock

    Still working on it but I had to recently tackle more urgent things like WebGL context lost. Still working on text input but I still have no ETA
  13. 4 points
    Deltakosh

    New feature: Behaviors

    Hey community! I'm pleased (as always :)) to announce the availability of behaviors: http://doc.babylonjs.com/overviews/behaviors I don't want to rewrite the documentation here so if you have 5 minutes, do you mind checking it and give your feedback here? Is it clear enough? What could be missing? any ideas for upcoming new behaviors? One of the behavior I would like to add is the DraggableBehavior: https://github.com/BabylonJS/Babylon.js/issues/2697
  14. 4 points
    javalang

    PBR composer ( node based )

    Hello, I'm happy to announce that the node based PBR Composer is on the road. What is PBR Composer ? In short, PBR Composer helps you design and visualize a PBR Material in an efficient way. Parameterizing takes place by dragging and connecting specific nodes from a palette (typically textures, colors and uv-coordinates) to the output node, which represents the PBR Material. A preview panel lets you see all changes in realtime and the corresponding js-sourcecode will be updated as well. The resulting graph can be downloaded in JSON format for later use. Images can be inserted via preview fileselect dialog and/or Drag&Drop, in latter case the images will be transformed to embedded data-urls so the javascript functions can be reused without dependencies. Different meshes and environment-maps are available to see the material under different geometry and reflective light conditions. Motivation for PBR Composer: Due to the complexity of the PBR material (soo many combinations with soo much amazing effects) there is a need of having realtime feedback reflecting the changing parameters. Other than some editor already out using a bunch of parameters in confusing properties panels, nodes lets you to concentrate only on the parameters you need giving a nice overview in form of a graph. Nodes can also be shared and avoids therfore redundancy in the sourcecode. The goal is/was to make the user interface as efficient as possible. The idea for realizing the PBR Composer was inspired from Shader Editor. Technical details: PBR Composer is a web application based on dat.gui, w2ui, litegraph.js and of course on BABYLON.js TODO: At the moment, PBR Composer is customized for PBR-Glossy materials. The current activity is realizing a function for switching between Glossy and Metallic paradigms. Any questions? Let me know... PS: PBR Composer is still in alpha stage but will be deployed in beta stage soon Here it is te demo ...
  15. 3 points
    RaananW

    npm update

    Hi, before I finish the documentation, here is a quick overview: babylonjs 3.1.0-alpha3.4 and all of its modules (materials, serializers, loaders, GUI, post processes and procedural textures) are now npm (and webpack) compatible. To use it: npm install --save babylonjs babylonjs-gui If you are using TypeScript, the typing needs to be added to tsconfig.json: .... "types": [ "babylonjs", "babylonjs-gui", "iAmTheWalrus" ], .... Afterwards it can be imported to the project using: import * as BABYLON from 'babylonjs'; import * as GUI from 'babylonjs-gui'; The next step is you programming a mean game and showing us what came out!
  16. 3 points
    Rybar

    Greeble, a #js13k entry

    Hello everyone! Last week I finished my #js13k entry, Greeble. I'd love it if you guys could give it a play and let me know what you think. http://js13kgames.com/entries/greeble
  17. 3 points
    Hello all, Just wanted to let you guys know that the new CreaturePack runtimes have been accelerated with WebAssembly support: https://github.com/kestrelm/Creature_WebGL You can check out more details and a complete write up here: https://medium.com/@kestrelm/creaturepack-high-performance-2d-webgl-character-animation-with-webassembly-72c436bec86c Live Demo ( requires latest Chrome/Firefox): https://creature.kestrelmoon.com/WebDemo/wasm/PixiJS-WASM-Pack-MultiDemo.html Cheers
  18. 3 points
    click on door to open and close them ! goo.gl/BswF63
  19. 3 points
    RaananW

    OBJ file not loading correctly?

    My Dear Mythros, No, I am not kidding. And I am also not here to argue. I am here to be able to help users that have problems with Babylon. Don't get me wrong, but I am not going to install php on my computer, just because you "worked your ass" off compressing some files. Try actually reading the pinned document in this Q&A forum (here, a link, just in case - ) so you can understand where I am coming from. My opinion regarding forum posts hasn't changed since. I will be more than happy to help (as I did so far), but We both need to have the same state. Which means - providing me a zip file with some php files and a lot of unneeded information will do no good.
  20. 3 points
    pichou

    Reverse Particle System

    Hey deltakosh, Here is a playground of the reverse particles system : https://playground.babylonjs.com/#PSK6N1 Hope it could help other developers. Maybe there could be an option in the BABYLONJS particles system where you define the behavior of the emitter : emit or attrack particules. But the custom function do the job perflectly here. Cheers, Pichou
  21. 3 points
    The VRHelper will implement a default teleportation behavior and will display the 3d models of each solution. It will offer also a default picking mechanism that will test the meshes for actionable items. For the GearVR, yes, this is still planned to add support for the controller.
  22. 3 points
    Deltakosh

    Animation change

    Hey team!! as part of a change I need to do for animation, I introduced a new internal class named RuntimeAnimation. The rationale behind this class is to make a bit clearer how animations work. Animation (the class) is here to define an animation and its main goal is to store the keys and associated values (type, loop, easing) When you start an animation on a mesh by using scene.beginAnimation(mesh), all the animations stored on mesh.animations will be used to create an Animatable. Animatable is a store of a list of runtimeAnimation which will use the animation as source and which will be used to interpolate values. Before my change Animation class was used for both storing the data and running the actual interpolations which was misleading. I DON'T think that this will break any existing code. But If I'm wrong please report your findings here. (let me ping @Wingnut as I know he was playing a lot with animations)
  23. 3 points
    jerome

    SPS experiments

    ok back. I was about to implement some high precision float to integer casting in order to use the painful Atomics feature. Painful, because it implies to manage the way each buffer element is updated, then is tagged as asleep in one thread and being surveyed until awaken in the other thread... this for 7 million array elements ! Well, before diving in those complex programming constraints, I re-checked at last time my initial code that shouldn't make real concurrent access to the same part of the memory because each worker was supposed to read and write in the buffer on its dedicated portion only. Moreover the main thread was only support to read the shared buffer whatever the data were up to date or not. And I found a tiny bug in the way I used the indexes to share the pieces of buffer for each worker... fixed. So no more flickering, now. And no need for integer casting and all the Atomics stuff. Everything is here : http://jerome.bousquie.fr/BJS/test/SPSWorker/ There's a folder for each version : one or two workers. Just click on the html file. The difference between the version 1 and 2 is just that the version 1 implements the particle logic in the main thread, whereas the version 2 implements the particle logic in each worker. Theoretically, the version 2 should be faster. On average machines, the FPS should be up to 20 times higher than the typed array mono-threaded version or the legacy SPS one : Reference legacy SPS : http://jerome.bousquie.fr/BJS/test/spsReference.html Lighter typed array based version : http://jerome.bousquie.fr/BJS/test/spsBuffer.html On fast machines, the FPS is almost always around 60 FPS. This is expected because the render loop is decoupled from the worker computations. So don't really mind the FPS when close to 60, don't compare also the particle speed between both version : the velocity step is clocked on the render loop in the version 1, but is clocked on the worker cycle in the version 2, so they might be different. So what to compare then ? maybe the smoothness with what the particle evolve ... are they jerky or not. I tried also with 4 or 6 workers but could not get any gain. Actually, as the Vertex Buffer, used by the GPU at the end, can't be shared among workers, we have to copy the buffer shared between workers in the vertex buffer before the rendering. This means anyway a loop to copy 7M elements in the main thread.... this loop (as well with particle logic when in the main thread) can slow down the main thread, so the FPS. As usual, please wait for a while until the FPS meter stabilizes.
  24. 3 points
    The answer to: is always yes. Babylon does everything apart from making coffee . (I remember @Temechon was trying to get that to work as well, I wonder what happened)
  25. 3 points
    jerome

    SPS experiments

    clearer :
  26. 3 points
    url:https://forreall.cn/3ds/app/debugcloud/ This is a simple and efficient material debugging tool that allows you to upload your own model, and then export the unique identification of the url, like "babylonjs - playground", some of the above function on existing tools, such as: https://github.com/ssatguru/BabylonJS-EditControl, and now, it supports the material properties of very little, but we will extend the content later. You can simply modify the properties below PBRSpecularGlossinessMaterial 、PBRMetallicRoughnessMaterial 、 StandardMaterial 、light Here's a video demonstration
  27. 3 points
    Deltakosh

    memory leak?

    Good catch! I found a fix that will be available on the repo in a couple of hours Please let me know if it worked
  28. 3 points
    Deltakosh

    The Wingnut Chronicles

    On a side note I plan to add scrolling capabilities to GUI (one day :))
  29. 3 points
    Wingnut

    Terrain Slope Problem?

    Poor Mythros. *sigh* How are we going to set you on the path of righteousness? You asked... "Why is there no demo that shows how to do this basic player movement with changing terrain slopes and sliding/blocking?" How about this answer. "Because it is not an easy task, and everyone wants theirs to act differently than another." There's no standard way of doing these calculations, and accelerated slidings. You must code it... to make it act as you wish. Console.log everything. Learn how satguru's system works, and adapt it to work for you. You seem to be against "hacking it out for yourself"... and I'm kindly asking WHY? This terrain can be ANY rez/subdivs, so maybe the slope changes every 20 units walked, and maybe it changes every .1 units walked. Needless to say, current slope needs to be calculated constantly... even while a slide or a blockage is happening. Sliding? Without using a physics engine/impostor, YOU must move the player yourself... to slide. YOU must tell it to slide (unless you can convince someone to write your code FOR you). Sliding is a movement of x, y, and z... all at the same time. Y value must be constantly accelerated per the continuously-monitored slope-angle beneath the constantly-sliding player's feet. WOW! Blocking? YOU must tell it to ignore movement commands in directions where angle > 30 degrees. AND... you haven't even STARTED addressing momentum. Myth... do you know what switchbacks, are? Sure you do. The slope COULD BE > 30 degrees, but if player uses diagonal switchback method, maybe they can still climb the hill. It all depends upon whether/not you will allow "strafe" movement... side-stepping, and whether/not side-sliding is possible. AND... are you going to use the same rules for side-sliding... as you are for forward/backward sliding/blocking? I wouldn't, if I were you. Humans can hold-place on steeper-angled hills... if they are standing sideways (using shoe/foot/ski edges). And, can the player make the turn at the end of each switchback leg... without accidentally back-sliding down the hill? There are no flat roads on our BJS terrain. SO, when player makes a turn at the end of a switchback leg, he/she will have a "moment"-of... facing straight-up a > 30 deg angle, and the code says "slide backwards" if that happens, so the player is not able to make the switchback turn. With me? I hope so. What you ask-for.... is very complicated. There are TWO directions of movement that you must always "sum". Sliding direction, and wanted movement direction. CAN a player be walking forward JUST FINE (no sliding forward or backward happening)... yet be occasionally or continuously side-sliding? If a player walks down a slope at a diagonal, could there be SOME sideways-sliding and SOME forward-sliding? If a player slides down a LONG slope, will you want to add acceleration? If the slope suddenly changes from > 30 degs.... to 28 degrees... will the player's mass, friction, momentum (inertia)... make him/her slide MORE... even on the 28 degree terrain? He/She will have quite a bit of speed. What if a logging truck accidentally fell-off one of those switchback roads? Do you think the truck would stop when it landed on the switchback road below? Unlikely. It's speed/momentum would likely make it go all the way to the bottom, ignoring ALL < 30 degree terrain on the way. You have SO MANY THINGS to take into consideration... for this project. Using physics engine/impostor... would handle MOST of your hassles. But... "walking" a physics impostor... is known to be a challenge, too. IT will ALSO cause you to do special and deep coding. This is a sufficiently complicated project... that you MIGHT want to avoid "hounding" anyone, about it. Not saying that you have done that, but, you know, tact and all. So again, why don't you want to simply "grind out the solution"? Don't you LOVE programming and console.logging other people's code/variables, and watch the numbers, and learn how things are done, so you can borrow those techniques for other projects? How can you NOT love doing that? It's wonderful, and it has a self-satisfaction quotient the size of the moon. Ya got a powerful robotics system in JS, ya got a geometry playground that listens to JS... just tell it what ya want it to do. It takes orders GREAT. Was I kind, in this post? I hope I didn't hurt your feelings.
  30. 3 points
  31. 3 points
    ian

    30 in collections

  32. 3 points
    Not everyone will be comfortable breaking policies like this and I'm not sure its a great idea to be advising people to do so.
  33. 2 points
    Mission 13 - Lost in Space Check out our newest game, Mission 13! We spent the last few weeks developing it for the JS13K Games competition hosted by Andrzej Mazur at Enclave Games. As most of you probably know, the idea of this competition is to fit a whole game in a zip file less than 13kb. We managed this with our entry, and here is the end result! Also, feel free to plaster it across social media, trust me, we won't mind http://js13kgames.com/entries/mission-13-lost-in-space Some technical features of this game, for all you nerds out there include: Custome image generation. (For stars, planets, and asteroids) Audio synthesizer using JSFXR. Support for both mobile and desktop with fullscreen resizing capabilities. Random terrain generation. And most importantly, love.
  34. 2 points
    adam

    Announcing Babylon.GUI

    Right, a stackpanel containing separate textblocks would probably make more sense. Then you can just write directly to each textblock.
  35. 2 points
    RaananW

    npm update

    Hi, All will probably be answered when I finish the doc. To answer your questions specifically: The way you use the imports should be working as well. But it will have no effect on tree shaking and I therefore see no reason to do that. The reason it doesn't do any tree shaking is because of the way babylon is currently built (as a large single unit). My first attempt at solving this was to transform the entire framework to an es6-import-based project. The problem was circular dependencies, that prevented commonjs from working correctly. We are serving a single minified file. So importing a single class will actually load the entire namespace (including executing loaded code) and send back the requested class. We can discuss this further if you wish, but it's not the scope here. Maybe I will find the time to write a blog post about it. The modules are extending the BABYLON namespace. The code is being executed after "requiring" babylonjs, which is a singleton holding BabylonJS's classes. When extending it, any code ran on this imported variable is simply executed, thus - the loaders should be registered automatically when you import them. If they don't, please let me know. Same things goes to materials, post processes, procedural textures, serializers. The GUI has its own namespace, so it can be imported independently. Hope this clear things a bit!
  36. 2 points
    adam

    Announcing Babylon.GUI

    Would something like this work? https://www.babylonjs-playground.com/#6SN3TN#4
  37. 2 points
    Lord_Garfield

    Google Fonts once and for all.

    Hi all, I think I found a solution in loading google fonts from your app instead of loading them with the google api. It is inportant to embed your fonts if you want to build native apps. So you can make shure your app works when offline. But using the @font-face in css you still have the problem that your font is not loaded immediatly and text in phaser will be rendered in the default font. Problem description: You load a font with @font-face or google api and you have to trigger a time-out to make shure the font is loaded before you add text in phaser. Using the google api you can write this like phaser.io example http://phaser.io/examples/v2/text/google-webfonts Nice but you can't use a time out when you load your font localy. (maybe a font you created on your own or paid for) There are things like font.js that try to do this but I think it is hard to implement. My solution Get a font Download a .ttf font from google or another place. (not shure if it will work with other types than ttf.) Go to fontsquirrel webfont creator http://www.fontsquirrel.com/tools/webfont-generator upload all fonts to your assets folder (or any other folder you like.) Use the @font-face that was given to you by fontsquirrel so you embed all font types to support almost every browser. Adjust the font-face sources so your path of the font file is set to the correct folder (assets or your folder) Load the font in your html file Put the your @font-face into the header tags of your index file between <style></style> tags. In your body the first element you create is a div with these settings: <div style="font-family:YourFontName; position:absolute; left:-10000px">Font Loaded</div> That is it. Phaser will use this font immediatly. no waiting times. This is becouse the div already loaded the font before phaser is loaded. Just make shure phaser is loaded after document.load. Or in JQuery terms. load it in the function $(function() {}); Kind regards. Lord Garfield
  38. 2 points
    Wingnut

    Canvas and CSS properties

    You don't use in-browser object inspector, @Pryme8? That shows all props and methods available on sprites and spriteManagers... and any other object. Handy. It will let you answer those easy questions. Here's a nice little sprite playground to learn-from. Wasn't it you that sometimes gets grumpy... because people don't research, read, study, learn? hmm.
  39. 2 points
    Deltakosh

    Reverse Particle System

    @pichou: Actually I plan to create a particles library where we could add as many behaviors as we want https://github.com/BabylonJS/Babylon.js/issues/2445
  40. 2 points
    aFalcon

    BABYLON.Augmented Reality ... in AR.JS

    Scale down ParentMatrix... and there it is: Utilizing nice fire texture plugin (+1), with stubbed colors. Demo 1.
  41. 2 points
    fenomas

    Physics Movement

    So, there are a few issues stacked up, and there's no "one true" answer to any of them. (Which is to say, Unity might have a single implementation for some part of this but Babylon and programming generally don't.) The fine details depend on what kind of movement you want and maybe on the engine. But at a high level: You should generally never touch a physics object's position or velocity directly. Apply forces and impulses, use constraints, change friction, etc, but let the engine figure out where to put the objects - that's what it's for. The main exception to (1) is, it's fine to zero out velocity to stop a character, or multiply it by 0.99 to slow them down, etc. Things like that make physical sense. Your post mentions touching mesh.position, but that's probably not useful - that just moves the mesh around, disconnected from its physics impostor. Apologies if that was a typo. The only position relevant here is the impostor's position, the mesh position should just be copied from the impostor. The simplest way to hack up physics based movement is usually to (A) read the user input and construct a vector for which direction to move, (B) scale that vector by some value representing how fast the character moves, and (C) apply that vector as a force to the player body. You do this every frame. For jumps you probably want to apply an upwards impulse, not a force. The steps in (4) are the minimum naive way to move a character that's controlled by a physics engine, but they probably won't give you the kind of movement you want. For example, you probably want the character to stop moving fairly quickly after the user releases the move button, but that will only happen if there's significant friction, and if there's a lot of friction, it will take a lot of force to move the character, making things very twitchy. For those kinds of reasons, "real" controllers usually do more stuff, and take some tuning to get what you want.For me in my current project, I do approximately this: First I poll the user input and construct a vector for which direction the player wants to move, scaled up by a value representing their maximum speed. I read the character's current velocity vector, and subtract it from the "desired movement" vector to get a "correction" vector representing which way the player must push themselves to end up moving in the desired direction. I then clamp this vector by some value representing the character's maximum move force, then I apply the result as a force to the player body. Whenever a movement key is pressed, I zero out the player's friction with the ground. When the key is released, I turn friction back on so they stop naturally. I think I also apply a counter-force to help them stop - I don't remember offhand. If the player is airborne, all the above stuff still applies, the player just has much lower move force to represent limited ability to affect their movement, and also apply a drag force for air friction. Incidentally, I think (2) above, with the correction force etc., is something I got from the Quake sourcecode. (3) about turning off player friction during movement is something I got from an article about Sonic The Hedgehog's movement physics. But that's all just one way to do it. You could also, for example, get very precise movement by creating an invisible anchor, moving the anchor precisely where the player directs, and attaching the player body to the anchor by some constraint, like a damped spring. Or lots of other things, if you have a pretty clear idea of what kind of movement you want, and you can envision what sort of physical realities would cause that movement to happen. Anyway that's the vague hand-wavey version. If you were having issues with things like diagonals not working, you probably have a bug somewhere much lower down, like in calculating the movement vector. This can be fairly tricky, since you normally need to do some transforming between world and camera coordinates (that is, pressing "right" probably means move "right relative to the camera", not "move East"). So this high-level rundown may not help much off the bat, but let me know if you have questions about it.
  42. 2 points
    amo yeh

    physic joint with angle limit

    I applied and it works as expected, Thanks for the help. a little demo update to simplify the function I was looking for http://www.babylonjs-playground.com/#8PQK71#3
  43. 2 points
    Hello, I moved all my deposits in a single place for various reasons. All my previous deposits have been removed. I had to reorganize all for less scatter. The new link to my deposits or you find CastorGUI, TerrainEditor and HeroonEngine and others on the same link later. https://bitbucket.org/JSbabylon/ I wanted again to start my news each project for any reset, I have therefore hide, you can not find them if you look for them. I would do my ads when I have something to say about them. The HeroonEngine site link is always in the same place, but I deleted the forum which is useless for now. But I forget to retrieve the tutorials the golds of my reorganization, so I'll have to redo all (better not to regret this loss. Perhaps video tutorial will be good) http://www.heroonengine.actifgames.com/index.php
  44. 2 points
    Just go and get them in metadata then if you have stoker in metadata. var listMeshes = newScene.metadata.meshes; var listLights = newScene.metadata.lights; I advice to stoker one object per file and not all the scene in a file because it will be too large if you add metadata to all your objects.
  45. 2 points
    JohnK

    Draggable mesh with constraint

    Sorry been so long answering been busy with other things. mesh.rotation.x = -Math.PI/2; scene.registerBeforeRender(function(){ mesh.rotation.y += Math.random()/100; mesh.rotation.z -= Math.random()/100; }) Does not mean rotate x by 90 degrees and when it is in that rotation rotate y by a bit and z by a bit. mesh.rotation is always done in a fixed order which in terms of the world axis , do rotation about z axis, then about x axis and then about y axis ( or if you want to think about local rather than world axes order of rotation is y, x, z ). Using mesh.rotate(BABYLON.Axis.Y, Math.random()/100, BABYLON.Space.LOCAL) mesh.rotate(BABYLON.Axis.Z, Math.random()/100, BABYLON.Space.LOCAL) accumulates the results in the order the rotations are given. This PG https://www.babylonjs-playground.com/#1ST43U#45 shows three rows, the top row shows the starter box then an accumulation of z, the middle row is top row plus x rotation, the last row the middle row plus y rotation. Thinking in terms of world axes notice after z rotation the blue side is parallel to the XoY plane and so giving a rotation to these boxes of -90 degrees about x brings the blue side to the top parallel to the XoZ plane, effectively the z and x rotation has resulted in a rotation about the y axis. Finally to these is added a further y rotation. In the PG above the z accumulation is positive and reinforces the final y rotation. In this PG https://www.babylonjs-playground.com/#1ST43U#46 the z rotation is negative counteracting the final y rotation. Since in the animation in this post's PG the accumulation is random with z negative and y positive the actual rotation carried out can be a small positive or small negative number resulting an an oscillation around the y axis. Besides the method used by @brianzinn another way to solve this is to replace mesh.rotation.y += Math.random()/100 with addRotation mesh.addRotation(0, Math.random()/100, 0) as in this PG https://www.babylonjs-playground.com/#2JXSKY#44
  46. 2 points
    hotfeet

    Collision Trouble

    here's a quick fiddle that shows that cool minkowski shizzle. i didn't add keyboard controls but just mouse over to move the rect you can just adapt from that. the relevant code is really just the function rectCollision(rect1, rect2) https://jsfiddle.net/hotfeet/euobdLvy/
  47. 2 points
    Pryme8

    GUI - Input TextBlock

    @brianzinn https://www.babylonjs-playground.com/#ZIPFMJ#51 I need to finish it up at some point and fix some errors with it but here is a good start to that.
  48. 2 points
    Wingnut

    Problem with mesh collision detection

    Okay... https://playground.babylonjs.com/#Z88Q4W#18 (open console, wait 5 secs for enemy to appear, then SHOOT!) Yay. Yes, it was the shot animation... still running... at its last keyframe. That was keeping it "stuck" in intersection. Line 99 - create a global-ish var called shotAnim. Line 133... make shotAnim contain a value. I believe it is a BJS "AnimatABLE"-type object. Line 150... stop the animation (after it intersects). Line 151... now that the animation is stopped, the shot mesh can be positioned OUT-OF intersection status. I move it to the camera. I am still having problems with shot.setEnabled(false) [line 152]... and shot.setEnabled(true) [line 107]. My thoughts are... pre-make 10 "shot" objects, and store them in "shots" array. Then just enable/disable them (and start their flight animations) as wanted. Each shot now "carries" its .targetMesh WITH it. So... the shots can be "fire and forget"... and likely, there are options for having all 10 shots in-flight at the same time. And... yeah... the same "stop the animation" issue... will need to be considered when the spheres (enemies) turn-on THEIR animation (flying towards the camera). But... meantime, we have progress! YAY!!! It's Miller Time!
  49. 2 points
    @Deltakosh Ah yeah! Thanks for green light. Extension will work then. Wasn't sure... There is a dependency issue going on with super-heavy-asm-backend, in /libs (I think). A tad heavy. All good stuff, (I need to look at), just needs organized. With BABYLON on the root, because, deep nesting in ar/babylon.js/examples/. Needs *-1. So BABYLON.side, at root .index with /lib/arjs and all the options composable. Ah, ok.... And yep, an extension pattern will probably be helpful to unwind and pack variations on dependencies ... interesting. I will check out extensions... thanks!
  50. 2 points
    Deltakosh

    WebGL2 occlusion queries

    I'm thrilled to announce that thanks to Ibraheem Osama we now have full support for occlusion queries: http://doc.babylonjs.com/overviews/occlusionquery