Is there a way to use other responsive units from CSS such as rem instead of px? I’m noticing there’s a lot of px values and I want my UI to be responsive across different screen sizes, zoom levels, and pixel densities. Using rem is how I usually get around that.
Are there mobile breakpoints with Babylon’s GUI? I want to something like this on mobile:
However, I don’t know if there’s any sort of media query behavior I can use to adjust GUI grid behavior between different screen resolutions, which I normally solve in CSS with mobile breakpoints. I have a feeling that the percentages I’ve set for each column/row will be very different on phone screens vs. tablets vs. desktops.
I just wish the GUI system worked like flexbox so I can set my three buttons to a square rem size and align them in the middle more easily, instead of fiddling with grids across devices. Let me know how I should approach all this within Babylon.js though. Thanks everyone!
(pinging @msDestiny14 since you had a great video on the GUI editor and maybe you can help me figure out a workflow here)
Hi,
Glad to see someone else 1) considering the BJS GUI for responsive design 2) willing to try it with the editor 3) challenging it All this to say that your post is already welcomed at least by me
As far as I know only pixels and percentage mode are implemented. Percentage would work for responsive, however there are a number of restrictions to it (and currently, even more with the editor that is further limiting the use of mixed values on containers and controls - something I’m trying to challenge and hope will improve in a near future
Yup but… no (not as far as I know). Another interesting question, if you ask me. There is nothing like @media for the handling of the GUI (again, not as far as I know). The only way I can think of to implement something similar is to make it through the window/canvas on resize. There’s an idealWidth an idealHeight for the FS GUI, but it doesn’t have more than one value so it cannot really be used in the same way (again, my opinion only).
Bring this through and I will hug you like you’ve never been hugged before
Disclaimer: Despite for the above and the somewhat cumbersome aspects to deal with, know that it is still 100% possible to create a convincing and responsive GUI with the BJS GUI. And then, there are other advantages to it (like better scene integration). But if you want to push the BJS GUI for further improvements, I will of course support you 100% in this.
@mawa 's response is very comprehensive as always - unfortunately we don’t support anything other than px and percentage yet. For the breakpoints idea, I think the best solution currently would be to check the width/height of canvas and do the needed adjustments. Maybe @PatrickRyan has done something similar before?
@wavetro, the Babylon GUI system is a stand-alone system build for the engine that takes inspiration from CSS, but is not a direct re-implementation of CSS. So there will be things like rem that have not been implemented into Babylon GUI. That does not mean they will never be there if there is enough call for them to be developed. And there’s nothing stopping anyone from contributing to the Babylon GUI system to add features like this before the core team can devote resources to them. But I can’t say for sure when a feature like rem would be added to our production schedule. But we do want to improve the responsiveness of Babylon GUI as we develop out the GUI Editor.
For your question about buttons and flexbox, I would agree with @mawa that the best way for now is to set your button size with pixels, and then the grid cells with percentages. This should prevent you needing to customize quite so much based on screen. It may not be exactly what you are used to with CSS, but that is the best way to work in the system as it stands today.
For break points, you have two options. GUI Editor itself is just a graphical editor for Babylon GUI code so you don’t need to write the code for all of your controls yourself. In that sense, you still need a scene to get the most out of your GUI such as behaviors and state change. You can approach updating your GUI based on device in a couple of ways. One would be to swap your ADT based on the screen proportions so that you are serving a portrait layout for portrait-oriented screens and a landscape layout for anything landscape-oriented. The other would be hiding/showing controls that belong to one orientation or the other depending on the screen orientation.
We have an example of the latter in the Space Pirates demo GUI Framework and you can see the in-game menu using that ratio where we check the aspect ratio of the screen and then either show or hide specific controls based on that check. In this case, we are generating all of the controls in code, but if you are using the GUI Editor, you would just use that check to enable or disable controls you have already created in your ADT. I would just use a name prefix or suffix to generate an array of all controls that need to be changed with the screen ratio such as controlName_land and controlName_port. Getting the control names and then splitting the string by the _ is an easy way to sort them into arrays.
You could also have parameters that change based on the screen orientation, maybe your grid has fewer columns or maybe your button sizes change. But changing individual parameters based on screen ratio would be very tedious. If you don’t want to load and swap multiple ADTs, you can create different control hierarchies for each screen orientation and then just enable/disable them based on the screen ratio.
This would be the same as if you were showing/hiding new UI based on user interaction like clicking a button. In this case, however, it would be driven by the engine updating the ADT based on screen width divided by screen height.
I hope this helps, but please feel free to ping back if you have more questions.
Thanks for the replies everyone! I guess the GUI will be more responsive in future versions of Babylon.js, but I’ll stick to the current px and % implementations until then. I would definitely contribute more CSS functionality to Babylon’s GUI if I could
I can give you a small trick for the handling of the editor (since it appears you are willing to use it).
In this beta version of the Editor, you will eventually not be able to set percentage mode to a container or control (although there is no limitation for it). The good thing is that there are also still lacks in the logic that you can put to use to actually force what you want to do:
When you set a percentage to a container or control (knowing it can handle it) and the interface automagically converts it to pixels, you can sometimes work it through by:
clicking first on the percentage icon, next entering value which is converted to pixel, next click on the percentage icon again and re-enter the value.
or – if the above does not work – click on percentage icon again after it has automagically converted to pixels BUT do not enter a new value. Instead, use the guides/bounderies of the control/container in the canvas to rescale it (in percentage mode).
As I said, I’m still challenging this automagic conversion from percentage to pixels behavior in the editor (which to be honest, I find pointless and also, as per the above, does not really work as of today) and I hope it will either be improved or even better, removed in a near future.
That would be highly appreciated. But even your comments, feedback and support (I believe) can also help pushing for improvements of the BJS GUI. So, please do not hesitate to come back here and share your experience (like I do).
Meanwhile, I hope you are still enjoying the experience with the BJS GUI. I do
Have a great day
Absolutely, and for this I guess I forgot to mention that, when using the Editor, you can actually avoid creating 2 or multiple versions.
Instead, you can host everything in a single GUI Editor layout. Work it out like ‘tabs’, constraining each version in a root rectangle container. Then simply offset this rootcontainer 100%, 200%, etc.
Next, in the script, on ADT select, simply hide the version that is at 0 left and/or top and push to the 0 left/top the root container of the layout you want to serve.
Below is an example for you which I’m using for my scene for all of my ADT for meshes.
All of my ADT for meshes are hosted in a single file (for about 30 ADTs with 5 variants (hopefully soon to be turned into ‘clones’ @Deltakosh ).
The advantage of working everything in a single Editor layout is clear, I believe. Not only, does it keep things in order, but for any later change, you can also make use of the awesome copy/paste/duplicate functionnality of the Editor and next update everything at once; making sure everything is also always using the same and latest version.
As a final comment for the team, I know I often make comments/posts to challenge the GUI or the Editor (sry ) but then, for this aspect, I just have to praise the Editor : It makes things just so much easier and under control. For me, it clearly is one of the unique advantages of this tool (probably even the first one )
Thanks for the great tips @mawa! I agree with you that the visual editor is great, but it shouldn’t force you to use pixels for everything. Although instead of pushing to keep % behavior in the visual editor, I would (or will) go further and push for responsive units (both % and rem) as well as flexbox layouts. Maybe one day, Babylon…
All this to say that your post is already welcomed at least by me 
Flexbox for react-three-fiber (github.com)
