Dal

Members
  • Content Count

    182
  • Joined

  • Last visited

  • Days Won

    5

Reputation Activity

  1. Like
    Dal reacted to satguru in Clara.io + Babylon.js Exporter   
    fyi
    saw this news today
    Introducing Clara.io + Babylon.js Exporter
    http://exocortex.com/blog/export_babylonjs_claraio
  2. Like
    Dal reacted to NasimiAsl in Texture Relation With FPS?   
    i starting make some TileGenerator for use in this case it maybe return 60fps  i share that after do
    Thanks all for looking this post when i see something and don't understand why i do like wild man to find why sorry ask this post and take time for yours (special @dbawel ) 
  3. Like
    Dal reacted to NasimiAsl in sample visualizer   
    http://babylonjs-playground.com/#1TYWYB#132
  4. Like
    Dal got a reaction from ozRocker in Vector3.lerp is concatenating instead of adding   
    class Player { position:Vector3 = Vector3.Zero(); } var message = instruction.message; var player:Player = <Player>message.player; vector = new BABYLON.Vector3(player.position.x, player.position.y, player.position.z); That probably won't work as it is but something on those kind of lines would avoid passing untyped data around. If message.player is the right shape it should fit.
  5. Like
    Dal reacted to Deltakosh in 2.4 is almost done   
    Hello all!
    Just an heads up to tell you that 2.4 is almost done and that I'm planning to close and release it by end of next week
  6. Like
    Dal reacted to josharrr in Getting typescript setup   
    @Fairydhwen Here's the d.ts I'm using: https://github.com/BabylonJS/Babylon.js/blob/master/dist/preview%20release/babylon.d.ts
     
    @Dal @JCPalmer Sure enough, when I took out the import statement I stopped getting that error. I also just had to restart Visual Studio Code for intellisense to pick up on the reference line. Thank you for the advice!
  7. Like
    Dal got a reaction from Nockawa in Canvas2D Main Post   
    Yep could be. I think we solve 2 problems with alt text etc. because it makes it accessible for people with sight or mouse difficulties but also in the process, search engines can "see" that alt text stuff and index it. So its good to figure out a way that it can be read and navigated by code and not just by the eyes
     
  8. Like
    Dal reacted to Nockawa in Canvas2D Main Post   
    @Dal
    1. I didn't tried on 4K/Retina devices, but I use HTML to render each letter you will use in the Canvas2D, So if you specify a font in "pt" units I think (because I'm far from being expert on the matter) than it will be independent from the screen DPI, then it should draw big letter on 4K/Retina devices. I compute the size required for the FontTexture based on the height of a line and the width of the 'W' character (couldn't find something more accurate). So it should just create a bigger texture for these kind of display. But I'd glad if someone could check for it. About text, right now the result is not as good as expected/should be, I have anti-aliasing/blending issues, I'll have to solve them quickly if I want the text to look always good whatever its background is.
    2. Well, these features are more part of an incoming GUI Library based on the Canvas2D, the primary intent is to build UI for gaming or pro apps, I honestly how far I will go, writing such thing takes time for a single guy, but I like it. I'll try to bring up the topic of accessibility when the time to build the GUI library will come. If there're cheap things to do that can help, I will.
    3. I think relying an HTML is better on this case. The intent is not to write another HTML, so interaction with the content should be limited to a real-time one with the User. Additions can come later, but for now I have my hands full!
    You suggestion about the HitRegions and Alt Text is a very good idea! Maybe a future contribution from you!?
    For now I'm finished the basics of Interaction mode, there's something wrong I commit yesterday night (if you go to the Playground, you'll see the example are not rendered the way they're supposed to...).
    It made me reevaluate my dev approach, the feature is quite big, so I need more testing/validation stuffs, so I'm going to work on that. I can't commit regressions everyday!
     
  9. Like
  10. Like
    Dal reacted to Nockawa in Canvas2D Main Post   
    The whole goal of this feature is about: not having to do what you say, but still somehow get something that reach the same intent!
    Let me explain myself: I don't want/can't rely on HTML to render GUI elements, it would be great in theory because you'd have a wide varieties of GUI stuffs (the whole HTML!) but performances and compatibility issues would kill you instantaneously!
    But still, it would be great to have TextEdit, ComboBoxes, Buttons as part of the Render Screen or directly inside the 3D Scene, right? With User interaction possible of course!
    That's the final purpose of this feature. Let me rephrase: this feature lays down the foundation to achieve this goal: writing a great/efficient GUI Controls Library for your creations, without having to rely on HTML.
    I'm (well, we, because I hope some people will soon contribute) not going to rewrite something as powerful than the HTML GUI, but I'm sure we will succeed to develop a GUI Library that will allow you to do many things. I'm pretty confident because I've already done it in the past and I've never realized a 2D Rendering Engine that optimized, so I'm sure we'll succeed!
    What I'm working on finishing right now is the feature itself, that's the first step. When it's reached I'll start the GUI Library.
    By the way, I've wrote a long tutorial to explain how to write your own primitive type: you'll find it here
  11. Like
    Dal reacted to Nockawa in DynamicFloatArray to the rescue for efficient Instanced Array!   
    Ok folks, this is the last quick post I have for you (I think)...
    The name of the class is well...I had to find a name, that's all...
    The problematic: to render efficiently we have to minimize the draw calls as much as possible, so when it's possible we have to rely on the WebGL Instanced Array extension. Basically, this extension is used to create an Array Buffer that will contains all the settings specific to each instance of the same object you want to render multiple time. Say hundreds, thousands of Rounded Rectangles in the Canvas2D, drawn in one call for instance!
    But how to feed the beast (the array buffer) ? Especially if the objects you send are subject to things like culling, clipping, visibility change: which make the whole list change frequently!
    The solution: A class designed to allocate/free elements, storing them into a Float32Array (because believe me: size does matter, and 32bits per number is ok for us!) and providing a method to defragment its content in order to update the Instanced Array buffer without worries.
    Well, ok, you've guessed, that's what DynamicFloatArray is about!
    When you create an instance of this class you specify the size of one element (the size is in floats, NOT in bytes): this is called the Stride. So if you need to store 4 Vector4 for a transformation matrix and one Color4 for the color of you object, the stride will be 4*4 + 1 = 17! You also specify the initial count of elements the Float32Array can contains without being resized (and it will, after this count is reached, by 50%, I know it may looks a lot, but resizing in not my friend!)...
    Then it's pretty simple: when you need to store one new element, you call allocElement(), it returns an instance of the DynamicFloatArrayElementInfo class (I know the name couldn't have been longer) which contains the offset into the Float32Array of where your element first float is located. It's up to you to be a big nice boy and copy the data accordingly, otherwise face the consequences!
    If you don't need this element anymore, just call freeElement() giving the corresponding DynamicFloatArrayElementInfo object.
    Now, what is the deal you might ask? When you call freeElement() it creates "holes" in your Float32Array, holes that you can't send to the Instanced Array buffer without facing another kind of very bad consequence!
    So all you have to do thanks to this class, is to call the pack() method (which I spent 3 hours to write, true story, that long...) which will defrag the Float32Array, removing the holes by moving valid elements to fill them (the holes!). Don't fear to call this method, if nothing is fragmented it will return in no time, if the content if full of holes, well, I spent 3 hours to make sure it defrags it very quickly! Calling pack() returns what is called a subArray, this is NOT a copy (I hate copies, like resizing, a little less though), but a view of your dear unfragmented Float32Array, ready to feed the Instanced Array Buffer!
    So to sum up: at each render when you use an Instanced Array, call pack() and update the Array Buffer that you just bind. (sadly, it's still up to you to detect if there was changes and if the update is needed or not, but it shouldn't be a big deal for you to handle)
    Beware!
    As the smartest of you may have noticed, calling pack() will move some elements, which means their position in the Float32Array will change! That is why I return an instance of the DynamicFloatArrayElementInfo class (which only contain a single property: the offset) and not a single number I wouldn't be able to update for you! When an element is moved, its offset in the DynamicFloatArrayElementInfo object is updated accordingly and it's your responsibility to get this offset every time you are going to update a given element.
    Conclusion
    Well, I forgot to say the DynamicFloatArray will grow when needed...but will never shrink, sadly...a such feature could be open for debate.
    If you plan to use Instanced Array, I believe this will a great help to you as it was for me when developing the Canvas2D. So far the class looks pretty reliable, but I have to admit: the pack() method...is not the easiest thing to code! (efficiently, for me at least!)
    Oh, by the way, it might interest you, but now the methods Engine.updateAndBindInstancesBuffer() and Engine.unBindInstancesBuffer() are able to update any kind of Instanced Array, useful! All you have to do is using the offsetLocation argument as a InstancingAttributeInfo[] which contains everything to wire the Array correctly !
    Have fun !
  12. Like
    Dal reacted to Deltakosh in Exporting Skeleton from Unity3D   
    Hey guys, I'm proud to announce that the Unity exporter now supports animated bones!
    https://github.com/BabylonJS/Babylon.js/commit/df0247f54edb4583e70978b811db7fd15ef3160c
    A big thank to @sebavan
  13. Like
    Dal reacted to jerome in Be efficient my friend: use StringDictionary!   
    impressive and smart
    mmmh.. don't you intend to add also a decent multithread model to js please ? 
  14. Like
    Dal reacted to Nockawa in Be efficient my friend: use StringDictionary!   
    Hello everybody, so this post is mainly for TypeScript people, even if Javascript folks could find some interest in this class.
    As you may all know the Associative Array of Javascript is the most efficient way to store/check/retrieve data based on a string (and a string only), so I've created a little class that wraps this feature nicely in TypeScript with some additional features.
    This is a generic class, the type of the value stored in the Dictionary is give at construction.
    Then you have many methods to interact with the dictionary:
    add(), to add an object from its key, will return false if the key is already taken set(), to change the value corresponding to the given key, false will be returned if there's no such key. getOrAdd(), return the value of the given key, if there's no such key the given value will be added. getOrAddWithFactory(), same as above but more efficient: if the key doesn't exist then the given factory will be called to create the object to store. contains(), to check if a given key is stored remove(), to remove the key and its corresponding value. clear(), to reset the whole dictionary forEach(), you give a callback that will be called for each key/value in the dictionary first<TRes>(), you give a callback that will be called for each key/value in the dictionary until the callback returns a valid <TRes> object, then the enumeration will stop. the count read-only property will return the count of key/value stored in the dictionary. The best way to store/check/retrieve data efficiently is by using a string as a key, so make sure you do! Converting a number to string worth doing it apparently to rely on associative array.
    Feedback is welcome. happy coding!
  15. Like
    Dal reacted to Nockawa in Canvas2D Main Post   
    Hello good people of the babylon.js community!
    Update #14 from January 29th, 2017
    Primitive Collision Manager (PCM, @ller request) 
    The PCM is finally done! Well, first release, I've already spotted some not supported cases... Anyway, you can check a PG demonstrating the feature here: http://babylonjs-playground.com/#1PXWLR#2 (I've commented the PG for you to see how it works)
    Turned out that I didn't do what I wrote in the previous message, I didn't check for OOB and I've implemented a generic triangle set versus triangle set intersection algorithm right away.
    Basically all primitive types now create/update a Tri2DArray which contains a list of triangles describing the primitives surface. It needed to be that way because an Ellipse with a intersection of 8 is graphically not shaped like a perfect ellipse: there's not enough polygons, so I couldn't use a intersection algorithm involving a true/perfect ellipse, same goes for the Rectangle2D with round corners. So I decided to go for the most generic and accurate way.
    All primitive types are supported except the new WireFrame2D one.
    Through the PCM object you have a list of all primitives intersecting with the Canvas' border (if you activate the feature), it's useful. You also have a list of all the pair of two colliding primitives.
    From a given prim you have the intersectWithObservable and intersectWith properties to get notified of new/removed intersections and to access the full list of them.
    New Text Alignment (vertical and horizontal) and word wrapping features for Text2D (coded by @adam, I'm very thankful to him! It's good to feel less alone on this whole coding...)
    Basically now you can set a left/center/right text horizontal alignment and a top/center/bottom for the vertical one.
    If you specify a size for your Text2D primitive you can now have auto word-wrapping if the line exceed the horizontal limit.
    Maybe @adam could share a PG demonstrating the feature! 
    New Primitive Type: WireFrame2D
    Well, I needed it to draw the debug World AABB and Cluster of the PCM, so I wrote it. The Primitive accept many WireFrameGroup2D, each one having a default color and contain a list of lines. Each stored vertex has its own color.
    Basically you create a WireFrameGroup2D instance then use its method to fill it with vertices. Note: it's Line List, not line strip: each line is defined by two own vertices. You can use an API to start, fill, end a LineStrip but internally it will double the vertices for everything between the first and last vertex.
    Right now this Primitive doesn't support any kind of intersection (point or prim-prim), I'll add an intersectionThreshold and implement the algo any time soon...It's not a priority right now...
    Misc things
    The BoundingInfo2D now support a WorldAABB with an efficient dirty/update, I obviously needed it for PCM Each Prim Instance has now a uid property which is a unique id (a GUID), I use it as a key to store the prim or prim related data into a StringDictionary, it's an efficient way to retrieve a given prim without going O(n). There's a Triangle versus Triangle intersection method in the Math2D.ts file, its implem is slow. If someone has the code for a Tri-Tri in 2D implemented using the Separating Axis Theorem (SAT) algo: I'm in ! Update #13 from January 24th, 2017
    WorldSpaceCanvas TrackNode feature
    So I've developed the feature requested by @royibernthal to create WorldSpaceCanvas that track a 3D Scene Node with the optional feature for the WSC to always face the camera (billboard mode). You can find a demo in this playground.
    It was truly missing to the whole "WorlSpace Canvas interacting with 3D Scene" scenario. Other users requested more about this specific scenario and it perfectly makes sense: C2D was develop to provide 2D support for the 3D Scene, I've been focus on the "2D stuff" by itself a lot, because, well, it's already a big task, but yes there should be more things to come on this area, I'll try to dev feature requests on this matter with a higher priority.
    Update #12 from January 11th, 2017
    Few announcements:
    We can now use BMFont to render text with Text2D PG here the documentation of the Text2D was update to explain the different techniques you can use to render text (normal, Super Sample, Signed Distance Field, BMFont) and which one you should use. (Thanks @MasterK for the idea and help) There's a new page about how the Rendering is working, it will help people to understand how to get transparent sprites, for instance. (this page is currently only accessible by the link I gave before, because I've messed up the link in the Canvas2D Homepage, yeah, that's my special ability, DK loves it) Some new Playgrounds are available at the bottom of the Home Page I was ill during the release of the 2.5, so I couldn't update the doc and the what's new, so I've updated the what's new of the documentation web site, go take a look if you want. As a separate module, Canvas2D has its own section in the What's New. Update #11 from January 5th, 2017
    Long time that I didn't develop new features but here we go:
    AtlasPicture is now supported, see the documentation about it. Scale9Sprite is a new feature of Sprite2D class.The Sprite2D documentation was also updated. You can play with the following PG:
    Scale9Sprite AtlasPicture Of course you can use Scale9Sprite for a Sprite generated from an AtlasPicture.
    Update #10 from October 21th, 2016
    allow3DEventsBelowCanvas
    Until now, pointerEvent occurring above a ScreenSpaceCanvas were also sent to the 3D Scene, many people (rightfully) complained about this so I decided to add the feature, which is called "allow3DEventsBelowCanvas" (which is false by default).
    The PR is here for more info https://github.com/BabylonJS/Babylon.js/pull/1448 (preview files updated and PG not updated so far).
    You have to realize that this is a change in behavior, now by default events won't be sent to the 3D Scene if they occurred above the Canvas, but I figured it made more sens this way. If you want them to be sent anyway, just set the setting to true!
    Update #9 from October 19th, 2016
    Stabilization
    The latest weeks were spent on keeping stabilizing the Canvas2D feature, fixing bugs and adding feature only when necessary. Overall bug fixes were concerning Positioning Engine (alignment), StackPanel Layout Enigne, pointerEvent observable (leave/out now works better), some dispose issues solved, you're supposed to have no more opacity/transparency issues (well, let's say, "less").
    One new feature
    One new feature was developed recently, during the creation of a ScreenSpaceCanvas you can now specify the renderingPhase setting, allowing you specify for which camera and which renderingGroup the Canvas is supposed to be rendered to.
    Simpler version: you can now interleaved 3D layers (which are renderingGroup) with 2D layers (which are ScreenSpaceCanvas). Many people requested it ( @MasterK, @HenryPeng, @stormwarestudios) to render 3D content above UI for FX (particles) or simply some 3D preview (like a 3D character preview in a UI). This playground  is a very raw demonstration of the feature.
    Modularization
    Oh, by the way, I nearly forgot to tell something pretty important: we have recently extracted the Canvas2D feature (and the forthcoming GUI Lib first code lines) from the main babylon.js file. This is the first step of what is going to be a modularization of babylon.js, Canvas2D/GUI being obvious (and easy) candidates.
    What is changes for you?
    Well, not that much, if you use C2D/GUI you now have to use the "babylon.canvas2d.d.ts", "babylon.canvas2d.max.js", "babylon.canvas2d.js" that are sitting next to the "babylon.js/d.ts/max.js" files in the "dist" directory of your choice (right now only the "preview release" directory contains the Canvas2D related files, for obvious reason. The module's name is still "BABYLON", which will ensure you'll compile without changing anything.
    On a repository point of view, the source code was moved from /src/Canvas2D to /canvas2d/src/. Our lovely boss made the move and the Gulp config to compile everything the same way babylon.js does so you don't be lost.
    La surprise du chef!
    And the "chef" is not me, but another core member @Temechon spent some very valuable time (and I can't thank him enough for that!) to work on a feature I desperately need for so long but that I'm unable to code (well, in the time frame it will took me) which is called: c2dinspector.js.
    Basically the c2dInspector is a HTML Pane that is added on the right side of your HTML pane and that displays all the Canvas2D instances in your Scene (well, Engine to be more accurate) and their content as a tree of Primitives.
    You can select a given Primitive to see its details on the Detail Plane below, you can even change some values (still work in progress).
    In the tree, for each item there're two icons at the very left, an "eye" to show/hide the prim, and a "double frame" which is used to show/hide the debugDisplayArea (more on this below).
    This feature will help you (and me!) debug and understand better what's going on and why! It's not released yet, but a beta will be very soon (tonight or tomorrow), it's still Work in Progress, but hey, it's better than nothing and it won't harm you.

    The debugDisplayArea (the only thing I coded, bugs are to expect!): as you may know a primitive has four area: layout, margin, padding and content, this feature will display them with a given color code (layout being light red, margin is yellow, padding is magenta, content is cyan). This screenshot below is the same UI as above but with the debugDisplayArea on the "GUI Visual Placeholder of MainWindow", which has a margin of 50, 50, 50, 50 (the yellow area shows it) and padding of 100, 100, 100, 100 (the magenta area show it). The content in blue is the Windows' background, in light grey, which is here covered by the blue area.

    GUI Library
    I've started the GUI Library, it's going on very well, but I just can't work as much as I wanted on it the last couple of weeks, so there's delay: that's life. There's a separated thread about the GUI here so don't expect me to say more in this post, got watch the other thread if you care about it.
    That's all folk, enjoy, as usual: feedback are welcomed, you can do it in this thread of course! I just don't want this thread to be a "bug tracker" one, if you have issue, keep creating a new post and don't forget to mention me as I don't look at the forum everyday to see if someone needs help (but DK does, happy him...)
    Update #8 from August 31, 2016
    I pushed a new commit today that address many things around using Scale on the Canvas object directly. I'm lazy so I copy/paste the PR description:
    You can now set a Scale (or ScaleX/Y) to a Canvas2D object, it will render as expected, for every caching strategies. At creation time of a ScreenSpaceCanvas you can set a designSize which will be used to compute the Canvas' scale automatically in order for you to specify absolute coordinate in the frame of the designSize (MasterK request) Any Cached Renderable Group can have a new GroupCache Behavior: GROUPCACHEBEHAVIOR_NORESIZEONSCALE. When set the cached bitmap for the Group won't be resized when the scale of the group will change, improving performances over rendering quality Ellipse, Rectangle are now drawn with a prescale computation to ensure the best result when using high/low scaling Prim2DBase has not the actualScale and actualScaleX/Y property that return the accumulated scale of the primitive. At their creation, primitives can specify if they should not inherit from the scale of their parent through the dontInheritParentScale setting. I don't know if many of you will get the GROUPCACHEBEHAVIOR_NORESIZEONSCALE and find a usage, but I thought it was the time or never to do it, so I did. And it works pretty well. I think for mobile gaming it may help to improve the perf by setting/keeping a fixed resolution of what's being rendered into a Cached Renderable Group2D.
    The designSize mode was made upon a request from @MasterK and it's really a good idea, I can see the use case from a game UI point of view and I hope it will work the way it should be, otherwise I'll do bug fixing!
    If there's no more urgent thing I'll go back on my working list and the next thing (that was already started but paused) is supporting the Device Pixel Ratio, which is another big thing for mobile gaming I think. I will be a breaking change for people who are right now "compensating the lack of this feature", but well, I'm sorry, there's nothing I can do about it except I wished I knew more about HTML few months ago!
    I know most of you are still trying to understand how things work with the Canvas2D and don't have time to try and use different Caching Strategies (and then rely on the DONTCACHE mode). Truth is the other modes were pretty bugged, they are less bugged now, but I'm not sure it's working the same.
    To solve this matter I'm revamping my whole "Unit Test" project, which was a local thing and not as powerful as it should be. There are so many different combination to test a given Use Case against: the different Caching Strategies, the support of the Instanced Array and with different Device Pixel Ratio values. I have to find time to put a good Unit Test framework and publish the whole stuff once it's done, because I think it will help all of you to discover the many things you can do and how.
    When this will be done then I think I'll start the true "why I did this": a GUI Library based on Canvas2D, with the UI Controls you all are waiting for. The foundation of Canvas2D is getting more and more stable so I think it will be soon the right time to start it and it will be the perfect chance to fix dozen of bugs, I'm sure of it!
    Update #7 from August 13th, 2016 @ Legoland, Billund, Denmark
    The latest fix is a long ongoing one noticed by @FlashyGoblin concerning transparency of Sprite2d. To make a long story short: I mixed up the implementation of AlphaTest and AlphaBlend (aka Transparency), the result were...well ugly...and you couldn't do things like the one FlashyGloblin ran against. So here are the new ground rules about this:
    I try to behave the same way the 3D Engine StandartMaterial does, so people familiar with it will catch things up pretty quickly. One noticeable difference is that useAlphaFromTexture is true by default. There are three render modes: Opaque, Alpha Test and Transparency (Alpha Blend). If you don't use Alpha in a Brush or a Texture and the Opacity is 1, the primitive is rendered in Opaque mode If you use Alpha in a Brush, if you set BaseTexture.hasAlpha to true in a Texture your primitive uses or if the Opacity is not 1, then it will be either Alpha Test if useAlphaFromTexture is false or Transparency if it's true. Beware: until now you didn't have to set hasAlpha for a Sprite2d to deal automatically with transparency, this is no longer the case! With the latest version your Sprite2d will be rendered as Opaque if BaseTexture.hasAlpha is set to false (which is the default value no matter what your bitmap stores).
    To sum up
    Text2d is set as a Transparent primitive to ensure a proper blending. Shape2d based primitives will be either opaque or transparent based on Opacity and Alpha in their Brushes. Sprite2d can use the three modes, the default behavior being Opaque if the texture has hasAlpha to false or Transparent if it's set to true and you can use useAlphaFromTexture to switch to Alpha Test.
    Update #6 from 15 June 2016: babylon.js 2.4 is out!
     
    I took the time to finish the overview/tutorial documentation.
    I also updated the playground and use the BABYLON. prefix everywhere it was needed (which mean I removed the alias like "var Scene = BABYLON.Scene") in order for you the user to copy/paste more easily.
    The documentation entry point is: http://doc.babylonjs.com/overviews/Canvas2D_Home (with all the playgrounds at the bottom of the page).
    The architecture/design doc is: http://doc.babylonjs.com/overviews/Canvas2D_Overview_Architecture
    Please, I've also created a PRO for the Canvas2D feature in Slant, for those who think it's a great addition to babylon.js, please follow this link and upvote, this work is on my spare time so fame is my only reward!   thanks!
    http://www.slant.co/topics/3777/viewpoints/4/~open-source-javascript-3d-engines~babylon-js#15
    Update #5 from 13 June 2016: new features added and also a lot of little bug fixes
    This version is supposed to be the "first official release", there were breaking changes with the previous ones, most notably: You don't use the public static CreateXXX method to create a primitive, you can now use the constructor, the parent is an optional parameter in the settings object (see sample below). At construction you can use a settings object that contains many many properties that you can set as you wish, some are somewhat overlapping (e.g. there's size, width and height, you set either the first or the two latest). This was designed to bring you some flexibility. You won't certainly notice, but the location of a primitive will always be relative to its bottom/left corner, regardless of the origin you set. This change was necessary to bring something coherent and understandable when alignment/layout comes into play. You have to use the actualPosition and actualSize properties to get the "real" values. position/size properties are the value before layout/positioning takes place. New features:
    This new creation mode allows you to cascade the creation of objects (see below). You'll see that Brushes can now be initialized with a string to make the code more simple. The same is true for margin/padding/alignment. You will find example in some playgrounds, doc will come asap. Lines2D now fully support intersection/picking, as well as roundedRectangle. The size of a primitive is now optional, if omitted it will be sized to its content bounding box. (the same behavior as Group2D) Margin, Padding, Alignment is introduced, you can play here. Margin/Padding support units in pixels or percentage, the value can be inherited from its parent or simply be automatic (0) A LayoutEngine feature now allows to position/size the primitive, by default it's the CanvasLayoutEngine that is assigned to all primitives, unchanging the behavior you already know.
    But I've made in few minutes a StackPanel Layout that you can test here (don't forget to CTRL-F5 your web browser to fetch the latest .js file) By the way, there's a new playground for Transparency testing. Update #4 from 03 June 2016: new features added and also a lot of little bug fixes
    intersection works better on Lines2D, I now support every Cap types, it's also accurate on rounded Rectangle (if you click on the empty zone create by the rounding corner it won't generated a hit). interaction mode can now be enable in WorldSpace Canvas, you can take a look at this PG for an example: http://babylonjs-playground.com/#1BKDEO#9 I've also added a alignToPixel property in Sprite2d to make sure the rendering of the sprite will be aligned to the render target device pixel, is ensure the best rendering quality, but in rare case of slow animation you would probably want to turn it off to ensure smooth animation. by default it's on. I won't detail it too much here because it need proper doc to be fully understood, but now you can give your own WorldSpaceNode to render a WorldSpace Canvas on something else that a simple Plane mesh. This mode is easy if you don't use Interaction, but if you do, you have to give a method that compute the world space intersection with your mesh and then compute the local position in the Canvas of the resulted intersection. This is not the simplest method to code but you have an example with the current implem for Plane World intersection to Canvas. Update #3 from 25 May 2016: new features added
    Breaking changes in the API: concerning the way to create Canvas and Primitives, now it's using the same signature than other object in babylons.js, with an options{} json object for optional parameters. There are default value each time it's possible. Including many bug fixes and little features improvements. We have two new primitives: Ellipse2D and Lines2D. I worked hard to dev a nice Lines2D primitive and I hope you will like it! A full Overview Documentation is now online, the main entry page is here: http://doc.babylonjs.com/overviews/Canvas2D_Home, from this page you'll be able to access to every others pages of the overview doc and also all the playgrounds I've made so far. The reference documentation is now online for the 2.4 you will find documentation for about 80% of the Classes/public methods. Update #2 from 19 May 2016: new features added
    Lots of little bug fixes, I hope everything will be ok with the origin property, nesting primitives, the text render is way much better now than before. Interaction is supported! There's an pointerEventObservable property in Prim2DBase for you to be notified about many things concerning interaction with a pointer (mouse, touch, pen). I've also added the support of the ActionManager, it's the same as Mesh and Sprite. I support all triggers exception Intersection and KeyUp/Down. Animation is supported too! You have the animations property in the base class of a Primitive for you to add animation the exact same way you would do for the scene objects. Update #1 from 16 May 2016: added link in the Documentation section to a new tutorial that explains how to write your own primitive types
    Original post
    I am very pleased to announce you a new feature I've been working on for weeks now!
    Well, to put things simply, Canvas2D is...a 100% WebGL 2D Engine!
    It may sound strange at first but I really thought it was missing to this lib, all started from the time I realized I couldn't efficiently display text in babylon.js. So I started to work on a new feature to do so and one thing led to another and I realized we could use of a real 2D Engine for many things!
    It's not related to the HTML Canvas Element at all, Canvas being a generic term (like Rectangle, for instance). I've called it Canvas2D because the main class controlling the feature is called Canvas2D and acts as its name suggest: you can draw 2D content inside.
    For performance reason the rendering is 100% WebGL your graphic card loves to do these kinds of things if you spend the right amount of time to create a good rendering engine.
    Developing such 2D Engine wasn't an easy task because I wanted to lay strong foundations to allow it grows decently through time. Future will tell if I did well or not!
    At last, for a better understanding this features serves the same purpose than Pixi.js, but the intent were slightly different: Pixi.js relies on two rendering engines (HTML Canvas or WebGL Canvas), but the Canvas2D relies only on WebGL, because it's made to be used along with a 3D Scene, which requires WebGL anyway.
    Primary focuses while designing the feature: fast, flexible and hopefully easy to contribute.
    Concerning the "fast" if your device support the WebGL Instanced Array extension, you should be really pleased with the result, the engine was designed to work with this extension (even though if it also works without). I think I overall did well although if there's still room for improvement.
    Basically, how does it work?
    You can create many Canvas2D instance on a given Scene, you have two kinds of Canvas:
    ScreenSpace: the canvas is displayed above the 3D Scene, in 2D space, like you would expect See this example. But there's another interesting mode: WorldSpace:the canvas is displayed in a 2D Rectangle as a part of the 3D Scene, you setup its position, rotation and scale, like a Mesh (well, it's in fact a Mesh of a Plane). See this example. When you want both Performance and Flexibility
    Things get a little technical! When you create a Canvas you have to choose a Caching Strategy. Why? Because depending on what you will do with it you may use different rendering strategies.
    CACHESTRATEGY_DONTCACHE: easy, nothing will be cached, all Group2D are called "logical" and the whole content is redrawn every render. If you have few things or if it always change, you may use this mode. It's also the most stable right now. CACHESTRATEGY_TOPLEVELGROUPS: my favorite! Only Group2D that are direct childs of the Canvas will be cached and considered as RenderableGroup, their children Group will be logical only. If you have some On Screen GUI to display at the different corners of your Viewport, this mode may be the best for you. CACHESTRATEGY_CANVAS: Well, the whole Canvas is put into a cache, you better avoid this if you create a Canvas with the size of the Viewport because a texture/depth buffer will be allocated with the size of the viewport. Note: this is actually the only mode that can be used with World Space Canvas. (the other at the exception of DONTCACHE will follow later). CACHESTRATEGY_ALLGROUPS: this is the most technical one, sound brute force at first, but its the opposite: the most complex one. Potentially every groups are Cached, but in reality for each Group you create you can set a CacheBehavior which states if: The Group follows the cache strategy (then be cached), It won't be cached (then rendered every time) or If it's cached in the nearest Cached group parent. This mode has been elaborate to allow the creation of GUI controls being part of a complex canvas with a lots of Depth and diversity. As for today, this is the least tested one, be indulgent.
    A canvas is made of
    Primitive: this is the base type, has many property like position, rotation (along the Z axis), scale (uniform), visibility, an origin, zBias (if you're not happy with the default behavior), and a list of children primitives. Group2D: to create a new reference of frame, but also if you wish to cache its content, to avoid redraw at every render. If you have primitives that are most of the time static (or changing sporadically, in response of an event for instance) it'll be well advised to cache them to speed up the canvas rendering. Renderable Primitive: as its name suggest, it's a base class for primitive that render to the canvas, so far: Text2D: to display text. Sprite2D: to display a sprite (a part of a texture if you will). Shape2D: another based class for a 2D Shape made of an optional Border and or Fill content. The Border and Fill Content are drawn using a specific type of Brush, for now SolidColorBrush2D and GradientBrush2D are supported. TileBrush2D (so based on a bitmap pattern) should make its way in the 2.5. So far only the Rectangle is implemented, but it does support roundRadius, which is nice. I think I can implement Ellipsis and Circle in no time, but well, I wanted to focus on the engine first. nPolygon, WireFrame should come later. Vectored based graphics (SVG support) should be a nice addition too. Documentation
    The tutorial can be found here.
    An overview of the feature architecture and capabilities can be found here. That's where you'll understand everything you can do and what you can expect in term of performance.
    A long tutorial to explain how to write your own primitive type can be found here.
    Few last things
    My mantra for this feature: by indulgent with the current state of the Canvas2D, but be fearless on the feedback side!
    I will try my best to fix things as much as possible, I've made already some testing, but nothing will replace the impartiality of the user!
    I also have some bugs already logged (like don't try to change the origin of a Text2D, the result will be rather funny...and unpleasant) and will fix them asap.
    Critical features are missing: Group2D and Text2d horiz/vert alignment, more shapes. As well as interaction support through an event system and a better support for animation. I will work on them right away. I don't make promise of what will be there for the 2.4 RTM but I expect everything except animation improvement, really hoping that interaction will make it (edit: also done).
    A big thanks to the core contributors of the lib for their help: @Deltakosh @RaananW @Temechon @jerome and @Sebavan!
    I'm waiting for your feedback!
     
  16. Like
    Dal reacted to Deltakosh in Shadow quality issues/settings   
    @Dal Yes, for 2.5
  17. Like
    Dal reacted to JCPalmer in Skeletal Animation, Picking Info, and Morph Shapes   
    @Dal, the exporter, Tower of Babel, is in the extensions.  Shape key groups for morphing have been done for a while.  Vismes are getting close.  The skeleton interpolator is not operational.  I did use it in a test scene recently.  No skeleton or actual talking, but exercising the FACE & WINK shape key groups.  The Eyes are using a rotation POV animation.
    I have abandoned motion capture in favor of inverse kinetics inside of Blender.  Not sure when this will be done, sorry.
  18. Like
    Dal reacted to fenomas in Why so much idle time?   
    Sure! That's what I do in my game - there are heavy long-running tasks like world generation, and every render or two I start a loop that works on such tasks until 3 or 4 ms have passed. Conceptually I just consider this part of the work being done each frame.
  19. Like
    Dal reacted to fenomas in Why so much idle time?   
    @Dal I believe that's down to how the browser is implemented. Like I said the browser is driving the loop (via requestAnimationFrame), so that's where the decision is being made how long to stay idle. If it was striving for absolute max FPS the browser could send the events more often, but that would likely drain the battery, heat up the phone, and make other operations (scrolling the page, background stuff outside the browser, etc) even slower. So I'd guess it probably just waits some minimum amount of time between frames regardless of how long the previous frame took.
    If you really need to push performance, instead of using the default behavior (rendering from the browser's requestAnimationFrame) you could drive your own loop with setInterval and a delay of 0, or similar. That would probably cut the idle time a bit but arguably it wouldn't be a good default thing to do, for the reasons above.
  20. Like
    Dal reacted to jerome in How do you find the edge of a mesh?   
    another simple fast way CPU side (the simplest actually) :
    if your edge is one of the ground widths : the first subdivisions+1 vertices are on the edge. So, for the whole mesh the first sub+1 and last sub+1 are the edges.
    if your edges are the sides of the ground (the heights) : 
    left side : all the vertices with an index stride of sub+1 :0, sub+1, 2 * (sub+1), ..., (sub+1) * (sub+1)
    right side : the same but starting at index sub : sub, 2*sub+1, 2*(sub+1)+sub, ..., (sub+1)*(sub+1)+sub
    if i''m not wrong 
  21. Like
    Dal reacted to NasimiAsl in How do you find the edge of a mesh?   
    Dal give me  3 days i have a solution but don't know about last fps and i solve picking problem but still physics problem remine
  22. Like
    Dal got a reaction from Xeonzinc in How do you find the edge of a mesh?   
    With the ground mesh I can only set an LOD for an entire chunk. If I have lots of chunks this means a lot of draw calls and bad performance. If I have only a few chunks then I end up with huge parts of the chunk being too detailed and lots of it behind the camera that we can't cull.
    The quadtree approach is meant to deal with that kind of problem, activating and deactivating the vertices that are needed.
    I'm giving that a try, but if anyone has ideas on how to solve that problem in other ways, do let me know   
  23. Like
    Dal reacted to jerome in How do you find the edge of a mesh?   
    well, if your mesh is a ground, it is to say that you know a priori the geometry specifities, it's quite easy to find the vertices on the edge :
    either you can store them when constructing the mesh, either you can guess a posteriori by evaluating the x and z values (knowing it's a planar rectangle) that should be the min and the max among all the vertices
    if you know the width and height, it's even easier because you can know the minX, minZ, maxX and maxZ before starting to compare the vertex values 
    here are the way x and z are computed in the geometry :  https://github.com/BabylonJS/Babylon.js/blob/master/src/Mesh/babylon.mesh.vertexData.ts#L1191
     
    and for a ground built from a heightmap, here : https://github.com/BabylonJS/Babylon.js/blob/master/src/Mesh/babylon.mesh.vertexData.ts#L1191
     the same computation actually
  24. Like
    Dal reacted to Xeonzinc in How do you find the edge of a mesh?   
    Hi Dal,
    As i mentioned before I've got a version which does this based on your continuous terrain approach.
    I've quickly thrown it into a playground- http://www.babylonjs-playground.com/#CEUFD#5  (takes a few seconds to load) A slightly better version: http://www.babylonjs-playground.com/#CEUFD#6
    The shading doesn't seem to be right now I've copied it out my project, but if you look at wireframe you can see the edges, and how the seams have been combined. My method for getting vertices was to loop through and define inner/outer vertices when the different segments were being built. You can see the code, but it's quite long, so ask for any more info
  25. Like
    Dal reacted to Rezoner in Why so much idle time?   
    That's typical for any game not just Babylon.js
    As your game become more heavy on CPU usage the gaps will get smaller.
    Game logic is being called 60 times per second - when the logic frame finishes its work there is not much left for it to do so the program goes idle and waits for the next frame.
    If there were no gaps - it would mean that your CPU can't make it and the game is going below 60fps

    In other words - it means that you can still throw more logic and content to the game because it has free computation power to handle it - which is a pretty good news.