Maybe it’s time Roblox looked into upgrading the compression and storage on images. We need to be able to upload larger images.
I know Google is a big company who can afford to do it, and they process our photos for other services (AI training, for example), but they offer free unlimited storage on Google Photos. Perhaps Roblox need to look into ways they can do this too to allow for larger, higher quality textures and images.
Allowing .svg files (or similar) would be a good start – certainly these would be useful for UI design, and no loss of quality when scaled. They also take a very small amount of storage when compared to other image formats.
Last I heard rasterizing SVG was nontrivial and rather expensive, hence why we don’t have in-game support for it.
This tool should not be taking exclusively uploaded images. Requiring heightmaps be moderated is redundant, introducing problem after problem for legitimate developers (limited size, waiting for moderation, heightmap is now public, tedium and hassle of uploading…).
Places and place thumbnails are already moderated. Inappropriate games are out there and will be out there whether you like it or not. If this tool requires uploaded assets, developers will just build one that doesn’t, and carry on their merry way uploading places with rude pictures drawn in the dirt.
I will not use a tool that unnecessarily cripples its own potential, and my workflow.
Since when is JPEG larger than a PNG? Almost all of my screenshots that I encode in GIMP when trying to preserve a close quality are half the size in JPEG (if not less).
Yeah, I know the quality loss and no alpha support, so don’t give me a lesson about that. But for textures that don’t require high quality or transparency like billboards which could also use compression as a style, JPEG seems like a good idea.
Well, it’s just a picture I found on Google. concentrating more on SVG vs PNG here, as both support alpha. presumably their JPEG file is 100% quality and not compressed well
Does SVG need to be rasterised? Surely native SVG support could be implemented, as long as the engine knows when it pulls the asset from the server what the file type is
This was declined because SVG is too expensive and complex. Fundamentally SVG needs to be rasterized to be rendered. Rasterization is the process of converting the vector image to pixels.
Expensive for what? Almost every modern webpage runs vector graphics, be it fonts or icons (most of the icons in devforum are vector based).
Rasterizing vector images is not a very expensive process, but still shouldn’t be overdone. Roblox could easily overcome this issue by rasterizing an image when it’s assigned to an instance and treat it as a raster from that point on.
Lets also not forget that SVGs are almost always simple icons as they have little use in realistic images.
Did you read the post?
Modern webpages do not render 60 times per second. You cannot pre-rasterize SVG if you expect the image to scale dynamically at runtime and remain sharp, and if you do pre-rasterize once to some in-memory texture, where do you draw the line for size? Too large and you’re wasting memory (which is very critical on mobile devices), but too small and there is no benefit to developers.
This is offtopic and has already been declined by staff in the past. Do not debate this issue here please.
Well, I did say I am no Php wizard! But, my thought was that you can use Php to encrypt passwords, so since the asset ID is just a string of numbers; you could use Php to encrypt the ID and place it elsewhere for the the content holder’s eyes only. I am mostly referring to some comments up thread.
I don’t really understand why this has to use Roblox image assets at all. You should just be able to use local files. There is literally no reason I can possibly think of for it to be uploaded
What if… and I’m just saying “what if”. What if the Emote Menu make a triumphant return before the terrain height map importer (intentionally lowercase, bite me)?
Now now, hear me out. Both came across a “issue” that caused it to be disabled. (Aye you, you right there thinking that the issues could be in two different ballparks. Well, we aren’t thinking about that right now )
But what if the Emote Menu makes an early comeback before this feature? Maybe I’m wrong in saying this, but in my priority list this feature is definitely up there. So if the Emote Menu come back in the time frame that has been given its okay for me to wonder how that priority list is looking in Roblox right?
At what point do I want to prioritize emotes in my world that doesn’t currently exist due to the height map I can’t import yet. Gonna be hitting those emote buttons on the invisible terrain yeah? Can’t even get an update with a glimmer, shimmer, maybe just a reflection of hope.
I’m losing faith here. Water is literally shooting out of my eyes like lightning bolts, landing just beyond my feet in the form of a height map just to spite me.
I’m sure you know hundreds of engineers work at Roblox and they all work in their own teams on their own features and projects. The people that work on a feature like the Emote Menu are not the same people that work on the smooth terrain height map importing, and work on one does not delay or interfere with work on the other.
I hope you’re not trying to say that engineers can just context switch freely randomly to entirely different features/teams within the company, and that they can just shove tens of engineers onto one feature to improve the speed of development of that feature, and that they have a priority list where every single engineer is meant to contribute to the topmost item on that list only. I’m sure you must have a bit of a better understanding of how software engineering works than what you are trying to convey in this post!
)