Coming from Unity, a few questions

[trecool]

Hey! 

As a student of UX design I have no real deeper knowledge of 3D development but have got about two-ish years of Unity under my belt. For a project as part of my intership I wanted to develop an application WebGL but as the Unity WebGL export is far from great and takes ages to load the simplest scenes, I made the transition to "real" WebGL using ThreeJS. I did have great sucess with it but when I dug a little deeper I ran into a few brickwalls I can't seem to find a satisfying answer to - so I hope some of you may shed some light on my problems

1. From what I gathered, ThreeJS is great for just displaying and rendering things but severly lacks in the anmiation and simulation department, where BabylonJS enters the room. Does this hold true? 
2. Coming from Unity, I don't quite understand the renderloop. A scene is created and then this scene is continously rendered in the renderloop. Correct? So why are not all objects and imported meshes loaded and created every frame but just once? Or is my view on the whole system totally scewed to begin with? Again, I'm used to Start() and Update() in Unity
3. and finally, I need to create some simple dynmaic animations in 2D and 3D space. Those animations are quite simple, one is for instance just two sliders controlling values and based on those values, something happens, nothing fancy or highly computing intensive. Basically a "if I push a button then a door opens" kind of thing. In Unity this is done really fast in an almost drag and drop manner, but I have no experience in creating such scenes by code alone. Is it more "difficult?" Or is just the transition period a little difficult and once I got a understanding of the mechanics its just smooth sailing? Would you recommend BabylonJS or is it more a "of course you could use it, buuuuut...."?

I do hope someone can enlighten me and support my decision to move to Babylon. 

Cheers! 

[Wingnut]

Hiya @trecool, welcome to the BabylonJS forum!  I'm no expert, but I'll give my honest opinions.

1.  Actually, ThreeJS does animations almost as well as BabylonJS.   Here is a Professor Stemkoski animation demo.  Just use your cursor keys.

2.  You are correct, the scene is rendered over and over.  BUT... the scene is not built/assembled over and over.  Besides rendering a scene constantly, many programmers "wedge-into" the renderloop and use it as an engine to do work.  Take a look at our playground demo for lights http://playground.babylonjs.com/?6.  Look at lines 56-67.  scene.beforeRender is one way to say "run this code just before EACH rendering happens".  Math sine and cosine values are applied to the X and Z axes of lights, causing them to do dynamic orbiting.  It's as if we hooked a belt or driveshaft to the fast-running render loop, and use that drivebelt to power scene machinery.  The main thing to remember... don't load-down the render loop with slow-running code.  beforeRender code should run fast and get done quick, or else your overall scene render speed will suffer.

Update is done here, too... but automatically.  Mesh have a Boolean flag on them... update-able or not.  I THINK... the more mesh that you can set updatable to FALSE, the faster the overall scene will run... but I might be full of crap. 

3.  It's not quite drag'n'drop with BabylonJS, but it's not terrible, either.  For example, a door mesh needs to be positioned into the door frame... and that can be done within BJS, or within the modeling software (if you use a modeler).  Sometimes, its pivot point needs a move.  That, also, can be done with one line of code in BJS or in the modeler.  Animations... a little more difficult, but still not bad.  In fact, we have a createAndStartAnimation() that requires only one line of code. Generally, set a start frame, set a stop frame, tell it which property you want to animate (door.rotation.y), and tell it how fast to do it.  Not bad at all.

There's a few things that BJS has, that 3JS doesn't.  One... a great working online "playground" with playground search.  Two... much better backward-compatibility.  Three... a very active and helpful forum, with a great "team" spirit.  Many times, I have seen LARGE NUMBERS of forum helpers... go to work on a user's issue.  Just read-around in the forum a bit... you'll see it, too.  The people here... pride themselves in the speed of helping, and in being thorough.  You don't see grumpy helpers here, even when a helper is answering the same question that has been asked a hundred times.  That is one of MY volunteer tasks around this place.  I watch-for repeatedly-asked questions and problems, and try to adjust our documentation to eliminate that.  Others do that, too.  Although I don't know much about the "give a crap"-factor for other webGL frameworks... the BJS forum give-a-crap factor is WAY WAY high.  Forum helpers here... sometimes go far beyond the call of duty, and teach-about/help-with issues NOT about BabylonJS, too.

And... we're example-crazy, here.  We LOVE to see and hear-about what users are doing with BJS.  This helps core programmers and documentation writers "contour" the system to accommodate everyone.  Speaking of accommodation, the chief author, and other BJS-core programmers around here... REALLY listen to feature requests, and always try to accommodate the request, when viable.  Not only that, but they add it FAST.  I have made requests for changes... and gotten the change added in under 5 minutes.  Really.  It's rare that features can be added that quickly, but if they CAN be, it's done.  In other words... great people with a high give-a-crap factor.  You're never alone... when you drive BJS.  You have friends, and some of them are geniuses and idea-folk.

