[Client Beta] In-experience Mesh & Image APIs now available in published experiences

i think you are running this on a plane engine

2 Likes

OMG in roblox 3d modeling ? this is FIRE !

1 Like

Imagine in the future we can control this API through Nodes. Like in unreal engine. We can make our own forcefield effect without being much knowledgeable in programming, promoting artists to create much tremendous effects or visuals without the help of a programmer. Having the benefit of reducing time for the programmer and more control for artists is huge.

that’s the tips section, not rules. ofc there are risks with this approach, with the responsibility on u

Seconded. Will rbxtemp:// images from CaptureService be allowed again as it was earlier in the beta, or should we anticipate its permanently disallowed?

4 Likes

Preventing under 18 users from using this powerful of an API seems counterintuitive. If a child can play a game with the image API, it doesn’t have any reason to be restricted to ID verification.

7 Likes

How is this is supposed to improve safety? Invading the privacy of the developer is not going to prevent the players from abusing the game’s features.

Besides, there are literally off-the-shelf libraries available right now that can be used to enable freeform image creation (and probably an equivalent for models) without the use of these APIs - restricting developers from using your first-party features is only going to drive them to third-party alternatives that you don’t have as much moderation insight into.

11 Likes

We were thinking about the best API to support drawing more complex shapes and were testing out DrawTriangle as an option for this. However, there are some issues with how we support drawing multiple triangles back to back without seams and the implicit API contract there. We are considering if instead of adding DrawTriangle we should add a DrawPolygon API.

4 Likes

In the long term, we want to allow certain types of captures in EditableImage. One issue is that we want to make sure the capture doesn’t contain sensitive information, such as the user’s Robux balance.

3 Likes

This is great news! My game heavily relies on EditableMeshes and it’s been tricky making live servers work (this is my fault I used them while a beta), so it’s very appreciated how quickly this kind of feature was pushed out. Huge thanks to the team!

I’m not 100% sure what editable images or meshes could be used for but could you use them for making custom liveries on vehicles? Like let players paint drawings on cars, planes, trains and whatever?

Regarding the trust and safety changes that go along with this- I think they need more clear wording.
There needs to be a line drawn somewhere between when drawing/custom content is an intended game feature, and games where it is a side effect of other features.

Freeform building games would now all need to be rated 13+ based on this, but what about tycoon games with grid-based placement, you could theoretically write out text/makes shapes using this.

Or strategy games with similar grid based building placement (or freeform placement)
https://i.gyazo.com/96bc30d3bcf5e0399e00057494142d5a.mp4

A classic game like epic mining 2 would also fall foul- what’s to stop a user digging out blocks in the shapes of text etc.
What about a driving game where vehicles have tire tracks? People could spell things out with those if they really wanted to.

The line needs to be more explicit in my opinion.

Regardless of all that, this is an awesome update, I’m already in the process of switching my minimap system over to using editable images.

9 Likes

I’m interested in when the other surface appearance properties will be settable via editable image. It would be very useful to set the normal maps etc

Edit: it looks possible but the documentation on how to do it is nonexistent.

Hi, this update seemingly took away the ability to use temporary texture ids with editable images.

I had plans to use editable images in tandem with the capture service to create a plugin that allowed users to take screenshots of their assets in studio (i.e. generating thumbnails for a backpack UI).

Up until today’s release that has been possible, but now when I try to run my existing code I get the following message:
AssetService:CreateEditableImageAsync cannot currently create editable image from temporary texture id.

I’m wondering if this is long-term intended and if so, why this change was made?

Edit: I now see reading up a few posts this has been partially answered, but the context it was answered in was related to usage in-client as opposed to in-studio. Are there also concerns about capturing the viewport in studio and the capture containing sensitive information?

9 Likes

Just to be clear, is this a rule that you can’t load assets from external sources, or is it just a suggestion? If we know that we have the right to use the asset and that it follows guidelines, then is it okay to do this? What if you’re loading assets from an unknown (user-defined) source? Would this fall into the 13+ category?

I have the use case of rendering SVG vector files at runtime using the Editable* classes. These files need to be loaded from an external source (likely embedded into the place during Rojo build). I assume that this use case is okay from a policy perspective? I’m also generally curious about more extreme cases as mentioned above.

3 Likes

Gotcha, sounds splendid for retro style 3D rendering :eyes:

And there goes Roblox’s chances of ever competing with the industry standard Engines such as Unreal and Unity. Great job guys! I could literally use other modules that allow me to draw with replication in real-time without any limitations, but unfortunately, this requires ID verification to be usable. Way to shoot yourselves in the foot. All of these engine updates and code implementations are just for a small portion of developers to be able to use these APIs. Great!

I am definitely going to give my very private information just to be able to use an API that has already existed in multiple other industry standard Engines for many years. Uh-huh.

7 Likes

We intend to make it possible to put some captures into EditableImage in the long term, as long as they meet requirements like not including particular UI. The full solution here is to be determined, and I can’t make any promises on the timeline.

In the near term, I think we should be able to allow this in Studio Edit mode only.

Also, your use case sounds pretty cool! We do want to support publishing EditableImages from plugins in studio so be on the lookout for future APIs related to that.

3 Likes

Sounds awesome! Studio edit mode would be sufficient for my use case.

I am eager for the publishing aspect as I’ve seen that hinted at a few times and I do intend to have that in the final product of the plugin.

16 Likes

Good feature. Except it’s pretty much useless for anyone actually looking to make a more widely available experience. And its even entirely inaccessible for anyone who isn’t willing to give out their ID to corporate overlords. I’m really not sure how we are really supposed to use Editable images/meshes when they have a dozen restrictions tied to them. It’s insane how now roblox is locking away engine features just because they pose a risk to the babies of parents who could not even bother to look after them for more than 5 seconds.
What’s next? GPU Shaders getting locked behind no replication, super limited API’s, ID Verification, 13+ Age requirements all in the name of “protecting” babies? Why not just add these restrictions on absolutely everything on the platform because ultimately EVERYTHING can be used to make spooky content. It’s beyond insane man.

This is only a slippery slope that will only get worse with time. All for the sake of “security”, “safety”, “moderation” and “civility”.

12 Likes