• Content Count

  • Joined

  • Last visited

  • Days Won


jahow last won the day on September 1 2019

jahow had the most liked content!

About jahow

  • Rank
    Advanced Member
  • Birthday 01/01/1985

Contact Methods

  • Website URL

Profile Information

  • Gender

Recent Profile Visitors

2162 profile views
  1. Hey einSelbst, Having worked both with BabylonJS and geo libs such as OpenLayers, I thought I'd drop by to help. What you describe is pretty much what Cesium does: https://www.cesium.com/open-source/ Unsurprisingly, rendering geographic data in multiple formats on a globe with varying LOD etc. is a complex task. Vector tiles for example is a format of data that holds much more than just geometry (it also describes all the geographic features inside of it) and requesting a webservice to stream down data at the appropriate LOD is also a complex task. Geo libs exist because of that. Also you probably won't be able to "slap" a map renderer such as Leaflet on a 3D mesh as the map itself is already a WebGL scene with all kinds of events and stuff going on inside it. To answer your second post, you could theoretically write a custom application that renders a globe and vector features on top of it, based on data received from services such as MapZen. Most geo formats are well documented and you could definitely parse them yourself. The variable LOD thing will make things much more complex IMO. Be aware that you won't receive vector data in the form of a nice series of polygons or lines that you will just be able to pass on to BabylonJS though Geometries can be Polygons, MultiPolygons, LineStrings, MultiLineStrings, Points, MultiPoints, GeometryCollections, polygons can have holes in them, you may have to reproject coordinates... but it is doable for sure. Hope that makes things clearer for you don't hesitate to ask if I was not clear enough.
  2. Hey, Seriously guys, running BJS server side doesn't seem like a proper solution to me. To have decent multiplayer interactions you need to reduce your server code to the barest minimum and only do the precise computations you need. BJS is first and foremost a render engine, so running it on a server by skipping the webgl part seems odd. As stated above, there are libraries on npm that will do a very good job at physics and general math computations (ie vectors). Writing a multiplayer code requires changing the way we think about things. Basically: All the actual game logic runs on the server Clients renders only what the server allows them to, and interpolates and guesses as much as possible between server messages BJS and its physics system can be used to interpolate between game states on the client side (ie avoid choppy movements), and simulate non-critical entities, for example puff of smokes or debris after an explosion. On the other hand, character movements and actions, visibility lists, collisions, player input, all these things must be handled by the server code. For the example given in the OP, the player may very well try to force its position manually and cross the wall, this would simply have no effect at all since the server would only register a "request to move in X direction", register a collision with the wall and prevent the player from moving further. Thus, no change on the visibility list, and no way to interact with the player on the other side. Players can still completely break the way the game renders on their screen (as with every JS application), but they won't be able to mess with the game logic. (sorry, I'm mainly rewriting things that have already been said!) As for handling many users, in my opinion it's all just a matter of optimization. Here are some thoughts that may be useful: reduce the amount of data sent back and forth. Your entities can only rotate on the Y axis? do not send 3 rotation values. Only send simplified input data to the server, i.e. : walk towards X+. Combine data with bitmasks if possible. Buffer data and send them in batch instead of sending too many messages. Do not send data to clients for things that are out of sight or unimportant. An object is moving/rotating regularly and in a predictable way? only broadcast its movement pattern and speed, and update if necessary. Do not send an update for an object if nothing about it has changed since the last time (ie do not resend all entities for every server update). reduce physics computation to the minimum. Use simplified colliders and octrees for spatial subdivision. Your entities are walking on an uneven ground but that is irrelevant to the game logic? just simulate a flat plane and let the clients render entities at the correct height. Not sure if my post helped, but I find this topic very interesting and felt compelled to contribute Also I can't wait to see a true multiplayer game done with BJS!!
  3. Sounds like you have your backface culling turned off for your transparent mesh!
  4. Hey, I'd say that for pure 2D rendering there'd be other engines that would do the job in a simpler way. Using BJS could be beneficial in the following cases: you plan on displaying 3D meshes along your 2D sprites (eg.: a very large character) you plan on using advanced shaders and postprocesses, for example some kind of blur or distortion you plan on implementing some sort of lighting system you just wanna be part of the cool kids Your choice
  5. A solution to this could be: first, render the scene using a special shader that will make the focused object completely white, and the rest of the scene completely black (this used to be called a stencil buffer but I'm not sure this has a meaning nowadays); store this in a frame buffer object then, render the scene again with the post process of your choice, and use the first frame buffer as an input; as you apply the post process, check for the provided frame buffer if its corresponding pixel is white or black: this will tell you if you're currently postprocessing your focused object or not This technique is for example used to render blurred halos around silhouettes (think Left4dead). You'll have to tinker a bit with the engine though
  6. Hey @jodo, I think your question is interesting. Unity is already a very heavy engine and their apps ported to WebGL have all the reasons to be even heavier and bulkier. I think this is almost inevitable when you're "compiling" to javascript from an engine that is not engineered around web apps in the first place. Unity has a core software written in C++ and a system of scripting on top of it, with a serialization system that bridges the two. Try to imagine what it would take to transpose this system in JS... Either a complete rewrite of the C++ engine, or an awkward additional JS layer on top of all this, I really can't tell and feel bad for all the coders that have to work on this mess. BabylonJS is written in javascript and designed for this language, so it will always beat a "compiled to JS" engine in terms of performance and ease-of-use. It's also a remarkably easy to use WebGL framework, so it should do fine for some more time. On the other hand, I think that web browsers will become more and more attractive for game developers. I mean, they probably already are, but the tools are lacking. There are 3D frameworks but they're only doing a part of the job (render, audio, input... admittedly a lot but still) and they're not actual tools, unlike the ones you name in your post. Also, JS is a language that is (I think) not very well known by game developers because not yet used widely in the industry, and also not very fit to be used in large, organized project. Typescript does a better job at this but still, coming from strongly typed, low level languages (i.e. c++) is not easy. Now, think of what gaming in web browsers opens up in terms of possibilities. You're not just running a piece of software that runs on its own or exchanges data with other clients or a server. You're basically opening a window to a virtual universe that is hosted elsewhere. This window can be opened from pretty much everywhere. There is nothing to download, nothing to install, nothing to patch. The whole concept of "software" is pretty much gone. You're only left with the data going back and forth between you and the server. I think that this is amazing in its own right. So, in my opinion, the field is currently clear for new sets of tools dedicated to in-browser gaming. There are already some in development (for example this one that I like a lot: http://superpowers-html5.com/index.en.html), so time will tell who really takes advantage of the new possibilities. I think this is a pretty exciting time That was my 2 cents, use it or throw it
  7. Hey, The convolution & color correction postprocesses will be perfect for that: http://doc.babylonjs.com/tutorials/How_to_use_PostProcesses#builtin-postprocesses
  8. Hey and welcome, If the bright area is centered on the camera, then as chg said: fog + ambient lighting is definitely the way to go. If not, then I think your best bet is writing a custom ShaderMaterial, to which you'll pass the center coordinates of the bright area and then to a nice color fadeoff according to this. Try looking at the docs if you don't know where to start Good luck
  9. To have smoother transparency, set myTexture as the diffuseTexture and opacityTexture of your material. You're currently using 'alpha testing' transparency, which gives off jagged edges.
  10. Hey! Glad to see you made good use of the lens post process! well done and happy new year too
  11. Hey, Sincerely, good luck if you're going with pure WebGL. Just look at the math libraries of BJS and that will give you a slight idea of what you'll need to implement to handle your transformations. You'll also have to handle all the buffers yourself, write code to handle GL states switching and buffering, and everything related to shaders too. BJS does a very good job at hiding all that, but you should take a look at the StandardMaterial code and its associated shaders to have an idea of what it takes to render "simple" shaded geometry. Using a framework or not is always an option, for sure. But if you want to create an actual game, going without one (be it BJS or any other) is in my honest opinion completely unrealistic Good luck with your project!
  12. For your example to be more realistic, you should disable back face culling: http://www.babylonjs-playground.com/#1WIGS8#7 This makes sense as both sides of the objects would retain a fraction of the light that goes through. That is assuming you want your objects to have a "tainted glass" sort of material, such as in the article you linked in the OP. Also, sorting has absolutely no influence in this scene as we're using the multiply blend mode. Let's call A the color of the background, B the color of the wide cylinder and C the color of the narrow one. We have A x B x C = A x C x B. Anyway, I'd be curious to see the end result you're looking for
  13. Hey NasimiAsl, Could you please explain a bit your method for achieving the blur effect ? It sure looks nice, even with a large blur radius!
  14. How about using the multiply blend mode? http://doc.babylonjs.com/tutorials/How_to_use_Blend_Modes Adding an additional rendering category for meshes would require some heavy modification of the BJS core. So, not really feasible in my opinion
  15. This is an absolutely awesome feature. Thanks a lot DK.