New update for 4.9! : I’ve made it so that the menu looks a lot better! It’s a scroll menu now with buttons fade-in/fade/out flashing. Here’s how it looks:
Now that the system is being released, I haven taken the liberty of recording a more proper video -this time without a cold, thankfully : ) - where I’ve explained what the system is so that every potential buyer will know exactly what to expect. I’ve also stated what the system will NOT provide you with in order not to mis-lead anyone into buying it in any way. Here it is :
Hello everyone ! I will do my best to make this resemble an actual support page, so here we go ;
FAQ :
-Is this updated to the latest engine version as of the moment ?
-YES!, just sent the 4.9 files to Epic - it should be up anytime now.
-Do these settings apply for packaged executables just as effective as they apply for your in-editor demonstrations (i.e. Can you save your options, quit the game, then come back and expect them to be persistent) ?
-Certainly, when I say persistent I really mean it : ) It works just the same as you see it in the presentation video where I’ve showed how it works in editor.
-Does this menu allow you to get resolutions supported by the client’s GPU ?
-No, as far as I know that is not possible without a plug-in. However, the amazing Rama has made a node that allows you to get the screen resolutions supported by the current GPU : (39) 's Extra Blueprint Nodes for You as a Plugin, No C++ Required! - Blueprint - Epic Developer Community Forums
My menu uses an enum that has in itself all possible resolutions that I could think of. So you can use Rama’s node to get all possible resolutions, then bind a function to the resolution combo-box, forcing it to skip the bytes that correspond to unusable resolutions in that enum. It is rather easy to achieve, yet I can always help you out with it if you reach me by email : )
-How do I add in a new resolution manually ?
-Right this way : Persistent Graphics Menu - Marketplace - Epic Developer Community Forums
-Can I buy this and expect to use it right away in a finished project, relying on it to solve my graphics menu needs ?
-Yes, this content does not only give you functionality for your graphics settings needs but also gives you an actual working graphics menu to use right away. You can use it without even needing to open the Blueprint editor for once. However do take note that this menu will not give you any visuals. You will still need to make this look in a fashion that you desire.
-So I still have to visually design my graphics menu; can I make it look however I want and still keep every functionality it offers ?
-Yes and no. You can visually design this through the UMG editor however you want with one constraint : you can not change the widget types that I’ve used without needing to change the BP a bit. For as long as you stick with the comboboxes and checkboxes, you can still change the visuals without needing to tweak the BP itself. Yet if you desire to have, for example, a glider instead of a checkbox you WILL need to change the BP a bit to make it work. It still won’t be hard though since I have commented and tooltipped every corner of it, yet I can always help you out with it if you reach me by mail. Or I can release an update that features different widget types if there is enough demand for it : )
-How about VR, does this menu give me any control over any VR functionalities ?
-No, none at all! : ) See this post : Persistent Graphics Menu - Marketplace - Epic Developer Community Forums
-Would this have any purpose as a learning material ?
-I am pretty confident that it would to be honest. One thing that I’m sure I achieved with this content is tidyness; the BP layout is very clean, comments are everywhere they’re needed, tooltips are present for every single public variable. Though it is probably a bit expensive to function just as a learning material if you have no other actual use for it : )
-Ok, I have the system but can you tell me in detail how to use all the fancy stuff it has to offer ?
-I already did! Here ya go, as detailed and boring as a manual can get : Persistent Graphics Menu Presentation - YouTube
You want to make sure you watch the second and third videos if you have purchased the system.
-I’m not a pro in these things, and I’m not certain that I know what I’m doing when it comes to graphics. Is there any way that I can harm my or the client computer’s performances or cause crashes when tweaking this menu ? Also some of these options are present in Post Process volumes as well such as bloom, what about those ?
-Nope, not a chance. Nothing in this menu will interfere with your post process options, meaning : Bloom for example will turn it on and off globally using a command that is not exposed to the post process volumes. On the same subject, all such options are tied to each other and the main Post Process Quality option according to the scalability reference provided by our dear friends at Epic. If bloom is turned on while Post Process Quality is at medium for example, the relevant quality value for bloom (4 when PP is medium) will be appended to its command node. Similarly, if Post Process Quality is changed while bloom is on, bloom will be re-initialized with the provided Post Process Quality value (so it will have its own quality value appended to the command execution node which is taken from the scalability reference). Alltogether this means you can safely use these options in any combination with each other as well as your post process volumes. If you know what you are doing, you can disable using Post Process Quality and manually put in your own values for these commands (by default you cannot do this when PP is being used in order to prevent crashes or extreme performance problems).
-I know a bit of these things, and I know for a fact that these “sg.” commands are packaged commands that include in themselves various “r.” commands. Those r. commands require values as well, how do you assign those values especially when some of these options are effecting one another ? What witchcraft is this ?
-Good question. Any combination that results in one option effecting another forces this menu to use the values as stated in the Scalability Reference by Epic. This ensures that you can not in any way have any unwanted outcomes with any options you are using with any values they are set to. See the above question for a bit more insight to it.
-Tis’ all good and well, but what if I want to expose only a few of the possible options and keep control over the others manually ? i.e. What if I don’t want to have Bloom and Effects Quality in my graphics menu ?
-All options are toggle-able, meaning you can expose whichever options you want to this blueprint and leave the rest out in case you want manual control over them (which probably would be the case in cutscene based levels). Furthermore, you can have any combination of used options you desire due to reasons explained above. The only limitation is that you can not use screen mode without using resolution (see “screen more issues” below).
-Screen Mode issues (windowed)?
I have not used r.FullscreenMode for controlling the screen mode since many people reported it to be not working (myself included) or bugging so you can safely use screen mode option as well (tested myself to see it works in 3 different rigs in a packaged project). If r.FullScreenMode works for you you can turn off exposing screen mode to my blueprint and use that command yourself; or if a lot of you request it I can implement it as an alternative to my current workaround as well : )
This is it for now, do let me know if I have missed some important information.
I am really happy and honored to have created a piece that was deemed worthy to be presented to such a wonderful community as this. I would love to hear your feedbacks, requests and questions. Keep up the good work everyone !
Cheers !
