Attempting to make an icon of an asset in-game

[Jhxan]

The best option like you also said is to upload it as an asset. By serializing the model we can get the XML format. Once we have this it’s basically just a matter of uploading it.

When the model has been uploaded, using an api such as https://assetgame.roblox.com/Thumbs/Asset.ashx?width=110&height=110&assetId=1818 would work just fine.

This might be of some help when it comes to serializing, it is a bit outdated but seems to work fine. Just make sure you change this:

if not hmm:find("%[") then props[name] = realTyp(typ) end

to

if (hmm) then
	if not hmm:find("%[") then props[name] = realTyp(typ) end
end

Example:

local m = require(script.MainModule)
print(m.Serialize(workspace.Baseplate))

For more information on uploading a model, this endpoint seems ideal.

[ScriptOn (Genya)]

Wow this is an excellent idea, thank you! I’m a bit of a noob when it comes to website APIs and such, would it be possible to do all of this from in-game? I’m trying to avoid having to set up my own servers as much as possible.

[Dysche]

Roblox web APIs can’t be used from within the game, hence the NodeJS bot I mentioned before, basically he just explained it better lol.

You’d have to setup a server with a web endpoint (REST or something) to send over the serialised data and make the upload request from there.

[Jhxan]

The serialization is done purely in-game but you will sadly have to spin up a webserver to handle proxying requests to roblox.

Step by step it could look like this:

1. Serialize the model into XML
2. Send a POST request containing that xml to your webserver
3. Webserver sends another request to the /upload endpoint with the contents
4. Send the asset id back to the Roblox server

You might also have to take the image Roblox returns and upload a separate decal of that. But only if you are unable to get an asset thumbnail using some sort of in-game api.

[static2240 (DevStatic)]

Do you mean something like this, i mean you could just make it model and publish it, You just have right click model and press save image as

(the image that right beside the sales is me moving icon with the mouse)

[Maximum_ADHD]

To clarify, are you trying to generate a thumbnail for something that was user-generated at run-time, or are these just static models that exist in the game when you publish it?

This is another fun case of Roblox’s tooling being insufficient for scenarios like this, requiring 3rd party software to accomplish. Even if you do get something like this working, you have to keep in mind there’s a potential risk of being moderated since the auto-generated thumbnails have to be looked over by someone now, and you won’t get an immediate thumbnail as a result.

I do understand the frustration with ViewportFrames and the amount of memory they consume, we’ve struggled with that problem in our game too. Would certainly be nice if we could capture a ViewportFrame into an image once and then free it from memory.

[ScriptOn (Genya)]

User-generated models at runtime, every minute or so. I want players to be able to cheaply preview a potentially massive asset without having to download it, which is why Thumbnails appear to be the only option.

[M_caw (Macaw)]

@NoTaxEvading

I read the post already, I just told you it is the best option to do.

So, the OP explicitly clarifies that they do not want solutions that involve ViewportFrames, and you willingly ignore this request? Telling the OP that ViewportFrames are the best solution is unhelpful as the OP already realizes they do not want to utilize them. What’s the point of your post if you’re not adding to the topic?

[NoTaxEvading (kneebandit49)]

I just thought I would bring that in, I know he doesn’t want ViewportFrames to be included but all I said was it was the best solution then I said the unexpensive solution

[Tomarty]

@Maximum_ADHD

Would certainly be nice if we could capture a ViewportFrame into an image once and then free it from memory.

This is exactly what we need. Would be perfect if we could do this server-side. Perhaps these images could have a unique content format so they are game-specific. This would prevent bloating Roblox’s content server with temporary asset ids. They would probably need to clean up or be down-sampled based on a few factors like image age, times since last viewed, and whether the game is producing an unreasonable number of icons relative to the player count. There would need to be some way to verify that one of these images hasn’t been cleaned up, so that the server can re-generated it. Image deduplication would be great too.

If images could be generated on the client, they definitely should be local and only work on the client that generated it. Images generated server-side could be potentially used cross-server, but not cross-game; Games should be held accountable for generated ViewportFrame images if the feature is misused.

[AstroCode (Ella)]