But the playground, and its searcher, and its ZIP feature.... those are the real "meat" of BJS.  There are probably 25,000 playground demos in the playground database - test scenes and experiments covering every webGL subject known to man, + 3 more.    This is a really nice learning environment with good friends in all directions, and a real fast framework.  Even if you DO switch frameworks, later... much of what you learned here, will transfer.

Yes, this is a SLIGHTLY smaller family than 3JS land... and we like it that way.  Also, BJS doesn't necessarily provide a pile of rarely-used helper objects, but BJS makes it easy for you to build your own helper objects... contoured to YOUR project.  The helpers are better when you build them yourself.  They fit your needs, better.  It just takes a little time, a little terminology learning, a little documentation site familiarization, and some great playground demo code... and in no time, you'll be fartin' thru BJS silk.  err... I mean... you will feel REAL comfortable here in BJS land.  Ask anyone here.  They all know... after a very short learning curve... the sun comes out, the ride gets smooth, and the smiles are everywhere.

So, just plant your butt into this nice BJS grass, and relax into our world.  You'll never regret it.

[GameMonetize]

Thank you Wingnut for this great response, this is really to have you on the forum!

[Raggar]

Damn. I never realized all the cool shit you can find by randomly searching the playground.

I found a couple of simpler, yet more performant examples of my own implementations.

[aWeirdo]

On 4/8/2016 at 11:02 AM, trecool said:

 

1. Coming from Unity, I don't quite understand the renderloop. A scene is created and then this scene is continously rendered in the renderloop. Correct? So why are not all objects and imported meshes loaded and created every frame but just once? Or is my view on the whole system totally scewed to begin with? Again, I'm used to Start() and Update() in Unity

If i may add one tiny note to this,

All game frameworks/engines have a sort of renderLoop, wether it is using webGl, DirectX or something else, the rendering is essentially drawing what you can see, so a frame is actually a picture drawn on your screen.

every single on-the-go visible change is possible because of this, so let's say you are controlling a player and moving forward, at a standard 60 FPS, it means that the renderLoop draws you 60 frames each second that passes, each frame a little different and it basicly turns code into visual movements infront of your eyes ,

[Wingnut]

Yep, yep, yep.  Seeing that @trecool is a Unity pilot... maybe we can talk about Unity for a few moments.

What the heck is that thing?  Modeler + game-logic thing?

I'm quite inexperienced, but I think the Blender "bricks" thing is also a game-logic contraption.

Game-logic doesn't export so well from ANYTHING, I suspect.  I can understand why.

Exporters are strange in themselves.  They don't really "belong" to anything.  We have a custodian... @JCPalmer... helps us with our Blender exporter while he develops his own semi-related product (it seems).  I think he helps us out of pure kindness.  We get a great Blender exporter... as a side-effect of his Tower of Babel project.  At least that's what it seems.  JC has honored MANY feature requests for the Blender exporter... but it is not really "his baby".  It belongs to all of us (again, thanks to his kindness)... and exporters... are a bit of a maintenance hassle (imho).

In general, we don't have "teams" to keep exporters "fresh" and juggle the versioning problems, as modelers evolve.  (modelers being 3DMax, Blender, Unity, Maya, Cinema4D, etc).  All those wares... are still evolving, and can cause exporters to need constant attention.  I think... keeping exporters fresh and working with "the latest xxx"... is a substantial task.

And then there's this other "pondering".  Whose "job" is it to provide the exporters?  Should Blender people build the BJS exporter?  Should BJS people?  Is it "part of the framework" or not.  Does it belong as part of the framework, or not?  Who has way too much time on their hands and has a subscription to always have the newest 3DMax?  Who can afford to do that, AND knows how to code Max exporters? 

Nobody, that's who.  Exporters seem to live in "no man's land", don't they?  They seem to be some of the most un-loved code, ever.   

Yet Blender folks visit and ask "Can BabylonJS do cycles rendering or shapeKeys or [insert new Blender feature here] ... exported from Blender?" 

Poor JC is probably a frazzled mess... losing more sanity with each new Blender feature that he has to honor, or avoid, or listen to forum questions-about.    Let's hope that's not the case.  JC is a local hero, for sure.  If he were a dog, I'd scratch his belly for a while.  He's a good dog.  Someday, I want to diagram what he does for TOB and exporting, and learn it.  And I wouldn't mind knowing the story of Tower of Babel. 

Are you building a "universal exporter", JC?  Can we read about it's far-reaching purpose, somewhere?

All in all, there seems to be plenty to think-about... with exporters.  In a way, exporters are "glue code", aren't they?  They hook one thing to another... and the people like JC who do the miserable job of running the glue machine... are truly a different breed.  I admire their tenacity. 

Comments welcome.  Let's contaminate Trecool's thread.    Maybe he'll tell us about Unity... and what he thinks CAN and CAN'T be exported.  Game-logic... might be rough.  Models... maybe okay.  Not sure.

