continued_at_new_forum The Wingnut Chronicles

[JCPalmer]

Good follow up.  I have not looked a my console for a while, and I do not get these constant messages any more.  I have also turned off writing the fps to the screen in my html since, which was probably causing it.  Interestingly, the reason I turned off displaying the frame rate was I thought displaying the frame rate was slowing the frame rate down.

 

I have implemented my own application level tracking:  (total deformation CPU, total wall clock, & # of frames) for shapekey testing, because I was concerned about being CPU bound.  A report is written to log file.  Thought I was going to throw it away before production, but this has got me to think I might leave it there, just clean it up a little.

[Wingnut]

Hi girls.  Regarding the gamepadCamera errors and camera nose-downs, the problem is finally resolved.

 

I tortured Deltakosh for a while, and then I tortured myself for a while, and finally... I unplugged the older Saitek joystick from the USB 1 port on my keyboard.  All the problems with the gamepadCamera went away.

 

I am going to assume that the gamepadCamera... or more specifically... the gamepadControl used with that camera (and the browser and hardware)... "sensed" that Saitek joystick on the USB 1 port.   It "sensed" it as a terrible gamepad (uncalibrated and generally broken). 

 

Of course it's a terrible gamepad... because it's an old joystick (cyborg).  It's not a gamepad at all. 

 

Ahhhh, fun.  I bother SO many important people with issues that are MY FAULT.  Sigh.  Learning learning learning.  Thanks Delta and Davrous and all the others who kindly tolerate me. 

 

I'm off to the tattoo shop, where I am going to have...

 

"Hey Wingy... got a bitchy GamepadCamera?  Check your ports for plugged-in garbage!"

 

...tattoo'd across the length of my arm in big fonts.  I don't want to forget this one.    Party on!

[Temechon]

I think we all want a picture of your new tattoo Wing

You know... For science !

[GameMonetize]

I agree!

[GameMonetize]

And btw you help me found two vicious bugs so no worries at all!

[Wingnut]

Hi gang!  First, that's good to hear, DK.

 

On another subject, I was recently wondering if anyone had used dat.gui library to make GUI for a Babylon.js project.  I did a little web searching, and yea, it has been done, and by none other than our own friend and hero... Temechon!  Temechon is building quite a fine repository of excellent demos and tutorials...

 

http://www.pixelcodr.com/

 

ALL the projects shown there... are very nice.  Not just fine scenes, but thorough narratives to go with them.  Want to sneak into the back door of the place?  http://pixelcodr.com/tutos/  Tour the folders... and download the zips.  Grabbing those zips and studying Temechon's techniques... will make anyone a HOT Babylon.js scene maker in no time.  I think those zips can even rescue ME, and that's no small feat. 

 

The Trees 'game' (a tasty introduction to using Babylon.js vertexData) uses the dat.GUI interface, and it's working perfectly.  AND... it uses a gradiant shader sky dome which Temechon introduces us-to in his Shaders Repository (shader #2 there).

 

Just good stuff, one end to the other.  Temechon saw some gaps between kiddy-level demos and planet-cracker demos, and filled that gap perfectly.  Plus, Temechon likes to model with math instead of modeling software, which automatically makes him a buddy of mine.    And, he's a good JS coder, so there's lots of cool techniques to steal.  The place is a gold mine, folks!  Nice job, T-meister!

 

[ok, ok, he DID use a car.babylon model, but he was teaching us about scene loading.  Cut us some slack, here, huh?] 

[Wingnut]

Ok, before he gets a chance to read that... and get all swollen-headed over it, we need to continue the chronicles.

 

So, the other day, I am hanging-out at Kostar's tiling tutorial ... and I see this cool map thing he built in the playground.  He was loading texture files (into a playground scene) from an off-domain site... with the blink of an eye.  "How does he do that?", I thought. 

 

Here was a domain (used in Kostar's map demo)... that did CORS! (no, it's not a beer but hold that thought) 

 

So I tried a few urls, myself.  I tried some domains which claimed to be CORS-ready.  And they were.

 

http://www.babylonjs.com/playground/#24O839 (a picture from a Picasa Web Album - Google)

 

    and...

 

http://www.babylonjs.com/playground/#24O839#1  (from a Facebook picture folder)

 

Ain't that cool?  Find the cors-active domains, and you, too, can reach out and touch someone... from the playground.

 

Warning:  Generally speaking, it is not wise to touch things in a playground OTHER THAN the playground equipment!

 

So, my buddy's domain... urbanproductions.com ... where I put some of my junk... is a godaddy site.  But I'll be darned if I can find information on how to use picture/texture files from there... as playground materials.  Still reading, but, whew... not much info found.

 

Deltakosh has been putting materials into the playground's textures/ folder for me... accommodating as he always is.  But it would be nice if I could get urbanproductions.com to be CORS-aware.  Maybe that is all controlled at the godaddy.com level.  If anyone has information about that, do tell, and please speak baby-talk.  (thx)    Party on!

[Wingnut]

Hi friends!  It's been a while since I posted here in The Wingnut Chronicles, and I'm here with a brand new demo!

 

Ain't it pretty?  I think so.  Mousewheel-in real close and do some dragging.  That's a pretty high-resolution ref texture... CORS approved. 

 

It is ALL stolen pieces... code, shaders and textures.  I just slopped it together.  Its easy to do now that we have...

 

THE CYOS GET-ZIP BUTTON!

 

Yay!!  Thanks Deltakosh!  Too cool.  I have been learning lots of stuff about wrangling shaders (not coding them)... and its all just too fun!  Go try it.  Zip-up that torus knot or that heightMap... with the spherical environment mapping (pseudo ray-tracy chrome)... take it home... put it on the big screen.  Its amazing, and its easy.  I might never make a non-chrome mesh again.    Shade on!

[Wingnut]

Hi kids!  Today I'm having fun with a playground scene that was created from our refraction post-process demo at our main website.  Here is the original demo, and here is the mess I made of it. 

 

These are my first experiments with our cool built-in post-processes, so pardon my mistakes.  The refraction post-process seems to be very powerful, and it can make some interesting art.

 

Mostly, I have been experimenting with different URL's for the refmap.  And oddly enough, I have had no CORS refusals at all.  WikiMedia textures and pictures never fail me for playground experiments, so Google image search for 'wikimedia texture' often returns CORS-cleared images to use.

 

Its totally fun to 'play' with.  So, go change some urls and adjust some settings (such as depth), and hit the RUN button.  If you make some cool things... SAVE them and then post the save's URL in this thread (if you please).  I'd love to see them.

 

On certain textures, I thought about scaling, but I could not do it, of course.  This is because most of our shader and post-process tools... require a URL.  WHAT IF... they could be a URL or a BABYLON.Texture?  Does anyone think THAT would be a possible future framework feature? 

 

I don't know if it's possible or wise... but what the hell... let's run it up the flag pole and see who salutes it. 

 

Also, postProcess.height and postProcess.width (set AFTER the postProcess is constructed) seem to have no affect, but I could be using them wrong.  They are not included in the above demo.  Party on!

[Wingnut]

Hi kids!

 

   Well, I went and looked at the source code for Assasin's Creed - Pirates today, and... well... holy miracles, Batman!  What an amazing pile of Wingnut confusion!  But I recently made a little plotting demo, and I decided to torture it.... by using it to display the untextured skydome mesh from the game.  Here it is.

 

That playground scene is about as exciting as watching old people eat.    But the PG-based plotter worked well.

 

Want to see the 3.5 meg 'pretty-fied' version of the game file where I stole the shape data?  I knew ya did:

 

http://urbanproductions.com/wingy/babylon/ACP/acp_pretty.js

 

I was going to paste it into the playground editor to see if I could get the game running there, but, you know, I didn't want to be a show-off.    (Kids, that's all a joke.  Don't try to paste it into the playground.  It won't work, not a chance, and you could lose a finger.)

 

