Wingnut

Members
  • Content Count

    5,640
  • Joined

  • Last visited

  • Days Won

    117

Wingnut last won the day on December 6

Wingnut had the most liked content!

About Wingnut

  • Rank
    Advanced Member
  • Birthday 12/15/1957

Profile Information

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

Recent Profile Visitors

7,534 profile views
  1. Wingnut

    GUI Fill

    hahaha... damn, I am SO blind. (hug) Hey DylanD.. are you on the new forum, yet? Perhaps start a new Q&A thread over there... "Testing GUI Health Meters" (anything you choose)... and we'll keep doing experiments and talks. Meantime, I'm marking this thread as solved. Message me if you want it re-opened for some reason. See ya soon at the new forum.
  2. Marking solved. PM me if needed.
  3. Wingnut

    GUI Fill

    Hi DD. I can't imagine a situation where a power/health meter or status bar... would want/use a moving container. That causes the entire health meter "control".... to move-around upon/within the advancedDynamicTexture (adt) (or upon/within other types of containers such as a grid cells). Few people would animate-move a control... after it is placed upon/within the adt container. But if YOU are happy, DD, then I am happy WITH you. https://www.babylonjs-playground.com/#7EPK2H#9 Pretend white-border "outer" container... is where you want the health meter on the screen... in your game/project. You need it to stay there, yes? Try to get your health meter... operating within that white box. Kenya? (can you?) One more wrapping container (outer) shouldn't affect your new control at all, right? Does it? I put a thin red line around original container... so we could watch it moving. SideNote: Hey @Deltakosh/others... line 17 - outer.left = "50px"; ... not working? outer.top seems to work, but not outer.left. Likely Wingnut mistake.
  4. Also, that looks like a question for a JQuery forum. On the way to the jQuery help pages and forums, you might wish to change 'target connected' to 'target_connected'. Cya later, somewhere else.
  5. Wingnut

    New forum

    Yeah! A robot... reads post after post after post, gathering the html, page after page... all day sucker. We keep squirting it with WD-40 until... after 90 days of 24/7 "gleaning"... it finishes, and promptly falls to pieces from robot fatigue. heh. "Mister Glean, Mister Glean... sucks your databases clean... by Mennon". errr... no, I got my brands confused. Wingnut checks Naz's "hunter-gatherer" license and it is valid and up-to-date, with proper certifications. hmm. Ok, that's an option. Throw a ton of money and hugging at Naz, and ask him to build his post-reading robot, if he (ever) has time. We really don't need any permissions, right? We just need to act like a user... who reads every post... one after another... for 3 months. Sort of like a "denial of service" attack engine. Thanks for the offer-idea, @NasimiAsl. Interesting and nice-of-ya! I say... name it... The P. I. G. G. G. ... programmable intelligent grunting gulping gatherer. Pigs "forage", and "nudge" and "root", and will eat anything.
  6. Well, remember... that the velocity of the mouse pointer... at the time of intersect... matters. With a fast drag, each diff value is large. Slow drags, the diff values are small. Sooo... it is difficult to determine how many diffs to back-out. Smarter to do some quick boundingInfo measurements, and force some positions... based upon those. De-overlap the two bounding boxes... but just barely de-overlapped. Just MAYBE... a function could be added to BJS Tools... deOverLap(mesh1, mesh2). mesh 1 doesn't move. mesh2 re-positions itself... using the shortest distance... to de-over-lapped state (from mesh1). Interesting. (Might need an option to lock the Y axis during re-position. ie. don't let mesh2 exit intersect state... via moving above or below mesh1.) Or, perhaps some other prediction tools could be thought-up... now that we know more info. @timetocode - What a fine explanation! THANK YOU! Fantastic.
  7. @JCPalmer Yuh, yuh, yuh... you are correct. Why do you think I'd try to "munch" a lens flare? See my eyes? Roadmaps, baby. heh. The lemon wasn't bad, but... I think I like "Master K" better. We really love skunks 'round these parts. Indica-tive, ya know? But transporting skunks is was risky. I have SO many new things to learn/try, but the stores won't be opening until 2020, I hear. hmph. But yeah, a new feeling of freedom has come-upon our state. I hope it comes to other states, too. Off-topic? Does it matter anymore?
  8. Hi gang! Well, here ends The Wingnut Chronicles, and this forum. 1,459 replies 96,174 views Not quite 100,000 views, but close. This forum is going READ-ONLY soon, so maybe the views will still increase into 2019. Come check out our new forum at... https://forum.babylonjs.com/ I'm still on the road to the new forum. I snapped some pics... http://urbanproductions.com/wingy/ipad_snaps/ip04/viewer.htm By the way, good whiskey helps... for getting a lens flare un-stuck from your tongue. Cya at the new forum! It ROCKS!
  9. Wingnut

    New forum

    This is the part I don't believe/trust. Words come easy, but follow-through is subject to folks "changing their minds". We don't need access to the current DB. We just need someone near the DB... to get us a backup. Not necessarily one of "our people". Ask the folks near the DB to make a copy for us. What's so difficult about that? Are we asking for the moon and stars? No. Just a backup. Would it be a binary mess that we couldn't decipher anyway? Can we fire-up an Invision forum later, and re-activate it all? (in case of emergency) Please, let's not be flippant/negligent about the value of this archive. These changes are happening much too fast and (possibly) without proper ass-covering. How about we take another month or two to completely investigate our back-up options? Just one wrong move during this hack'n'slash transition, and our knowledge base could be killed. Are there animosities involved... in these decisions? Is someone pissed at someone else? And while we're at it, what are the backup options for the new forum? Are we destined to go thru this "nail-biter" thing... AGAIN? So stressful. Don't we NEED to be ready... to revert, in case the new forum or its authors/support... suck beyond belief? This whole operation feels somewhat haphazard to me... done "on a wing and a prayer", perhaps. Maybe it's my inexperience in these things... that causes these worries. About 10 million future BJS users... have not read ANY of our posts, yet. People tend to quickly label as "everything is fine" when in-fact, everything is NOT fine. This premature "it's fine" labeling is often caused by laziness and rush. No matter the rush to fly to the new destination, take some time to pack some luggage and make sure your "home" is safe... before departing. This will be my last comments on this subject, I think. Sorry for all the worrying, but I'm worried. I love and cherish the posts in this forum. Aside: Hey DK, they make laptops that are ALMOST as small as tablets/pads, and almost as easy to take to lunch with you. With a laptop, you can get a REAL keyboard, and you can avoid thumb-typing. Then, you could even type sentences longer than "pinging RaananW". hahaha. Ahh, it's so much fun to pummel tablet thumb-typers. They yell "Hey Wingnut... more white space in your posts, please"... and I yell "Hey pad user... less white space in your posts, please". fun. The new forum looks kind of white-spacey... like a tablet user was involved in its CSS/design. The desktops vs. mobiles "styling wars"... continue.
  10. Wingnut

    General GUI troubles

    Great conversation, guys - thx for your work/tests/fixes! https://www.babylonjs-playground.com/#7EPK2H#2 Is THAT border acting correctly? Just curious. It sort-of looks like border and background are on different z-layers. Cool. More on that... far below. (oh no!) Wingnut mentally wanders-off... I'm still thinkin' that... "border" (and thickness) needs to be a control of its own. When GUI borderControl is invented, we get a PILE of versatility, and the world of currentMeasure (for other controls) becomes much less stressful to the GUI author - mainly DeltaFlyer. The borderControl would be very "extensible", whatever that means. Once it becomes a separate control, the world of fancy borders and marquis and a bunch of other animated and fancy crap... comes into view. When you need a borderControl added to ANY other control-type, you push that borderControl into the targetControl's .adornments array. 'Adornments' becomes a whole new area... to add "features" to any control. Add-ons. Layers. Even a borderControl... used mostly as an "adornment control"... has an .adornments array. Or maybe... 'adornments' are not really a control AT ALL. They are adornments. Similar to behaviors. BorderAdornments might have a property to set whether the border... SURROUNDS the target control area (blocking no targetControl surface area)... or OVERLAYS it (blocks edges of the targetControl surface). I dunno. Adornments would be add-ons. Things like... "graying-out" an inactive GUI button, could be done with an overlay adornment. A big red "X" across a button, easy, by attaching an adornment. One adornment can be used on MANY controls... just put a ref to the adornment... in the control's .adornments array. Controls could be told to ignore the adornment if the .build call to the adornmentObject... fails or times-out (possibly because the adornmentObj/Func 404'd when retrieving a web texture/svg it needed). Adornment controls could be designed... ready to animate... and can be told to start animating as soon as they are put into a targetControl's .adornments array. Rounded border corners could be troubles, though. Round-corner borders need to remove/re-paint background textures/colors... of the targetControl. In that case, the adornmentControl is SERIOUSLY imposing itself (forcing things) upon the targetControl. But, I guess an overlayed (non-surrounding) square-corner border... would also re-paint the edges on the targetControl. *shrug* I really don't know enough about the layering possibilities of a GUI control (and isBlocking hassles thereof). Perhaps... two types of adornments? Those that need to modify the targetControl paint-job, and those that don't? intrusive/non-intrusive? hmm. Just crazy talk, huh? I get that way when I watch Saturday morning cartoons and drink too much over-powered coffee. Hey NRA... sorry that the recent GUI upgrades caused stress... about client deadlines/criteria. We don't like to see that happen. We hope you are still on-timeline.
  11. Wingnut

    New forum

    Hiya V (and others). I second that question. I would LOVE to have the old forum contents... become webpages that we can EACH archive. I have written a crap-load of in-forum tutorial-like posts. I would HATE to see them destroyed... ever. I wonder how big a "dump to html" would be. If we could dump all old posts... to html... and I get a copy... that would be best. That way, my huge pile of yapping... is safe... and it's in OUR hands, not dependent upon anyone else. Also, I wish the new forum was a little less "preachy" about trying to control my niceness, and a little more preachy about how they are going to quickly fix/adjust all the broken and crappy things we find in their forum software. ie. Concern themselves with THEIR "nice", and let us run our own lives. Let's see if THEY act nice, and have ANY credentials to try to tell US how to act. We have 5 years of success under our belts. THEY are the ones on-trial, not us. We should be severely scrutinizing their issue resolution channels/techniques, and they should bending over backwards to ensure to us... that they have a good one and that we will be loved. When doing Us-Them wars (capitalism)... NEVER trust a them. Them's often have a big cock'n'bull "front" or "facade" erected, and zero integrity or intestinal fortitude to back it. This also applies to words such as... "old forum will remain read-only available". Don't believe it. Get a safer copy of our stuff... PLEASE, if possible. Don't trust ANYTHING. Once we get our old "stuff" into web pages form... we'll publish them at github.io. Then, we'll go thru our docs... and find/fix all the links to forum posts... re-targeting them to github.io pages/anchors. Safer. Wingnut won't cry because someone pissed-away 31 trillion pounds of Wingnut noob-teaching. PLUS... everyone else's posts that I still need to learn stuff-from. The forum is a HUGE teaching/learning center. Let's fig a way to save it and re-presentation it, somehow. Worst case, somebody, just dump the entire forum DB to DVD, and I'll pay for a copy... allowing future rescue if necessary. SOMEBODY, get us some more-safe backups and archives... please. Don't trust the words of ANY "them"... really. Sorry if I topic-wandered outside-of the scope of this thread. Perhaps a "backing it up" thread is apropos.
  12. Ahh, Collada. errr. BJS in XML. errr. Can you repro that in a playground, please? I want to see that. We can create a node... without first creating a scene? I bet we need to be Wizard-grade or higher. Might need a magic potion or some faerie dust. I've been staring at https://github.com/BabylonJS/Babylon.js/blob/master/src/babylon.node.ts for 45 mins, now, thinking about bigopon building his own nodeConstructor, or maybe adding a setEnabled(false) default behavior on all nodes. Wingnut == lost. I'm really not qualified to comment on this stuff, though. But I HAVE been interested in building a BJS scene completely with XML or similar. Then we can use xPath and XSL transforms against the DOM-ish scene graph... for filtering and other transform fun. errr. A different kind of 'transform' than the 3D type, of course. <scene clearColor="black" > <mesh class="bigopon" type="box" size="5" enabled="false" color="red" /> <light class="bigopon" type="hemispheric" direction="0,1,0" enabled="true" intensity="0.7" specular="blue" /> <camera class="bigopon" type="arcRotate" alpha="-Math.PI/2" beta="1.2" radius="40" attached="true" wheelPrecision="200" /> </scene> Coooool. BSML 1.0 (Babylon Scene Markup Language). We even write a DTD (document type declaration) so we can test if a given BSML file... is valid BSML. Wingnut wander-off: Packet-serving becomes scene-serving becomes node-serving... Ted Nelson - Transclusion. Bigopon logs-into our new 3D forum, and gets an XML <avatar> node from all visible forum-users... to be included in his "forum scene". All the mesh (avatars) in his scene... were "transcluded" from many places. Historically (back in the olden days), transclusion was also part of trans-copyright and micro-pay... it presumed that all links be 2-directional. Instead, Timmy Berrners-Lee screwed up the web forever. One-way links go stale. 2-way links can't. But transcluded webpages/XML (pieces retrieved from many places) can be slow-building (yawn). Still, though, there's not many formats that have the hand-around-ability and ease... of a packet of XML (a node).
  13. Ahh, you want to "predict" if the "upcoming" position change... will cause intersect. Yep, been there... wanted that. After mouse has done a pointer-drag... Preferred method: IF upcoming mesh move WILL cause intersect, don't move the mesh, and perhaps return pointer to pre-drag position. Kludgy method: IF mesh move HAS caused intersect, move mesh to PREVIOUS non-intersect position, and allow continued dragging without interruption. (disallow mesh overlap) Did I re-state issue correctly? I hope so. Intersection prediction. "Look-ahead". Ok, anyway, I modified a playground... https://playground.babylonjs.com/#1UK40Z#4 Notice I disabled lines 154-156, and tried using some fancy line 153. Notice it has a "scale" on it, which is the same as an amplifier or "power soak". Line 153 eliminates diff2, and instead "negates" diff... but then amplifies that amount... * 1.5 (50% more counter-diff). SO, I modded line 158 to use diff instead of diff2. AND, I added or adjusted line 161... so that line 166 operated correctly when we "fell thru" to it. Nothing really changed except... it doesn't get "stuck" anymore. Perhaps it is easier to see what is happening... when it quits getting stuck-upon-intersect. In line 153, change the 1.5 to be 1.0, and we get stuck-on-intersect again. Go fig. Perhaps we can learn why. https://github.com/BabylonJS/Babylon.js/blob/master/src/Culling/babylon.boundingInfo.ts#L217 Nothing in there indicates a reason to get stuck. hmm. COULD IT BE... that WHEN an intersect happens... 3-5 diffs continued to happen. In other words... it took time for intersect to be triggered... and 3-5 mouse drags happened SINCE the REAL position of intersection. SO, you and I try to "back-up" the mesh position ONE diff-level. BUT... that's not enough of a "back" to make it leave intersection state. We actually need to back-up the mesh 3-5 diffs. We need to set currentMesh.position to the current position minus 3-5 diff-moves. THIS is why backing-out 1.5 diff-distance (150%)... takes us out-of intersect state. Perhaps, this value needs adjusting or changes, depending upon how fast the pointer was traveling at the time of intersect. Drag "velocity" will likely affect the size/magnitude of each diff-change value. hmm. Heavy theory, eh? I could be right. Ya just never know. Probably not. heh ------- getGroundPosition() is an interesting func. It returns a "wobbly" diff.y... because of camera angle vs. ground angle, so I do a little currentMesh.y position forcing... in line 147. ------ SO, I have no real solutions, and I haven't designed a "prediction system"... but maybe SOMETHING is helpful, here. Let's do more experiments and listen for more/wiser comments.
  14. Wingnut

    GUI Fill

    https://www.babylonjs-playground.com/#7EPK2H#4 One more. No images, all rectangles. outerrect.myvalue 0-175 sets the amount of green fill added from the left. I have a random value setter... turned on. Probably off topic, and certainly not a single control. 2 controls, as a matter of fact. StretchX (which is also compressX?) is likely wiser, if the image can be stretched/compressed on one side only. I dunno. Do we need GUI healthBarControl v1.0? Maybe, eh?
  15. Wingnut

    Universal camera on mouse up

    Hi again. Hey, good info-gathering/reporting, thx! You should probably try canvas.onMouseOut or whatever. There has been other forum threads about mouse remaining in "drag mode" after it exits the canvas area. But I can't remember the fix. Be sure to search the forum for 'iframe' and maybe even 'pointerLock' (because a mouse that gets stuck in drag-mode... after it accidentally is dragged off-canvas... is SIMILAR TO pointerLock). It's NOT a pointerLock-based problem, though. iFrames are strange. They are "isolated"... in a rather tight security sandbox. There are 17 returns when doing playground search for 'iframe'. Might be something to learn, there. Perhaps... don't use iframes? *shrug* Anyway, take a look, at our docs... https://doc.babylonjs.com/how_to/gui See the little "eyeballs"? Click on those, and a BJS scene "pops-open", and they don't suffer-from "accidentally drag-camera-pointer off-canvas" problems. BUT, they DO allow camera dragging even when the pointer exits the canvas area. SO, maybe not the correct solve, yet. Issue review: DOM-event for canvas onPointerOut/onMouseOut... NOT seen triggering (so far - needs further tests?)... if pointer leaves canvas while dragging. buttonUP while pointer is off-canvas... not seen by DOM, either. Ok, stay tuned for better comments from wiser people than I.