Dal

Members
  • Content Count

    182
  • Joined

  • Last visited

  • Days Won

    5

Reputation Activity

  1. Like
    Dal reacted to fenomas in Why so much idle time?   
    The browser sends out an event every time it's ready to display a frame of animation, and Babylon gets that event and renders a frame of animation, then waits for the next event. The fact that there's idle time in between just means the scene is successfully rendering at the target framerate. If you added more stuff to the scene, or more code to be run between frames, it would get done during the idle time.
  2. Like
    Dal reacted to Wingnut in Why so much idle time?   
    Great topic, great answers!
    The Gods of comedy were just SCREAMING at me.... when I read this line:
    Although miserably difficult, I waited for others to seriously answer Dal's questions.  Now, that is done, and it's time for some laughs.
    Dal... every boss, supervisor, and biz owner I have EVER known... says exactly those same words... about their people... seemingly once per hour. 
    When I was in the US Air Force (9 years)... idle time was filled with a bottle of Spray'n'Wipe and a cleaning rag (it was called busy-work).  Maybe we could tell the framework engine to dust, mop and vacuum the scene when it's not rendering. 
    Maybe we should do SETI ops during that idle time.  (Search for Extra-Terrestrial Intelligence) 
    Ok, that's enough simulated comedy.  Sorry for the interruption.  Ok, no I'm not sorry... I'm still giggling.
  3. Like
    Dal reacted to mwpowellhtx in Mesh drag and drop conflict with JS scope GC   
    OKAY!
    So I wondered what else I was missing, and it was the pep script, which apparently got included auto-magically when I pasted code into my HTML test fixture.
    I like capturing the handlers and properties in a self-contained custom object, but all that is secondary to just including the pep script(s) in my jQuery bundles.
    Thanks!
  4. Like
    Dal reacted to snot224 in Nost-Kartrah : Strategy game   
    Thanks for your returns, I will try with Instance and I will be fixed by the best technique
    I've soon finish man model (with some morpher to generate random human model in all unit creation, that morpher will modify only unit and not the model.

    Lets talking about the game,
    each unit have a personal evolution growing by killing or using things. This evolution will be the key to win, because, when unit pass a level, it can be convert to an over kind of unit
    Each party will be different. In the start for all new gamers, it will be very simple, 3 kind of unit can be use, and when he win, new level is unlocked, with new possibilities, and each level have his own advantage.

    This game is a great tournament, to determine the choosen one .... ( Story will be explain later )
     
  5. Like
    Dal got a reaction from jerome in How could BabylonJs possibly be faster ?   
    When working with WebGL you have to keep in mind a few things:
    Javascript is a dynamic language and isn't precompiled to machine code. That means it runs a lot slower than native C++ code as there's more work to do to get it into something the CPU can run and some of the optimizations that C++ compilers can do are not possible. On the other hand, there's no "compile time" involved when working with JS. You can make changes and see them reflected on the screen right away. There's no need to install and compile loads of libraries or dependencies to get it working, it just works in any modern browser.
    WebGL itself is limited - a lot of the more advanced features of OpenGL and DirectX 11 are not available to us yet in WebGL, so we can't always do everything the full-blown libraries can and we can't always get all their optimizations either.
    The benefits though really outweigh that in my opinion. What we lose in runtime speed we gain in development speed and productivity. You can instantly see your results and quickly iterate your changes without waiting for things to rebuild. You don't have to waste time dealing with memory addresses and craziness. You don't need to worry too much about different platforms at all and you certainly don't have to port the code to a bunch of different systems or maintain multiple projects for different targets.  You don't have to worry about different audio drivers or write all your shaders differently for different targets.
    If raw speed is all you care about, WebGL will never be as fast as some C++ engines. But if you only have a small team or are working on your own and you want to build something that can run everywhere, its worth it.
    That said - I am sure there are ways Babylon can still be optimized. There's always room for improvement in any system  
  6. Like
    Dal reacted to NasimiAsl in How could BabylonJs possibly be faster ?   
    Fast or Slow it is not depend for BABYLONJS or any other Engine ! 
    BABYLONJS Like Tools For Make WebGl  So Your last Buffer and Shaders and Texture and 3D Sytems (collision ray cast shadow reflect dynamic postprocess) and Game system (physics SPS .. ) Client Resource (GPU CPU RAM ) can make your result fast or slow 
    you need make this stuffs for make fast
    1. Buffers : make it any low buffer you can have stable scene (texture size + vertex,faces,alpha mode )
    2. Shaders:  you need make it low data communication (less dynamic - less calculate )
    3. Texture : try use in  small than 1024 x 1024  (compress or uncompressed is not matter )  try use (DDS format) and try Use smart Array For Loading (less Ram )
    4.   3D Systems (collision ,ray cast ,shadow reflect dynamic postprocess)  : you need research that all a lot of way to make faster
     5 . Game system (physics SPS .. )  BJS have wonderful Game System just learn how to use it standard way.
    6. Client Resource (GPU CPU RAM ) look your customers clients and choose best (resolution +polygons +(on or off) your unnecessary ) (hd or sd ) and mobile
    7. learn about octree and lod system
    8. move all you can to GPU side 
     
  7. Like
    Dal got a reaction from NasimiAsl in How could BabylonJs possibly be faster ?   
    When working with WebGL you have to keep in mind a few things:
    Javascript is a dynamic language and isn't precompiled to machine code. That means it runs a lot slower than native C++ code as there's more work to do to get it into something the CPU can run and some of the optimizations that C++ compilers can do are not possible. On the other hand, there's no "compile time" involved when working with JS. You can make changes and see them reflected on the screen right away. There's no need to install and compile loads of libraries or dependencies to get it working, it just works in any modern browser.
    WebGL itself is limited - a lot of the more advanced features of OpenGL and DirectX 11 are not available to us yet in WebGL, so we can't always do everything the full-blown libraries can and we can't always get all their optimizations either.
    The benefits though really outweigh that in my opinion. What we lose in runtime speed we gain in development speed and productivity. You can instantly see your results and quickly iterate your changes without waiting for things to rebuild. You don't have to waste time dealing with memory addresses and craziness. You don't need to worry too much about different platforms at all and you certainly don't have to port the code to a bunch of different systems or maintain multiple projects for different targets.  You don't have to worry about different audio drivers or write all your shaders differently for different targets.
    If raw speed is all you care about, WebGL will never be as fast as some C++ engines. But if you only have a small team or are working on your own and you want to build something that can run everywhere, its worth it.
    That said - I am sure there are ways Babylon can still be optimized. There's always room for improvement in any system  
  8. Like
    Dal got a reaction from Boz in Geo-Clipmapping Endless Terrain (contribution)   
    Hi all,
     
    I've managed to implement a geo-clipmapping terrain for Babylon
     

     
    It is based on the awesome writings of Florian Bösch (https://github.com/pyalot/webgl-lacr), and Jasmine Kent (who uses Florian's method and explains it nicely here:
    http://www.gamasutra.com/blogs/JasmineKent/20130904/199521/WebGL_Terrain_Rendering_in_Trigger_Rally__Part_1.php
     
    In theory this kind of terrain is really good for WebGL, because it puts most of the work onto the GPU and it allows very large terrains.
     
    My implementation isn't quite right at the moment though and I hit a few snags trying to implement it in Babylon:
     
    1) Florian's implementation uses non-indexed meshes and triangles. I figured out how to create the same shapes needed using Babylon mesh functions, but I am sending waaaaay more data to the GPU than Florian does. 
    2) I also struggled with other issues like how to give the different meshes their own materials/settings without creating a lot of duplication.
    3) I'm not sure I am using all the settings correctly... I'm finding it hard to get good looking results.
    4) The mip levels really don't seem to be working properly
    5) The detailing is definitely not right either
     
     
    I think I've come about as far with it as I can with my understanding of Babylon... but I am hoping some smart people in this community can help me fix it / finish it
     
    Source code is at: https://github.com/darrylryan/BabylonTerrain
    Live demo is here
     
  9. Like
    Dal got a reaction from Xeonzinc in Questions about large worlds with Babylon.JS   
    I think we should form a project group on this to make an awesome terrain system for babylon. Its something very much needed for lots of games, but its also maybe not something on the immediate roadmap for the core devs, so its a good thing for us to build together as a community I think.
    Before I start a new system though I am very interested to see what results @NasimiAsl will achieve. It looks interesting so far and he's certainly very smart
  10. Like
    Dal got a reaction from Boz in Questions about large worlds with Babylon.JS   
    I think we should form a project group on this to make an awesome terrain system for babylon. Its something very much needed for lots of games, but its also maybe not something on the immediate roadmap for the core devs, so its a good thing for us to build together as a community I think.
    Before I start a new system though I am very interested to see what results @NasimiAsl will achieve. It looks interesting so far and he's certainly very smart
  11. Like
    Dal reacted to Deltakosh in Why the 4 light limit? [EDIT: Limit has been increased!]   
    @dal: babylon.js turns light off according to inverse creation order  
     
    just create the sun first and you're good!
  12. Like
    Dal got a reaction from eboo in Questions about large worlds with Babylon.JS   
    I think we should form a project group on this to make an awesome terrain system for babylon. Its something very much needed for lots of games, but its also maybe not something on the immediate roadmap for the core devs, so its a good thing for us to build together as a community I think.
    Before I start a new system though I am very interested to see what results @NasimiAsl will achieve. It looks interesting so far and he's certainly very smart
  13. Like
    Dal got a reaction from Wingnut in Why the 4 light limit? [EDIT: Limit has been increased!]   
    Well, it would have to be a bit smarter than that... shadowColor would just mean our trees will shine a tree-shaped light onto the ground beside them. We need to invert the shape.
    The way I would probably attempt it (with no previous knowledge of this kind of thing) is to create a sphere around the light which has its area of effect, then apply light to the lightmaps of all objects that fall inside it, and subtract the shadowmap from it.
  14. Like
    Dal reacted to Wingnut in Why the 4 light limit? [EDIT: Limit has been increased!]   
    Oh...  you mean... the houses/buildings cast light through their windows?  ohhh.  Sorry.  Yeah, an inverse shadow map...  interesting.  A pointLight inside the building, shining through a tiled window, would make tile-shaped brighter-spots on the ground outside.  Yeah, that would be... something to behold.  Good idea.  Well, an interesting idea... kind of scary.  heh
    Would .shadowColor do it?  I don't think it exists, but maybe.  Or, as you suggested... a lightShadowRendererThingy.  Silhouetter v1.0 
    "anti-shadow"  haha.  Good comedy, but good description, too.
  15. Like
    Dal got a reaction from Wingnut in Why the 4 light limit? [EDIT: Limit has been increased!]   
    No, I do mean cast lights... if you think about it, in your streetlight demo, a pointlight really just draws a circle of light onto the ground. Its kind of like casting an anti-shadow
     The pointlight shadow mapper works out all the areas that should be dark and draws it to the shadow map. I'm wondering if its code could be hacked so that it just makes everything lighter that is within its radius, EXCEPT the shadow area.
  16. Like
    Dal reacted to Deltakosh in Why the 4 light limit? [EDIT: Limit has been increased!]   
    So it could be cool to have an automatic lightmapper, I agree:) need to add it to our roadmap
    But so far, you can already have some kind of light manager: every light has a range. Objects outside the range are automatically removed from light influence list. So you can have dozens of lights. As long as you limit the range, this could work 
  17. Like
    Dal reacted to Deltakosh in Why the 4 light limit? [EDIT: Limit has been increased!]   
    @jerome: the perf cost is inside the shader unfortunately. The only way to freeze it is with a lightmap
  18. Like
    Dal reacted to Wingnut in Why the 4 light limit? [EDIT: Limit has been increased!]   
    Hi guys.  Sorry to butt-in, but I had to show Dal my stupid streetlight demo. 
    Maybe the important thing to note... is that each white circle on the roadway... is a texture on a plane... blended with the roadway material beneath.  Take note that I made this demo LONG before I knew anything about textures, so I just blindly activated everything until it worked.  I'm sure there are many wasted properties set on my "light circle" material.  The main thing is... I got it done.  I faked 15 lights on a single material... and without any baking or lightmap crap.
    Let's pretend a hallway in a fancy hotel... gaslights lining the walls... a nice patterned wallpaper.  You could use my "white-out" circle on the walls behind each gaslight.  Then add a single REAL directional light... parented to the player.  Then, as a player passes the gaslight, you light-them up with the directional light that they are actually carrying with them. 
    See how my box lights-up as it passes under the street lights?  Pure fake, baby.  The light that lights the box... is carried by the box.
    BUT... my roadway is NOT a paisley print wallpaper.  SOME testing would need to happen... to see how well the wallpaper pattern behind the gaslights... would show-through the white circle.  Sure, the white circle over-layed texture could be bright enough to "wash out" the wall paper pattern.  But, in reality, the wall paper pattern SHOULD remain somewhat visible, even with the white circle texture layered atop.  Fine tuning. 
    I LOVE foolery, don't you?    All in all, I just wanted to give you some other options to think about.  There is another user who is/was grappling-with multi-lights, recently, too.  His forum thread is right here.  Good light discussions went-on in that thread.  Be well!
  19. Like
    Dal reacted to davrous in My new blog with a cool animated WebGL banner using babylon.js   
    Hi!
                  During my vacation, between 2 games playing Ori and the Blind Forest, I’ve been enjoying to setup my new blog: https://www.davrous.com
                  Based on WordPress, hosted on Siteground, I’ve customized the Oblique theme to use Flexbox rather the strange dynamic layout computation and fix a lot of layout issues to support all browsers. The worst browser to support was definitely Chrome. MS Edge and Firefox was very cool. It was because of the complex oblique layout using SVG elements. I had a couple of issues with srcset on Firefox but seems to be fixed now.
     
                  Last but not least, I hope you’ll enjoy the cool animated WebGL banner (using our lovely Babylon.js of course! J). This one was fun to build also. Getting the resource from the HoloLens Galaxy Explorer open source project, converting them to Babylon.js using our Unity exporter, placing the WebGL planets on top of the background image using a transparent canvas and simulating a background-size: cover behavior by code. You can check my code via this sample: http://david.blob.core.windows.net/babylonjs/banner/coversim.html
     
                  The interesting part is there:
     
                  function resizeToCover() {
                var currentWidth = myHeader.offsetWidth;
                var currentHeight = myHeader.offsetHeight;
     
                var scale_h = currentWidth / canvas_w_orig;
                var scale_v = currentHeight / canvas_h_orig;
     
                var scale = scale_h > scale_v ? scale_h : scale_v;
     
                canvas.style.width = scale * canvas_w_orig + "px";
                canvas.style.height = scale * canvas_h_orig + "px";
     
                canvas.style.transform = "translateX(-" + (scale * canvas_w_orig - currentWidth) / 2 + "px)";
     
                engine.resize();
            };
     
                  Could be useful if you’d like to do something similar.
    Cheers,
    David
     
  20. Like
    Dal got a reaction from jerome in Questions about large worlds with Babylon.JS   
    I think what you want is just an evolution of the same basic concept...
    You can use multiple "octaves" of noise and layer different noise algorithms and erosion algorithms on top of eachother at different scales etc. until you get something that looks natural. As long as all the algorithms are seed/input based the result is predictable and constant. You could then mix that with image textures that use different colours/shades to map out the different regions and biomes...
    You could just have a map with the mountainous areas drawn in red and the desert areas drawn in green for example, then you convert the world coordinates to texture coordinates and pick the colour in the shader... then based on what colour you get you multiply the values of the noise to make it more or less bumpy, maybe clamp it or multiply with other sorts of texture that cause different kinds of features to appear etc. etc.
    Its really hard to get natural looking noise and features though and its computationally expensive. You need to combine loads of algorithms and really tweak it for hours using trial and error to see how it looks and trying to do it in realtime can really hit performance. Most people just use existing software tools like Terragen to generate nice terrain height images as its a lot easier and gives better looking results.
    Personally I think hand-sculpted terrains look much better. Procedural generation is great but in practice it tends to lead to huge, boring landscapes that aren't fun to explore. As with most things in computer games, we can't really put in the scale and detail of real life so we have to make things smaller and more exaggerated. Doing that in a way that looks good and plays well really requires an artist's touch and a lot of thought about the flow of the game and how the player will progress from different towns, regions, biomes etc. 
    I just want to create a huge paged terrain that will let us sculpt a nice looking terrain ourselves, but using things like erode tools and heightmap stamp tools to help the process.
  21. Like
    Dal reacted to snot224 in Nost-Kartrah : Strategy game   
    Hi all,
    here is a topic to talk about a game I started some months ago but due of many reasons (Works, Family, ....) , still in progress, but I really want to finish it.

    It's not yet playable online, but I will put contents here to show my work.
    Sorry for my english, I'm french, and not very good to do long speeches.

    Here some current pictures of this game.

    Here you can see the interface, the logo, the menu when you select the house all in the left. In the right, the house and the Castle for buildings, and 3 kinds of units.

    Here you can see loading panel, and 2 connections in same time (2 players)
     

    And here the chat panel to talk with over poeple inside the game. All in real time.
     

    I will put movie soon to let you see fonctionnalities...

    Next step is to put some trees, grass on the floor, rocks.
    Do you have some idear for the grass ??? I see something like fur material, I will try to see if it's workable with my ground.

    Thanks for waching.

  22. Like
    Dal got a reaction from jerome in Questions about large worlds with Babylon.JS   
    Well that's easy... you just need to either:
    a ) Use image files and load the same image each time you visit the same tile (you can modify the image file just by drawing shapes and brush images onto a 2d canvas and saving it out... either painting manually or by code).
    b ) More commonly, use a noise function such as perlin noise or simplex noise. These will take a seed number as a parameter and as long as you always use the same seed, they will always generate the same height data at the same location when you feed in the same x,y coordinates.
  23. Like
    Dal reacted to Xeonzinc in Questions about large worlds with Babylon.JS   
    RE: seams
    I've been working recently on a terrain system using the same theory behind Dal's 'Endless Terrain' from Nov last year. One of the the differences being it allows for non-power of 2 LOD levels, and has varying LOD levels sizes even within the same segment to increase the flexibility. This has meant developing a re-usable method to remove the seams between different LOD levels, which works by essentially duplicating all vertices on both sides of the seam (and with a lot of code....). This is almost in a usable state so should have something to share soon, and could easily feed into a chunk based system. (also agree with josh/Dal on the example above, it must be the heightmap data if the vertices are perfectly aligned).
    Does anyone have a robust 'chunking' terrain system we could add the LOD onto? With the right system is should just be a case of replacing 'createGroundFromHeightMap' with a version of the new function i'm creating. It sounds like what you have Josh may be similar that, although we are replacing the same function so may need to merge them somehow!
  24. Like
    Dal reacted to fenomas in Questions about large worlds with Babylon.JS   
    @Dal Is the time being spent in mesh selection, or elsewhere?
    In my scenes so far selection is usually the issue, but that's partly because I add chunks in a sphere around the player, so the number of meshes grows as distance cubed. If you're only doing a ground mesh then of course it'll grow as distance squared, and scale differently.
    As for vertices, in my scenes like the demo I linked, a typical chunk has 1000-2000 vertices.
  25. Like
    Dal got a reaction from Boz in Questions about large worlds with Babylon.JS   
    I've been doing a lot of work with large terrains lately. I've had trouble with getting anything that runs fast. My voxel approaches with dual marching cubes and dual contouring don't run too well on mobile devices.
    @joshcamas has the best approach I've seen so far (are those editor tools open source?)
    I think we need to implement a proper LOD terrain using quadtree/geomipmapping to get really good big terrains in Babylon. Does anyone have any interest in working with me on it?