But man oh man, what a piece of source code.  It's nothing short of amazing.  And... it's a shader festival, so if you are a shader hoarder, get in there and STEAL STEAL STEAL!    Party on!

[gryff]

here is the mess I made of it.

 

Wingy, not sure I would call it a "mess" - more perhaps the stuff of nightmares 

 

Nice effect

 

cheers, gryff

[Wingnut]

Thanks!  (99.9% stolen).

 

She's such a pretty young lady, too.

 

https://c2.staticflickr.com/8/7190/6830904136_1afd479df9_b.jpg

 

But them are the kind that will drive the roto-tiller up onto your bed while you sleep, and mulch you into the mattress with an evil giggle. 

[Wingnut]

Hi again, gang!  Whelp, I was looking-over our Scene Environment tutorial (skyboxes and fog) recently, thinking about fleshing it out a bit, and I realized that I knew very little about how it all works.  So I stole a copy of our fog demo from the Babylon.js website, and made a playground scene from it.  The playground is a great place to experiment and learn.

 

I also added a skybox.  I was curious about how skyboxes looked... through fog.  By the way, skybox2, skybox3, and skybox4 have been added in-scope of the playground. They are in the playground /textures/ folder.  (thx for the additions, Sir Kosh of Delta).

 

Simpler said, feel free to set the skybox textures path in line 56 to...

