[EDIT : RELEASED !] What about a code generator for the Playground?

In using it I have a few thoughts as there are several scenarios that get tripped up with the current feature.

  1. There are some elements - like primitives - that are checkboxes and multiples can be added, where others are a single use template - like lights. It seems to me that a user may want to mix lights and/or have multiples. There is one light option that creates three spots, but that is not the only lighting combination users may want, so it will either need to be an exhaustive list or lights are treated like primitives in that they are checkboxes.
  2. Checkboxes on lights brings up another pain point. What if I want two spotlights (not three) or two cameras because I need to create a render target texture? If you can only have one of any node from the tool, we are locking out certain scenarios. Maybe this needs to be additive - each click of a menu item adds a block of code rather than replacing a common node type in the playground.
  3. It’s very easy to delete user code in the current example. Each addition or change to the template replaces the whole PG rather than just what is affected. If the user adds a light manually and then adds an animation, that user-added light is deleted. This alone will cause a lot of frustration as the feature is not usable after the initial population of the PG. In this sense, I agree with @Deltakosh and @RaananW that maybe this needs to be a wizard and once the PG has been populated it can’t be called again.
  4. Another option would be to make it closer to the ctrl + space flow of wherever the mouse is in the PG is where we add the code for the selected node that is added. This avoids deleting user code and allows the user some control over the formatting of the playground. This could also be coupled with the wizard flow where a new PG would allow for the user to add a bunch of nodes from this menu and then once the user types anything into the monaco editor, it switches mode to just adding code to wherever the cursor is at and does not replace the PG anymore.
  5. I noticed a behavior that if I had added something like the dude animation with the tool and then reloaded the PG, as soon as I selected anything from the menu that dude would appear again. It seems like we are caching the selections from the user and on reload we add everything back from the cache. This can be surprising to the user if they don’t expect it.
  6. I also noticed that in some cases if I added debug through the checkbox and then removed it using the checkbox, clicking on the inspector button in the UI did not know the inspector had been closed and I had to click the button a second time to get it to open. In other cases, clicking the debug checkbox to enable and then clicking it to disable would not close the inspector but put it in embed mode as it would have been due to the size of my window. So it seems that the checkbox opening the inspector is having some issues with setting the state of the inspector button in the menu.

Basically, the challenge we have here is we should never replace code in the editor but should leave that up to the user. If the user adds multiple cameras and then decides they don’t want them, we should leave it up to them to delete them. There’s a design philosophy that I often come back to which is “never assume user intent.” If we are taking the step of deleting ANY code from the editor, it needs to come from the user. This could mean that the user disables a checkbox and we delete specific code we have tagged as added by the tool. But at the same time, if the user changes a part of that code - say changes the name of a light - that code is now custom and no longer should be attached to that checkbox. And if the user does not have any indication of which checkbox in the menu corresponds to any chunk of code, we will get inadvertent deletions that frustrate users.

This is why I feel more like we should not be deleting code at all. Maybe the wizard flow for a default PG is fine and we can rewrite the contents of the editor as much as we like, but as soon as the user types anything in the editor, we switch to an add mode only and no longer delete code. But that UX is tricky because we have to communicate to the user that the mode has changed and is no longer a wizard.

Honestly, with the current functionality, I would not open the menu at all for fear of losing code. The user needs to trust that we won’t delete any of their work because as soon as you change anything by adding it from the menu, the undo stack is cleared out and you can’t go back.


What if: before user executes generator command, dump the playground into a localStorage (or sessionStorage or so) key. Then you can always go back to a working state.

@PatrickRyan thanks for your very complete and structured feedback !
I’ll try to keep the same level :grin:

I think the main problem with this tool (and it must come from me, for sure) is that we might not have the same interpretation of what the Playground should be used for. But you guys developped the PG, I didn’t, so I’ll align myself on what you intend :slight_smile:

That said, I’ll still share my vision, for you to understand the design I did, and it will somehow answer your points 1,2,3 :

I use the Playground to quickly test some specific stuffs in a “ready to use” BJS environnement, and also to help people debug issues (same for you I guess). In both cases, I don’t consider the Playground as “a code editor”. First reason is that there is no CTRL+S and to me, no CTRL+S means I don’t want to use it as an editor (for safety reasons). I see the PG as a place where I can copy paste some code to be run easily, and also (thanks monaco editor !) if I need I can even edit some params and hit run again, saving some time, instead of going back to my “real” editor.

