• Content count

  • Joined

  • Last visited

  • Days Won


Wingnut last won the day on July 2

Wingnut had the most liked content!

About Wingnut

  • Rank
    Advanced Member
  • Birthday 12/15/1957

Profile Information

  • Gender
  • Location
    Bessemer, MI, USA
  • Interests
    3D Web, CSS, HTML, Guitars, NORML, storytelling

Recent Profile Visitors

3,783 profile views
  1. @Deltakosh You are SO mean. Naz: "Here, this way works, too. Sebavan, you can borrow this for official grid material usage." DK: "Could we have detailed docs?" Naz: "You want me to teach how shaders work, in English?" (Naz searches frantically for some sleeping pills to O.D. -on.) hehe Just kidding, of course, but I don't think Naz anticipated the 40 tons of added workload. Were you wearing a hard-hat, Naz? DK can drop big rocks. Here's a little secret... "This material is created with shaders. For more information, learn about shaders." There's your "comprehensive documentation". ahhh haha. I guess I should ask... SHOULD our current gridMaterial be scrapped, for Naz's method (to get shadows working better?) *shrug* Then maybe Sebavan and Naz can get together and Sebavan can help do the docs for the new system? (Did Sebavan create current gridMaterial?) All in all, I hate to make Naz write English docs... something that could feel like a HUGE HASSLE to him. I think, if there is ANYTHING Naz could use help-with, its writing docs. He certainly contributes plenty of other cool things. What is your language, Naz? Farsi? I can learn it in a few months, right? Problem is... speaking "shader" is a foreign language in itself. Farsi shader talk... wow... that could be a serious challenge. Wingy being goofy, ignore at will.
  2. Fun! Let's see... each char in a canvas2d input box... has to be a separate object. In that way, it is easy to click within text... to place a flashing cursor-bar. In fact, each char... needs to be made from TWO Babylon.GUI simplebuttons... one for its left side, one for its right side. That way, when the click arrives, we can determine if the flashing cursor should be placed BEFORE the clicked character, or after. Nah. We can use some math, along-with char localCoordinates... to determine which side of the character to place the flashing cursor-bar. Back to one object per char... smarter. Once the "where is the cursor?" system is created, then advanced crap like highlighting, inserting, backspacing, type-over, and deleting... can happen. We will need to allow that flashing cursor to be re-positioned with arrow/cursor keys... AND shifted-arrowkeys for highlighting, AND control-arrowkeys for word-jumping. Cool. It needs onChange and onEnter, just like the HTML input field, and payload is .value, likely. Then there is field width, and maximum chars, etc. We should have a set/settable fontFace, too, and that will affect/determine the initial height of the input field. Wow! According to my web searches, nobody is even CLOSE-TO creating such a thing. We would become (more) famous! I'm thinkin'... oh... 10,000 lines of code.
  3. Hi guys. Brick... folks often "bind" or "wire-together" things inside the scene's renderLoop. One of the most common... scene.beforeRender=()=>{ camera.beta = player.rotation.x; // this line can get lots more complicated // lots more stuff that gets done every frame } Some cameras don't have beta, so then camera.rotation.x = player.rotation.x, or maybe venture into camera.rotationQuaternion and visit BJS Quaternion yaw/pitch/roll methods. (Quaternions aren't always an easy-learn, though). Sometimes you might use += or -= in place of = Sometimes, you need things like camera.rotation.addInPlace(player.rotation); Fun, demented wire-ups/bindings. Anyway, I just wanted to show you how to "bind" things to other things, with the render loop. Sort of like patch cords, eh? A reminder to forum helpers... Brickster is most-concerned with making a standard followArcCamera... be able to follow nicely when player does STEEP Y position changes... needing camera POSITION to "follow" nicely. (I hope I re-stated correctly, Mr.Brick) Our followCams do okay when following left/right turns, but do they follow JUST AS NICELY when player does steep drops and rises? I think this is Brick's initial concern. The ArcFollow might TILT .beta nicely, but does it have good position-following when target does large Y-pos changes? I bet, when player drops quickly into a deep valley, our followCameras will smuck-into the ground... in an attempt to follow (dependent upon camera followDistance).
  4. Yuh, yuh, yuh. Good answer, J, but... gruesome. Sorry to butt-in, but, there's another way, Captain Brijesh. The fake. (I love visual trickery, it makes me smile.) Use a 2nd tube. The 2nd tube doesn't exist until 1st tube intersects border. Then start lying. The 2nd tube (outside-of-border tube) has it's pivotMatrix/origin set to the border (at intersect point). Its size and rotation matches the 1st tube, but 2nd.scaling will determine how far the 2nd tube will "protrude" outside-of the border (the 2nd tube's length). Increasing the scaling will make the 2nd tube increase protrusion... because its origin is set to range border. In the example picture, the green tube is the 2nd (duh) and its origin/pivot is set fully left, where green tube meets border. Scale green tube to increase protrusion amount. Origin will stay in-position at border (left side of green tube). Cheating. Just one function... var faketube = generateFakeProtrudedTube(tubeToExtend, whichDirectionAndMagnitude); Devious, we are. heh. "Purists" are gagging and shaking their heads in disapproval, at this point. There might be one other cheat... depending upon what is needed. A spotlight/shadowMap. The "circle" might be a spotlight-circle, or its inverted shadowMap, or something similar. You won't be able to get a different TEXTURE for inside/outside, but you can surely get the material COLORS to change (when any part of the tube exits the spotlight circle). Our lights have arrays to determine WHICH mesh are affected/not by that light, which could be useful. The question might be... CAN our shadowGenerators generate other-than-black shadows/s-maps? Can we have yellow shadows, or other colors that actually increase the brightness of mesh material... when a shadow is cast-upon it? (in-shade mesh are actually brighter, not darker). Demented ideas from Wingy... ignore at will.
  5. Don't let him scare you, Brick. P8 has been snorting bytes since noon today... he's already well code-toasted. Inertia, reaction times, camera mass, overshoot, heavy momentum goods. (Wingnut opens the top of Pryme's head and looks around in there.) He calls it "the basics". heh. Um, the basics would be a nice playground with BabylonGUI sliders to adjust all the variables WHILE a violent high-speed chase is underway. Anyway, here's a terrible flight sim with a ton of BROKEN cameras and buttons, but it was ONCE used to test airplane-following cameras. With a little (a lot of) work, it could be hammered into being a follow-cam testing scene, once again. Perhaps @Pryme8 will install one of his inertia-cams in a new blue button. Perhaps someone will fix all the other broken cameras. Perhaps we need a robot stunt pilot for this airplane. Maybe much later, we spawn 5 of these airplanes and do a 1930's "Blue Angels" show! Cooooool. Five robot stunt pilots... communicating with each other... doing an air show for us. "Keep it inside the skybox and above the ground, boys" Air show choreography comes from a "script" or maybe a block of xml nodes. Excellent! I'll code the smoke systems for the planes. Sound good? Let's GO!
  6. Hi BTW, and hi DK, too. I think Brick is going to need a "flight path" to do camera tests/modifications-with, and we have no flight path generator. I would say @jerome's rollercoaster is one of our better "static" flight paths. It uses a followCamera in line 178 with some kind of real-time radius adjuster in line 230. But, it seems that the camera never tilts on X-axis, as BTW mentions. Let's pretend... a "chase airplane" is following the purple "wagon". Let's pretend that a human in the passenger seat of the chase plane... is holding/aiming the camera. If the wagon makes an extreme climb or dive, there would likely be a two-step process. The camera operator would tilt the camera to try to follow the wagon, and that would likely happen fairly fast. Meantime, the pilot of the chase plane... would begin climbing/diving... chasing the wagon. When/if the chase plane got (back) onto the path of the wagon, the camera operator would then de-tilt the camera and start aiming the camera more straight-ahead. If we watch the rollercoaster demo carefully, we can see that the camera is always (trying-to?) matching altitude with the wagon (camera never x-tilts, or not very much). Just for fun, I did some adjustments... disabling line 230, and adding a camera tilt report-to-console in line 233 [link pg #28]. As we can see by watching console, camera IS tilting SOME. The camera never needs to tilt very much, because the camera's altitude is continuously changing - to match wagon. Let's try another [link pg #29]. This time, I locked the followCam altitude at 50 units (in line 233). NOW, the X-tilt values seen on-console... are much more extreme. The tilting is "dictated" by the location of the .lockedTarget set in line 179. Just some interesting things to learn-from and think-about. (okay, okay, perhaps not very interesting, but I still wanted to talk about some stuff and do some basic tests.) Party on. PS: BTW... it IS quite possible to FLY the wagon yourself (no rollercoaster tracks), using one camera aiming out the front of the lead airplane (so you could fly it properly), and have a "panel" on your dashboard that shows a "renderTargetTexture" (RTT) of the followCam from the chase plane (a view from the chase-plane followCam). Although that scene would require some serious work, that would be the ultimate test-bed for your followCam. Ever heard the phrase "fake them out of their jock strap"? Well, if your lead plane could make extreme turns, dives and climbs, you could do some of those (as pilot of the lead airplane), and "watch" (on the RTT panel) when/how-often your flying skills were able to "fake out" or "deek" the chase plane and its camera operator.
  7. There's some kind of "echo" on this thread. heh. Yep... at-seam normals-averaging. And at places where 4 ribbons connect, 4-way averaging. Setting each "edge" normal to 0, 1, 0... will still produce a noticeable "seen" seam. This is can be EASILY-seen when part of a mountain SLOPE is on ONE ribbon, and another part is on an ADJACENT ribbon. The angle of the normals along the steep slope... must stay consistently angled, or else the mountain slope shading will go wonky and look strange. A (0, 1, 0) normal along that slope... would screw up the shading/lighting. The needed "edge normals-averaging sewing machine" is not easy-coding, either. @adam once said he might try it... for my 16-tile heightMap mess... but he wussed-out in the end. hehe. (I'm just funnin'-with Adam.) I was totally honored that he even THOUGHT ABOUT trying it. Pretty nice of him... and I wouldn't wish that task on ANYONE. It would be very hard work... I think. @Zuzuk, do you want to "feed" new ribbon data... to the scene... from a server? As user walks around, scene makes queries to server for new ribbon-making data? OR... do you simply-want any "endless" (dynamic-generated) terrain? (easier) I think NasimiAsl's dynamic terrain thing CAN query a server for fresh data. Unfortunately, its playground version is broken due to mimetype problems. Jerome's dyna-terrain isn't really designed to query servers for fresh data, but perhaps COULD. I'll let him show us his fave playgrounds. Pryme8... I don't think I have a playground of his dyna-terrain, yet, and I'm not sure how ready it is for server-fed terrain data. And don't forget LOD. WebGL can handle a fairly-large STATIC (made-once) heightMap with good resolution, and still maintain performance via "level of detail" checking. *shrug* Anyway, just Wingnut rattling-on, as usual.
  8. Hi Lary. Actually, I didn't use this playground code... at-home. So I didn't need to import-in gradientMaterial.js. It is already included-into the playground app. Your error is texture-related, I would assume. I wasn't able to get textures active AT ALL in that playground. (see lines 29/30). But, I didn't test well, yet, and I make lots of mistakes. I don't even know IF gradientMaterial ALLOWS textures... I haven't checked its code, and I didn't code it. I will do more study. In your test... when you get the error, are you using ANY textures at all? Anything like... gradientMaterial.diffuseTexture or gradientMaterial.emissiveTexture? Or, are you getting this error with NO texture usage? Any chance you could zip-up your entire project (with current errors) and make it available to us? I wonder why your project has texture errors, when only colors are being used. hmm. *scratch scratch* I am going to assume that you are ONLY using the code that you included in your first post. I have only tested the LATEST babylon.js... the one used in the playground app. And I have only used the gradientMaterial.js that is automatically included-into the playground app. I tried switching to BJS version 2.5 in the playground (selector in upper right corner), but that is currently broken. ------ Feel free to "mess-with" that playground... and see if you can cause the same error in ITS JS console. Edit and save new versions of that playground... as often as needed. You can't hurt anything in the playground. The URL for the playground scene.... will increase its version each time you save. If you find something interesting, do another save and paste that URL to us, here. Then we can all see problem. We want to TRY to cause the same error as yours... in the playground's JS console. Then... you know... we can get the entire team on the case. Are you SURE the error... is caused by the gradientMaterial code, and not some other code in your project? Make sure the gradientMaterial IS the cause of the error. (Sorry if I'm treating you like a child, but, sometimes we all forget to check the source/line #'s listed on the far-right side of the error report.) Also, make sure that gradientMaterial.js is being properly loaded with a script tag. Make sure it isn't doing a hidden File-Not-Found / 404. All in all, thanks for the error report, Lary. We will find its cause, soon. I will do more tests, and maybe you can do more tests, and we will beat this. Please report ANYTHING you learn (here), and I will do the same. Talk soon. Other forum helpers... please submit ideas/comments. Thx.
  9. Ahhh, ok, I found the problem. We were setting box positions AFTER setting physicsImpostors. Here I set positions in 38-40, and then use constructor-set params in line 42. Also reversed the flat shaded/ground-impostor lines. Works pretty gooood. Still, the success seen via 'late' parameter-setting... is interesting, and worth investigating. I didn't think there was a problem with constructor-set parameters, because SO MANY other physics playgrounds are using it successfully. Learning learning learning. Maybe someday, we can update docs... once we learn how everything works. Update: Just for fun, I moved that CannonJSplugin .executeStep into top of version #76 playground. No difference in speed seen... between #75 and #76. Interesting! That would indicate that things we discovered today... have affected the .executeStep issue, too. So many things... seem interconnected, here.
  10. Ahh, look at that. INTERESTING! Good find, SG! hmm *beard scratch*. What the heck?
  11. Hi SG. I think the "explode" that happened in that playground (which I didn't code)... was because the user spawned many physics active boxes in the same place, overlapping each other. I never bothered fixing that. I was working on different issues. Two issues I worked-on... were the "mud" (sinking into ground), and the other issue was... boxes coming to rest on their edges (not laying flat when coming to rest). Your #72 playground still has both of those symptoms. (But hey, thanks for fixing the exploding launcher. Your launch is must nicer.) The reason was found... for the sinking and edge-laying. Don't convert ground to flatshaded... before setting physics impostor. Just reverse the order of lines 67 and 69, and the #72 playground looks pretty good. (I'll let you experiment with that, but in my quick tests, it fixed it). Lately, there has been some proposals for offering another method for doing BJS flat shading. There is talk of doing it with post-processing. Lastly, there was one other issue seen. Just forum search for 6162. It involves the cannonJSplugin .executeStep function. When that little function is included into the playground, CannonJS scenes run much faster. That is still being pondered... and has not been solved. We'll talk.
  12. Hi guys. I found a gradient playground while I was walking in playground park. You guys can use it for testing. I decided to add an animation to move the sphere up/down. The material doesn't "ride-along" Weird. I also added a couple textures, but I didn't have time to test why they aren't showing. Perhaps others will improve this test PG. Have a fine weekend, everyone.
  13. Hi @distraub, welcome to the forum. If all the starting points in space were at a different Y value, they would each encircle the planet around a different "non-equatorial" orbit. So, the chances of orbits over-lapping each other... would be slim. Some orbits might be elliptical, too. Then create each in a different color, and you might have good success. But, does distraub WANT to allow a few orbits before doing de-orbit burn (2-step process.) Really, a 3-step process. First, know what orbital insertion point is wanted and draw straight line to IT. That line will smoothly intersect a circle or ellipse orbit trajectory. THEN, finally, a curved line indicating the de-orbit burn (slowing craft, letting gravity pull it through atmosphere). One straight line, one circle or ellipse, and one curved line from orbit to landing point. Ow! Orbital insertions. Too cool, but not used by weapons/meteorites, etc. The space shuttle used a few more curves. While they were approaching the landing site, they were in air, so the air-plane-like control surfaces were used to do steep banking, left/right etc... to scrub-off unwanted speed. Then, when near the landing site, they banked around a "heading alignment circle" (HAC). It was an invisible cylinder near the end of the runway, and no matter the approach angle, they would bank around until they were aligned with the runway, then break-away from the circle, and drop trow gear. Computers do most of it, but in the video above, they were still "slightly low at the 180". (180 degrees around the HAC) I think... maybe... the need to enter an orbit FIRST, and then do a "de-orbit burn", slowing the craft to allow gravity to pull craft to the planet... is based-upon amount of fuel used to do braking thrust. AND... are there living things on-board that wish to survive the landing? Or is it a meteorite that cares nothing about soft landings or burning-up entering atmosphere? Thank goodness distraub is only concerned about drawing lines at this point. The function that calculates the most fuel-efficient and SAFE flight trajectory and de-orbit maneuver... would be quite an undertaking to code. It would need to consider spacecraft mass, planetary gravity, insertion speeds, etc.etc. erf. Still, fun! Got some contacts at NASA or other space programs? Would they loan us some pseudo-code/formulas? heh. COOOOL.
  14. Hiya Simon. Sorry for slow replies. I've been doing some testing. [link pg #3] SOME progress, but... hmm. I am printing diff to console @ line 125. Open console and do slow drag on ground. See diff alternating negative/positive? I think that is the problem, but I'm not sure WHY it is happening, yet. I'll keep thinking/testing. Others may have ideas/fixes, too. Stay tuned. Update: [link pg #4] There we go. Line 141 was causing problems. Nopped it out, life got better. hmm. You can remove lines 136, 137, too. They are not necessary. Party on.
  15. Thankya, DK. Nicely done! You saved the world yet again! Now if we can just find Zhang. I hope he didn't fall through a crack in the forum floor.