continued_at_new_forum The Wingnut Chronicles

[Vousk-prod.]

In fact I didn't mean "regimentation" for tags, it's too complicated and restrictive. I think we should let people tag as they want to, all tags are indexed and in the search engine you can see the list of used tags updating realtime according to yhe characters you're typing (for instance, while typing "sca" you'll see the list scale, rescale, scaling, scaled, scalling, etc, every tags one day used and indexed). With ability to search for many terms at same time.

Agree with you, author is not really applicable...

For the methods, they're should be auto indexed, not by user action.

[Ahiru]

Should be a full-text index, then finally there would be the chance to see examples for all functions babylon.js has to offer. I often wished in the documentation-API there would be links to examples how to use the functions.

By the way Wingy - you gave me too much credit in #649 - I mainly compose 2/3 playgrounds and a bit camera-code together. Since I use the ArcCamera from the beginning for Space environment I always set the beta limits to 'null'. So I noticed that it seems strange to have the limits at 0 and Math.PI instead of -Math.PI/2 and Math.PI/2 (for having-a-ground uses) like this: http://playground.babylonjs.com/#FCHQW.

That was the first time I stumbled on the strange behaviour of the ArcRotate Camera and guess to "solve" this phenomenon someone came up with setting the standard limits to 0.01 and Math.PI in between which it won't be visible.

And by the way - which one you think feels more natural?
 

http://babylonjs-pla....com/#1RWE59#35

http://babylonjs-pla...s.com/#YRIPX#11

[Temechon]

I do agree with Ahiru: the full-text index is better. Let's remove the tag idea. As a user, I just want to look for a specific function, and see how it is used in an example.

And the full text search would be faster to implement: just do a search query in the playground DB.

[Wingnut]

Nod.  Isn't anyone going to talk about where this happens?  At Azure?  How long will that search take to complete, for the current 38 meg db (16000 records)?  How long when it grows to 100 megs (40000 records)? 

 

All still plausible, without using tags?  Can multiple people search at the same time?  Any merit to my "do it on your home machine" thoughts?  Do I ask silly questions?  (Likely so.) 

 

I imagine the "home machine" idea is not so good for the mobile folk.   Maybe periodically, our GitHub repository downloads and stores a fresh DB from Azure, and the new toys work with THAT db as a source?  *shrug* 

 

I'm not qualified for ANY of this conversation.  I need to clam-up, and watch and learn and drool. 

[Ahiru]

Cmon - 16.000 records each maybe around 100 lines long, that's not really a big number for a database. Especially as we don't need the time consuming stemming function of a normal language search (where you also would like to find "children" when searched for "child", or "took" when searched for "take").

[Vousk-prod.]

