• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by Wingnut

  1. I'm scared, and I think ya'll have been power-drinking or something. I haven't understood anything said in this thread, and my dog is whimpering (like he has to go out and pee, and then run away to a new caretaker). You know we have no docs for GeometryBuilder, yet, right Naz? I looked at it once, and said "Oh, I see. This requires a doctoral degree in quantum physics... to understand. You bet, I can write docs for this." Now you are inventing yet another GPU-beating contraption (machine)? And you think a kiddy-level dude like me... can explain to youngsters... sigh... oh goody. Hey, I might speak English, but not advanced calculus. heh. customMaterial, eh? hmm. Interesting. defaultShader is an inbound arg! Not compiled yet? Good ol' ascii text shader code? So, the "custom" function in [line60] can do text replacements to defaultShader code, and append more shader code text onto the bottom of defaultShader... etc. Yes? (the dog just started shivering and whining again) It is a "down-stream hack-festival"... for material shaders. The defaultShader is already in the box, with packing material, almost ready for shipment, and then suddenly... a customMaterial robot enters the box... and changes-around everything, if it wishes. COOL! Of all the unmitigated audacity! SO outlaw, eh? Naz: Hey Deltakosh, can we please make ShaderBuilder part of core? DK: No, it is too weird. Stay out in BABYLONX domain... don't stink-up my core with weirdness. (3 months pass) Naz: Hey Deltakosh... if I use this latex rubber protective lambskin sheath called customMaterial, can I get closer to core? DK: No! Maybe. You're a madman. Fine... but you better have a decent docs writer... or... hmm. Man, this just feels wrong.
  2. Hi gang. I recently did some light playing with dynamically generated log cabins. Just getting "rolling". I must be in a Lincoln Logs frame-of-mind, today, huh? I, once, started assembling one in Simply 3D or Bryce or somewhere. Didn't finish. Lifting the logs with JS... is sure easier than in real life, I tell ya. Feel free to run-with this playground, gang. Let's see your log cabins, should you decide to assemble some. Log on!
  3. Hi gang! Newbie Wingnut here again, hope everyone is well. I've been playing with the multiple-basic-object (primitives) demo in Tutorial 02. After firing it up... I found that the PLANE involved in that demo... starts on edge to the camera, and is black (textureless) on one side, and invisible on the other side (backface culled). AND, the plane is too big in my opinion. AND the camera too far away. A few tweaks and things got closer to looking like the demo picture... but no apparent default material is on the plane. And I suspect that we can make cones with a correctly-argged createCylinder. All in all, I think BABYLON.Mesh.CreatePlane should create a plane that is more see-able by default, via positioning it as a 'floor' upon creation, with its non-culled side UP, and via putting a default material on it like the other primitives/basic-geometry. But, that's really not what I wanted to yack about. I can foresee a time when we will have LOTS of procedural (dynamic) geometry-making routines in babylon.js. So many, in fact, that I think a 'procedural geometry pack/lib' might be considered as an add-on library to BJS. So I ponder this... Instead of things like... BABYLON.Mesh.CreatePlane(blah, blah, etc) We/you instead have only one geom-o-generator command... BABYLON.Mesh.CreateGeometry([word or number], blah, blah, etc) In the first arg/param... a word/name or a number. IF its a number (say 12), a dodecahedron (12-sided polygon) is created like any other of the basic shape primitives. IF the first arg/param is a WORD, such as cube, sphere, cone, box, etc... it works like it does now, using the rest of the parameters as beginning settings FOR that object. That first word could also be the NAME of a procedure/method that might be inside the geometry generator lib mentioned above. IF the first arg/param is a word that is NOT defaultly recognized, such as "octagon", the call looks in the 'shape generator library' for a procedure of THAT name, and if the right amount of added args/params are set to satisfy the call... it uses the code in the 'generator' to make said geometry(s). Now lets go back to the NUMBER as the first arg/param. Lets say that number is 8... which means produce a octagon-ish 8-side polyhedron with either a builtin BJS procedure, OR call the addon geometry generator's octahedra method. This way, we/you could essentially eliminate all the createWhatever commands (there could be lots someday), and use one instead. The command would sometimes/always defer the action to the add-on primitive/shape generator. I goof around in 3dMax a bit, and I've seen their massive 'library' of procedural primitives/shapes, and one would think that BJS is destined to have every one of those, plus a few hundred more. Thoughts, anyone? Thanks!
  4. Hi @yuccai, good to see you again. First, you had a split code-line around line 38... maybe no big deal. The seemingly important changes happened in your setViewpoint() where I added camera.checkCollision toggling AND some scene.render()'s. What the heck, it started working... but I'm not sure why. A famous adage: Even a blind squirrel (Wingnut) finds an occasional acorn (a lucky fix). heh The reason I thought that a scene.render() or camera.update() was needed... was because of your DUAL (nested) setTimeout. That got me thinkin' (which usually just makes me need more coffee, but not THIS time) Hope this helps. Lines 54 and 55 might need to swap order. We should probably study this, because this solve is rather kludgy, eh? Perhaps unavoidable. Hopefully, smarter people than I... will reply. PS: I don't think there is a camera.update(). We had a similar thing with gravity on ELEVATED cameras. The camera wouldn't start dropping when the scene finished loading (it needed a cursor keypress first). Then one day, somebody pointed-out... camera. _needMoveForGravity ... a non-public boolean property (available on SOME cameras). Setting that true... made the camera fall when sceneReady. Wild, huh? I bet you didn't expect an exciting story like that... as a little tag-on gift (snore).
  5. Cool. Yeah, don't let the "database" part scare you. Just collections or arrays... I sometimes refer to this document. But really, you just need a buildingClass "factory", spawn 10 new genericBuilding(blah, blah, blah, blah, blah); Push the returned objects into an array, and there ya go... test database complete. No need to give yourself a tumor right out of the gate. JS is magically easy... almost no rules. And DOM is nearby. What if... createElement("database") creates a <database> element? Set its CSS display NONE, append to <body>, and then start stuffing it full of other made-up element names. var building01 = createElement("building")... creates a <building> element. Append to <database> element. building01.xloc = "15", building01.yloc = "20" (DOM attributes ONLY like strings as their dataTYPE, I think). Anyway, that is another way to store your data. At render time, your "building generator" would parse that "tree", or "tree-walk" it, or... umm... XSL filter it (ahem!)... and return stuff. XSL has lots of power... and its built-in to the browser so it's fast, and it can bring you ALL sceneItems in the tree... with attribute type = "hangar". XSL is the regexp of dom nodes. JQuery probably has equal powers. It's an interesting project, no matter the lookup methods. Essentially, you would be inventing WebGLmmk Markup Language v1.0, and a parser for it. Weird idea, huh? See why I lightly mentioned that your "world editor" could be a HTML form? Okay, maybe that would be strange. heh. Possibilities, though. JS can create and append generic XML-ish nodes, and can do setAttribute and getAttribute on those nodes. (does anyone still use those?) Junk can be done. Tree-walking/recursion. Fun! And yes, the standard Babylon particleSystem has an easy wedge-in point... to add your own custom startPosition func. Then you disable about half of the particle updateFunction (to keep them from flying), also an easy wedge-in. See this, as wanted. It is a demo... with "the big 3 customizable particle funcs"... already hijacked into a playground... ready for demented experiments. Essentially, these "big 3 customizables"... are the particle "engine". Many of the property settings of the particleSystem (such as .emitBox and .direction1/2 and .colors1/2/dead, lots more)... are utilized in these "big 3 customizables". UpdateFunction (the funnest point-of-demented-hacking) runs fast and hard... continuously... so don't slow it down too much, or you'll produce oatmeal-speed particles. It's a high-efficiency high-rpm blazer-func. Lines 36-57... can you feel it vibrating the playground.... cuz it's going so fast? *nod* Radiating heat, too, See that line 50 angular crap? That spins the particle around its Z-axis... a waste of time for stars. Might as well remove that line and gain 13 mph, huh? COOOOOL! Have fun.
  6. Hiya @kaitek666, welcome to the forum. I'm not sure what you mean by askew, but, in this version... I added a loop with some texture uAng, vAng, and wAng testings (lines 65-67). The wAng is currently animated. Are any of those properties... helpful? I have a feeling that these will not satisfy the issue. Vertical stripes on one side of the ramp, horizontal stripes on the other side. I think there is a uv's issue, here, and thus... I started some uvw (xyz but for textures) -testing. (lines 45-50 area) Let's ping @jerome, a God of ribbons, just in case he wants to listen-in, and/or give advice. Ribbons might not use the same UV pattern as more-standard mesh. I don't know if there is an easy fix for this, except to set all 20 UV's yourself. You can view the UVs for the ramp... by activating line 49. Twenty UVs, each with two floats. Essentially, each UV (2 values) is an X and Y value between 0,0 (lower left corner of texture)... to 1,1 (upper right of texture). So, if you know how to "drive UVs", you can manipulate the values in the uvs array. (ideally, just before line 50) That's all I have at this time. I hope I didn't say anything incorrect. Others will likely comment, too. Welcome again.
  7. haha. You have SO MUCH playful personality and inventor's spirit... too cool. If you don't mind, I'll point-out a couple issues. First, depending upon the type of game, if user walks west from Hangar #9, and then turns around and walks east, you should probably, somehow, allow them to re-arrive at Hangar #9. Now, Hangar #9 need not exist ALL THE TIME, render-wise, but... the number of craft stored there, the direction of its hangar doors, its location on the landscape, etc... is what REALLY needs to be stored. Your "hangar generator" code can repeatedly create flight hangars, (with SOME random differences in looks... hangar-to-hangar). And each hangar has unique characteristics/properties. You could call them hangar hard-traits and soft-traits. Hard traits... general hangar shape, size, capacities, materials, repair speeds, etc. Soft-traits might be... current aviation fuel, current # of craft, current # of personnel, food levels, first aid supplies, etc (all soft/variable values). So, really, what you need to store is a DB record for Hangar #9. These "SceneItem Class Objects"... could have a .type = "hangar", and when your "sceneItem generator code" sees that it is .type = "hangar", it uses the hangar-assembler section of the sceneItem generator. OR... hangarClass objects could be a subClass of buildingClass objects, etc etc. (Very OOP-based, like my friend @Temechon might do. He has some nice tutorials at his home site, by the way). OOP stands for Object Oriented Programming, of course, and yes, LOD means Level Of Detail. But, for BabylonJS/webGL, 4 LOD levels... means creating 4 different models, each with different resolution (and having them in-memory, too, I believe, but not .enabled) BabylonJS will automatically swap-out the models at whatever LOD-zone radii you wish to set. This is a performance thing, not a visually-nice thing. If you don't need the performance... let the webGL renderer naturally de-detail the model, with its depth rendering stuff, and use camera maxZ to boot it from the camera frustum... at a certain distance. For the skybox "far stars" textures? Yeah, not easy to get skybox stars to look right AT ALL, and then to make them look right when mixed with mesh stars... hard to blend. Remember to consider using a screen-grab image... of a full-screen view of your near/mesh stars (the non-skybox ones). Everyone forgets to try grabbing 5-6 skybox images... grabbed from their own screen (showing a BJS scene - possibly viewing the 10,000 mesh stars scene). Also, be sure to search the forum for 'panorama'. There's some folks who are using certain kinds of textures... mapped spherically, and getting some pretty nice 360 degree seamless backgrounds. There's a bit of image-gather near the poles, avoidable by using camera beta (tilt) limits. I think this is called "equi-rectangular projection" - here's a demo, another demo, and some more equi-pics. [thread] I like your 10,000 stars thing, too. I'm a USE MESH kind of guy, too... but... as you likely know, 10,000 spheres can get a bit heavy. Particles are an option for "skydomes" too. Here is a demo (you might have seen it before) that uses custom particle startPosition and particle update functions... to place the particles in a spherical pattern. It uses some fancy Cartesian crap and spherical coordinates funcs stolen from the web, and it has some polar and equatorial "flocking" issues. It could easily be converted to hemisphere, too. That might be a way to produce lightweight starfields, too. Imagine 4-5 of these particleSystems running at the same time, each rotated-around a bit to remove flocking problems, and each producing a different kind of star or planet. Might look pretty good, and still keep its speeds. Particles are "billboarded" and thus... always face the camera. Back to structure generators... I think you should try to stay object oriented, if you can. Base-class sceneItem, has a subClass buildingItem, which has a subClass hangarItem, etc. Basic database items. They are simple JS objects... with no mesh associated with them at all. Perhaps each has a property called .mesh. That property... references either a real BJS mesh, or a function that generates that mesh(s). In this way, you have "detached" the rendering of the structure... from the data for the structure. This separation will be very handy for you, as the project gets larger. Not only that, but you can tell your database to "render as an HTML table" too... easily letting you view (all records or single record), and possibly edit... items in your "world database"... via a web page. You could even view all the items in a plain ascii list. It could even be rendered as a SVG/2D map. The database is separated from the (many) methods of viewing it. Handy. Each database record... (each sceneItem) carries UPON it... all the values and "stuff" that the "hangar generator" or "tree generator" might need... to render THAT hangar or tree. SOME properties and methods are inherited from their superclass, and some props/methods are only defined down at the hangarClass or other subClass. Sure, the tree generator itself could also do some randomizing... so all the trees don't look identical... but... things like .LODzone... are carried on the DB record for the item. You will need fast searchers on your database utils... able to find all "zone#6" items in the database... fast (if camera frustum just entered zone#6, for example). Code must then either create all those mesh structures (only the structures in field-of-view), or them.setEnabled(true). A busy time. Fun thinkings, eh? *nod*. A BJS scene is really an endless frontier of wide-open possibilities, eh? Your mind is working fine, sniffing out the possibilities, about ready to try some tests. I look forward to your playgrounds and other experiments. This is going to be (continued) fun! Reminder - I'm no expert, and the suggestions I give... COULD be bad approaches or COULD contaminate your idea-flow. At certain points, or perhaps at ALL points, it might be wise to ignore me. heh. Sorry for all the yapping.
  8. Good to see you, too, JK. Hope you're doing well. Cool find... with that paper. I got a little math tumor just by clicking the link. Is the "C" shape... one of the simplest-yet-most-challenging cap shapes? What if... this new app... codename - "El CAPitan"... is "user-assist" (instead-of automated)? It is a "special" scene, where your mesh is placed in wireframe/pointcloud mix-mode, and you click-to-paint triangle lines... eventually creating your own custom cap. Freely toggle back to solid render... check your crap, make sure lighting normals look good, and then... umm... SAVE.... something... somewhere. hmm. "Write cap mesh as .babylon file?" Editors suck, eh? But... click on pointcloud points to draw indices... that's pretty fun, huh? Trouble, though. Normals around edge of cap... could be weird. Maybe not. They would be double verts, I suppose, so 2 normals on edge points. More if flat shaded. hmm. kbye agn.
  9. Hiya @webGLmmk, welcome back! Good to see you again. Yeah... this "move the scene past the camera" (as opposed to moving camera through scene)... is an interesting theory. MUCH is dependent-upon ... are you going to allow the user to freely navigate-around? OR... are you taking them on a guided tour, and user sits back and enjoys "the show". Needless to say, the no-nav guided tour is MUCH easier (for live-genned scene items). But if you allow user free-navigation, including up/down... then you must be prepared for user backing-up (reversing). When user reverses... there can be trouble. You REALLY want to .dispose() the mesh/lights that the user is "leaving" (to get more CPU horsepower)... but... they are still dead-center of user's view (because they are reversing). If you "pop-dispose" them in front of the user's view... well... that's just not normal or natural. Perhaps gradually fog-over the forward view before doing the dispose()? "Yuh, yuh, yuh" (AL - from Happy Days). LOD zones. Radius rings. And camera frustum stuff, too. Let's pretend we have 4 circular "LOD zones" around the camera. Pretend the zones... 0-100 meters, 100-300, 300-700, 700-infinity... away from camera. IN the camera frustum (in-view)... all 4 zones-of-depth should/could be rendered (user can see quite far, with possible lower rez on items in zones 3/4). It might be wise to design your dynamic model generators... with adjustable resolution, yes? You never know which LOD zone/ring... you'll need to "grow" that model-within. I know-of 2 "continuous terrain" demos nearby, coded by active forum folk. But, a good old-fashioned createGround works fine, too, right? Ahhh... the cursor-up and "w" keys. Our friends. When I press cursor-up, am I moving the camera through the scene, or moving the scene past a stationary camera? A big dog OpenGL/DirectDraw guy would say... "you ain't doin' neither" Be well, talk soon, write back.
  10. Thx @JohnK, a darned good idea. Building-on (capping-off?) that idea, any chance of automating John's suggestion? MeshCapper 1.0. Yeah! An algorithm/code COULD extract the top-most points of a model, and store them in a Path2d or Path3d. Then... the new MeshCapper would... umm... probably have the same troublesome anomalies as the current mesh cappers. hehe. Never-mind me. I had a pipe dream for a moment, there, but... it wasn't very well thought-out. Sorry. It just feels like... what JohnK describes, could be automated. Perhaps not. hmm. Good topic, though, eh? Thx Simona.
  11. Hi again. Cool... glad to hear my words were helpful. It sounds like you are "on your way", testing 1 of about 6 ways of doing GUI for a scene. But keep in mind that webGL is still quite new, and still evolving. So, there hasn't really been enough time for "super tools" to be developed, yet. In one way of looking at it, BabylonJS is a super-tool, but it is not designed to be that high-level layer where advanced editors are at. Blender is really our best friend. Most people create/import their models into Blender, and then use the .babylon exporter. Then, with a few lines of JS, these .babylon files (a JSON file) can be imported into scenes. Some folks use the SceneLoader class, and some use the AssetsManager feature. There are many playground examples of mesh-importing, and a thorough search of the forum will return MUCH talk about importing. We also have an .OBJ importer, and a gITF importer, and a STL importer... extensions (BJS 'extensions' often require one more <script> element in your project.) Loading .babylon files requires no extensions/externals, though. It is "native". We have people working with Unity, which seems to show some hope for importing "game logic". But, most BJS game designers write their game logic in JS, within the Babylon scene code. It doesn't "appear" easy at this time, because it is new for you. Soon, you will see it get easier. Give yourself some time/patience... and know you have the best forum on the planet... backing you up all the way. The core authors of BJS didn't load-down the framework with lots of helpers... for a reason. It is because making your own helper apps and helper funcs... in JS and HTML.... is darned easy (for most game proggers). So, most "assistants" are best if coded on a case-by-case basis... specially contoured to the exact task. Also, it was determined that... everyone wants their "helper app" a little different from other people. All these versions of the helpers soon become unmanageable, and become more hindrance than help. We found that when users need a helper... and if BJS hasn't already made it easy... then it is best to write a CUSTOM or "specialty" helper... contoured perfectly for the need. JS is fast and easy.... to code tools, or to code tools that make tools, or code tools that make tools that make tools that make toys. Luuacro and his team's editor... is really a scary walk onto a tree limb. He could become very busy, branching the editor, making special versions, branding it for companies, on and on. He could get real busy... just by creating that higher-level tool (a layer above the BJS framework - which this forum talks-about). I think he is brave, and I applaud his enthusiasm. Other editor-creators are nearby, as well. Proggers who try to build (online) scene editors for webGL... are brave trailblazers - my heroes. Big big BIG undertaking. I think it takes about 7 million buttons, switches, dials, and knobs... to GUI-use the many features within BJS framework. Learn to search. Take the time to read. Try not to be in a hurry, and instead... enjoy the road into BabylonJS... it is FUN AS HELL if you're not impatient. AND it is a road that pays off... and is quite worthwhile. You won't regret learning to drive BabylonJS. I've been doing it about 2 years now, and it has been a great journey. I was also impatient and in a hurry for helpers... in my early months. But, it's all about search. LOTS of demented torturing and ingenious ideas... have been tested in playgrounds and discussed in forum threads. Learn to search for the right keywords, and you will learn fast. Here's some important links. Babylon Docs Site, Playground Search, Forum Search, BJS Homepage, BJS GitHub, Offsite Tutorials List Note about playground search: Last I heard, avoid periods, commas, underscores... other odd things... when using playground search. Be well, good luck. I'm sure others will comment, too. I'm certainly not an expert, but I'm still having GOOD BJS FUN after 2+ years. Still many hopes and dreams, including making model-loading easier/faster. It's all evolving... and improving by the day. PARTY!!
  12. Hiya D! I don't think there is anything 'wonderful', but texture scaling and offsetting can convert an "atlas" like that... into a tile collection. I suggest a hi-rez texture atlas. Perhaps others have other ideas. Be well.
  13. Hiya @dqope21, welcome to the forum. Unfortunately, I don't know anything about the editor. But yes, you can add keyboard or controller events to any mesh/scene... by attaching an actionManager to the mesh/scene. (and also using classic DOM events) (and also observers/observables) Now, a spacebar... in a room full of paintings... will need some kind of "which painting?" -checker, of course. ALL the paintings in the room... could be spacebar-active, so some kind of "which?" discriminator will be needed. camera.isInFrustum(picture) is a nice "is it in-view" checker. I really like our playground editor, for learning BabylonJS. There you can start simple and small... one mesh, one actionManager, easy javascript. (see demos in actionManager docs). Diving-in from a large demo like ESpilit... that can be somewhat overwhelming. And the editor... if it is the "new" one... could still have issues. But maybe it is fine. I just don't have the hands-on experience with it... to know, and it is a big job to determine. Let's ping @Luaacro, in case he wants to follow this conversation (I think he is the chief coder of the new editor). But, all in all, yeah, we have full event power, with BabylonJS. If you know anything about "observers" and "observables", know that we have a very powerful/versatile system of THOSE, too. We recently got a new 2D system, too... for doing things like mesh name-labels, 2D interaction buttons, popup context menus for mesh, large and small GUI and HUD... it's marvelous. AND... IT is nicely event-active, of course. (no corner-drag-to-resize a 2D panel, yet, but coming soon.) Yep, BJS does events GREAT. It takes a little while to get familiar with observables and actionManagers, but... once you do... you have LOTS of event power. Plus, all the classic DOM events work within the JS and HTML, including window.addEventListener, canvas.addEventListener, etc... all attachable to handlers that can manipulate BabylonJS scene items (lights, mesh, camera, 2D things, anything). And our handy scene.onDispose function is a perfect place to .removeEventListeners, as wanted. " how might I add this feature? " - that is difficult for me to answer. The Espilit demo is fancy... and I would have to dig into the code to find the picture frames, add actionManagers, write a little "which painting is this spacebar for" code, and maybe even learn the new editor (And I don't really like editors. I like code/program-control much better.) BUT, if you want to play-with some playgrounds from the actionManager docs... maybe build a simple 4-painting scene... and try to get that "feature" working, I'll be here to help. In fact, maybe one of the other forum users will build us a little playground demo like that, and show us some actionManagers or keypress handling. I need a little sleep at the moment. Hope this has been helpful. Welcome again, write back.
  14. Hi J! Good to see you again. I'm not qualified to talk about this, but a search of our github site... for 'fbx' + "handed"... returned an interesting hit. There sure is lots of talk in there... that could be pertinent. Hope this helps. Maybe smarter people than I... will comment soon. Stay tuned.
  15. Hi again, B! Um... first, I think you meant to reference #5 playground instead of #4. #4 playground has no canvas2d stuff. If you wish, you can edit your previous post, and then I will adjust THIS post (removing my previous sentence). Your choice. Here's the fix for your #5 issue... Temporarily, I rounded the corners on your panel a bit more, just so we remember it is not a mesh, but instead a canvas2d. Variable canvas, in this case, is a WorldSpaceCanvas2D... which is not a mesh (although it DOES have a .worldSpaceCanvasNode helper-mesh). So, the "parent" set in line 73... would need to be a canvas2d entity, and NOT a mesh like sphereM. Then, I set trackNode to sphereM in line 72, and it started working. The panel was positioned inside-of the sphereM box, so I made sphereM semi-transparent so we could see it do billboarding. (It needs some Z value set in line 70... to exit the box, as you likely know already.) Hope this helps. Sorry for slow reply. Holler if you have more questions on this subject. I like your "reveal" system, including your camera.radius monitoring. Pretty cool! Be well.
  16. @Richard C and I have been working on some particle emit-patterns... doing some playing. Richard is now at the point... where he MIGHT want to try using custom functions that can easily be installed in our standard Babylon particleSystem. These three functions (and easy user-intervention/customization points)... can be used to really "take command" of a particle system. Anyway, I was making a playground for the Richard C project, and I thought it would be handy for THIS thread, too. Just a deep box, using large .emitBox Z-axis values, and also with .direction1/2 set to spray particles into the upper-left quadrant (up and left). Nothing TOO fancy, there. BUT, this demo has all three customizable funcs... already "hijacked" into the playground (lines 17-57) (big-time hacking fun areas!) They are still "default"... essentially identical-to BJS 2.5 core code. No customization has been done at all (to the 3 custom funcs). So, this playground is a nice "experimenter's starter kit"... for those who want to play-with custom functions for a standard BabylonJS particleSystem. Do experiments, make mores saves, grab a zip, try to blow up the world! Talk more soon... party on.
  17. It's all cool, A, thx for petting me! Yeah, it looked like you were in a hurry. No problems... thanks for being cognizant of your forum personality. I appreciate the kind words and thoughts. I'm a little slow sometimes, and quite inexperienced, too. I hope I don't accidentally tell you wrong things. I worry about that. Watch out for Wingnut mistakes... ALWAYS. Party on!
  18. I can confirm Temechon's skills at knowing about OzRocker's skills. heh. What goofy forum-folk we are, eh? Model viewing. hmm. Interesting. SO many formats and SO many things that can go wrong. err... those are not very project-pro-active words, are they? Sorry. Touring models is great fun, though, I must say. I dream of the day... when we can install ANY model in ANY scene... with the snap of a finger. But one must be careful with shared scenes. Back in the 30's... when geezers like @gryff and I were doing VRML virtual worlds, roaming show'n'tell idiots would try to enter our rooms. These were BIG, FAT, 350 meg avatars... draped with weaponry, armor, cloth, fur... packed with animations... painted in HDR textures... just big fat pigs! The pimp cars of the VR world. The moment they entered the room, 70% of the room occupants' Commodore Vic 20's.... crashed. Ok, that didn't happen. But still, I designed a special door knocker. When an avatar knocked on the door, the "peep hole" checked how fat the inbound idiot was, and if he was larger byte-wise than a Q-Bert (a box)... the door would refuse to let him import into the room. Ok, none of that is true. But it sure is a great story, huh? Welcome, Matt! Good luck on your model viewer(s), guys. Cool project... super handy. BabylonJS is the best-equipped tool to render them in webGL, that's for sure. Now, about our loader extensions...
  19. Hi Simona. First, I don't think you are doing anything wrong. You might be discovering limitations to some of our features... and some of those limitations might be surmountable (fixable/work-around-able). I'm going to ping @jerome so he can monitor our talks, if he wishes. He has done LOTS of work in these areas/features, but there are some possibly-unavoidable limitations to these types of dynamic mesh. I ran into a similar problem when I tried to "cap the bird". heh. (When I used the bird data for an extrusion.) Change cap styles 0-3 in line 73. Same problems. The cap won't go around corners. Then there's the bobsled... assembled dynamically, much like your building attempts. The slightly different colors seen on various parts of the bobsled... indicate an issue with lighting normals being "interestingly aimed". The tail cowling and side foils have good normals, and the many-piece body section and single-piece nose cowling... have the "interesting normals". Notice how the light's "specular shine" works nice on the tail cowl, but sort of fails on the nose cowl. I believe these "interesting lighting normals" are the reason you have some see-through walls, even when a material is applied and is set material.backFaceCulling = false; . Perhaps... the safest way to build buildings... is with modeling software (such as free Blender), and then import into BJS scene. You can also use all BASIC mesh elements such as planes and boxes. But yes, you'll get a little higher vert-count on buildings made from many pieces. You can give ALL the building pieces... a common single parent (so the structure can be rotated, positioned, and scaled by adjusting those values on the central parent - those three characteristics are handed-down to children mesh). Or you can mesh-merge all the "primitives" (basic shapes) together... at the end of the modeling code. I MUST also mention forum friend and coding God @NasimiAsl and his wonder-buildings. He has built two BJS extensions (extensions need "including" via extra <script> elements in the html.) One is called ShaderBuilder which is a shader-code assembling assistant, and the other is GeometryBuilder, which is a... well hell, I have no idea how it does what it does. It starts with an SVG 2D floorplan, I believe, and then it does lots of magic from there (Wingnut is not sure WHAT.) Let's look at one of his "building" playgrounds. "Naz" has some capping issues, too, apparently, but oh, what pretty generated buildings, eh? Check out that spiral staircase! Pretty nice stuff. I wish we knew how he did it. It can be learned. But Naz is kind of a genius, and he approaches webGL/JS from a unique angle - mainly... the GPU angle. GPU code is much faster than CPU code, and GPU code doesn't restrict/bog CPU code (JS) at all, except for the time it takes to assemble and compile the GPU code (pre-render). (at least that is MY understanding of it - probably incorrect) All in all (or half'n'half), I thought I should tell you about Naz and his "oh my God" buildings. There are not any highly-detailed docs for ShaderBuilder or GeometryBuilder, but a forum search for both terms... will produce some good results and beginner playgrounds. Okay, that's all I have for you, so far. I will keep thinking. Perhaps @jerome will have some words about disappearing walls... not sure. I like what you have accomplished. Cool experiments! I hope we can get some things "tweaked" and make it work for you. Perhaps smarter people than I.... will comment soon. Welcome to the forum... good to have you with us. Sorry that I couldn't be of more help. Let's keep talking and testing things.
  20. My pleasure. Good to hear, thx! Why is 'emitBox' not a sphere? GOOD QUESTION! I think we need to be math professors to understand why. heh. BUT... did you see my dome-of-stars demented experiment? Line 10 is the particle start-position custom func. Line 20 is the update-each-particle-each-step custom function. Look at lines 31-39. That is code from BJS normal particle updater. I just ignore it. Nope, Mister JS, you won't be doing any addInPlace or scaleToRef (flying) MY particles. I need MY particles to stay where they started. At lines 140-152... I don't even set gravity or direction 1/2 values. MY custom update function ignores them, anyway. GOD of particles. Taking control. Particle Choreographer. Can you "design" a particle dance number... with 5000 particle dancers, and not have any stage stumbles? (how le femme) Anyway, I had to steal code from the Cartesians, and then Theta and Phi got involved, and it all got ugly. My startPosition needed lots of help. Apparently, getting things "spaced" in a spherical way, is not easy, worldwide. And apparently folks don't like the "flocking" near the poles, either. Flocking poles. hrmf. I guess they want perfect distribution/dispersion of particles.... whomever "they" are. (Wingy tosses a k-ration from a Russian military plane as if flies over the north pole). Circular things... (flat, not spherical)... are a little easier. Check out lines 3-11 on THIS circle-maker playground. Not sure, but I think I have seen SOME fireworks... be tilted upright, or aimed relative to the launch point. That type would be less-reliant on gravity, and more a "blast it toward/away-from the audience" report. Let's call that... a "vectored report", ok? Easier to type. Target-able report, rotation-wise, including aiming straight up or down... but not dependent upon gravity to accomplish that. SIGH. Damn, describing stuff SUCKS. I'm pooped! heh. Like ANY of us REALLY wanted to study fireworks technology at this time in our lives. You could easily mod my wall-of-emitters... into a circle-of-emitters, right? Perhaps a very tiny circle. Notice they are not mesh. Each nozzle is a vector3. Each nozzle shoots almost straight up (see lines 167-168, and lines 29-32 where those directions are applied to the particles). You would do start-position settings based-upon sin and cosine stuff in lines 8-9 of the circlemaker. Try to avoid pre-making the positions like I did. Try to "derive" the next position... "just in time". "Stream" a "flow" of vector3's into ps.emitter. It's a propeller, when you get it working properly. But... what if you could do direction updating (all the addInPlace/scaleToRef stuff)... based-upon the sin and cosine, too? You would then have 18 vector3 emitters... in a circle... all firing (direction'd) outwards. Spokes generator. Many of today's fancier fireworks... do a fast spokes-background first... beams or flower petals. Can you make a "Spokes Nozzle"? (Opposite of the low-powered water-bubbler nozzle). Okay, now you have some more formulas for your "fireworks nozzle design company". Grab a fresh toddy and The Spherical Coordinates Manual, and may your horse be with you. Anything is possible.
  21. Yeah, I think I have a new best friend. It's all cool... except when the fan club gets as big as DK's fan club. Then ya need Purina Puppy Plow. heh I don't have an answer for that, Abdullah... but... I found a possible work-around. Way up in line 43... set impostor on ball... 0 mass so it hovers. All normal there. Down in lines 265-272 we process the "L" key. Before, we would set a NEW impostor on sphere (line 268). This time, I just set a mass on the sphere. First "L" keypress drops the ball, as one would expect. But no "applyImpulse" is seen on first "L". All further "L" keypresses work ok. hmm. Creating the impostor... inside the "L" key handler... seems to cause troubles. Possibilities: #1: CannonJS hates applyImpulse immediately after impostor setting. #2: CannonJS hates adding impostors... WITHIN a keypress handler. (still a possible 'dispose original' issue). #3: About 200 other potential causes. Hope this helps. Physics engine is sure being grumpy, huh? *nod* Let's keep experimenting. Teach us things you discover, please. thx! It helps all of us understand CannonJS third-party physics engine. (Wingnut checks the bottoms of his shoes... for some goofy reason) I accidentally started another PG series... oops. Feel free to hack-up that series with demented experiments and many more saves. Sorry for the repeat PG series. The playground app assigned the new URL when I wasn't paying attention. heh
  22. Hi guys. The child (b/blue) must be impostored... BEFORE the parent (a/green). Maybe better now? Hope so. Party on. PS: Changing line 38 (parent Y position) to higher numbers... does strange things. Still learning. Perhaps my line 39 is wrong. *shrug*
  23. Hi BT. I think you are doing great. Keep experimenting. 1. If you DID have upper left and lower right positions of a single particle "bounding area", would that be somehow useful? 1a. Are you wanting values for the upper left and lower right of the entire "group" of particles? Would that be somehow useful? 2. The square-ness of the fountain... MIGHT be caused by having .minEmitBox and .maxEmitBox == 000. Consider using different values, there. Advice: Turn off physics/launch (the mortar and shell) for now, and work-on ONLY the "report" (the blast/pop). Perhaps build BangTao's Particle Popper Laboratory. A confetti popper factory. heh. REAL fireworks "report patterns" come from shell-packing methods... AND fancier tech. They sometimes use "bouquet" shells, which are shells with other shells inside. This allows for different "stars" to travel at different speeds... after the pop. So, if you REALLY REALLY want to get realistic fireworks... you will need multiple particle systems operating at the same time. You could also "hack" our current particle code, and turn it into a "multi-channel" particles system, but the perf results could be similar. The BJS particle system is somewhat easy to understand and easy to hack-on. For now, let's pretend you will use more than one PS. Notice that directional updating... is done in the update function. So, YOU get to say how each particle flies. You also are allowed a custom start-position function, so you control where they start, too. Think about that power. YOU are the God of your particle systemS. Shooting particles from the verts of a sphere... is easy. The code is in the playgrounds above... and if you would become a professional at setting sphere vertex colors (colorKind data on the vertexData object for the sphere)... then you could make colored "stripes" on the sphere. Next, squish it like a pumpkin... squatty. Set its subdivs real high... and .manualEmitCount = 5000. POOM. Was it pretty? The important part... learning how to "paint" a sub-divided sphere... using colorKind data (color per vertex). When you use that nicely colored sphere... to fire stars from its vertices... it SHOULD look nicely multi-colored. You can hide the sphere with .visibility, like line 17 in this pg. Now pretend there are FOUR hidden spheres, with a particleSystem hooked to EACH ONE. WOW. Or, maybe one little sphere, one medium torus, and one tall thin cylinder. And guess what. BangTao is going to turn-on .manualEmitCounts on everything, all at the same time, for 1 second. POOM! heh Multiple particle systems, multiple particle sizes, multiple colors, directions, and multiple "spheres". Cool. Yeah, I know... firing stars from vertex points on mesh... IS a bit slow. But, it is somewhat already coded. Again, you can do custom particle systems with custom "start" and "update" if you wish. I think... direction1 and 2 define a range... the upper and lower limits of system-provided random values. Remember custom startPosition and custom updateParticle. Using simple sine and cosine, a person could "start" particles in a circular pattern. In update func... each particle can be checked. Investigate its property values. Fancy stuff COULD be done (like a BJS particle system custom designed for fireworks). But if you can afford perf loss, then consider using hidden (custom painted) mesh and firing particles from their verts... to get patterns. SOME people can live-move particle start locations, perhaps managing an "emitter state", and make pretty Fibonacci snail patterns and fancy junk... with math from their brains. Not me, though. Math hates me. So, are you going to enter sphere-coloring school? Become a God of setting vertex colors on mesh? Remember PlayDoh Fun Factory? You "pumped" the PlayDoh through "cookie cutter" templates... to make pretty shapes. In a way, emitting particles from mesh vertices... is similar. The shapes and colors of the (hidden and highly-colored) mesh... is the cookie cutter. Sort of like swap-able "nozzles" on the fireworks machine. Collect a toolbox of sphere colorizers... little pieces of code... each makes a different color mesh... for spraying particles-from. Sorry, Wingnut just RAMBLING on and on... no real purpose. heh
  24. Ahhh, okay, I was on a wild goose chase (going in the wrong direction) Sorry. hmm. In a way, it is a tree, then, right? Collapsing, expanding, dependent upon camera distance. Zoom to drill into database. (I guess) Interesting project. Yeah, camera zooming on abs positioned HTML... won't have much effect, of course. Back to Canvas2D I would suppose. Set up some "zoom zones", ya think? Panel changes to sub-panels at a certain camera distance, perhaps more than once? Eventually, with enough zoom, the "information" unfolds into view? I'm still trying to visualize the goals. Thx for the new info. Maybe I am on-topic, finally.
  25. Yep, Canvas2D, basic widgets, attached to screen surface or tracking mesh. Canvas2D system is being developed into a "fleshed" GUI system... but it's not quite complete, yet. Still, a person can make a darned nice GUI... using Canvas2D "within" a BabylonJS scene. And bGUI and castorGUI and "dialog" can do nice things, too. (more to learn about, someday) But, HTML/CSS works, too. HTML elements can surround a 3D Canvas, much like you see in our playground application. Also, when you set HTML CSS style.position = "absolute"... then you can set style.left and, and place an HTML element anywhere ATOP the 3D canvas (called absolute positioning). Generally speaking, you set the HTML x percent from the left, and y percent from the top... of the HTML page. This will put an HTML element directly atop the 3D Canvas if you wish, and it will have full HTML events active on it... (IF the CSS z-index for the element... is a lower value than the z-index for the 3D canvas element). You can also "model" a button, using a plane or box mesh... and then attach a Babylon "actionManager" to it. Then IT can generate click events, etc. SO, an HTML element can be a button, a mesh can be a button, and a Canvas 2D "primitive" can be a button... all "atop" or "within" the BabylonJS scene. Lot's of options. There, I used some SERIOUS dynamic (generated) HTML... for stuff. Nothing is absolutely positioned, but elements are "appended-into" the playground webpage at certain positions... to make my simple toolbars and readouts. It APPEARS that the HTML is atop/within the 3D Canvas, but it is really sitting adjacent (flowed-into the canvas's container... called canvasZone - see line 6)). Hope this helps. ok bye again.