Why is sprite and sprite manager seperate?

[lihis]

Hello!

Why do we have to first make a sprite manager and then pass it onto the sprite instead of having the manager made automatically?

var spriteManagerPlayer = new BABYLON.SpriteManager("playerManagr","Assets/Player.png", 2, 64, scene);
var player = new BABYLON.Sprite("player", spriteManagerPlayer);

I would like to be able to just write:

var player = new BABYLON.Sprite("player","Assets/Player.png", 2, 64, scene);

I'm just wondering what is the reason for this. For me, as a beginner, it would be easier to understand if it was automatic.

[Wingnut]

Hi @lihis, welcome to the forum.  And that is a darned good question... which I don't have an answer-to.  I should probably wait for @Deltakosh or another expert to visit, and tell us WHEN and WHY folks use "managers".  But you don't care about that.  You are wondering WHY no auto-generation of the manager.

18 hours ago, lihis said:

var player = new BABYLON.Sprite("player","Assets/Player.png", 2, 64, scene);

It might have to do with "granularity".  In the above line, programmers would not know that TWO different-class objects were created with that single line.  This line LOOKS like... "I want var player to be a Sprite-Class object". 

The programmer didn't request a spriteManager.  There might be good reasons for creating a sprite without a manager, so we must somehow modify your idea... to allow them to auto-create a manager, or NOT. 

This could be done with a flag.

var player = new BABYLON.Sprite("player","Assets/Player.png", 2, 64, true, scene);

The "true" would mean... auto-generate a manager... but... there is no manager RETURNED.  Only a sprite is returned.  SOOOoooo... let's go look at the Babylon Sprite Class.

Notice it has no "manager" or "spriteManager" property, but it COULD.  We'll talk about this MORE, in a moment.  Primarily, I was looking for a place to store the auto-created manager (if a user chose to auto-create).  There is no place yet... to store our auto-created spriteManager.  It is floating in space.    But perhaps that is where spriteManagers are located... all the time.    I have not studied sprites very well.

Ok, let's pretend we DID have a property on Babylon.Sprite called .spriteManager.  That might be fine but... WHAT IF... a single sprite can be used with multiple managers?  I haven't seen a use-case for that situation, yet... but maybe our framework author wanted to ALLOW that kind of "granularity" and multi-use feature.  That could be one reason why sprites don't have a .spriteManager property.

Let's look at actionManagers for a moment (a powerful-yet-simple way to activate "events" on a mesh or scene).  ActionManagers are a similar situation.  Under most circumstances, folks store actionManagers ON MESH... but perhaps... they do that just so they can FIND them.

Have you used our actionManager?  We could use your same idea... on those. 

var action = new BABYLON.ExecuteCodeAction(BABYLON.ActionManager.OnPickTrigger, runThisFunction);

In this case, a new actionManager would/could be auto-created.  Here, also, we could use a true/false flag... to allow programmer to auto-create an actionManager or not.  But again, we should probably not simply auto-create the actionManager without informing the programmer, somehow.  The programmer would need to know that TWO objects were created.  The main object is a BABYLON.ExecuteCodeAction.  The "behind the scenes" object created... was an actionManager. 

Programmers might say "Hey, I didn't want an actionManager created.  I only wanted a BABYLON.ExecuteCodeAction created." 

By doing these auto-creates behind the scenes... we are "overloading" the constructors.  We are making them do MORE than the programmer might have expected them to do.  We "imposed"... by doing auto-creates... without the programmer ASKING for them, or KNOWING that it is happening (except for reading the docs). 

But... what if... there was something like...

var player = BABYLON.Tools.CreateSpriteWithManager("player","Assets/Player.png", 2, 64, scene));

NOW, we have some possibilities, eh?  The programmer now KNOWS that they are auto-creating a manager.  We don't know where we will STORE that manager, yet, though.  But the programmer knows he/she is creating at least TWO objects, now, right? 

THIS kind of "wrapper" is used in a few places within BJS... and for the very reason you have stated.  Easier to learn... easier to use.  Allow me to show you one such "wrapper"...

var animatable = BABYLON.Animation.CreateAndStartAnimation(name, node, targetProperty, framePerSecond, totalFrame, from, to, loopMode, easingFunction, onAnimationEnd)

That's one hell-of-a-wrapper, eh?  Create and start the animation.  Two things, wrapped into one handy tool.  In fact, it is MANY things wrapped into one handy tool.

Soooo... I would say... your idea is excellent... if done with a wrapper.  Now we can hear from more people and think about how often it would be used.

