• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by Wingnut

  1. Thanks for the swift fix. Well done. Works fine.
  2. Hi M99. I show good mouseWheel zoom activity in BOTH of our playgrounds. Yours was slow, mine is faster. No mouseWheel zoom for you?
  3. Sounds good, thx! There might be some pivot point considerations involved here. The left eye and right eye should not be rotating precisely the same, and with this work-around kludge, they are doing so. There is an... umm... .lensSeparationDistance and .interpupillaryDistance involved in the metrics of VR cameras. Essentially, it is the nose-bridge width, I think. Both cameras are not in the same position. They are separated by some distance. SO, when both side-by-side cameras are looking at the same target... their rotation values will not PERFECTLY match. The camera that is furthest from the target... will be rotated a bit further than the other, I think. This is a potential problem. No problems for simple spinning of both cameras like our demo is doing. But more problem when you wear the VR glasses and you have problems getting left/right rotational "coordination"... and you get a brain tumor after 15 minutes of game-play. Truth is, the rig itself... should allow parenting... but the rig is really a matrix transformation, I believe (similar to a bone). Perhaps, to do this task properly, each camera's CURRENT transformation... should be multiplied by the rotating box transformation... each frame. (ouch) This way, the box's rot transform is "affecting" each camera viewMatrix, but not forcing it to be a COPY of box's rot transform. Box's rot transform becomes an OFFSET which is added to each camera's current rot. The two cameras always maintain their slight difference-in-rotation from each other, that way. It's pretty much over my head... but... forcing left/right camera rotations... to be COPIES-of box rotation... seems like an improper solution (kludge) that could cause problems in a project. *shrug* Party on.
  4. Hi guys. I will help with PG... Snupas... I removed positioning lines 46-48, and lines 55-57. I also added line 26, but it is not needed, because line 57 is disabled. After those changes, it started looking better... so I thought I would show it. I hope this helps you guys.
  5. Deltakosh... two subjects are in this thread. Borislav issue is first... Shadow disappears when line 29 texture activated. ================================ Lynxerious arrived later, with "acne" issue, and yes, it would be nice to have playground for Lynx issue, and perhaps branch to new thread. Ok, that is all.
  6. Hi Andy, good to see you. I hope you have been well. I know of workaround. [link #2] See lines 30-31. Might not be correct way, but it works. Hope this helps. Smarter people than I ...will surely comment soon.
  7. Nice work, you guys! Yep, BJS boxes are set flat-shaded by default, and that is why I could not reproduce issue when using standard BJS box. An interesting test would be... UN-check "use flat shading" button in Blender export, but then do... cube.convertToFlatShadedMesh(); BJS scene code. I think that would work, too. Forum hero @JohnK is a teacher extraordinaire, and he has written "The BabylonJS Guide" and stores it off-site (it is a multi-layer site, based upon reader skill levels - just fantastic). One of his docs... "Facet Normals"... does a good job at describing the differences between flat shading, and other shading methods. Look at the difference between his picture #2 and picture #4. Notice how many MORE white lines in picture #4.... and how many MORE vertices are used... when a cube is converted to flat-shaded. In John's example, the cube changes from 8 vertices and lighting-normals... to 24 vertices/normals.... when converted. Why, you ask? In all of BJS land, only ONE lighting normal is allowed for EACH vert of a model. But for flat-shaded cube, we need THREE lighting normals (white lines) at each corner of the cube (one for each of the faces that intersect at that corner position). So... somemesh.convertToFlatShadedMesh()... adds many (repeat-positioned) vertices to a mesh, which makes the mesh bigger (vertices-count-wise). Thus, checking that "Use Flat Shading" checkbox will INDEED change the vertexData seen in the .babylon file. It probably triples the amount of cube verts/normals, etc. There was nothing "wrong" with your earlier import. Perhaps if you would have used different lighting - a directionalLight aiming STRAIGHT-AT the cube image... from the side... then the dark area might disappear (without needing to set flat-shaded). So it is not really important to remember the flat-shading checkbox.... but to understand WHY the lighting acted that way... when the cube was Phong-rendered or Blinn-rendered, or whatever method is the standard. Those rendering algorithms are SUPPOSED-TO do that lighting fall-off... that darkening. That lighting fall-off was quite normal... for above-cube lighting upon a non-flat-shaded cube imported from Blender. Wingnut should have discovered... "Oh, this is an 8-vertice box, and not a 24-vertice BJS default box"... but I was too stupid. I get that way, sometimes. Anyway, I'll let you guys get back to business. Thanks @gryff! Congrats, FB! Good to hear your happiness. Your friendly words and enthusiasm... are enjoyed by everyone. You seem to be very kind and appreciative... thanks for that. Good to have you with us.
  8. Hiya degressor! Interesting project! I wish we had a few more details. Are you doing land? (you mentioned 'ground'). Anyway, here is #1 demo image... and #2 demo image found via Google image search for 3D heat map. In both of these, there is no "drawing" of a classic 2D heat map. No fancy color-dithered texture/material. The color dither (gentle transition across color-change edges)... is done by placing the bars close-together. Color = heat-level, like normal, but you would be "painting-with-colored-bars" and not with BabylonJS DynamicTexture (a texture made-from a context2d canvas). This method would be fairly easy to do. It is the gentle color changes from 3Dbar-to-3Dbar... that makes it appear color-dithered. No 2D drawing at all. Only various colored 3D bars... whose height AND color... are determined by the heat values. Since heat values rarely change large amounts across short distances, the colors automatically dither (change gently) across adjacent bars. It self-dithers, due-to heat map data being "bound" to color spectrum. I mentioned DynamicTextures. This is how to have a canvas "context2d" (like SVG... paint-on-canvas) that you can use as a texture. You could use your heat data (gotten from a json file/data?) to draw-onto a dynamicTexture's context2d canvas... and then use that dynamicTexture as a Babylon.standardMaterial.diffuseTexture. That will make a 2D heat map, but that method is not used in either of the demos I reffed/linked. AND... you could use both methods. Use a 2D dynamic texture to make a 2D heat map for the bottom texture, and then STILL do color-coded (and height-coded) 3D bars atop that. It might look "visually-busy", though. Possibly too many colors... difficult to determine values, visually. Sometimes, when visualizing data, it is best to keep it simple and clean. But you can offer users MANY visualization options to choose-from. For this, it is good to understand "overlaying". Some examples might be... turn on/off 3D bars. Turn on/off 2D heatmap on bottom layer (on the ground itself). Change colors, scales, viewing angles, etc. Layers/overlaying is the way to allow many viewer options, and it gives good power for future expansion. Perhaps, you could choose a few URLs from the Google image search, to show us what you wish. Paste your favorite image URLs into another post, or edit your first post and paste some favorite image URLs in there. This would help us "see" what you want to do. We want to see what you wish-for. Then we can give better advice. Cool project! I see good fun and learning ahead. Others will surely comment soon, especially after you give us some image urls to your favorite visualizations. Sorry for long post... I get talkative sometimes.
  9. Good tests, @Lynxerious! You are on the trail to success. I have also told the two top-dog framework coders that have made recent mods to shadows... about this thread. They are both upper-level programmers at Microsoft, so they are very busy, yet they are extremely kind and will take some time to look-at this issue. Pretty cool of them, eh? You haven't shown any dismay with us (thx), but just for kicks... here's a little more background and insight... BabylonJS is not affiliated with Microsoft in any way, but I wanted you to think about HOW BUSY their jobs/lives are. It is truly a miracle that these two guys had ANY time to improve our shadow generators. Yet they did... and without irritation. Pure love of the tech. They will thank you profusely... if you found a framework/shadows bug, or found an issue that isn't covered by the shadow docs. And, they will forgive you if you haven't read the docs thoroughly. Sebavan and Deltakosh both give 120%... and that's something you should cherish and hold in high-esteem, in my opinion. They're great guys, with great brains and hearts. All the helpers on this forum... are volunteers, not paid. We answer hundreds of questions... many of them are repeats, and many are answerable if folks would read the docs carefully. We forum helpers rarely get to work on personal projects. It is a good thing that we are caring, patient, and emotionally level-headed, right? You don't HAVE TO wait, of course. You can continue studying and experimenting. It's only JS and webGL, not neuro-surgery. Nothing would be irritating about that, unless you make yourself angry when you learn things, right? And learning always goes "your way", because you are the one doing it for yourself, yes? You didn't answer which type of shadows you are using. Why is it taking you so long to answer that question, playground-less one? That's pretty irritating. (nah, not at all, but I thought I could maybe make you laugh a little, about it) heh Did you try "poisson" shadows? Did you try both exponential and blurExponential? Did you try rubbing a magic teapot mesh... to get the webGL genie to appear, and grant 3 bug fixes in your code caused by you and only you? okay, okay, I'll stop trying comedy for now, but if I sense you getting irritated over this brand new, constantly-evolving, bleeding-edge tech... I'm going to try to make you smile again. I'm just that way. WebGL is a friggin' miracle and it is one of the most empowering and enjoyable hobbies in my life. I enjoy a challenging bug-chase, and I enjoy the company and knowledge of others... when we team-up for a bug-chase. I hope you can enjoy webGL in a similar way, someday. I will always try my best to make people enjoy BabylonJS, but I won't skip a meal for anyone.
  10. Ahh, ratty shadows. "acne". Thx for the pics. um... which type of shadow are you using? BlurEponential? Or, default settings? Have you tried all the different types, from the docs? There are some "tweaks" listed in the Shadows Documentation. Have you tried a few of those? .bias is a good one. Keep experimenting... and try all the adjustments. I have had similar problems, but beat them... with adjustments. But I must re-iterate that keeping the dirLight ALWAYS aimed directly at the player... will result in the BEST shadow clarity. Think about distance from light to player, and notice the minZ and maxZ comments in the docs. I think it would be wise for you to put a dirLight.setDirectionToTarget(player.position) inside your renderLoop, if you can. Do your best. It is difficult for me to help...when there is no playground example. So, for now, I will tell you what I would try.... if I were you. Likely, we will have more shadow experts here, tomorrow. They are all waterskiing right now.
  11. Hi Lynx! In that playground, your light is positioned at 0, 0, 0, aiming straight down. This is ok when NOT using a shadowGenerator, but when using shadows, the shadowMap is derived based-upon light.position. Your light was not above the sphere. See line 11. With directionalLight shadows, I always do 2 things. First, position the light somewhere above the wanted target... and then light.setDirectionToTarget(someMesh.position). But that's me. Main thing, you must get dirLights up in the air and wisely aimed... because the light position is being used (like a camera) to determine the shadowMap (I hear). Take note that direction vector3's are not the same as position vector3's. Direction vectors are much more difficult to determine... especially for geometry-impaired noobs like me. That is why I so-love late-in-the-code light.setDirectionToTarget(someMesh.position). It is my friend. Works great for spotlights, too. When put inside renderLoops, it keeps makes a spotlight "track" a moving mesh (line 70). Hops this helps.
  12. Hi girls. @Sebavan / Deltallama... is this a possible issue with your new shadow stuff? *shrug* More likely a Wingnut mistake, but I thought I should report-in. I brought some raspberry koolaid, too. Want some? Hard to get. I smuggled-in 5 packets from Canada.
  13. Update: [link #5] - MUCH simpler playground. Activate line 29, shadow gone. hmm. So... um... blurExp shadowGen using pointLight... fails to cast shadows on textured grounds. Stated correctly? Phew. I spit and drooled a little bit... trying to speak that sentence.
  14. But, aren't you getting warnings about "variance has been replaced with exponential" in the console? Hmm. I thought I had a working version for my #2 playground, but I discovered I was using 2.5... so never mind. Still working on playground. I will test your theory in a moment. Update: [link #3] 'blur exponential' seems broken. (lines 146-150 area) Non-blur seems ok, but not the 'blur' version. Still learning. Possible bug. Perhaps pointLights can't do blur? Nah, that's not the problem. There's still a Wingnut mistake here, somewhere, I just know it.
  15. I'm working on the PG a bit. I did a little cleanup/adjusting... not much change. I haven't figured-out why the shadows are failing, but I'll keep testing, and others may join-in. Thx for making this playground, well done. It makes testing easier for everyone.
  16. My pleasure. When my web browsers load, they display a web page (a browser start-page) that is stored on my local drive. It looks somewhat like this thing, but it is filled with links. Feel free to use that empty HTML table/file for yourself. Perhaps save it to your local drive, using your browser FILE pulldown menu. I have two columns of links... all for BJS things. I have one column full of HTML/CSS related things, and another column for JS-related things, and the rest is filled with assorted yummy links. Having a "hot links" web page... full-of Babylon-related links... is a HUGE accelerator for learning BJS. You may wish to consider doing that yourself. *shrug*. It takes some time to edit the html and add all the hot links, but once it's complete.... it's sweeeeeet. And the BJS playground... phew... what a HUGE learning accelerator that is. Mega-tool ! Examining other people's playgrounds and doing tweaks... then hit RUN, then another adjustment, then hit RUN... playing with a scene... flattens the BJS learning curve beyond description. It is wonderful, and very fun/addictive. Don't forget to eat (it is THAT MUCH fun).
  17. Hi guys. I did some experimenting. Open console, focus canvas, start hitting arrow keys. No "camera moved" reports to console. I can't get my PG's render loop... to "see" the camera being arrowkey-positioned. What the heck? I seem to have forgotten how to code. (Wingnut bangs himself in the head with a shoe) heh. Assistance welcome. Goofy. Somehow, I got stupider. I didn't know that was at-all possible.
  18. Hi again. #5 and #10 both apply. A forum search for 'typescript' might also help. Oh, look at that. There's ANOTHER link to 'roadmap' there in #11. (Wingnut grabs BWS's sunglasses and carefully washes the lenses) Also, this looks interesting. And yes, you certainly may contribute tutorials (we love it), and it is very simple. It often starts with a familiarization of "Github Markdown Language"... or MD, for short. It is super easy... takes 10 minutes to learn. Later, we will tell you more details about how to install the .md file in the correct place and include it into our docs-"build", so that it becomes part of our docs website. There is a certain (simple) hierarchy format used in our .md docs... that CAN automatically generate a table of contents (TOC) for the HTML-version of your document... during the build. (Not required, but it is a nice feature.) It is created during the automatic HTML generation... that happens to the .md tutorial files during the build. The TOC for a tutorial is only view-able AFTER the docs-build is complete. Our docs-site curators will do the builds, when needed. But you may also clone the docs repository to your home computer, do grunt/gulp builds there, and actually have a complete BJS docs website on your home computer. This makes it easy to check/view TOC's before they get put into "production". Lots of automation, too. When you do the home docs-build, the website automatically launches on localHost:3000 as soon as the build completes. It's a sweet system... once you familiarize. Here is the folder at our docs site... where the "general" category of .md files are stored. You can see some example .md files, there. There is also a file called statics.json that is heavily involved as a map... to tell our docs-build WHICH .md files that we would like to create html files-for, and include them on our docs website. We'll talk later about all that. But first, I think you should spend some time FINDING tutorials and documentation links. That way you can be sure that any tutorial you write... is not a repeat of another tutorial that was already written. Our documentation site is very large and reasonably comprehensive (somewhat thorough/detailed). Take the time/patience to tour/explore it well. It will become your best friend. Be well, party on!
  19. Hi BWS. Scroll far down. 'Roadmap' is a link down there. Fun with reading.
  20. Hi B! That line looks strange. Are you sure you have entered that line correctly? What happens when you remove it? Anything good? There HAS BEEN recent changes/improvements to shadows, so there COULD be a bug, but it is difficult to troubleshoot without having a playground scene that shows the issue. Can you reproduce the problem... by using the BabylonJS Playground app That would be nice. You can simply paste-in most of the code... from your project. You can use a basic cylinder instead of importing a player model into the playground. Do your best, thx.
  21. Hi Flyingbee... welcome to the forum. Sorry to hear you are having problems, and thanks for reporting and testing. I made a BabylonJS playground scene... that is similar to your issue. It is something to experiment-with. I was not able to reproduce the problem that you see. FB or anyone, feel free to make edits and do more RUNs and SAVEs. Tell us what you learn. I will continue testing, too. FB... can you publish/share your .babylon file and perhaps your .blend file, too? When I need to share/publish BabylonJS-related files, I use my free Github account... and then I can use those files in playgrounds... like this. You could do the same. You can actually drag'n'drop files into GitHub folders (then scroll to bottom and press COMMIT button after the drag). Quite handy, if you don't have a CORS-cleared web server of your own. All in all, I think there is an issue with the Blender pointLight (perhaps a range setting), or possibly something odd with the lighting NORMALS on the Blender cube. We can learn more... if you can provide .babylon and .blend files. I'm going to ping @gryff and see if he has some ideas (thx Gryff). Gryff is quite experienced with Blender and imports from it (and he's a darned nice guy, too) Also, we can examine .babylon files with Windows Notepad or many other online/offline JSON-file viewers. Perhaps the Blender exporter is doing something unusual. We might be able to see/find it... by examining the .babylon file carefully. I assume you are using BabylonJS 3.0 preview? And you are using newer versions of Blender and its exporter? Anyway, we WILL find out WHY this is happening... if we do enough experimenting. Comments from everyone... welcome.
  22. 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!
  23. Okay, back to the 6162 issue. PG #61 vs. PG #62. I can't let this thread die. This issue needs "wrangling", so I will bump it. Why is #61 fast and the #62 slow? (Wingy watches his step) (lines 2-6) hmm. Thx for any help, gang.
  24. Hi kids! Admiral Deltakosh recently adjusted some code to get our CannonJS heightMap impostors working somewhat better. (still avoid non-square terrains) BUT (there's always a but)... check this out [PG test #45]. Wait for all the movement to stop. Are all the boxes sitting on their edges? Impostor-meshShape rotational-sync issue? Me thinks so. Also, I think I see muddy ground (mesh slightly sinking into terrain). We will know more... once the rotation issue is solved. I mentioned it in this recent discussion (scroll to bottom), but DK has been pretty busy, so we should try to puppy-chow these issues (try to solve without expert help). But... the rotation issue started recently - possibly caused by recent activity in heightmapImpostor or boundingBox code. @Deltakosh, I will ask blunt. Did your recent heightmapImpostor fix... somehow affect boxImpostor rotations? Do you/anyone see boxes in #45 demo... resting/sleeping on their edges? Any thoughts/ideas? Should I be in bugs? Should I have continued talking in the github comments? (I fixed a bad link to pg #45 in github comments) I never know how to report stuff. Over 60% of my reports... end with finding a Wingnut mistake.
  25. Yep, yep, yep. Thanks @satguru. Yeah, after thinking about this more, and getting some words from Satguru and DK... it is best to change camera types, and not change rig_modes, Ian. I should NOT have force VR-rigged the arcRotate cam in my earlier PG. That was a bad hack. It is better to switch camera types... than to switch rig modes. Sorry for misleading you down a bad trail.