Hi folks! I love new tools in BabylonJS such as the Sandbox and various editors. I’ve been thinking about how to incorporate them more efficiently into my VS Code-based workflows.
As a starter project, I created the Babylon.js Asset Viewer (source code) which wraps the Sandbox viewer in a VS Code extension. It’s very similar to the Babylon.js file viewer, which has not been updated in a while. It also adds schema support for .babylon files which makes them nicer to view and edit. (Although probably no one besides me tweaks those by hand )
If any of that sounds useful to you, I’d appreciate feedback on the current pre-release. Feature requests are welcome.
very cool. I have been wanting to do something similar based on this GitHub - xyc/vscode-mdx-preview: MDX Preview for Visual Studio Code . This mdx extension has a cool stateful reloading mechanism without using a dev server. It could actually be a replacement for webpack in the babylon editor (the electron version). I gave it a college try one night, but didnt get too far because the electron editor code is a bit too nested, using many electron windows, and using relative file paths for project files, all making it pretty hard to change. My next thought was a vscode addon or something in browser. I havn’t seen any vscode addons do this, but I would really like to have an extension be able to create a detachable window, like how the NME editor works.
I don’t think I’m completely following you. When you say “stateful reloading”, what is the state that you want to preserve across edits? Also, I’m not familiar with the “NME editor”, and Google search didn’t shed much light. Could you elaborate?
stateful meaning the entire state of the app, but the main point is that it doesn’t do a full window reload. Sorry, NME is the babylon node material editor. It can be hard to find, another reason it’d be cool to have it in vscode. There is also an awesome animation curve editor and texture editor too.
Hi guys!
I started to create something similar maybe a half year ago just out of curiosity and I wanted to learn how to code VS Code extensions. I stopped to work on it for a simple reason. Every extra window in VS Code occupies valuable screen space and I usually run out of it after a few minutes of coding despite I code on an ultra wide 4k. Now I run VS Code on the 4k, the browser on a Full HD and I have a third one for the developer console. So it’s much more comfortable for me to open the assets in the Sandbox with all the functionality available.
@ComicSans thank you very much for sharing your extension with the source code available as well and thank you for the effort you put in it! My opinion is based on my experience and my coding habits and I am pretty sure that your extension will be very valuable for other coders!
Thanks for the details, @jeremy-coleman . We’re on the same page with respect to the value of integrated editors!
Also, the extension is not doing a full page load when you change the target of the viewer. I initially implemented the viewer window as an editor window, similar to the digest. However, it had the issue you’re referring to: browser state was sometimes discarded when you wanted it preserved. The current version (with the viewer being docked in the side panel) was implemented to work around this problem. What looks like a page reload is actually just the default Sandbox behavior when you change the asset under view. So, if the desired behavior is possible in Babylon at all, we should be able to replicate that here.
@roland , I hear you about total screen real-estate! I have a triple-monitor setup, and my typical workflow has a running version of my babylon app in one of those side displays. The canonical issue about supporting multi-display windows in VS Code has been on the backlog for years. Even so, I believe there are ways that this could be worked around today. I’ll think more about it. Thanks for the feedback!
I am surprised that you were running out of space on an ultra-wide, though. I was hoping to upgrade to a Samsung 49in, specifically to work around this issue. Unfortunately, I don’t have the budget right now. Is there a limitation with using VS Code on an ultra-wide display that makes this approach impractical?
I like to separate my functionality into multiple smaller classes so sometimes I need to open more than 6-7 windows at once. I open a window or 2 for the frontend, 1-2 for the backend and I might want to open another one for whatever reason and I’m already done. I need to hide the explorer already. I use CTRL+B to show/hide the Explorer and CTRL+P for quick file search a lot but I always end up with no more space available for a quick CSS editing window LOL!
The second thing is that I like to be very descriptive when it comes to variable/function/whatever naming so I end up with quite long lines. But it helps me a lot to instantly recall what a given variable is used for.
Another thing is that I am using Prettier with printWidth set to 160. The standard 80 is totally nonsense, 120 might work, but because of the descriptive naming 160 fits me well.
It’s all about your coding habits but IMHO an ultra-wide is a must At least for me…
)
I use CTRL+B to show/hide the Explorer and CTRL+P for quick file search a lot but I always end up with no more space available for a quick CSS editing window LOL!
At least for me…