Using the createManager true/false flag is probably not wise... UNLESS... we "wrapped" sprite creation, too.  Do it in SOME way where "new" was not used (not a constructor).  Something like this...

var player = scene.makeSprite("player","Assets/Player.png", 2, 64, true, scene);

See?  We used a wrapper here, too.  A tool.  We avoided contaminating/overloading the clean'n'simple constructor... new BABYLON.Sprite()

This is all a bit difficult to explain... and I'm no pro.  Your idea is a good one.  There are good ways to implement it... with wrappers.  BUT... notice I used "scene.makeSprite()".  Our Scene object is already pretty "loaded" with helpers/wrappers, but... why not another, right?  This is the "plausibility" part of considering your idea.  How many will use it?  Does that matter?  Will most people, from now into the future... be using a Sprite2D instead (from our new Canvas2D system)?  Will our old-style sprites soon be converted to Sprite2D's ANYWAY, un-announced and un-noticed by end-users?

I think your idea is good... as long as it is "implemented" correctly, with no behind-the-scenes object-creating that the programmer doesn't know-about.  But we REALLY need to hear from smarter people than I.  So, I will FINALLY shut up now.    I just wanted to welcome you to the forum, Lihis, and give us some things to think/talk about.  "Food for thought", you know?   

Be well.  Perhaps soon, we will see a GitHub Pull Request (PR) submitted by you... to install Lihis's brand new Scene.createSpriteWithManager() function/feature.  You'll be famous!  You'll be a co-author of BabylonJS!  Your name will be written in the history books, and in the stars.    (And we all get a wonderful new framework feature.  Yay!)   Cya 'round the forum.  Thanks for the cool suggestion!

[lihis]

Thanks for the welcoming. Oh and for all the food!

Let me try to digest some of it.

9 hours ago, Wingnut said:

There might be good reasons for creating a sprite without a manager

But in this sprites tutorial it says: "This manager is mandatory, even if you want to create one sprite." There might very well be a reason to create a sprite without a manager, but currently it doesn't even seem possible? If it must be, then why doesn't it just already be there for me? 

Now as for all the stuff regarding what the programmer wants, or should know, or asks etc. I get what you mean, but at the same time, this engine is already doing so much. Webgl is already doing so much. So many decisions already made for me. I've heard of things like vertices, matrixes, shaders, algebra and a million other things. But i don't know what they are or what they do. It's like black magic all this. If my goal is to draw a sprite on the screen, and the engine says there must be a sprite manager for this to happen, i don't think i need to know that. If i want to do advanced or complicated things that require this information, then surely i'm at a point where i should either know to read the documents, dig in to the engine itself or find/hire someone to do it for me? Well, that's how i feel about it anyways.

Sprite2D... huh. Well what the fuck is this?   It's different from sprite? Is it better? Should i be using it instead of sprite? What are the differences? You asked some good questions in response as well. Are we in a situation where we have two different ways of doing pretty much the same thing? Because if that's the case, i wish the choice was made for me. I don't want to see people making these wrappers, tutorials and things for two different systems that do the same thing. Because i'd imagine the tutorials and wrappers and things created by users would be of superior quality when there is no splitting of user base.

Haha, I don't think i will be doing any pull requests anytime soon, because of... things. But if i get far enough in whatever it is i'm trying to do, i just might try to pay couple bucks to someone from fiverr or whatever to do something for me and ask them if they could make a pull request!  

Thanks for your thoughts. Have a good, whatever you wish to be good, halloween perhaps.

 

[Wingnut]

2 hours ago, lihis said:

If it must be, then why doesn't it just already be there for me? 

Hi again, L!  Nice response... good questions.  This is an open-source project, so the reason it is not already there for you... is because you weren't here long enough to add that feature, yet.  What is taking you so long?!  heh.  Deltakosh is the primary framework author, and, for me, I like to let him pick and choose what is a good idea and what isn't, as far as framework features.  And this framework is authored in Typescript, so a core-code contributor needs to follow a few coding rules that scare some of us little people.  Also notice... I have NOT properly answered any of your questions, yet... so... expect much better answers than mine... after folks come back from weekend partying. 

2 hours ago, lihis said:

So many decisions already made for me

