The Leftover

Members
  • Content Count

    98
  • Joined

  • Last visited

  • Days Won

    2

Reputation Activity

  1. Like
    The Leftover got a reaction from Deltakosh in Text as polygon mesh   
    Thanks for telling me everybody moved.  I would have been a shock to return to the old campsite and discover a cold fire pit and a note.
    I enjoyed reading the latests posts.  Ya'll are really crazy.  I forgot.
  2. Haha
    The Leftover got a reaction from Wingnut in Text as polygon mesh   
    Thanks for telling me everybody moved.  I would have been a shock to return to the old campsite and discover a cold fire pit and a note.
    I enjoyed reading the latests posts.  Ya'll are really crazy.  I forgot.
  3. Like
    The Leftover got a reaction from Veksi in Rendering another WebGL canvas on BabylonJS canvas: geographic data visualization with MapBox GL and deck.gl   
    Three views of Baltimore, MD, with different CSS declarations.

  4. Like
    The Leftover got a reaction from Deltakosh in Rendering another WebGL canvas on BabylonJS canvas: geographic data visualization with MapBox GL and deck.gl   
    Three views of Baltimore, MD, with different CSS declarations.

  5. Like
    The Leftover got a reaction from ssaket in Rendering another WebGL canvas on BabylonJS canvas: geographic data visualization with MapBox GL and deck.gl   
    Three views of Baltimore, MD, with different CSS declarations.

  6. Like
    The Leftover reacted to Wingnut in Text as polygon mesh   
    That shader code was stolen from the amazing CYOS (create your own shader) editor...  https://cyos.babylonjs.com/
    Default shader for CYOS.  Ain't fake-chrome PRETTY? 
    I used the ZIP option in CYOS, to insert that shader code into a giant string, and bring it home.  Then I took the shader-code string and inserted it into a playground... for use in the BJS ShadersStore-method of storing shader code (which is the same method that the zip from CYOS uses).  I think there are about 3-4 other ways to store shader code.  One, is within files. Another... within an HTML script element, and also ShaderBuilder can store it in JS... in little pieces/values... and assemble/compile it at scene run-time or whenever needed.
    I THINK... a more-standard reflection-texture can be used instead-of a shader, and can look/act exactly the same chrome-like way... IF we correctly set the reflection-texture parameters, and maybe the texture's "coordinatesMode".   But also... I think the "addressMode" used for texture wrapU, wrapV, and wrapR... is pertinent, too. 
    In THIS effect, the reflection is mega-important.  These advanced texture settings... aren't well-understood by noobs like me.  We probably need a PBT (playground-based tutorial) to teach these advanced texture things.  uv(w) offsets, scales, angs, wraps, and coordinatesModes... the big 5 "weird" texture knobs. 
    Wraps and coordinatesModes... being the weirdest.  Those 2 set which part of the texture to clamp (glue) to which part of the mesh, and which areas are allowed to stretch or compress, as best I know/can explain.  The mesh's UVs are involved, too, if they are present.
    Yep, these meshWriter fonts/words/sentences... have a whole lot of reflection experiments that need to be performed/tested.
    Add-in another camera used to generate a renderTargetTexture (rtt)... put chrome words in front of it, and then use ITS texture on a different single-word mesh!  OMG!
    For example... a child learning a word.  The word sits in front of them... in big fat fonts... and in the reflection of the word's texture.... sentences are slowly scrolling-thru... showing the word properly used in example sentences.  SO COOOOOOL! 
    Further down the line... I believe .moveWithCollisions() works on letter shapes.  Sooo... letters of a word... can bump into each other, and that can open-up a whole new world.  AND... Jerome has basic SPS collisions already happening somewhat... without a physics engine (actually, with his own basic SPS physics engine). 
    And there's scaling...  making each letter of a word or word of a sentence... go squatty'n'wide, then tall'n'thin, back and forth, as it bounces along on the rolling plains.  Nice.  There's some serious (comedy) options for making text dance and sing, here.
    In a way, we are talking about meshWriter "behaviors" here, similar to camera behaviors.  Or perhaps... array-of-mesh behaviors.  For example... scale wide and squatty, then scale tall and thin, back and forth at some rate and some limits... is a "behavior" that can work on ANY array of mesh, not only a "group" of meshWriter characters or words.  Many of @jerome's demented SPS experiments... could be considered SPS "behaviors", too, yes?  It really depends upon how flexible we want to be... with the term/definition of a "behavior".
    So... we probably need to think about IF/NOT... meshWriter behaviors... and general array-of-mesh behaviors... are the same thing.  Or... AT LEAST the two things might inherit from the same base class... should we decide to try array-of-mesh behaviors AT ALL.  In a way, this is "advanced choreography", which will LIKELY involve the BJS animation system, AND might also apply to array-of-lights and to cameras, too.  Scene.actionManager.choreographyManager ...  v1.0    Not used too often for games, but instead... for shows and mesh parades.
  7. Like
    The Leftover got a reaction from Wingnut in Text as polygon mesh   
    Your Wingnut has now returned to an age-appropriate profile.
  8. Haha
    The Leftover got a reaction from Wingnut in Text as polygon mesh   
    Wingnut thanks for caring (heart heart heart).  (I am working on being more emotive.)
    This must have emerged with the new release.  It also appears in the playground of record,  https://www.babylonjs-playground.com/#PL752W#1  Some sandpaper outa do it.  Back soon.
  9. Like
    The Leftover got a reaction from JohnK in Illuminated City   
    Hello coders and countrymen,
    I have continued the labor with Illuminated City in ways that are not nearly geeky enough for this forum.  I have, for example, spent hours with crime analysts for San Mateo and Santa Clara Counties.  (You know, stay close to the target user.)
    One request was the ability to take crime data from multiple geo-adjacent cities and put it onto one display.  Oddly enough, crime does not stop at administrative boundaries.  And cities are utterly incompetent at unifying data-anything.  Did that.
    Another request, only partially complete, is to be able to observe a "patrol waveform" and compare it to the "crime waveform".  The goal would be to help place patrols more effectively.  Patrol presence reduces crime.  It's a challenging problem; I will discuss another time.
    Finally starting to take specific steps to create buzz.  This might include creating consternation on the way -- this is crime after all.  My first blog post is 90% complete and I am itching to show it to someone.  Tag.  You're it.
    http://blog.illuminated.city/
    Maybe 85%.  Anyway, almost there.
  10. Like
    The Leftover got a reaction from jerome in Illuminated City   
    Hello coders and countrymen,
    I have continued the labor with Illuminated City in ways that are not nearly geeky enough for this forum.  I have, for example, spent hours with crime analysts for San Mateo and Santa Clara Counties.  (You know, stay close to the target user.)
    One request was the ability to take crime data from multiple geo-adjacent cities and put it onto one display.  Oddly enough, crime does not stop at administrative boundaries.  And cities are utterly incompetent at unifying data-anything.  Did that.
    Another request, only partially complete, is to be able to observe a "patrol waveform" and compare it to the "crime waveform".  The goal would be to help place patrols more effectively.  Patrol presence reduces crime.  It's a challenging problem; I will discuss another time.
    Finally starting to take specific steps to create buzz.  This might include creating consternation on the way -- this is crime after all.  My first blog post is 90% complete and I am itching to show it to someone.  Tag.  You're it.
    http://blog.illuminated.city/
    Maybe 85%.  Anyway, almost there.
  11. Thanks
    The Leftover reacted to jerome in SPS Optimization : Feedback Wanted   
    Thanks to all of you for this important and fast feedback.
    This has showed that the SPS code refactorization has the very same results whatever the OS or the device :
    - huge gain in Chrome from +25% up to +100% speed
    - relative loss in Firefox, around -15%  (please FF devs : why ???)
    - no impact or very small gain on the other browsers
    The PR will be merged soon. All credits and congratulations to its author : @BabarJulien
    The relative perf loss in FF doesn't really matter. Indeed the demo you've tested is a stress test, an extreme scene that users usually don't build : 20K or more solid particles are hardly visible when set apart from each other in the screen area. A good practice is too manage less solid particles and to worry only about those visible in the frustum by recycling them.
  12. Like
    The Leftover got a reaction from jerome in Web Assembly   
    Dang dude!  You stuck it through.  Slings, arrows and coral reefs.  Impressive.
  13. Like
    The Leftover reacted to jerome in Web Assembly   
    Hi guys,
    Here's my first real WASM test : http://jerome.bousquie.fr/BJS/test/SPSWasm/spsWasm.html
    Caution before clicking on the link : it's a very big SPS with 40K solid particles, this could freeze your browser. I'll report more precisely about this experiment here :
    About WASM itself :
    I generated the WASM bytecode from some code ported from TS to AS, AssemblyScript . If the logic is quite simple to port from TS to AS (because the syntax is almost the same, just add strong types like "f32", "u32" instead of "number"), the shared memory access (shared between the JS main program and the WASM module) is really complex and painful. Indeed, WASM knows only very basic numeric types only : i32, u32, f32, f64, etc and nothing about more complex structures like strings, arrays, objects. It's really low level and we have to deal with pointers and offset to pick/store the data at the byte level directly in the memory.
    Note also that there's no garbage collector. This means that creating any "object" (array, instance of a class, each time we type the word "new", etc) in our logic will require to manually free the dynamically allocated memory to prevent memory leaks. Moreover WASM doesn't provide any math library, so no trigonometry at all (sine, cosine, tan, everything required for 3D computations actually), so we have to implement by ourselves, say, the function sine.
    In brief, for a developer coming from a productive high level language, despite the help of the easy syntax of AS, it's a jump back in the past because the way to code it right looks more like some the C or the assembly way. Indeed, the first version of this code, very TS-like, very twice slower than this more low-leveled published version.
    You can get the AS source here : http://jerome.bousquie.fr/BJS/test/SPSWasm/index.ts    [EDITED]
    That's said, what about the gain ?
    Here are different versions and the FPS in my Chrome :
    Legacy SPS   - 8 fps : http://jerome.bousquie.fr/BJS/test/spsReference.html 
    Reference Buffer SPS - 7 fps :  http://jerome.bousquie.fr/BJS/test/spsBuffer.html  fun to see that now the legacy SPS what has been optimized is faster than the lighter buffered one
    WASM SPS -  31 fps : http://jerome.bousquie.fr/BJS/test/SPSWasm/spsWasm.html  it's the port of the Buffer SPS in AS
    perfs gain = x 4.42    ... not that bad, finally
  14. Like
    The Leftover got a reaction from JohnK in Text as polygon mesh   
    I see no error right now.  The Illuminated City certificate is valid and has not been changed for more than a week.  It is provided my GoDaddy and the site is hosted by Amazon.
    HOWEVER.  I get that error intermittently on all kinds of sites, myverizon.com, facebook.com, nytimes.com.  For the past six months, it would appear, rarely and briefly, and then disappear.  I assumed it had something to do with my crappy ISP or Russian hackers.  (NY Times had a DNS attack that lasted 18 hours.)
  15. Haha
    The Leftover reacted to Wingnut in What's next?   
    Hey, thx for the setInterval idea, DK & Lihis (in pm)
    MeshWriter is still being discovered, @The Leftover!  Does it need some WD-40?  Is it getting rusty?  How many future hi-tech-looking advertisements and game intros... will fly-into-view text like... "From the Makers of Serious Sam..." (you know, big chrome fonts... big music, lots of hoopla)?  Lots to come.
    Using webGL for those "holy crap" game intros and company ads... is just getting started.  No video, no rendering farms, just big chrome-like meshWriter words... smacking users in the face... with blasts of sparkly particles and camera shakes!  BA-BOOM... from the makers of Lite Brite...  BA-BOOM... comes a game SO amazing...  BA-BOOM... that you will forget to pee!
    All of it, in real time.  No video.  No post-processing or rendering.  It's easily usable on standard webpages (html5 canvas), without a flash player, without a video player, without a Java applet.  Just good ol' webGL (with BJS easifier) producing a screen full of dazzle.  Love it.
    Aren't ya kind of tired of media players fighting over who gets to be "your one-stop media playing app"?  That fight has been going-on for 25 years.  Realplayer, WinAmp, Win Media Player, VLC, BSPlayer, KLite CoDec packs, on and on.  Time to wave the white flag and eat some webM and drink some OGG.  (What did he say?)
    WebGL.  YUM!  Versatile, powerful, and easy.  With enough flashing lights, sparkly particles, and chrome-coated fonts/words, we can do some SERIOUS hoopla.  Add a little John Phillip Sousa music, and we got us a parade!  YAY!
    Probably smarter to fly the camera into the words, instead of the words into the camera.  Looks the same in the end.
    Nah, meshWriter better not go anywhere, in case you were thinking of moth-balling it.  Its very bright future is sure to arrive.  It helps if you remember the days of "cracking screens" and the competitions to see who could do the best "TA DA!" hoopla.  Websites will be introducing themselves similar to movie intros/trailers... more and more.  I promise.    Flying 3d fonts have a big future, I suspect.  Wait for the 2nd and 3rd "wave" of webGL fanatics to arrive, and then look at your usage stats.  You'll have 100 emails per day of feature-add requests... friggin' puppy stampede.  heh.
  16. Like
    The Leftover got a reaction from jerome in Web Assembly   
    Jerome, if I am belaboring the obvious, sorry.
    I only have one copy of the data structures.  It is shared between WebAssembly and Javascript.  If you look at the code (from my August 3 post above) you will see that I create the array as WebAssembly memory.  Then I create a view into that memory.  Javascript or WebAssembly both may address the array at that point.  As far as JavaScript is concerned, it is just a typed array.  This array is sized/created early in the session and tends to persist for quite a while.  In fact, sometimes I clear the array and start over; as opposed to allocating a new one.
    To drive the point home:  Sometimes I write the same function in JavaScript and WebAssembly.  More specifically, I have already written it in JavaScript and it is working.  When I develop the WebAssembly, I set it up so that I can call either "flavor" of the same function.  Given that I don't have a battery of test suites, this helps me spot unintended changes of behavior.
    Once I get things settled, smaller interactions with the array are usually done through JavaScript.  Larger ones are done with WebAssembly.
    After all of this, I am happy with the effort.  I did hit many dead ends but I also got several large tasks to run 3X faster.
    I hope this is useful.
  17. Like
    The Leftover reacted to jerome in Web Assembly   
    About ComputeNormals(), I agree it's a good candidate.
    First note : usually, unless you're dealing with an updatable, then morphed, mesh, you don't need to recompute the normals each frame.  But it's still a good candidate for a WASM computation, especially when the mesh needs to be morphed.
    The current implementation of ComputeNormals() has been optimized many times over its life (check old forum posts about this topic)... and I'm the culprit 😄 . Actually there are parts of the ComputeNormals() code that are conditional and used only for the feature FacetData, because they use the very same algo on the same data. So it's faster to compute the normals and the facetData in the same time than to do this big loop twice. But you can just ignore the facetData part if you want to focus on the normal computation only.
     
    About my first test with WASM, I did like you : I used only TypedArray. Actually one big TypedArray in to pass the data to the WASM module and a big TypedArray out to get the results back from the module. 
    But, in order to focus only in my own logic, I also used the library wasm-ffi : https://github.com/DeMille/wasm-ffi
    This library handles for you all the TypedArray/ArrayBuffer exchanges between the AssemblyScript code and the WASM module. I should probably get rid of it and manage the data passing/sharing by hand to be sure it happens like I really want.
    At last, WASM and workers are compatible AFAIK because modules are objects that can be passed to a worker, then be instanciated in the worker itself. So, although it's probably hell in terms of data exchanges and memory sharing (main thread sync/to/from/ the workers, each exchanging with their own WASM module), it's also maybe (theorically) what could bring a huge performance gain.
  18. Like
    The Leftover got a reaction from jerome in Web Assembly   
    Jerome, delighted to read your report.  This FYI:
    I had done some profiling of Illuminated City and determined that speeding 'VertexData.ComputeNormals' would be a win for my application.  It is a good candidate in other ways, being about 200 lines of vector arithmetic (with two calls to Math.sqrt).  I had considered rewriting it in native WASM but quickly realized that I did not understand application well enough.
    Also, there were a bunch of boundary issues:  it deals with multiple arrays that - I think - were not typed.  Converting typed <--> untyped is gonna add a lot of overhead.  Also, the only way I know how to process multiple arrays in a single WebAssembly module is to put them in one array and use indexed addressing.  I do this for my own application but it is a hefty bunch of work.
    At the end, I did not.
    'VertexData.ComputeNormals' is an example of a function that I would optimize the hell out of in JavaScript first.  Good chance that is a win.
    Here is my only actual concrete suggestion, respectfully placed from someone who doesn't really understand your code:  Migrate to typed arrays for the obvious suspects, like uvs and normals and so on.
  19. Like
    The Leftover reacted to jerome in Web Assembly   
    Quick feedback about some first tests : a big loop computing all the vertices (rotations, translations, scalings) of a modified SPS in a WASM module.
    For now, the results are quite ... disappointing :
    1) even by using a cool language, AssemblyScript, to emit WASM bytecode at quite no porting cost from TS, the way to manage the exchanges between the JS code and the WASM module is painful. Not even speaking about the lack of a garbage collector WASM side what forces to give a particular attention to every object creation.
    2) WASM, although being a bytecode usable in the browser (we could expect some features like other bytecode based languages like Java can provide) doesn't provide any math functions ! This means we have to implement by ourselves, say, all the trigonometry (sine, cosine, etc). How can we compute any 3D rotation without sine or cosine ?
    3) the first global execution on the same basis than the SPS experiments is ... slower than the full stack legacy SPS !
    I'll profile and tweak the WASM code soon in the hope to get something faster. But for now, it's not worth it at all... unless I'm missing something.
  20. Like
    The Leftover reacted to jerome in Web Assembly   
    I agree : calling small wasm functions could be slower than using the same algo inside the JS process, because of the memory access and the entering/existing.
    I think that the gain and the power of wasm could be real when dealing with few calls of wasm functions treating large amounts of data at once (some kind of batch computations) : big loop with huge iteration numbers, big float arrays (meaning over 10K elements to treat), etc
    Example : CPU particles, culling (if it were batched : one process for all meshes at once), SPS, WM computations of instances (idem, if it were batched)
    Most of the BJS functions are already very fast and quite short, they won't probably get no gain at all  to be translated to wasm as is. 
  21. Like
    The Leftover got a reaction from JackFalcon in Web Assembly   
    The heartbreak of today was that the module I snipped this from runs faster in JavaScript.  In other areas, I have reaped a 3x speedup with WebAssembly.
    I believe that issue is that there is substantial overhead in entering and exiting WebAssembly.  You want the work it does while there to be large enough to make up the overhead and still give you a win.
    Gonna go soak my head . . . 
  22. Like
    The Leftover got a reaction from JackFalcon in Web Assembly   
    Jerome, thanks.  I usually do something like this.  I create a module config object, and attach the memory there.  This hands in whatever settings are needed and the memory.  Now both JavaScript and WebAssembly can access the same typed array using 'hexlatticeMemoryView' and 'i32.load'/'i32.store'.
    I treat the WebAssembly module as a persistent "closure".  Some of them have four or five function entry points.
    JAVASCRIPT JAVASCRIPT JAVASCRIPT JAVASCRIPT JAVASCRIPT hexlatticeImportObject = { settings : { weekbreaksLength : weekbreaks.length*4, weekbreaksStart : 16, monthBreaksLength : 0, monthBreaksStart : 16+weekbreaks.length }, imports : { log : console.log } }; hexlatticeMemory = new WebAssembly.Memory({initial:1}); hexlatticeMemoryView = new Uint32Array(hexlatticeMemory.buffer); hexlatticeImportObject.imports.mem = hexlatticeMemory; JAVASCRIPT JAVASCRIPT JAVASCRIPT JAVASCRIPT JAVASCRIPT WEBASSEMBLY WEBASSEMBLY WEBASSEMBLY WEBASSEMBLY WEBASSEMBLY (module (import "imports" "log" (func $log (param i32))) (memory (import "imports" "mem") 1) (global $weekbreaksstart (import "settings" "weekbreaksStart") i32) (global $weekbreakslength (import "settings" "weekbreaksLength") i32) WEBASSEMBLY WEBASSEMBLY WEBASSEMBLY WEBASSEMBLY WEBASSEMBLY  
  23. Like
    The Leftover got a reaction from JackFalcon in Web Assembly   
    Gentlemen, thank you for the links.  Let me some opinions base on three days of work.
    I started writing in straight WAT.   Because I have a genetic defect that causes me to do things the hard way.  However, it has caused me to learn a lot of things.
    WebAssembly is at the "MVP" stage as they call it.  One can only create a module with functions below that - two levels.  One can create a list of which functions may be exported.
    The MVP status shows:  I couldn't figure out how to make a module-global variable that was mutable; so I did a work-around.  One can share a typed array between JS and WA.  In WA, it is called "memory" but there may only be one of them.  I redesigned things a bit so all processing was applied against one array.  This could put a crimp in my style.
    Is it possible the "C" converter bypasses these functionality bottlenecks?  It seems a little unlikely; I think wat is the textual representation of wasm and they go hand-in-hand.  They do appear to be beavering away at this much as we are here.
    The integration makes it *NOT* an all or nothing kind of thing.  When the module is built, it can receive JS functions, notably console.log.  So I can log things to the console.  I could make other JS calls if I wanted.  Exported functions are just a function.  You can call it from JS.  (If you print them it says "native code", which gave me a kick.)
    In light of this, I am pushing forward with creating limited functions for the three or four places where Illuminated City sits for more than a second.  It requires some re-organization but I have the substantial advantage of being the only author.  I can also write these functions in JS.  That part is really neat; the array is one array and looks the same whether the manipulation was done by JS or WA.  This will be helpful for testing.
  24. Thanks
    The Leftover got a reaction from dbawel in Web Assembly   
    Gentlemen, thank you for the links.  Let me some opinions base on three days of work.
    I started writing in straight WAT.   Because I have a genetic defect that causes me to do things the hard way.  However, it has caused me to learn a lot of things.
    WebAssembly is at the "MVP" stage as they call it.  One can only create a module with functions below that - two levels.  One can create a list of which functions may be exported.
    The MVP status shows:  I couldn't figure out how to make a module-global variable that was mutable; so I did a work-around.  One can share a typed array between JS and WA.  In WA, it is called "memory" but there may only be one of them.  I redesigned things a bit so all processing was applied against one array.  This could put a crimp in my style.
    Is it possible the "C" converter bypasses these functionality bottlenecks?  It seems a little unlikely; I think wat is the textual representation of wasm and they go hand-in-hand.  They do appear to be beavering away at this much as we are here.
    The integration makes it *NOT* an all or nothing kind of thing.  When the module is built, it can receive JS functions, notably console.log.  So I can log things to the console.  I could make other JS calls if I wanted.  Exported functions are just a function.  You can call it from JS.  (If you print them it says "native code", which gave me a kick.)
    In light of this, I am pushing forward with creating limited functions for the three or four places where Illuminated City sits for more than a second.  It requires some re-organization but I have the substantial advantage of being the only author.  I can also write these functions in JS.  That part is really neat; the array is one array and looks the same whether the manipulation was done by JS or WA.  This will be helpful for testing.
  25. Like
    The Leftover got a reaction from jerome in Web Assembly   
    Jerome, thanks.  I usually do something like this.  I create a module config object, and attach the memory there.  This hands in whatever settings are needed and the memory.  Now both JavaScript and WebAssembly can access the same typed array using 'hexlatticeMemoryView' and 'i32.load'/'i32.store'.
    I treat the WebAssembly module as a persistent "closure".  Some of them have four or five function entry points.
    JAVASCRIPT JAVASCRIPT JAVASCRIPT JAVASCRIPT JAVASCRIPT hexlatticeImportObject = { settings : { weekbreaksLength : weekbreaks.length*4, weekbreaksStart : 16, monthBreaksLength : 0, monthBreaksStart : 16+weekbreaks.length }, imports : { log : console.log } }; hexlatticeMemory = new WebAssembly.Memory({initial:1}); hexlatticeMemoryView = new Uint32Array(hexlatticeMemory.buffer); hexlatticeImportObject.imports.mem = hexlatticeMemory; JAVASCRIPT JAVASCRIPT JAVASCRIPT JAVASCRIPT JAVASCRIPT WEBASSEMBLY WEBASSEMBLY WEBASSEMBLY WEBASSEMBLY WEBASSEMBLY (module (import "imports" "log" (func $log (param i32))) (memory (import "imports" "mem") 1) (global $weekbreaksstart (import "settings" "weekbreaksStart") i32) (global $weekbreakslength (import "settings" "weekbreaksLength") i32) WEBASSEMBLY WEBASSEMBLY WEBASSEMBLY WEBASSEMBLY WEBASSEMBLY