"/textures/skybox" or...

"/textures/skybox2" or...

"/textures/skybox3" or...

"/textures/skybox4"

 

...and then click RUN.

 

Thanks to 3delevisions for letting us use these fresh skyboxes for this non-commercial activity. 

 

I am using skybox2 (our name), which is the same as #35 at the 3de website.

 

The .fogStart and .fogEnd properties... are important... and so is the size of the skybox.  In this early experiment... my green "fogbox" is bigger than my skybox.  (There's actually no such thing as a 'fogbox' although it appears as if there is.)

 

So I start the camera animation FAR away, and fly it diagonally across the skybox.  Interesting!  (At least I think so.)  Have fun changing values and skyboxes... and then click RUN.  If you make something cool or learn something fascinating, click SAVE and then paste the URL here, if you please (and tell us about it). 

 

Fog with a skybox... is coooool, so we want to learn all we can about it.  Party on!

[Wingnut]

Hi again!  Here's yet another demo, which is 95% stolen from our new Fresnel Demo at the playground.

 

One thing I noticed in the original demo... is that deltakosh (who I suspect is the author of the demo) used a

BABYLON.CubeTexture as the material.reflectionTexture not just on the skybox, but also on one of the sphere materials (sphere5).  This makes it appear as if it is reflecting the skybox textures.

material.reflectionTexture = new BABYLON.CubeTexture("textures/TropicalSunnyDay", scene);

So I decided to remove the skybox, and ONLY use the cubeTexture reflectionTexture on the sphere.  Worked great.  I think we will soon see an addition to our advanced texturing tutorial... near the 'mirror' section. Who knew that cubeTextures (skybox-like uniquely-named texture 6-packs) could be used for a material.reflectionTexture?  That... is cool, huh?  I think so.

 

Here is a similar demo, with material.reflectionTexture.level = 3; and no flat shading.  Easy and gorgeous!

 

Go visit my new demo... check it out, and while you are there, mess-around with the new Fresnel properties and values on our StandardMaterial.  I didn't use very much Fresnel effect in that demo, but some.

 

Also, if you look at deltakosh's original fresnel playground demo, you can see that we have yet another cool skybox/reflectionTexture (a 6-pack of cubeTextures) that is available within playground scope:

 

"/textures/TropicalSunnyDay"

 

This cubeTexture 6-pack is guaranteed to keep all your playground meshes... toasty and tanned!

 

Are you longing for the beach, gang?  Me, too.    Play on!

[GameMonetize]

Funky!!!!

[Wingnut]

Hi girls!

 

    I've been goofing around with a CORS-clear jack-o-lantern template... brewed-up with a little Babylon.js displacementMap.  Have a look.  I had to "borrow" the .applyDisplacementMap function from Mesh class, and put that in the playground, too.  (I needed a large crowbar to get some stuff done... and playing with core funcs is a fun way to learn things.)

 

It's a poor texture... not enough white space around it.  And I know I haven't got my gradient code-line correct for crisp-edged black and white maps... but it's still better than peeing on your foot.    Happy Halloween... to those it applies-to!  Party on!

[macguyvok]

On 10/29/2014 at 11:27 PM, Wingnut said:

[...] It's a poor texture... not enough white space around it.

ProTip: I've learned recently, after playing around with the BJS Playground. If you post your file in a Gist, (including a private one), and the past the url into rawgit, you can use the cdn link (under "Use this link in production") to get a CORS-free version of the file, that loads great in the Playground.

For example, I've done this with one of my meshes, and loaded it in the playground:

http://playground.babylonjs.com/#1WNUCR

Great way to do some testing.

[Wingnut]

Thanks macguyvok! Very cool.

The Seeking of Faery Dust

Hi gang.  No demo this time, but I wanted to talk about ... well ... glitter sprayers.  (faery dust fountains)

Faery dust (glitter) has to "sparkle" and "twinkle" and it is no easy task to create a particles that can do it properly.  Here is one of my better attempts but nothing fancy in it.  Here's another fun one.

Recently, Deltakosh introduced shader effects on particles.  We put a section in the Particles Tutorial about how to use them, and... well... a guy COULD use a shader to create "the twinkle".  That's ONE scary way of doing it.  At least we don't have to "tumble" a quad (a particle) with each particle having a reflectionTexture... shining a tiny beam of light into the camera lens for each tumble  (somewhat like the gemstone glitter flashes with Junior's lens flare demo).

ReflectionTexture, lens flares, or particle effect shader?  What IS a sparkle/twinkle?

A twinkle shader?  Not an easy task.  (Donations from great shader coders... certainly welcome.)

Again, no need to tumble a particle to test this method.

But now... reflectionTexture and/or lens flare?  Those are both in need of a particle... that tumbles.  So that is my current quest.  Somehow modify the BABYLON.ParticleSystem... to allow the particles to tumble on random axes.  They currently spin on their z-axis, I believe (billboard mode, like a sprite, always facing the camera.)

Tumbling is step #1 to future non-shader twinkle testing.  Once the particle is tumbling, then I can (somehow) apply a standard material to it (emit standard planes), and then add a reflectionTexture (mirror texture) or a lens flare flash like Junior's thing. 

Donations welcome!  (ideas, code, food, clothing, shelter, pot, booze, money) 

Here is a picture of single color faery dust... which is kind of cool, but, LOTS of particles, eh?  Ouch. 

Hmmm.  I might need an animated gif/png on each particle.  Double ouch!  My CPU wants to purchase bus tickets to Bermuda. 

Think sparklers, the pyro-technic type waved by children during nightime celebrations (except multicolored - like the BIG fireworks).  Turn up the brightness and contrast on your monitors.  We are going-for retina burn, here, gang!    Ideas/help welcome.  Comment freely.

Ok, see ya next time, right here, on The Wingnut Chronicles (yikes).  Party On!

[Wingnut]

Hi again, gang.

 

   Continuing with the subject of the previous comment (faery dust), I was finally able to modify a BABYLON.ParticleSystem to emit standard built-in mesh (in this case, boxes) with StandardMaterial applied to each particle.  Have a look.  The zipped version is there, too.  You can look at the heavily modified ParticleSystem, too.  I've done these mods once before, but with a particleSystem from BJS version 1.10.  This version starts with a particleSystem that is much newer.

 

No box tumble, yet.  Tumble might take me another 3 months. 

 

VertexBuffers (vbo's) have been turned off, colors and colorsteps are ignored, angular (z-rot) crap is ignored, the update func is almost nulled-out, particles are using random emissiveColors, and there is a new and simple func called makeParticle. 

 

It's pretty hacked up, but it does something that myself and maybe others have wanted for some time.  It emits standard mesh, easily changeable.

 

"So what, Wingy?!" 

 

It's an interesting starting point if you ever wanted a particleSystem that sprays ANY mesh (like 3D Max particleSystems can).  Since it IS spraying standard mesh, it is much more CPU-heavy than our default particleSystem.  If you start your CPU on fire with this, (maybe by trying to spray 100,000-poly models)... I'm not responsible.    Party on!

[Wingnut]

Hi kids!  Well here we go again... with the faery dust subject.  Here's a brand new demo and its zip file.

 

This is just plain BRUTALLY hacked-up.  Here we spray little planes, and then tumble them oddly, and apply vertex and fragment shading, and the frame rates are indicative of that goofy idea.  This does not use the particleEffects shading feature at all (fragment shader only).  It uses a (stolen) shader that is made for standard mesh (fragment and vertex shader code).

 

Hey, we are seeing some artificial sparkles and twinkles!  YAY!  But I think I have the maxLifetime set a little high.  If I reduce that, I think I can increase the emitRate without the scene getting so fps-heavy.

 

I hard-coded the URL for the "refTexture" (inside the hacked particleSystem file) to be a direct link to the flag of the Seychelles!  Now that's getting weird.  Grab the zip, take it home, improve it, play with it, crank-up the emit rate, bog your system, it's too much fun! 

 

Party on!

[Wingnut]

Hi gang!  Here's another faery dust attempt, using a completely different method.  And, its all in the playground, nice and messy like a playground should be when play is happening.  This one doesn't tumble the planes, it doesn't use a shader/effect, it ignores the particle texture(mask), and it doesn't set a color on any particle.  Instead, this puts a Babylon Lens Flare System (its API docs here) on each particle, with ONE flare each.

During each particle update (the update function), the previous "flare object" is removed from each particle, and replaced with a new flare with a random color.  So the particles are constantly changing their lens flare.  In a Babylon lens flare system, many flares are allowed on a single system... and are stored in an array... lensFlareSystem.lensFlares.  Each time the particle needs to update its position, I empty its .lensFlares array and make a new random-colored flare.  So, the particle appears to change colors... and changing colors is a "twinkle" or "sparkle", but not a dramatic one.  Actually, only the flare itself is changing colors.

I needed to test this method, out of curiosity.  When I first learned about Babylon.js lens flares, I saw a place of experimenting and fun... primarily for making things glow, possibly with interpolated colors (color phasing).

This version was put in the playground for one main reason.  I see something strange happening in line 348:

particle.lfs.lensFlares[0] = new BABYLON.LensFlare(.1, 1, new BABYLON.Color3(Math.random(), Math.random(), Math.random()), "http://i166.photobucket.com/albums/u83/j1m68/star.jpg", particle.lfs);

In this demo, each particle "carries" its lens flare system on-board the particle, so particle.lfs contains a lensFlareSystem... and you can see in this line that I am replacing the single flare (not the lfs itself) on the particle.  The first parameter of the flare creation constructor (.1) is the flare size, the next parameter is position, next is color, next is a texture url, and the last parameter is indicating WHICH lensFlareSystem does this flare belong-to/apply-to.

The position is the parameter that I have questions about (the 2nd parameter).  It is acting strange when set to a negative value.  It's documentation reads:

"Position (a floating value between -1 and 1). A value of 0 is located on the emitter. A value greater than 0 is beyond the emitter and a value lesser than 0 is behind the emitter."

(I suspect that the word "beyond" should actually be changed to "in front of".  Maybe "before"?  Maybe "afore"?  hehe.  *shrug*  English sucks, but at least we don't use "zed") 

Back to the strange thing, negative values seem to flip the entire scene upside down. Strange.  If anyone has any information on this parameter, and/or can verify that the parameter is working properly, I'd love to hear about it.  Thanks.

A little more background... a Babylon lensFlareSystem can use a camera, light, or mesh... as a flare emitter.  In my case, I use a mesh... the particle mesh that the lens flare resides-upon (in particle.lfs).  Setting that second parameter to 1 was the ONLY setting I could use... where the flare would stay positioned WITH the particle (amd the scene not inverted).  I would have thought that setting it to 0... would do that. 

Again, setting it to -1 (or -.9) seems to invert Y for the entire scene.  It goes upside down, including the particleSystem itself.  Or maybe the camera goes upside down.  *scratch scratch*  I don't think a lens flare parameter should have the power to invert a particle system or camera. 

There might be a bug in this parameter, but I have been known to be wrong.  All in all, that 'position' parameter does very strange things to this scene.  Adjust it and hit RUN again in the playground... see for yourself... and have fun.  Try setting it to zero.  The lens flares won't position with the particles at all.  They just ball-up in the center of the screen.  Strange. 

Maybe I need to do some lensFlareSystem.computeEffectivePosition(globalViewport) calls IF I set the position parameter to zero, but I am not real sure how that is used.  There is one in line 352, currently remarked-out.  No success was seen with that... during my tests.  That may be for camera emitters only.

Caution:  This scene is "heavy" and you may see some long wait times when hitting RUN again to test changes.  I don't know if I am cleaning up the disposed particles properly, and I think this scene gulps memory because of that.

This method of making faery dust is a bit more cpu-heavy than the others, but I could be wasting cycles with my bad code.  I don't think putting a lensFlareSystem on each particle... is an efficient method... but it worked. 

One good thing - there is no StandardMaterial on each particle.

There are MANY ways to put a lens flare "glow circle" around a particle.  This method is surely one of the more inefficient ways.  A better way would be to simply over-ride color1, color2, and colorDead... with my own random color maker, and use no lens flare systems at all.  Visually, the effect would be the same, and the speeds would likely soar.    Party on!

Oh, you wanted another version?  Here ya go!  Since particle size-variance does not affect the size of the lens flares, I decided to try a random flare size (randomNumber(.05, .3)) during each particle update.  SPARKLY! 

[Wingnut]

Hi gang!  Here is yet another faery dust demo, and probably the last one.  This one uses a Babylon.ParticleSystem with very few modifications.  No tumbling, default VBO-made mesh, no lens flares, no reflectionTextures on StandardMaterials, no custom shaders/effects.  The only "special" things that are done are the over-riding of color1, color2, and colorDead (instead, continuous double-strength random colors), and... I am continuously changing the size of the particles to a random number between .minSize and .maxSize.  This causes good sparkles.

As you can probably see, this is the most efficient way found so far.  This runs very smooth, and still gives us the faery dust twinkling that we have come to know and love.  And... this version doesn't torture the playground so much.  If you did re-RUNS or Get Zip attempts on the last two demos, you know what I am talking about.  Bogged to the point of browser crash. 

But this one is nice.  It can easily handle emitRates in the 200 area (line 52), which is 10 times higher than any other faery duster I've built so far!  That's because the default code for our particleSystem is nice, and I didn't need to modify it very much at all... to get the twinkles and sparkles. 

Somebody get in there and animate emitter0 to do some figure-8's in space.  Let's see how well this faery dust sprayer acts... when attached to the end of Tinkerbell's magic wand. 

Thanks to the author of our EXCELLENT particleSystem!  It totally rocks, and is very fun to play-with!

I hope everyone is doing well.  Party On!

One more, you say?  Ok fine.  Here's a 200 emitRate coming right at you!  Go full screen, and watch out for seizures!  Why am I thinking about the opening sequence for The Jetsons? 

[joshcamas]

Wow! Very impressive, but a little seizure-inducing.

[Wingnut]

Hi again, gang.  Whelp, the last step in the Great Faery Dust Project... is streamlining.  The BEST faery dust emitter came from a barely-modified Babylon.ParticleSystem.  I did only minor changes to the _update function, and we got great results.

 

If you have been following along, you have noticed that I have been "carrying around" an entire ParticleSystem with the demo (which I borrowed from core BJS framework).  But WHAT IF I could simply create a standard BJS ParticleSystem, and then replace ONLY the _update function.  Override the default _update,  with a custom _update function of my own, and nothing else.

 

And... it worked (I took a couple of utility functions, too).  It was easy.  The total size of our demo is now greatly reduced, and here is a 500 emitRate duster with a circular-animated emitter and short particle lifeTime.  Tootie frootie comet!  Just a standard particleSystem with a replaced _update function.  How easy is THAT?!  Wonderfully so.  Streamlined. 

[joshcamas]

Dang! Fricken' AMAZING!