This is an inventory UI that I made for my game and I just wanted to get some feedback on it (Excuse horrible buttons at the top, they are to be re-worked)
1 Like
There are many incoherent elements in that UI, issues are slightly noticeable but you do have a few mistakes pretty much all around that inventory.
For some reason, we can notice about 3 different kind of weapon outlines :
- no outlines
- white tiny outline
- dark glow
I Know this will consume you more time making icons for all weapons, but i believe it’s a must, or see ViewportFrame Release
Scaling issue, the vertical and horizontal sizes are not equal just like the inventory, therefore make deformed images.
i am not sure about that, but the button’s round border have the main color slipping through the shadow one, which doesn’t look good, specifically when all other borders doesn’t do that.
i’m not gonna judge your choice colors as i don’t have much idea what your game could be, but i feels like this Category selection “Blue” is pretty sudden and not much noticeable, you should make options/button like the inventory integrate it, not feeling like it’s a element apart and it’s was added up at the last minute.
Overall, this UI seems pretty stable, simple and probably works well, there is no major issue to talk about as it’s efficient and very easy-to-understand page sets.
12 Likes
Thank you. The texture Ids of the weapons are really bad and will be re-done because I stupidly rushed them. Anyway, I really appreciate this, thank you again
np, Just replying back to “insist” on waiting the ViewportFrame feature if you don’t need to add a custom outlines on your weapon icons, as it might be cool to add as it doesn’t make players downloading .png from your game (less or no internet data would be required to load the whole inventory)
2 Likes
This might be a good read
1 Like
Erm, what? Anything with an AssetId needs to be downloaded. Whether you use a ViewportFrame or not doesn’t matter - one is a 2D static asset and one is a 3D asset that needs to be rendered. There is no “faster” or “slower” in this scenario. I do believe however that a 2D static asset would load faster because it’s one image, whereas a 3D asset can be comprised of more than one asset and thus they all need to be loaded for all their worth (i.e. MeshParts need both their MeshId and TextureId downloaded, as well as anything else - including if a Material is applied to it).
1 Like
The icons for the weapons do not correlate to each other at all so maybe pick one effect like a drop shadow and give it to all of them instead of having a drop shadow to one and a white outline to one.
1 Like
You’re quite right, regardless my point will still comes valid if the rendering process is local. (probably not but i’d never know without proof) What i pointed out specifically was the internet data. So claiming there is no “slower/faster” without official informations of the rendering procedure gives me doubts.
There’s less data used if the ViewportFrame is given an object that can be rendered locally, such as a model consisting of several parts. The moment any of it is is a mesh or anything with an ID that needs to load in from the Roblox asset servers, a request needs to be made. Take in mind that an image consistently needs a single request to load all that needs to be shown, where a model with several meshes and/or textures needs multiple. Unless you are using mostly part-based models, the data used with ViewportFrames exceeds the data usage from plain images. (and my guess from the image is that most of OP’s weapons use meshes)
Do note however that, since the weapons are in-game already, the meshes and textures will need to load for them to be used. While the overall data cost would be higher, the data is required regardless assuming a client needs to be able to load all the weapons in-game.
4 Likes
No, your point is still the same, not any more valid than what it began as. Whether an asset is on the client or server side, its relevant AssetIds need to be downloaded by the client first before it is displayed or rendered, whatever the asset type is. Anything to do with AssetIds is already client-sided so that they can actually see the asset being displayed.
As the above pointed out, the only thing that doesn’t need to be downloaded would be items not utilizing an AssetId or plain geometry data. This is why bricks and builds load the fastest in and why you see everything as grey when loading is slow, before other assets (materials, decals and textures, MeshParts, Unions, clothes, hats, etc). Simply using a ViewportFrame isn’t going to magically make the process faster.
There is always preload if you’re really that troubled by how long things take, so you can prioritize the usage of assets, however beware that preloading large amounts or your entire game is bad practice because that’s not what preloading is for.
There isn’t any less loading involved with a ViewportFrame. If you aren’t explicitly using plain parts, it will certainly take longer because now you’ve added more assets to the download queue.
Alright, seems like i was not precise enough, therefore i will ask a question about the feature instead of just being told the basic informations of asset ID.
A meshpart and a decal is two different thing, means two different assets loaded, simple.
What about having a meshpart and it’s being rendered in Viewport? It takes the same ID therefore it’s not going to download twice the mesh/texture, the reason why in my first post i’ve mentionned “not making loads PNG” is due to my lacks of information the format Viewportframe id exporting at, and i assume it’s not a image as the 3D model rendered can be rotated w/ script. (CloneTrooper’s 3D Module worked that way, so this is why i find it possible)
For me, it’s pretty much a model copied and set to a frame = no additional internet data required
If it does, please let me know, i know you’ve been trying to get my knowledge corrected but the whole discussion didn’t lead to the elements i was actually lacking documentation
But this was literally the whole point of your statement, that supposedly using ViewportFrames is more performant than a decal. Aesthetically yes, as it relates to OP, it can save them time for icons, but your information is flawed in the sense that you think VPFs load and render quicker than other assets.
No one said they are the same. I said that they’re both assets. MeshParts have more assets to be downloaded than a decal.
No asset is ever downloaded twice. Once an asset is downloaded, it is cached for the rest of the game session. This applies to any and all AssetId based content anywhere.
Re-read my previous post. This is a very basic question as it relates to AssetIds which has already been answered. Anything with an AssetId has to be downloaded. Using a ViewportFrame or 3D adorner doesn’t skip this process or make it shorter. The only thing that is implicitly loaded (for the most part) is geometrical data and plain parts. Everything else - materials, textures, unions, MeshParts, whatever - has to be downloaded. Just because a model is in the 3D view and it’s copied to a frame, doesn’t mean it’s going to magically skip the process. It still needs to load.
This whole statement has been explained three times now. I fail to see what you don’t understand or what your point is.
No, all i asked was " if the rendering process was from either server side or local " cause i thought it was a generated .png BECAUSE you first replied negatively at
Countering with
Therefore i started to be confused and just agreed obviously, loading a image would be faster than the server generating it from instant request. Which is why i said to skip the basic and to precisely say that i needed a more advanced documentation about this feature.
in no way i intended to correct you, i was saying this so you could easily compare with my upcoming question and so you could skip this info…
Yes i already knew, but once again, it’s because you made me think it’s was a actual picture generated therefore making the game load the same assets twice (one for in-game workspace, other for the viewport)
I’m going once again back to my original point when i’ve replied back to WhatZitTooyya : You countered the following information : "it doesn’t make players downloading .png from your game (less or no internet data would be required to load the whole inventory)"
so yes, didn’t thought i’d actually have to say it, but i didn’t wanted to know the basic because i already knew them, and you said it too that downloaded assets goes to a cache, therefore you’ve been argumenting the whole time on something i was actually right,
just to let you remember, the essential elements i recommanded for him to use ViewPort was just “Less or no internet data would be required” as the object would already load via Workspace (In-Game)
The server doesn’t load any assets and there is no “instant requesting” either. All loading is done from the client. There’s nothing advanced or basic about it. The client renders items in the 3D view and grabs assets so they can see it or hear it depending on what it is.
I only slightly understand what you mean now - your wording was unclear so I hadn’t a clue what you were trying to convey. You’re saying that if a model has already loaded and been in the 3D view, then using a VPF wouldn’t need to do any downloading at all - it’d instantly render. Okay but that doesn’t change much about the statement. This is only reliable if the asset has already been loaded and rendered once before. Doesn’t make it any different from queueing a decal asset and having it load for the first time, or preloading it. There’s quite literally not much of a difference and if you assume that the player opens the shop for the first time later after most loading has been done, it’d load quickly because the queue is small.
There are always exceptions, sometimes there are so much assets it easily take me a full minute to load all assets on certain games such as Counter Blox, or if i’m playing while sharing my mobile connection or even playing outside is easily a possibility now, skins on games can be numerous and expanding the number above a hundred is not even a rare case now,
a simple “quickier” load is probably more than you think, because it’s optimizing the time of “millions” players, of course it includes people that come back in the game aswell as they’re getting live the download just from playing another day.
Well yeah, you explained it yourself. Asset loading is dependent on your connection and how many there are in the queue. Just preload what you need instantly seen by the client and the rest can get loaded in naturally. It’s not like a load screen or waiting a bit is going to hurt, unless you’re waiting long.
ye i was just recommending the new feature since he will have no need in making icons.