Some.  But... keep in mind that you can use JUST the engine.  Or JUST the engine and the Scene object... or anything you want to do... because the source... is javascript (and Typescript).  Hack the framework into little pieces, use only THIS, or only THAT, and write your own "user layers"... the BJS authors have given permission for ALL of that.  YOU could completely re-code the sprite section of BJS, and YOUR version might be accepted as THE new system... for BJS version 2.6 (especially if you code its source in Typescript and make it be backward compatible with the previous system).  Although the current sprite system is working, it is certainly not perfect or at maximum power and efficiency.  But there is no "customer service team" available to activate your ideas.  This is all done as a hobby, in people's spare time... and Chief Deltakosh has a heavy workload happening IRL, right now.  Other local coding Gods are also under similar loads.

Your ideas are STILL good, and possibly warrant heeding... including the inference that possibly... too many decisions about the sprite system... have been made for you.  Try to be patient.  Folks will be reading your ideas.  Every new system is "black magic" until you spend some time with its code and people... and realize it was WHITE MAGIC the entire time. 

2 hours ago, lihis said:

Sprite2D... huh. Well what the f*** is this?

White Magic.    It is part of a system in-dev yet in-stalled... called the Canvas2D system.  Are ITS sprites "better" than standard sprites?  Nah.  Just different.  From a "big picture" viewpoint, Sprite2D ARE better, because they are more powerful.  With that power... comes more newbie confusion and questions.  It's always a give and take... this innovating thing.

2 hours ago, lihis said:

Are we in a situation where we have two different ways of doing pretty much the same thing?

With Javascript as the underbelly, most things have about 12-20 different ways of doing the same thing.  Deltakosh and the core team... chose the best 1-3 ways... and are still experimenting and learning every day and with every byte.  WebGL is a brand new frontier and no end is on the horizon.  It's wild... untamed... and people like you are blazing trails in all directions.  There might be nobody nearby that CAN tell you if an idea or experiment is better/worse, good/bad, etc.  You use the profiling system of your browser (part of its dev tools) and you watch performance speeds of your experiments.  Those numbers tell if your invention is good/bad.  Those performance numbers are the numbers Deltakosh and the core team use... to pick the 1-3 BEST ways of the 12-20 ways to do something. 

2 hours ago, lihis said:

I don't want to see people making these wrappers, tutorials and things for two different systems that do the same thing. Because i'd imagine the tutorials and wrappers and things created by users would be of superior quality when there is no splitting of user base.

That happens, with open-source.  But, "bad decisions" done earlier, and "unused things"... DO get deprecated or superseded... due-to the moving target that IS webGL.  It is evolving, so the API/commands we use to interact with it... will continuously change.  SOME bloat... happens.  But that's why we have the "core" version of BJS... so you can trim-off the "fluff" if you wish.  Again, you are allowed to write your own Node class, Mesh class, Scene class, Light class, Camera class, ANYTHING.  Decisions HAVE been made for you, AND they are not "chiseled in stone"... so they are NOT made for you, too.  

What do you think-of a system where every decision that "seems" made for you... is only LOOSELY made for you... and can easily be overridden with anything you wish?  Does it feel wonderful and free?  We BJS fans think so.  When Deltakosh coded the sprites system... he said... "You guys don't HAVE TO use this method, but HERE is a method created FOR you that has shown some of the best performance in my dev tools profiling."  He really made NO decisions "for you"... he made it for performance, for making it somewhat easy to do, and for providing a nice framework for his friends and fans.  He certainly had no intention of tying anyone's hands or making decisions for others. 

Deltakosh is a great guy and tasty coder... but he is busy busy busy, and has already done a big, wonderful thing... by making BJS free, available, and hack-able.  He's done his workload.  Now we... the fans... must grow and contour this baby, and TRY to keep-up with the ever-changing webGL spec, HTML spec, JS spec, Typescript spec, etc, etc.  Again, there is no customer service dept.  It's just us users/programmers, with our walkie-talkies (the forum)... and we're all blazing trails.  Fun as hell!  Beautiful scenes.  Geometry learning.  Great forum personalities!  Nurturing and collaborating.  Demented mad-scientist experiments.  White Magic!

2 hours ago, lihis said:

Oh and (thanks) for all the food!

Was that an obscure reference to Hitchhiker's Guide to the Galaxy?  The Dolphin message?  COOOOOOOL! 

[fenomas]

On 10/30/2016 at 5:05 AM, lihis said:

I'm just wondering what is the reason for this. For me, as a beginner, it would be easier to understand if it was automatic.

Sprites and sprite managers are separate resources with separate life cycles. When you create a sprite manager, Babylon will load up the required texture image, but not create any meshes. When you then create a sprite, Babylon will create a mesh and render with the texture it already made. Later on if you destroy the sprite, Babylon will get rid of its mesh but keep the texture, so that you can make more sprites of the same type. If you destroy the sprite manager, then Babylon knows you don't need that kind of sprite anymore, and it will get rid of the texture image.

