Wingnut

Members
  • Content count

    3,704
  • Joined

  • Last visited

  • Days Won

    80

Wingnut last won the day on May 16

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

3,351 profile views
  1. *nod* thx. Good catch... views nearing 65536. Time for another goofy PG demo? Ok... here. Raanan's cloth demo used "particleImpostors", and they don't work against the meshImpostor hemisphere bowl. So I changed them to sphereImposters, and I set the resolution of each "point-shape" very low. AND, I made the points fatter. This runs slow as molasses on my machine, but I probably have a big fat bog-log in the code somewhere. Lines 107-112 is where the points get their physics. If the point is a yellow "stead", it gets no mass. It is a hang-point. Otherwise, it gets mass. Set some mass in line 109, and the cloth will drop to bottom of bowl. Set restitution to 1.3 in lines 109 and 112, and things can get violent. So much so, that portions of the cloth are blasted-thru the sides of the bowl. Fun! When using 2.5 mode, cloth POSITION is off-centered... in a corner quadrant, which is EXACTLY the problem I see with the heightMapImpostor (another thread). HeightmapImpostor works in one quadrant of the terrain. Other 3 quadrants are fall-thru. I smell boundingBox.extendSize (and .center) issues, I do... in 3.0. Hey, I wasn't playing with this PG, people. I was working a forum customer service ticket. No, really, I was. I was hauling a big truckload of research to an issue, and this PG jumped-out in-front-of my truck. I had to lock-up the air brakes. Had to take a detour. Really. I would never lie.
  2. Hi @lery0, welcome to the forum. Could you reproduce the problem... in our "playground"? Here is playground search... http://doc.babylonjs.com/playground?code=lensrenderingpipeline 18 things to play-with. Are you importing mesh? Are they complex/irregularly shaped? Have you tried the picking... using only built-in BJS mesh shapes? Any differences seen... when using BJS 3.0 alpha vs. BJS 2.5 ? Perhaps modify https://www.babylonjs-playground.com/#1OUJRM#0 ...add some picking... see if you can reproduce same problem? Feel free to make many edits/runs and saves, and paste new after-playground-SAVE URLs to here. (and tell us about your discoveries) When you make a simple playground that shows the issue, it is easy for EVERYONE on the forum to help/test. Thanks.
  3. Whatever ya need, but forum search will find it. Dump-to-html doc b4 axing... would be nice. Still searchable, then. Probably need to run-it-past DK when he returns from vacation. Mostly, I care about my previous post... Q&A questions going long-un-answered. That's more important than the length of this thread, at this time, imho. Let's see if @rich will visit and give us some pointers. I STRONGLY-prefer dump-to-webpage before killing. Force-set views to 0, at will, Rich/whomever.
  4. Wow, we got 0-reply questions... on PAGE 3 of the Q&A forum. OMG! Calling all forum helpers!
  5. Cool. Yeah, syncing the sampled-type audio would definitely be nice, too. I bet there's more enthusiasm for THAT... than there is for listening-for-sysex from a midi player. People sort-of forgot about midi... but it won't die. The Chuck E. Cheese band will ALWAYS need it. That thing that JcPalmer pointed-at... that was weird. They send the midi file into a converter (pre-process into another file type), converter available live online, and it converts to something... looked like "blocks" of samplings. Then they feed that into a JS synth, which has no wavetables, or maybe software based wavetables with a half-hour load-time. And, the embeded sysex messages could be lost along the way. "Faked" midi playback, as Davrous puts it. *nod* Can you imagine how wonderful a midi timeline/eventScheduler would be? Playground movies! 2 hour run times... an entire war saga... red mesh vs blue mesh... big orchestration... tunt... tuh tuh tuh tunt... marching into battle...tymps... swell... swell... SWELL... CRESENDO!!! Cannon fire. A six-stringer eh? You probably play bass just fine, too. Likely some keys, too. Very cool. Once upon a time, I decided I would learn everything I could... about my Alesis s4 rack synth (a QuadraSynth without a keyboard). The s4 is a wonderful sound module, and by sending the right sysex at the right time (from a Cakewalk midi)... I learned to make that S4 SING! After some of my demented experiments were done, I could hear that s4 panting and wheezing. Check this mess out... http://webpages.charter.net/wingthing/html/s4/s4sysex_p08.txt What kind of idiot... would make such a... ahh nevermind. We music tards are a little "off"... you know well. Yeah, keeping motion in-sync with music... most people still HAVE TO render to video. What fun is that? The gamepad doesn't work during play! heh
  6. Hi again. Much of that... is good info... thanks for sharing it. That might help locate the problem... cool. I have had SOME luck... with standard heightMaps... but using the Cannon MeshImpostor and not the heightmapImpostor. http://www.babylonjs-playground.com/index2_5.html#1YOCO9#40 Occasional fall-throughs, but still much better than current heightMap impostors. *shrug* Rumor has it that MeshImpostors ONLY interact with spheres, but I think I saw a boxImpostor interact with a meshImpostor, a couple weeks ago. My mind has been a bit blurry, lately, but I think I got a decent bag of weed this time, and that might be causing it. One thing to note... car tires are spheres, or at least CAN be (scaled narrow). So, if a guy was to build a 4-wheel soap box derby car, it MIGHT roll down that bumpy meshImpostor hill just fine. Perhaps worth a try. If you try it, tell us about your discoveries, if you have some. Thx. I have still seen some "start in slow motion" physics demos in BJS 3.0. They seem to run faster... in BJS 2.5. If you DO get a slow-motion demo start... you can browse to http://www.babylonjs-playground.com/#1RKZXB#32 THEN change the URL back-to the slow-motion demo, and it should run faster. Not sure what the story is, there. One of MANY sticks in our campfire. That #32 demo above... works pretty good, eh? It uses a "Wingnut-hacked" CannonJS plugin _updatePhysicsBodyTransformation(). The terrain MUST be square. Rectangular... has many problems. Oh yeah, if #32 doesn't "speed you up", http://www.babylonjs-playground.com/#1RKZXB#31 will work. #31 has never failed me... for speed-up. Go fig. #31 has a LOT of code from the physics system... hijacked into the playground. #32 has ONLY the "affected code" that I did hacking-on. Until moments ago, I thought #32 ALWAYS started at proper speed... but... moments ago... it started in slow-mo-mode. Could be my computer, but it is not a browser-based issue. Slo-mo mode happens in IE, too. Raggar/anyone... if you DO see a "slow-mode" and "fast-mode"... could you verify it to me? Thx. It could be my computer. FPS stays same... no matter fast mode or slow mode... on my computer. And that #31 playground ALWAYS starts in fast mode... for me. Love it. Ignore/remove the green box overlaid on the terrain... it's just there for testing. Anyway, meshImpostor might be useful for ya... until other things get fixed. Party on!
  7. Me not smart enough, either. I think it is a boundingBox issue... but I've said this a few hundred times before. It is FAR-reaching... affects physics, affects the collision ellipsoid issue that I'm wrangling... it's a big and important bug/issue. None of the big dogs seem to be losing any sleep over it, which I totally don't understand. Even the little guys should be "on this", right now... but it seems few care. As you know, the people sitting around this campfire... none of us have our "Class-A Pyro-Technics license" and so... we stir the fire with our sticks... fairly aimlessly. heh. We're just stirring and staring and drooling in fascination... with the campfire. There is a type of mesmerization that happens... when campfires are stared-at. Sometimes there is more drinkin' than thinkin' My best skill is in building playgrounds that test/prove stuff. What to do after something is proved... well... that scares the hell out of me. I could make a mistake that would burn down Babylon.
  8. Latest: http://www.babylonjs-playground.com/#WWCK0#30 This PG is for climb-over/dive-under testing. Only barrels. Left barrel is the "mover" and its Y position is precisely set in line 270. See info in line 269. Hold down the D key. Keep holding it, and eventually see barrel (left) "climb-over" barrel2 (right). Clearance height is 36 - an interesting number (see more below). Needless to say, things are way way wrong. Mesh are far apart from each other... and still causing collision. Set line 270 Y value to 24.0, (RUN, then hold D key) and we get "dead stop" collision. Set line 270 Y value to 11.9, and we get "dive-under" (hold D key for a long time, it will dive). Let's see... 24.0 - 11.9 = 12.1. The barrels are 12 units tall. Hmm. All console reports are ellipsoid sizes, not positions. Right barrel (barrel2) is at Y-position 6, half it's height (line 292). No barrel .ellipsoidOffsets are set. Actives keys are WASD (laterals) QE (altitude) R (reset mover) I think... we got trouble... right here in River City. Continuing tests. I'm too scared to try a 2.5 version. hehe I have a collide observer on barrel... at line 282-285. It is working, but its red text colorizing... is over-ridden by line 187 which happens every keypress. De-activate 187 to see text change to red on-collide. Unfortunately, there is no barrel.onCollideClearedObservable ... to change text back to yellow when collision has cleared. I guess I could TRY to code one.
  9. Thanks guys... these look very interesting. At least some folks are thinking about it, eh? Unfortunately, there is no mention of MIDI in the html5 spec. Not that there SHOULD be... but... I think the audio element is not being considered AT ALL... for playing midi files. That's sad. This probably means that only <embed> and <object> can play midi, and they will hand-it-off to system... guided by the .mid mimetype to find a player. Compared to an .mp4 or .wav source for an <audio> element... umm... I don't know how it compares. The <audio> element seems to have quite a few limitations for the allowed file/mime types, (.mid apparently isn't one of them). <audio> probably uses a player built-into the browser, or something like that. "Stream-audio" (samples) like .wav, aiff, mp3, etc... don't need access to the wavetables on the soundcard/on-board audio. Only midi needs the wavetable... to get its instrument sounds. hmm. Thanks for the responses and research, guys. Reading reading reading.
  10. Hi D. Yeah, thx. Actually, hmm... in MS land... I think there is a midi-mapper thing. The only part I would be interested-in... is "intercepting" the midi OUT data. I have no need to trigger mesh with midi-IN device, but others might, someday. Users are allowed to select which "player" handles their .mid mimetype, I guess. Do all these players... use a "mapper" of some kind? (asking anyone). Wouldn't it be great if the JS object... could interface to these mappers... AS IF the JS object were a midi hardware device? Perhaps read-only, from the mapper? hmm.
  11. Realtime song gen, right? Can't do it. Outlawed in the first post. Song won't stay in tempo... latency problem due to morphing spherical harmonic that Elderwolfy put into the scene. Gotta get sysex messages from midi file... real time, while being played. No cheating. The midi port or soundcard... is the boss... sets the pace.... stuff like that. If song tempo-slips at all, we're all gonna be arrested for interference with hardware.
  12. LOL! What a great helper you are! (Wingy hands you a broom) Here... keep the thread clean. And don't molest the girlies. But yeah... asking JS to reach-across into... soundcard-land. Or... into midi-port land. hmm. Or asking soundcard-land to yell at JS when you see a JS-targeted SYSEX message roll-thru. But this is important. This opens up... webGL movies.... all based upon LONG midi file. Could be a 24 hour song... if your webGL story takes that long to present. FUN! Some events... could be told to start .wav/mp4/whatever files... too. Want your mesh talking to each other? No problems.
  13. Hi gang. Question: Has anyone thought about sync MIDI to scene events? MIDI sequences allow insertion of SYSEX messages... and often these SYSEX messages (among the note on/off data)... contain something called MMC... midi machine code... used to automatically turn knobs/adjust settings... on certain midi playback gear (such as soundcards and midi synthesizers). But we demented experimenters... would LOVE to access those sysex messages... and make our 3D mesh do things... at that playback time. We (I) want to make my mesh... dance to the beat of the midi song. If I insert sysex messages into my midi song, and IF I can "see" those events happen with a scene observer... that would just TOTALLY ROCK! (literally!) I know @davrous is a musician/composer, and he knows some seriously-advanced stuff about JS audio. I hope I can "entice" him to come aboard this cause. Also, I don't want to use code to play the song, noteON-by-noteOFF. Ideally, I want to insert an HTML <audio> element into the dom tree, and if the song contains sysex messages of type-BJS, I want them to activate sysexMessage observers in the scene. Would THAT be cool, or what? You ain't NEVER seen "Mesh'n'Light Shows" like the ones Mr. Wingnut could produce... if that "choreography system" was operational! YUM! UberYUM! Ok girls... can it be done? Is there a wall to cross? A river to ford? Do we have the bridge-making gear? Thoughts welcome... any thought from any one. Thx! (Again, let's NOT make scene code play (poke) each note, step-by-step. That type of system will not stay in-tempo. Let's avoid that idea.)
  14. Latest... is #28, now. I'm doing some measuring in lines 23-25, making sure dude's sphere is exactly the same size as dude.getBoundingInfo.boundingBox.maximum.scale(2). It is. I also activated line 4... this.refreshBoundingInfo(); SOME forum users might have noticed that I have been "chasing" an elusive "difference" between BJS 2.5 boundingBoxes and 3.0 boundingBoxes.... for over a month, now. So, just for fun, I fired-up #28... in BJS 2.5 mode. http://www.babylonjs-playground.com/index2_5.html#WWCK0#28 vs. http://www.babylonjs-playground.com/index.html#WWCK0#28 Differences! Positioning differences, not sizing differences. hmm. I'm still looking at stuff done in this commit, but I'm not sure of the purpose of these new "world" methods... introduced in 3.0 (centerWorld, extendSizeWorld, maximumWorld, minimumWorld). ---------------------------- Off-topic stuff ------------------------------- Is BJS going out-of-business? Seems sort-of ghost-town-ish 'round the forum. Maybe everyone went GearVR coding. :x A special thanks to @jerome for doing some fairly-recent inside-the-ts documentation. Way to go, Super-J! Don't shoot yourself if the BJS ship is going down, J-man. It's all for the greater good (I hear). (Wingy chains-open the Gates of Babylonia, affixes padlocks to prevent the doors from closing, and swallows all keys.)
  15. Hi gang. While I'm waiting for anyone else to verify this physics/boundingBox issue, I wanted to point-out something else. User @ben_a_adams, who kindly refactored our vertex buffers... making them "interleaved" (sounds scary), once provided a nice link to an English talk about networked physics. Worth a view, I think. Thx Ben... and Glenn. That Glenn Fiedler guy says "Quaternions" really fast! Listen carefully. heh. Also, when he says "at-rest"... that is the same as our "isSleeping". He also says "at-rest" very fast. Fast talker... but... Glenn has definitely done some comprehensive (meticulous/detailed) tests about networked physics. He summarizes the different methods... real nicely. (~ 1-hour video presentation) I even understood some of it! Wowzers, Penny!