• Content count

  • Joined

  • Last visited

  • Days Won


Wingnut last won the day on February 1

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

2,645 profile views
  1. cloth

    Hi @jorditantadiaz. Take a look at THIS browser-bogging playground. First, notice the demo uses CannonJS physics engine, and not the default Oimo physics engine. (line 5-6) CannonJS is currently the ONLY 3rd party physics engine for BabylonJS... that allows meshImpostor. meshImpostor is how to get a physics impostor... that perfectly "matches" a complex shape such as a manikin. So, your manikin MUST use a CannonJS meshImpostor... for its physics impostor (like I did with the torus knot... which is a complex shape). Now for more bad news. meshImpostors ONLY interact-with sphereImpostors! OH NO! Thus... notice I changed particleImpostor... to be sphereImpostor... for the cloth (line 53)? I had-to. When it was particleImpostor, the cloth drops "thru" the shape. And notice the speed of the demo? Browser killer! 4-5 FPS? Nod. But, this is your challenge. Cannon MeshImpostor on the manikin, sphereImpostor-based sim-cloth for your garment. I don't mean to discourage you, but your hopes... are rather large. What you MIGHT wish to code... is a custom collision system. Perhaps it will be much less powerful and detailed than Oimo or Cannon, yet it will allow you to place garments upon manikins with SOME body-contour-following accuracy (spandex). But even then, garments and manikins are NOT simple bounding boxes, so simple mesh intersect testing/checking... is difficult. Now if you want to use "weighting" on the entire surface of the garment (so you can see how a dress or sport coat "hangs" on a person)... you will need many many many weight points and calculations (for proper-acting clothing). This is a big challenge for Javascript. Interesting, though. I figged I would tell you some little things about meshImposters and complex shapes. Perhaps others may comment. The "super-hero" move would be... get particleImpostor... working with meshImpostor (deep Cannon.js hacking and native-method calls). That would be essentially the same as coding your own custom collider/intersecter. You would essentially be creating "CannonJS For Clothing" ... also a big project, I suspect. I'm no expert, though, ok? I could be wrong about anything, anytime.
  2. (Wingnut giggles and points at Ozrocker for being pulled-over by the topic police) (Wingnut also reports officer Palmer to authorities... for being far off-topic... with his off-topic-ness comment.) heh Now we're REALLY confused, huh? Ok, but now, "BJS is moving fast"... umm... uhh... crap... I can't think of anything pertinent to say. Let's see... I need a universal "juicy" comment... to keep the thread alive. USA... 1950's saying... "So's your old man!" There, I said it. NOW we have some controversy and drama, again. Maybe Ozrocker will think twice next time... before using comedy to lighten the mood of a tense thread.
  3. endCapTri is undefined (uh oh) @Rolento... did this label avoidance thing. *nod* *thx* N. Containers. Groups. Borders. Padding. Are groups... containers? Should they wrap, overflow, clip, auto-expand-to-fit? Are borders added to padding? (thus, are border widths part of wrapping/clipping equations/consids?) Do groups need to communicate very carefully with their "assigned" border prim? hmmm. I love speculating about this crap. Sometimes Nox teaches me cool stuff. hehe
  4. Cool! Congrats on the new positioning system, Noxxy! Was the refactor caused by a situation with container flow/overflow/scroll/wrap/wordwrap? Bet so. Containment SUCKS! The folks at CSS Styles Working Group, and the folks who work-on browser "flow" systems... have all gone insane. They're all in mental institutes... getting shock therapy. It's very big. Padding == 12 mile nautical boundary waters. Wrap = South China Sea. Containment... is a HUGE subject. Don't let it take you down, Nox. Borders, paddings, margins, wraps, scrolls, overflows, etc... hasn't yet been learned by earth creators... so YOUR system of working with those... cannot be done perfectly, yet. (Wingnut being goofy.) Did you lose some backward compat on the primitives? Major changes to some of them? It's all okay and expected... along with time needed. Farm-out tasks if you can, Nockawa. I'm qualified to do laundry and fetch groceries for you, but that's about all. @thiendv's context menus were quite easy, though. A little steep learning curve, and some problems with isPickable when we installed it in the scene... but... worked good. Once we learned how the knobs were used, we turned them to the correct values. We were picking the skybox with the mouse right-click, and the context menu was bouncing around in the scene. Then we set skybox .isPickable = false (and some other isPickable tweaks)... and it all started working good. @adam's doing some things, too, I think, right? Working-with centering prims/wsc2d's on their trackNodes... I think. Maybe that's what caused the need for positioning refactor, eh? Thanks alot, Adam, dammit!!! (just kidding, of course). Thanks for your work on the prefect-centering issue, truly. Bounding box measuring hell, I bet. We also want to find that guy who wrote the "labels can't overlap" demo/system, recently. I want to make sure that his system STAYS WORKING. (I can't rem his name). SO... let's find him and his demos... and make sure the new positioning system... doesn't break his no-overlap system. If so, let's help him fix it. I think the "no overlapped labels" is a rather important tool to keep handy. ok, party on, guys!
  5. Hiya SR! First, that error has been seen in CannonJS, too. Even though it is annoying, I think it can be ignored, for now. No impact to physics operations have been seen so far, caused by that error report. BUT... it could be related to the ORDER that the physics impostors are added to parent/children. You should probably read this thread. It does some talking about the ORDER of impostor-adding.... when dealing-with parent/child compounding. This badly built Oimo document might be of some help, too.... for advanced OIMO learning/hacking. (I don't wish that on anyone) ("native" calls are scary!) And... lastly, we have seen SOME indications that... it is un-wise to scale a mesh that will be used as a physics parent. By using the meshBuilder system of creating basic mesh, you can set some mesh size/scale dimensions... without needing to use .scaling. Scaling, rotation, and position are handed-down from parent to children, and this is how it could be related to the "order of adding impostors". I'm no expert, and docs are introductory level, so far (but thank goodness and Raanan for those, too). Perhaps you can help us with advanced physics docs, in the future? Don't forget playground searching, too. Hope this helps.
  6. VERY nice, @thiendv! You ARE an expert in BabylonJS! I think you are ready to open 3D Graphics School and teach others. Well done! Only one (context) menu activated so far? No door or drawer opening/closing? It's okay. Perhaps you can create "Doors, Drawers, Context Menus and Color Changers" ...teaching playground, someday. Yes? Maybe in a year, okay? In a year, perhaps @Nockawa and his team (he needs MORE team, by the way) will have new context menus. They will be much easier to use than our current method, T. Anyway, again, congratulations @thiendv... your scene looks great and works great! COOOOOOL!
  7. Hi hunts. (Some basic obj loading - see console for mesh names.) When used at home, you must include the object loader extension. See Hope this helps.
  8. Hi K! No replies yet, huh? Sorry. I see no particles reflected in the mirrors of my xmas tree demo. Something is broken or something has changed in 2.6 alpha. These things are normal for alpha versions (work-in-progress), and thanks for the report. We'll make sure @Deltakosh sees this issue, and that it gets addressed before 2.6 official release. I wish I had more answers, but I don't. I know some webGL 2.0 things are being tested, but I don't know if those would affect 2.6 particles and mirrors. Perhaps others will comment soon. If not, I will eventually tour the 2.6 git-mits (github submits) and see if I can determine when/how the issue was introduced. Thanks again for the report... good find, well done.
  9. Hi BT! Sorry for slow replies. I am not expert, but I try to help. Please DL/view It is "stripped" (and white-spaced) dude.babylon. In "meshes" section, I have removed almost all values in big arrays... such as "positions", "indices", "matricesIndices", and "matricesWeights". Now they are only for looking-at. This .babylon file will not load properly. I broke it. Please take notice of matricesIndices and matricesWeights. Those affect animation. See all 58 matrix animations in stripped_dude.babylon? All are dataType 3. Go to some playground and enter line console.log(BABYLON.Animation.ANIMATIONTYPE_MATRIX); Returns: 3. All 58 animations... are matrix animations! They are being done to "bones" which are not mesh, but really matrix transformations, that happen to mesh... which have properties matricesIndices and matricesWeights. Starting to see answer to Q1? When you do see it, TEACH ME ALSO, PLEASE. heh. Q2: Here I was playing. I do funny rotations in line 25-26. In line 27, I get positionsKind data for meshes[1]. Then lines 28-30... I try to move (transform) one .position/vertex. Then line 34, I try to "write" positionsKind data back to object, with parameter updateExtends = true. (updateExtends adjusts boundingBox size if needed). As you can see, bounding box size IS growing, but I cannot make a vertex on dude's head... move/display movement. Maybe he is set updatable = false. hmm. Just playing with the mesh... having fun learning. Q3: and Q4: I have no answers. Possibly, JSON parsing/de-serialization performance is optimized by using these methods. Not sure. Perhaps @Deltakosh or other 3DMax exporter contributors will respond soon. Fellow forum helpers... please help, and please correct me if I have said wrong things. I am no expert in bones, skeletons, and their animations. (actually, I'm no expert in ANYTHING, except perhaps aimless talking.) heh. Darn. Matrix transformation animations! Coooool. Bad to the "bone". Sorry I wasn't more helpful.
  10. Hey @fenomas... notice that we (Hans and I) are not concerned about seeing the jitter, and we are not concerned about reducing CPU load. We just want to keep the player box atop the platform. But a THEORY we have is: Jitter affects friction. AND... we have a new issue that Hans has raised: Friction is asleep on sleeping bodies. So, if we move the platform while player box is asleep, platform-player friction will not work, and player will not move WITH platform. AND... we would like to learn about LOCAL linearVelocity and see if we can impulse the green box from side-to-side ATOP the platform... without affecting the platform (other than maybe tiny platform tilt due to mass position-change). NOW we're tuning some parameters. Ground-platform mass/friction, platform-player mass/friction, etc. But still, we have studies to do on auto-sleep... and when to wake, and why. If we slowly tilt platform... with sleeping player atop, will player EVER start sliding? hmm. Perhaps player box will wake when tilt starts. Tests ahead.
  11. AllowSleep on world. Wow, I didn't expect that. Cool, thx. Does it affect anything in our 5-minute jitter-off scene? Did you test it, @fenomas? This is your "working" demo, with both renderLoop anims disabled. The green box falls-off-of the red platform... after about 4.5 minutes (on my desktop machine). Is that "working"? Hans has done lots of "parameter-tuning", already. Telling him that incorrect solve... TWICE... well... seemed a bit hard-nosed to me. Then again, you didn't back-read the thread, so you didn't know what was already tried. *shrug* It's all cool. Hans has been waiting a long time... for better help than I... and we have both done some begging for help... for about what? 3 weeks now, Hans? A month? Not many forum helpers wanted to come to this campfire. We're glad you visited, Fenomas! Sorry for the long thread... but... it's been THAT long unsolved. We just kept experimenting and trying things... and failing. But we were also working on an issue about scaling physics mesh-shapes, too. Thx for the reminder about world.allowSleep. I think that is the solve we were looking-for. Added that line at 157. That demo now shows a quick-change to player.sleepState = 2. And, I'm not seeing any indication of jitter-off. YAY! Perhaps we can learn about auto-sleep, now that it is activated and apparently working. Who would have expected world.allowSleep to be false by default? hmm. Okay, we have things to work-with, now. New life for our dead-end thread. Thx @fenomas, well done.
  12. You are using a tranquilizer dart for sleep, and "smelling salts" to re-awaken! heh. That's not the same as "falls asleep" Comedy aside, I think all should be automatic. There should be no need to test for intersection, and no need to force sleep(). It should be magically done FOR us. (maybe) hmm. I'm going web reading about this - see if I can learn something before I fall asleep.
  13. @fenomas, what IS sleepSpeedLimit, allowSleep, sleepTimeLimit, sleepState supposed to be used-for, then? When is the auto-sleep system SUPPOSED to be used? For what? Why do these parameters exist... if they are not used to stop forever-jitter? I'm confused. (thx for clarification) By the way, I turned-off all the before-render animation in your demo: Although I didn't watch it... I estimate about 5 minutes until the green box jitters-off the platform. Fenomas, can you (kindly) clarify? Auto-sleep cannot work... when gravity is a constant force? Do you know? (This was talked-about in previous areas of thread. I think Hans saw sleepState = true IF he reduced gravity to zero.) Or maybe, sleepState NEVER had ANYTHING to do with jitter? Maybe it's not intended for that. (these are some thngs we could use answers-to, everyone). Hans has been a delight to work-with, too. Kind, extremely patient, entertaining, willing to experiment and invent, reports all discoveries, just a great guy. I highly suggest we try to treat him kindly, in return. Yes, multiple issues have been addressed, here, but still... topic is on-subject with... WHY no-sleep/why jitter-off? Perhaps Hans and I are on a wild goose chase.
  14. Hiya @SebRomeo, welcome to the forum. Sorry for slow replies. Does "infinite relative map" === "infinite terrain"? I'm no expert in webGL, but we DO have some BJS infinite terrain projects nearby. @NasimiAsl's Blog500 is such (pg demo, too, use down-cursor to back-out of Nasimi's "home cylinder"). And I believe @Pryme8 has some noise-driven infinite terrain in his Teriable demo. Tiled grounds has been tested a bit, too. Please visit the 3 links for CĂ©lian Garcia... seen in our Offsite Tutorials List. I played with tiled ground a bit myself... here. It uses a divided-up displaceMap/heightMap to create 16 tiles, which I then try to assemble back together. Mostly, I fail. This demo/series is still awaiting a lighting-normals "sewing machine" - to "average" the normals across the seams - to avoid color changes at the seams. There's a massive thread about it all... here. All participants in that thread... died of boredom. heh I hope I am on-topic. If not, sorry, please clarify. I wish I had more/simple examples to show... but I don't. Perhaps others will comment soon. Welcome again.
  15. Hi guys! This is some heavy thinking, here. Binki, I feel your pain and curiosity. Here's my take. The best compound impostor... is made-of various other impostors... which are cooperating (grouped). But, think about that. When two sphereImpostors are linked/jointed together, they are in battle. So, to build a compound impostor, it is more sane to "sum" the area of the two shapes, and attach a box impostor of THAT general size. Since ONE of the two shapes will be ONE "extent" of this new "summed low-detail boxImpostor", we might as well use it as the "master" of the compoundImpostor. I think this is why ONE of the shape-parts... is used as the master. It is considered a boundingBox extent (one edge/corner of the new derived bounding area). OR, I could be completely wrong! Has anyone ever wondered... what would happen... if child mesh overlapped parent mesh? (both physics-active) You know how those darned impostors HATE being inside one another, and prefer to "spit-out" each other? Coooool. Would one impostor be put into constant "barf it out" mode, while the parenting says... "you ain't going nowhere, overlapped child impostor". Parent-child wars! CPU mega-chow! Pretty soon your browser's immune system would start breaking-down, and then... blue screen of death! err... okay, maybe not that. Good questions/thinkings, Binki! Gotta think about... "What IS compounding?" When the sphere impostor is attached to the box impostor... don't you lose the best features of both? Really, they should be distance-jointed together, so sphere keeps its sphere-ness physics, and box keeps its box-ness physics. Even then... that joint... hurts the box and the sphere. They are both hands-tied... so they can't roll with the flow. Over in another thread, I think @Hans and I discovered that we shouldn't ever scale the parent, but that's all I have learned. (I hope you weren't expecting anything wonderful from me) heh