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?
3 Likes
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
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.
7 Likes
This is a ridiculous suggestion but you could run a stripped down version of your raytracer with actors to generate the images.
1 Like
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?
2 Likes
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.
2 Likes
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.
1 Like
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.
2 Likes
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.
1 Like
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)?
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.
1 Like
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.
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.
4 Likes
It actually looks like the Creator Dashboard still uses some kind of API to generate the icons on places without any custom icon:
icon from the game on the Website ↓:
icon from the game on the Creator Dashboard ↓:
Not sure how is it done, but maybe there’s still some kind of trick to get it?