This is a ridiculous suggestion but you could run a stripped down version of your raytracer with actors to generate the images.

[ScriptOn (Genya)]

I’ve considered this but I run into two of the same issues:

• 1: I now need to store 4096 * (5 - 14, depending on Color3 values) bytes to store just a 64p image, which means I have to go through datastores, which is a strict no-no for my use case due to latency
• 2: I now have to load 4096 (64p) parts/frames per room, but I can have tens of rooms visible at once, which quickly adds up

The only reasonable solution is to just have every place be a small icon. Memory efficient, easy to store/access on my end, and the asset ID only takes up like 10 characters?

[Tomarty]

Is it possible to approximate the model with fewer parts? There could be a low-detail version of each asset in the model, and obstructed assets could be omitted.

[ScriptOn (Genya)]

The issue is that I now need to go through DataStores again, which really ruins the fluid experience I’m going for. MessagingService only has like 1000 bytes and it’s the only way I can get a responsive server list, which is absolutely critical for the games function.

[Tomarty]

1000 bytes might be doable if MessagingService supported binary strings. You could fit an approximate cframe in 13 bytes if you had to (3 shorts for the positions and 3 shorts + 1 byte for a smallest-three-encoded quaternion rotation; You could have a header byte that specifies the range for the position shorts.) You could probably manage 16 bytes per object by storing the object’s id and other info in 3 bytes. You could fit 60 objects within 960 bytes this way, but you’d need to convert the binary string to base 64 which would leave you with 45 objects. It really depends how much customization you allow and whether it can be approximated with just a few large objects.

[ScriptOn (Genya)]

I appreciate your efforts but 45 objects isn’t enough. I need to display thousands of objects + characters models on top of that.

If I compressed it to a semi-visually identifiable state that’d still be hundreds of objects, at minimum.

[PysephDEV (Pyseph)]

With the current state of Roblox, this would not be possible without utilizing options that would be either expensive (ViewportFrames, as you mentioned) or using external applications (which you didn’t want to).
Also, could you clarify on how you would expect this to function - would the user be creating assets never seen before, or are these assets still cached in one way or another (I.e pre-defined / pre-modelled assets)?

[Tomarty]

@ScriptOn

hundreds of objects, at minimum

Yeah there’s no way you’re fitting that in less than a kilobyte without dropping objects and suffering from serious precision loss. At best you could send a janky approximation that later updates using the full data from DataStores, but it would still lag the client and show up low-res on mobile. Would be cool if you could blur the janky approximation until it loads.

[FieryEvent]

@ScriptOn

I remember years ago you could do this by creating places and using the icon, but now the default icon on newly created places no longer shows what’s actually in-game, and there’s no API to change it from in-game.

Would you still be interested in this if we could find a workaround for displaying the thumbnail of what’s actually in-game? That is, after the slow process of creating a place with CreatePlaceAsync, having at least 1 player join that new place, and then saving the model with SavePlaceAsync.

[Anaminus]

Messages allow 1024 bytes of JSON data. A JSON string is the best way to store data. Minus two for the double quotes.

1024 - 2 = 1022

Not 8-bit clean. Base85 is good; has an efficiency of 0.8.

1022*0.8 = 817.6

Bits are better to work with.

817*8 = 6536

You said hundreds of objects. 152 has a hundred in it.

6536 / 152 = 43 bits

Objects will likely need a size and position, and probably a color, too. Let’s allocate some bits.

sx 111111  64
sy 111111  64
sz 111111  64
px 1111111 128
py 1111111 128
pz 1111111 128
bc 1111    16

Size: [0,63] at 1, or [0, 31.5] at 0.5, or [0, 15.25] at 0.25, however you decide to divide it.

Position: [0,127] at 1, or [0, 63.5] at 0.5, or [0, 32.25] at 0.25, however you decide to divide it.

16 colors. Maybe use that leftover 0.6 bytes to store a color palette index.

Now all you have to do is use some black magic to reduce the model to fit these constraints. Or if that’s no fun, you could just let the player “draw” their own 3D icon made out of simplified blocks. There are plenty of creative solutions.

That should do it. I’d have put more thought into it, but folks these days need answers within minutes.