Yep, very simple basic search task for those few thousands PG. Just imagine the quantity of indexed element in a average forum on the web, so many posts, so many messages by post, so many words by message... and still a search button always enabled and efficient... No big deal, such common (but don't ask me how those magical and so powerfull search engines are coded )

[Wingnut]

Cool.  I like hearing that, thanks for the info.

 

Where does that happen, again?  Whose processor will be doing that?  (I'm starting to think that "where?"-talk... is being avoided.) 

 

Temechon is obviously getting pretty good at gruntin', gulpin', and gitin'.  Pile-o-robots to the rescue, right T? 

 

Temechon might have NPM disease.  Somebody needs to check on him.  If he has more than 100 gigs of NPM modules on-site... he's a junkie.  Hoarder.  He's on the snort... we'll need to go rescue him. 

 

You saw that goofy child-like excitement he had... when he found a chubby json file to send his robots after, right?  Yep, we all saw it.  He might need an intervention.  NodeJS disease removal team.  heh.   Pipers disease.    (Good luck on the project, T.  Thanks for your interest/work!)

[Temechon]

Npm disease... What is that ? I currently have the Babylon disease. I'm very sick, but i don't think there is something I can do, sadly :/

[Wingnut]

https://www.google.com/search?q=npm+modules&gws_rd=ssl#q=how+many+npm+modules 

 

If you have over 50,000 stored on your computer... then...

 

Aww hell, my comedy failed...  let's move-on. 

 

Edit:  Hmm, that link ONCE showed a chart of how many NPM modules exist... as-of a certain date.  Now it doesn't.  sorry.

[Wingnut]

Wow!  Look at this, guys... https://github.com/BabylonJS/Documentation/blob/master/content/tutorials/01_Play_Pen/02._Discover_Basic_Elements.md

 

I did a git-thing!  Yay!!!  That link will only show my name until the next contributor happens, so screen grab it, frame it, and hang it on your walls in awe and splendor. 

 

I was able to remove the unneeded 98 nbsp's from that doc, and I used Dk's "Easy Way" from his contributor tutorial, and I did it!  ME!  Holy crap!  Temechon kindly re-built the beast or otherwise merged things, and boom... http://doc.babylonjs.com/tutorials/02._Discover_Basic_Elements#side-orientation is now looking good.  Three links... working.  Yay!

 

It wasn't something wrong in the html compiler.  It was something wrong in the content that gets fed-to that compiler (now fixed).  The robot (compiler code) is healthy, but we were feeding it contaminated robot chow... a human mistake. 

 

In the contributor tutorial...

 

When done, just select "Create a new branch for this commit and start a pull request" and hit Propose file change.

 

I didn't see that choice.  When I finished editing, there was a "Propose file change" button at the bottom.  After that, I found a "Pull Request" button, and all seemed to go well.  I saw no selection named "Create a new branch for this commit and start a pull request".  The pencil click created the fork/branch, and the PR button was much later... after the propose button... if I remember right.   Docs might need tweaking.  *shrug*  Party on!

[GameMonetize]

Great job!!!! I'm proud of you!

[Vousk-prod.]

Yep !! Congrats.

Great news for us and the docs

[Wingnut]

Hi gang!  Thanks for the nice words!

 

Ok, today, I'm just yapping, as usual.  Two different subjects.  First, I want to talk about gulp and grunt.  These two nodeJS modules... are sometimes called task runners.  Some call them build tools.  A Google web search on the subject... returns plenty of fine reading material.  In general, it seems that gulping is for liquids... streams.  Grunting seems to be for non-streams... batchy.    Don't mark my words.

 

At our new GitHub BabylonJS Docs site, may I first remind everyone to scroll down, and see the fine documentation that resides there.  I like to call it the "down-low".  The down-low is full of information... but most important... it shows us how to do grunt build.

 

I encourage all of you to grab a clone of our docs repository, install the needed tools, and do a build on your machine... per the down-low doc.  It is truly TOO FUN!  I know many of you do builds like these many times per day, but for those who have never "experienced" a build... you are in for a treat.  Our Gruntfile.js is right there on the top level, and it is very cool.  That file is the "grunt commander".  Today, I might try a node-module called grunt-prompt... so I can pause the build at certain places, simply to let the robots catch their breath. 

 

Doing builds is great fun, and anyone can learn tons, quick... experimenting with it.  These are things that apply to the "going further" section in DK's docs contributor docs.  And don't forget to browse your new build at h t t p://localhost:3000/ ...to see how well your local build worked.  It's all quite fun, and packed with learning.

 

-----------

 

The other subject, today, stems from a property NAME... seen in the new glossiness/roughness feature of our StandardMaterial... useGlossinessFromSpecularMapAlpha

 

Wow, what a property name.  There is a similar name used elsewhere... useAlphaFromDiffuseTexture.

 

"use" - interesting.  Use this for that.  Use that for this.  Use this if that isn't set.  Use that if this isn't set or if that is <0 or if etc etc.  "Bindings", right?

 

It's starting to "feel" like StandardMaterial needs/is... a patch panel (patch bay).  Hook this to that, wire that to this, etc.  But patch panels are boolean.  A connection is made, or not.  Patch panels and other binders... have no conditionals like...  IF something, THEN hook that to this.  ELSE hook this to that. 

 

THAT kind of patch panel... requires something similar to a spread sheet.  Programmable patch-panel jacks.  One jack is a useAlphaFromSpecular, another jack is useAlphaFromDiffuseTextureIfThis.hasAlpha == false, etc etc.  Each jack, each cell, has a formula... which defines a preset.

 

And that brings us back around to thinking about preset materials in BJS.  Pre-configged.  Pre-patched.  Imagine a pile of pre-made materials... selectable from a panel in the playground, or something similar.

 

(It would need to insert code into the editor at the current cursor position. Is that too much code intervention from the app?  Maybe so.)

 

Maybe it is a "special mode" for the playground... materials mode... a way to play with the preset materials and effects in the materials library.  Some of the problem... is in describing these pre-made materials on a pulldown menu.  Some of the names will be long... like... native_alpha, medium-gloss, medium-rough, Fresnel-active, cubeTexture-reflection, etc etc.

 

Another way to deal with this... is to give the pre-made materials... cute names... like spiffyshine, and city lights, and guacamole, etc.  When the user mouses-over the cute-but-short name, a sub-window opens similar to the PG intellisense pop-open, and shows the code used to define the material.  This is the same code that is pasted into the editor at the cursor location... IF the user selects it.  Naturally, this does not "turn-on" the material... but it includes it, and the user can then apply it to a mesh, as wanted.

 

The same can be done with shaders.  Cute names, not really saying anything about what they do, but these shaders would be pre-wrapped in shaderStore constructions, lightly commented, ready to select from the list and use on a material.  In THIS case, we cannot pop-open a panel to show the shader code that is about to be pasted.  It would probably be too large... but maybe not.

 

Both kinds of "pre-made" things mentioned above, will often require textures... and each pre-made package must use textures that can be found in our playground's /textures/ folder... or else they won't be easy for the user to select-insert-bind (easily use).

 

I once sort-of tested DK's feelings about adding power-features to the playground.  I was able to talk him into the CLEAR button, and he has added a few nice features, but generally, he wants to keep it "clean"... and I can understand that.  But that doesn't mean we can't talk him into a special "mode" where... no holds barred.  This special mode... would maybe use modules.  Plugins.  The material lib would be one.  So would the shader lib.  How about basic shapes lib?  Choose a torus knot.  Choose a tube.  Select it from the list... and poom, puts it in the scene at the cursor.  Did you choose the MATERIALED version of the tube?   Then the mesh picker launches the material picker automatically... after the mesh is selected.

 

Need a light?  Pick it from the list!  Boom.  Need a cam?  Pick it from the list, we'll try to make it work out-of-the-box (have all the right settings to make it easy to turn-on).  This would be "special mode" for the playground... where the playground becomes instantly BJS-intelligent and provides libraries of "good stuff".

 

Maintenance/updating nightmare?  Absolutely true.  Maybe.  We probably need to use github to store the plugins as... yep... playground plugin modules.  These modules MIGHT need to carry their shader refmap and other basic textures that they need in order to operate correctly... inside each plugin module.  Maybe these libraries need to be self-sustaining... so DK has ZERO maintenance to update the playground.  All he does is allow "special mode" which then causes the playground to go check for plugins in a git repo, and do grunts and builds as needed... in order to include those libs/features into the playground.  The shaders and materials are kept separated at github... each one self-contained... and the pulldown lists are dynamically assembled at "special mode" time. 

 

Some shaders might fail.  Some shader authors might suck.  Some feelings could get hurt.  There's issues.  There might come a time... when the less-quality shaders might need to be culled because the library has gotten too large.  But maybe, with proper tree-managing, which a "build-on-the-fly" COULD do... everyone's shaders and demo materials could be included.  Naturally, we would want to keep the texture sizes small.  These are just demos... quick-constructors... and the user can change to fatter textures later, as wanted.

 

All thoughts and comments welcome...  as always.  Thanks!

 

Back to subject #1 (and finally wrapping-up), running grunt build over and over is VERY fun.  Watching all the gruntings activate... all the robots come to life... it's an exciting thing.  240,000 lines of output happen during the build, and a little drool falls out of my mouth EVERY TIME!  Using a clone of our docs repo and build system... and doing local builds... is a great way to learn it all, and in the process... open up the doors to being a power contributor to our docs.  C'mon along on my fun ride... let's BUILD!  Congrats to the team that made our build system.  I'm still scared, but so what?  That team rocks!  They have all done some REAL FINE grunting. 

[Wingnut]

Speaking of setting pivot points...  http://www.babylonjs-playground.com/#WRH6X#1  That's pretty cool, huh?  (authored by Deltakosh)  I've never seen that easy pivot set.... done before.  Interesting.

 

The goofy shaped sphere is pretty fun, too! 

 

Remember THIS W-A-S-D strange demo?  I made that, using an invisible parent gizmo to flop the box, pivoting on its edge.  But... hmm... now someone can make another version of this... that keeps adjusting the box pivot point and doesn't need an invisible gizmo parent!  Wow! 

 

That pivot adjuster technique has probably been around forever... but... I finally learned it!  Yay!  sphere.setPivotMatrix(BABYLON.Matrix.Translation(0, -2.5, 0));  So easy.  sigh.  I'm SO SLOW at learning.  sigh.  In my opinion, that code line, and a few words ABOUT it... should be included in all our docs that talk about rotation.

 

So, anyway, quickly, somebody update that box-tumbling demo... to use pivots instead of gizmos.  I bet the code length will be 1/2, when done.  Bet so.  

 

Addenda:  http://www.babylonjs-playground.com/#WRH6X#5  I wanted to find out IF pivot points could be placed beyond the edge of the mesh surface.  As you can see, no problems there.  Hey Gryff... I think our old hinge issue might have gotten easier to deal-with.    Offset pivot points can make simple animations... do BIG ACTIONS in the scene.  Leveraging and fulcruming, ya know?  Catapults.    Can you imagine being able to offset the pivot point of a physics imposter?  omg.  kbye.

[Ahiru]

Yes, that Pivot-Point setting was great for me, too. It's MORE than time that we get a searchable playground, so we can search for all functions that BJS offers and see them in use!

[gryff]

Hey Gryff... I think our old hinge issue might have gotten easier to deal-with. 

 

Well Wingy, I still find it so much easier to "set the hinge" in Blender. A couple of clicks and I can move the origin to an edge - Desk with doors

 

The advantage for your WASD demo is that the "pivot point" can be changed on the fly - so the block moves in any direction depending on KB input..

 

cheers, gryff

[Wingnut]

Hi G!  I think I missed a PM reply to you, or two... sorry about that. 

 

Yeah, good point about the hinges.  This is the same issue that ChrisR is dealing-with right now, I suppose.  When he sets the pivot point, the mesh translates... and possibly vertices-transforming is needed to get it back home.  Yuh yuh yuh, I forgot about that.  Well, I guess I didn't know about that... until Chris's thread and DK's demo.  hmm.

[gryff]

Wingy, my little post above somehow leads me to something you posted on the "Starfields" thread about contests.

 

I have nothing against contests - but I know that I can not compete against the likes of RaananW , jerome, Temechon or you.

 

I smiled when RaananW urged people to "spend a few hours" building a game - I thought to myself, maybe more like a few years for you gryff

 

But then, if the results are public and the code accessible, I can always learn some new programming tricks. That is why I bought Temechon's e-book and why I often use his game tuts.

 

I like your thought:

 

There's too many differently-qualified folks on this forum

 

which is of course correct - though I sometimes feel like an outsider, as I have no formal qualifications. Basically self taught - apart from a couple of courses I took in Fortran many years ago. And that probably betrays another difference - my age (likely the oldest person on the HTML5gamedev fora ).

 

But I do enjoy your often whimsical and philosophical posts. They can bring people back to reality.

 

cheers, gryff

 

 

[JohnK]

Competition v cooperation. Well Wingy thought provoking as usual. Is a challenge a competition? Could be or could not be! For me entering this challenge was a challenge for myself. I thought I could probably do it (that is set up a 3D game of life) - much less sure whether I could produce one where people went 'wow'. OK it was not true altruism, I take any recognition for my entry I can get and the bottle of beer if I won and ever went to Berlin. Starfields I could never contribute to or move it forward. If it was a challenge however I might just have a go to see if I could do anything to create one and learn more about sky boxes.

The great thing about this site is the responses and cooperation you get from the mighty experts to newbies. Anything that spoiled that would be a disaster. Even when I have nothing to say I still enjoy reading the forum and learn a lot.

With just a couple of entries and no interest shown in taking it further then I do not think a disaster is in sight.

Just to show how non competitive I am I am going to hijack this thread (Tomorrow I win all

[GameMonetize]

 

 

It's MORE than time that we get a searchable playground, so we can search for all functions that BJS offers and see them in use!

Sooooooon....soooooon

[gryff]

Gryff I challenge you to a duel - first one to 100 wins

 

A duel I will let you win JohnK. I hope to amble to 100 - not race

 

(I wonder where I put my book on Relativity?)

 

cheers, gryff

[Ahiru]

Well, talking about a good physics engine might be important, but for real game-programming - wouldn't that normally be done server-site? (That's why I try to get socket.io to work - ideally in the playground)

 

In general, for a gaming-framework I am missing the real Node.js integration, so many things could be used server AND client-side - am I wrong here?

 

Coming back to the physics-engines: 

 

Oimo seems to have a problem with mass - if I apply an impuls it seemed the mass of the impulsed object was not taken into account, wich is weird,

Cannon has nice functions like local-impuls, which is not available through the plugin, though - AND it seems that there is some problem with higher speeds...

 

Both do not really work in atmospheric environments - so a new physics engine MIGHT be the right choice - together with a plugin, that really uses the complete function-set of the engine.

[Wingnut]

Hi ahiru!

 

I'm not very experienced in these things... but...  I'll comment on some of it...

 

 

Well, talking about a good physics engine might be important, but for real game-programming - wouldn't that normally be done server-site? (That's why I try to get socket.io to work - ideally in the playground)

 

WebGL games are "real"... but they don't require the installation of client-side game software.  They run in a browser.  Considering that they do that, machine/assembly language physics is not available.  All of our implemented physics engines are coded in JS.  I don't think you can expect JS physics to ever operate as fast as machine language physics.  Again, the downloading of client-side software... gives non-webGL games a bit of an edge, but they don't have the advantages and features that a webGL game has.  WebGL games are a different way to do games... still quite "real", and it opens access to many platforms.

 

 

Both do not really work in atmospheric environments - so a new physics engine MIGHT be the right choice - together with a plugin, that really uses the complete function-set of the engine.

 

Must we make a "choice"?  Must we label something as "right"?  My personal objective is to always allow the author to use ANY physics engine... and PERSONALLY determine what is right for them or for the project.  It all seems to be evolving, yet, and may do so forever.  I think it would be best to keep the doors as wide-open as possible.  So, my choice, and what I think is right... is ALL choices.  *shrug*  I think that's what the physics plugin system is all about.

 

The other things you wrote about... others will need to address... as I haven't got the experience.  In general, though, I really doubt that people are doing the physics for their online games... on the server side.  The server would need to be streaming its brains out... trying to update the positions/orientations of a pile of physics-moving mesh.  I think that this would not be a wise use of a server.  But again, I have no experience in this... so maybe others will shine some light on your good questions.  Be well!

[Ahiru]

You have to calculate it on both sides - server AND client. On the server to write the results / events into the database - on the client to render it and visualise it for the players.

 

The best way to have it would be to use the same code on server and client (that's where Node.js comes in), so first: You don't have to code things twice - second: You can be sure the results would be the same.

 

You can't just let the clients do the calculations and send the results to the server, since these results are too easy to be manipulated.

[Wingnut]

See?  I told you I didn't know anything about game serving.    Interesting!   What you say... makes sense, though... and thanks for explaining it to me.  The server maintains a mirror of the client's scene.  I have SO MUCH to learn!  (sigh)