Make sense? I'm omitting some details but that's the philosophy behind it.

[lihis]

@Wingnut Ah, but i'm not saying too many decisions have been made. It's the opposite. I think too few choices have been made for me. That's the reason why i ended up fiddling with Babylon in the first place. I was browsing the web to see how i could make some particles. At this point i was still thinking all 2D btw. Endless sea of options. You click and click and it's just engine and framework and tool after another. I hated it. Well maybe hate is too strong, it really is amazing for sure, but you know... just... too much.

Babylon seemed to do really good job of bundling things to a package that i could actually use. Just placed a javascript file into my Node.js / express / socket.io pile (i don't actually understand what they do either but i managed to get them do something) and i believe this means that i can take the socket.io user input and show it in Babylons dynamic 3D world. I haven't tried it yet, but if those (socket/node/express) worked with Vue.js they should with Babylon too right? right? Maybe i'm just wasting time. But that's pretty sick if it works as i'm hoping. And i mean why even make 2D if i can make 2D + 3D in 3D just as easily?  So while i am aware that everything is there ready to be poked and messed with and i think it's extremely cool, i don't want to do that. Sorry!  My hope at this moment is to put pictures and music and stories and interactivity on the screen, not spend time making tools or libraries. I want to use these engines and frameworks that people have made. I like making music with FL Studio. At some point i spent quite a bit of time with Paint Shop Pro, later a bit with Photoshop too. I learned some PHP + MYSQL back when i wanted to make a website, so that's coding but i learned that just enough to do what i wanted. I didn't go writing frameworks or libraries. Who knows, if i did, maybe i'd still be writing them. It never does get finished does it? That's why i asked about the manager. I was introduced 2 things when i wanted to put a sprite on my screen. Manager and a sprite. I understand i need a sprite to show a sprite but what is this manager thing, what does it do, why was this given me, these types of question popped into my head. So i came here to ask questions. Why was i given this manager, what am i suppose do with it?

I'm not expecting anyone to do mine or anyone elses bidding, but i came here because of simplicity and i think it could be even simpler (hence the question). Maybe everyone else wants something different from this, but i thought it was important for me to give some feedback out there what it is i like about Babylon and what i think should be important focus. I got replies so the idea got out there which is all i wanted. Maybe it will make a difference, maybe not, doesn't really matter. But now you know what i think!  And noooo i'm sorry, i was referencing to you when you said "Food for thought" in your post, not Hitchhiker's, but it's pretty cool your mind went to some dolphin message.

@fenomas That does make sense, but maybe that's because i'm imagining it wrong. Your description makes me think the manager as a texture library of sorts. Like if i wanted a gun that shot random bullets, i could load 10 different textures in to the manager and when calling the sprite i could load any one of those textures in the manager. Or use it to preload some textures that i know i'll be needing at some point but not sure when. That makes me think that there would only be 1 manager though, not multiple ones. So when making a sprite you would type:

var player = new BABYLON.Sprite("player");

Which would load "player" texture from the "library". 

Also, now i have even more questions. Like are there cases where you work with just the manager or just a sprite but not with both at the same time? Is destroying the manager manually so you can free the memory used by textures something that someone might want to do for example? Can i use this managers texture in some other place than the sprite? Ahh i'm too deep already. Asking questions about things i don't really care thaaaat much about haha. Oh well.

Thanks for the replies both of you!

[joshcamas]

Basically, the manager... well, manages them! It's designed to hold info that could be available to loads of sprites, instead of just having each sprite share their own identical data! Sharing is caring!

Example: Here is fake data attributed to 3 sprites without a manager (if this was possible):

Sprite1:
-X,Y,Z
-Image
-Cache
-Stuff

Sprite2:
-X,Y,Z
-Image
-Cache
-Stuff

Sprite3:
-X,Y,Z
-Image
-Cache
-Stuff

Lots of data! 12 different objects, and 3 images that are identical! Here is one with a manager:

Manager:
-Image
-Cache
-Stuff

Sprite1:
-X,Y,Z

Sprite2
-X,Y,Z

Sprite3
-X,Y,Z

Much better! 6 objects, and only 1 image! Now, obviously this is super duper pseudo code, but you get the picture I hope!

[GameMonetize]

Love this forum..Nothing to add, it was perfectly painted by my fellow forum users

TLDR: Manager is here for performance and optimization purposes.