Now, the reason why I developped this tool was to have a quick way to change my “Starter Playground”. Before this, each new Playground was FreeCamera, Ball on Ground, no Shadow, etc… Each time I had to change everything. I ended up saving some custom “Starter Playgrounds” and bookmarking them in my Chrome bookmarks. But on Starter A I had ArcRotateCamera, on Starter B I had a dude walking, etc, at the end, still I had to open them in multiple tabs, and copy paste code from the one to another to build any new PG.

That’s why I designed this tool that I see more as a “Playground Starter Generator”.

About your point 5, this behavior was intended, since it was the param of this “Starter” beeing saved. point 6 : ok I’ll have a look.

Now, that said, I can align myself with your vision.

I 100% follow you on that one :slight_smile:
In Blender, for years, while CTRL+N was New File, the same shortcut in edit mode was Recalculate Normals. What a joke. They needed like 10 years to accept that it was non sense to have multiple CTRL+N shortcuts which would loose all your work if you are not in the right context :joy:

About your point 4 : I think it can be a good idea to get closer to the CTRL+SPACE snippet menu.
Now I see two possible (different) solutions, tell me what you think/prefer :

  1. Destructive : We officialize this tool as a “Playground Starter Generator”. Not to be used after editing the code. Or at least triggering a BIG WARNING. Like hitting the “New” button.
  2. Additive : We keep the full DropDown Menu as is, replacing all checkboxes by simple buttons, and we make so that it’s 100% additive, like the CTRL+SPACE. The code would be inserted at the cursor position. You are coding, you need a camera, either you hit CTRL+SPACE, either you walk trough drop down menu, and you choose your snippet to be added.

I’ll be happy with both solutions 1 & 2 :slight_smile:

1 Like

@Tricotou, I completely agree with you that we don’t see the playground as an editor, but more a “playground” where you can try out code and more than anything, learn how to use Babylon.js. It’s super useful for passing around examples or bug repros, but as I see some playgrounds with hundreds - sometimes more than a thousand - versions it does feel like some people are using it for more than just a quick experiment. Granted, anyone can find a playground and save a version to grow that number, but I also see people working out ideas in the PG before they bring it to their own codebase and staying in the tool for a while.

By the way, there is a ctrl + s on the PG, and I believe it’s enabled by default:

I also agree with you that this feature’s superpower is to quickly set up a playground to experiment or quickly build a repro and I love that about it. But I also know we have a broad range of skill in our community from working engineers to those just starting their learning journey into computer graphics. The ones who are just learning are far more susceptible to any potential pain point in the UX and may not even realize the intent for this feature to quickly set up a scene rather than being a “build a scene through templates” approach. And getting used to our snippet server saving and PG ID system does take a little time to realize what is going on for a new user.

And I would be remiss if I didn’t admit that I am prone to doing stupid things that cause me to lose work from time to time. I could just be setting up a quick bug repro (which means I’m not saving) and need to add something else like a shadow generator or arc rotate camera and not be thinking and grab it from this feature where whatever I wrote would be replaced. If I can easily imagine a scenario where I use these tools every day and don’t find it strange that I could find myself losing code, I have to imagine it could happen to anyone.

And as you say about Blender, all companies making products for humans make decisions based on how they think that product will be used and almost all find out that when humans get involved, design intent means nothing. I can’t tell you the number of times I thought something would be obvious until I handed it to someone else. I learned early on that if I think something is obvious or easily understood, I’m not thinking hard enough about it.

I think from both of your suggestions, the Additive solution offers the most benefit with the least amount of risk. If we have to put big warnings on a feature, we are relying heavily on users to read UI or not just click through warning boxes. I mean how many EULAs have we all clicked accept on as soon as the window pops up? We are conditioned to do it so I don’t think any amount of red text or scary language will prevent people from losing code and feeling the tool is broken. I love your suggestions, though and I think that having both ctrl + space and a dropdown that work in the same ways actually becomes a strength. I always try to design UI to have multiple paths to do what people want. Some like menus, others like shortcuts. Enabling both has the best chance of pleasing the largest number of users.