[JCPalmer]

@Wingnut, the changing of both Blender & BJS was part of the reason for switching to a multi-source file / zip media file architecture.  Though the massive single file approach was already "out of gas" for all the Tower of Babel things not in the JSON exporter.

I am not building a "universal exporter".  My original analysis of BJS 2 years ago was the animation sub-system & and its reliance on external modelers, as you call them, is just not good enough for me.  I am building an extension which is essentially a replacement animation system. 

This required that I actually address this before things got to BJS.  FYI, I have even written all but one of the operators in the new MakeHuman community plug-in for Blender.  I control of more of my own destiny by stretching out my process pipeline.  Most times when you hear "I made a model in XYZ, imported it to this thing, changed it, bounced it off the Apollo Moon reflector, then ...", basically they are loosing something with every step.  I am actually gaining things!

QI is not a "sub-system", but a OO approach where each sub-class mesh has a dedicated before renderer.  This allows for coordinated POV movement & rotation, with morphing, and skeletal interpolation.  Making mesh sub-classes requires source code generation.  JSON is not going to cut it.  Specifying the name of a base class in Blender means you can actually code methods and add properties in typescript, and the exported sub-class is automatically just plugged-in.

BTW, the gains of actually doing the animation performance in JS are massive.  Not only do you avoid large input files, but with minor scene level work, you can add bits of randomness.  A 10,000 word vocabulary comes to mind (thanks Carnegie Mellon / defense dept).

Further, you submit your animation targets asynchronously to a queue.  Queuing means you do not have to know when things end then start the next at the application level (you can put a function at the end of the submission if you want though).  Want to synchronize the maybe 50 vismes (morphs) for a long sentence?  Good luck.

[Wingnut]

Wow.  Thanks @JCPalmer.  When you say QI, you mean... "Quantitative Invisibility"?  I'll assume yes.    I think I understand SOME of the rest.    In the exporter, you are generating JS code that is later run locally after the import arrives at BJS.  ("stretching out my process pipeline").  You do some pre-processing "before things got to BJS".

Very nice.  No more .babylon file, but instead, a zip of files attained via the pre-processing in the exporter.  Some of these files contain JS source that is run in BJS after import unpack.

With the MakeHuman thing (congrats on your successes, there, btw)... this QI approach can be used to avoid rendering parts of the skeleton that are not in-view, yes?  (I'll assume yes). 

Having a beforeRender on each subClass/subMesh, is a place to put QI code that checks if the camera POV or skeleton rotation has changed in such a way as to require vertices to be set visible/invisible.  This way, the engine only renders the parts of the skeleton that the camera can see?  (I'll assume yes). 

I hate to waste your time on my noob questions.  I needed to clarify/reword some of your statements... I hope you don't mind.  thx agn for the info.  Repair my bad thinking, as wanted. 

[JCPalmer]

I meant "Queued Interpolation" extension.  The module name is QI to keep it short.  In retrospect BABYLON might work better if it were BJS (too late now).

Quote

you are generating JS code that is later run locally after the import arrives at BJS.

No, the JS code file is the import.  There is not actually even an import process (unless you want to attach a JS file on the fly post load).  It is all in the JS file, with all the values for positions / normals / UV / vertex colors / matrix weights & indexes / shape key groups / indexes as inline code.  Just put the JS file in the HTML header.  When you want an instance of any particular mesh, just say some similar to instancing a ground: (module by default is the .BLEND file name)

var instance = new module.MyMeshClass('name', scene);

In Blender, you can specify a base class for a mesh in TOB.  If you do not, the base class will be either BABYLON.Mesh or QI.Mesh is there are shape keys or an armature found.  QI.Mesh inherits from BABYLON.Mesh of course.  It sets up the before renderer / queue(s) for you, as well as has all the functions for submitting things to a queue.

There is no preprocessing in JS code.  There is however an optional post constructor processing hook.  Lets say you write a typescript mesh class to queue random eye rotations.  You would then set this as the base class of each eye mesh (don't tell anybody, but it is set for you in the separate eyes routine in the MakeHuman Plug-in).  In the computer built constructor, the first thing called is super's constructor, then the inline geometry initialization executes.  You cannot do anything to set things up that rely on the geometry in super.  If there is a method postConstruction() found in super class, then it will be called at the end of the computer built constructor.

There is enormous preprocessing of Blender shape keys into QI.ShapeKeyGroups though.  In Blender, a shape key covers the entire mesh.  A QI.ShapeKeyGroup is only part of the mesh, so you can have multiple groups for multiple independent morphing. (FACE, WINK, L_HAND, R_HAND, BOOBS, etc).

When I said ZIP media file, I meant the python source files.  There is still a .babylon as output for the JSON exporter just released.  A single source file > 4000 lines is not manageable.  Also a ZIP file can contain files other than python source.

[Wingnut]

Thanks again, JC.  Boy, was I on a wild goose chase of wrongness.