The alpha bleed is not as fast as I’d like but I can’t think of how to make it much faster than I have already. Once parallel luau is allowed in plugins it’ll get slightly faster, but not much. As a result I added a new option in the settings to disable alpha bleeding. This works better for workflows such as yours where you’re exporting the images and bleeding them externally.
Speaking of which you mentioned that exporting one image at a time is slow, but it’s def possible to do multiple at once by grouping them all as a model. I added a “how to” for this in the OP + a lot of other documentation.
Also, you can now right click on an image when in the gallery to switch the background.
Finally, mentioning this here as well since a number of people were interested in it. You can now exceed the 1024x1024 limit by using the “Full Viewport Capture” mode. Again, more details on this in the main post.
I’ve found personally the best place to put the actions is on the quick access toolbar. However, I’ll look into alternatives as this may be non-optimal for some.
This…this is amazing! After I read this announcement, I checked the plugins bar but didn’t find the new option, but I read the first post and set up the action shortcuts. It took at least a minute to finish (plus I trimmed the image using Photoshop then lowered its size using Squoosh), but when I checked the exported PNG’s size, seeing something above 1024×1024 was cool! I wish the DevForum didn’t downscale large images (since I tried to make it take up less server space), but this File Explorer screenshot says it all:
Although it was scaled down, here’s my capture of my spring model (that I never finished texturing):
Also, I tested its UI capturing, which took a nice “screenshot” of my classic Windows-esque design with translucent pixels (its border)! (If you’re trying to do this but the plugin button’s disabled, select a GUI element like a frame first.)
Well, the missing feature was implemented, and seems to work beautifully, so I’ll keep my promise; Photobooth is a perfect plugin, and I can still recommend it for those needing high resolution renders of models in Roblox’s somewhat unique-looking 3D renderer.
Is it possible to add alpha bleeding setting to the Bindings functions? It would be nice to be able to hard code it similar to how you can with captureType. Since as of right now you need to constantly turn it off because it doesn’t save after you restart studio.
There are a few options here that I’m aware of, but having it work like it does now was a purposeful choice.
I have two concerns with having the setting save:
If a user toggles it off and forgets they may get a worse experience. I’d rather an unknowing person use alpha bleeding than not as it results in the “more correct” output.
Not every setting will save so from a UX perspective it’s weird that only the alpha bleeding checkbox saves between studio sessions.
Similarly I have concerns with adding it to the bindings. If I do that it opens the door to adding more things in the future and I don’t want the bindings module to blow up in complexity.
I’m not against giving control via code over this, but I almost want it to be a hidden feature. Something you actually look for, not something you stumble across.
This has improved my workflow tremendously! Thank you so much for making this.
I believe it could benefit from collapsing the settings and ribbon buttons into a single panel dock for the following reasons:
The plugin currently uses 3 ribbon buttons and frankly I do not have the real estate to justify it.
– Plugin panel could have settings to bring back the dedicated buttons
– Some of the features currently only work with quick access hotkeys. I don’t have much hotkey real estate, and quick access is like 6 pixels on my 4k monitor.
You mention “not all settings saving” UX issue- this also can be fixed with a panel.
– You can add two tabs, one labeled ‘Capture’ and one labeled ‘Settings’ and this will contextualize which settings are saved in a plugin context and which are session capture options.
– Instead of settings being a confirmation modal, add a Save button with a toast upon click.
Using a panel allows you to add a gallery view by default, showing multiple recent snapshots. Clicking could select them in workspace.
Additional photo related features that could be nice but are further from the initial scope of the plugin:
Saving and loading camera positions would be massively helpful as it enables further workflows:
– You can export ‘shadow passes’ by taking two identically positioned photos where one is empty and the other has a shadow catcher.
– You can design a thumbnail or icon, then go and modify your scene or character pose without losing your initial framing.
Any kind of lighting saving/loading. Lighting is a huge part of taking photos. There are not really any good plugins that are made to save and load lighting properties let alone light instances.
– One of the biggest issues is that you cannot see lighting instance ranges while simultaneously moving their parent object. No plugin currently solves this.
Selection functionality similar to the ‘Model Scope’ plugin
– Once enabled, if the user hits capture with one or more workspace instances selected the plugin would deparent the entire unselected workspace contents to a folder directly in the game datamodel.
– This allows people to take captures of objects within an otherwise very complex scene without deconstruction their scene or creating new place files and recreating lighting.
– Select the hero object, any lighting objects that influence it, and then click capture!
This plugin saves me enough hassle I’m more than happy to contribute to some of the ideas I’ve suggested if that makes implementation easier.
Regarding the ribbon I think this is likely to remain as three buttons.
I experimented with having everything be in one panel, but ultimately there were a number of UX problems with that approach.
A fair amount of click friction is added. Not only does the user now have to do two times the clicks for a simple capture, for things like the UI button they also need to ensure that the viewport is visible else they’ll get an empty image.
There’s also the whole confusion of binding the closing of the viewport capture option to the dock widget gui. If a user accidently closes the dock then it closes the viewport capture and now the user has to open everything up again. If we don’t bind the close of the dock to the close of the viewport capture we get the same problem but in reverse. You close the dock, but forget to close the viewport and you have to open everything up again.
Regarding the hotkey situation it’s something I’d actively like to improve. In my head a clean solution would be to just right click on the viewport dimensions bar and then select “Fullscreen”, however so far I have not been able to implement this without the regular right click context menu getting in the way. The “Focus” action can probably remain an action as I think for the most part it’s a power user feature.
In regards to your suggestion for additional features I agree that these are a bit further from the initial scope of the plugin. I think all of these could be implemented via the bindings option or the regular old command bar.
I highly disagree with your view of the user experience.
A panel being open during plugin use is the common and expected way of interfacing with a tool. A photobooth plugin is not a passive plugin meant as an overlay or global toggle, it’s a tool with accessories. We open the toolbox when we need it and close it when we’re done.
“The user has to open up everything again” is just selecting the Photobooth icon in their plugins list. The user will always needs to re-open plugins after closing them. Thankfully closing plugins is very hard to do on accident…
The issue of click fatigue is valid- but you are thinking about this all wrong. Currently the user has two clicks to initiate a viewport and then snap a photo. Yes- this would turn to three.
But, on the flipside, every other aspect of the plugin is less usable as a result of this decision priority.
Right now you have to hop between a panel, quick access menu, and ribbon bar. It is far from intuitive. By reducing the screen real estate required to interface with the plugin you improve usability by providing a single point of focus for the tool. And like I said, it’s rather trivial to add a setting to put the additional buttons back on the ribbon bar.
It seems to me that the Photobooth plugin is a rather power user focused plugin, and those are the types more likely to have a filled plugin bar.
As to the extended scope of the plugin, these suggestions would add value to the plugin since they’re closely in line with typical use cases. No demands for the features, but your suggestion to use a clunky alternative such as the command bar is precisely why they’d be so useful
Managed to get it to work by parenting to StarterGui and just bulk selecting and exporting (may work with a model but I didn’t try it). Not sure why bulk exporting only seems to work when parented to StarterGui when single exporting works fine in ServerStorage.