I really appreciate all of the thought and effort you have put into the design of the tool and I think this change will make it a better UX overall and make it useful in even more scenarios!

1 Like

@PatrickRyan OK, clear !

Ah yes I meant saving without a page reload with new playground ID. I use to save something like every 2 lines or almost, ahah, it’s a CTRL+S reflex :joy: HOPEFULLY for the Playground snippet server, I don’t use it :smiley:

Ahah, sure. Have a look at My Meme in the Meme Topic :grin: I’m not gonna lie, I lost code as well in the PG ^^

Then we have a deal :stuck_out_tongue:
Will work on it this afternoon

1 Like

Ok, @PatrickRyan here it is :slight_smile:

  • Destructive → Additive
  • Checkboxes → Buttons
  • Removed onUpdateGenerator
  • Removed onGenerate
  • Added onInsertSnippet
  • Fixing indentation based on cursor position

Also, for the sake of security, I’m forcing an insertion in case the user has some code selected while he clicks in the menu.
(The range constructor is like so :

new monaco.Range(startLineNumber, startColumn, endLineNumber, endColumn)

And I’m inserting at :

new monaco.Range(startLineNumber, startColumn, startLineNumber, startColumn)

Which would insert at beginning of selection in case it exists)

@Dad72 following your suggestion, I added in the snippets :

  • Skybox
  • Lens Flares
  • Audio
  • Sprites

(available as well in CTRL+SPACE menu)


@Tricotou hey! Something is not working as expected here:

And why don’t use const and let instead of var? “Nobody” uses var anymore :smiley:

Ah, is it a try on the new PR ? If it’s so, it’s a mistake, basically there is two versions of the snippet, one with “raw” code, and one with this ${N:code} which is a convention for monacoEditor, for automatic edit after insert (+tab to go from a field to another, which is ordered by N). I’ll have a look ASAP :slight_smile:

Because the official playground starter code uses var, and I thought, there must be a reason :grin:

1 Like

Wanted to create a screenshot but now it works…

In addition to const/let we should use async/await with the async version of functions where available to demonstrate modern javascript/typescript code.

I’m enjoying adding basic code just by selecting it in the menu a lot! :slight_smile: thanks! However it has a drawback. This way we will forget even more even faster LOL


In addition when I tried to add a light using the menu it rewrote the whole PG :smiley:

Just to make sure : Are you testing localy using my pulled branch, and the babylon-server ? Because otherwise you cannot test the PR with the snapshot server, FYI :slight_smile: (It’s another CI/CD build and the tools such as the playground are not considered on the snapshots links of the PG)

I’m testing the current PG which is online. Should I stop until the new PR is merged?

The links on the PR are for testing the core of Babylon, given the PR modifications
For example this link :
Is not a way to test. It’s running the playground from umd, except the core, from PR.

Since the changes of this PR are done in the /tools/ folder of the repo (not /dev/), it’s basically the same than the official playground, in this case

If you want to test this PR before the merge, you need to :

Thank you! I’m aware of everything you’ve written.

The issues I experience are present on the current https://playground.babylonjs.com

Since there is the new menu with the snippets I suppose your previous PR was merged. Unfortunatelly it introduced bugs.

I rephrase this question. Is your latest PR solving these issues so I shouldn’t be reporting them until the last PR will be merged?

NP :+1: it was just to make sure :slight_smile:

Ah ok, clear.

  • The fact that it replaces code is intended, and will be fixed in the last PR (not merged yet)
  • The ${N:keyword} is not normal, and I never had this. Do you have a specific way to reproduce ? :thinking:

The last PR will solve the code being replaced, to have it purely additive

1 Like

Go to: https://playground.babylonjs.com

remove the line with the FreeCamera (CMD+X), start typing add, choose arc rotate camera:

Hum :thinking: I cannot manage to reproduce … Maybe have a try with another OS / Browser ?

That codicon message is appended each time I step over an item from the list of available snippets:

@roland the last version is not online yet, let’s wait for this last one to test your setup again :slight_smile:

@RaananW how come the last PR (destructive → additive) merged 4 days ago (thursday) is still not online ? Is the tools build happening only once a week ?

c’mon guys it’s getting so horrific and disturbing ! :see_no_evil: I always used to change to ArcRotateCamera as the first step.