No, it’s no longer possible. This is similar to the project I was working on. Memory limits get hit now when you even try to approach doing something like this. You could do it with larger meshes and more vertices per mesh, but then you have more difficulty coloring/texturing anything properly.
While this works, editables are still better =C
Do Decal/Texture instances work on EditableMeshes? One of the major performance hits of my game is simply updating hundreds of Texture offsets every frame as I want to be able to scroll a single texture across a bunch of parts at once–I aimed to fix this by using an EditableMesh to generate the geometry, but when doing this the Texture didn’t appear on it whatsoever.
Is this intentional behaviour?
Second question; is there a way to disable frustrum and occlusion culling on EditableMeshes? I want to be able to edit the meshes in real time without the worries of having to create ask AssetService to make a new mesh part with updated bounds. (This is solvable by making the EditableMesh massive, but runs into a problem when I aim to place stuff outside of the max 2048x2048x2048 bound.)
Nope not yet and question 2 idk
This is awesome looking!
HOW does it decode images so fast if this is all done in plain Luau?
That’s the most impressive part about it for me perhaps.
Also what’s the music? I kinda like it.
Thank you!!! I still have optimizations to make (as you can see with the gif that took super long) but Luau seems to handle it extremely well! I’d say the part that takes the longest (as of now) is turning all of those color indexes into buffers that I can use to write on the screen. Hopefully I can find a good method to speed that up!!
music is “difficult to see” by dreamstation btw :D’
Im afraid its not possible, i tried that too and got a maximum of 8 too. A workaround i found is to basically create those 8 editable meshes from the beginning, Then you are just limited to use those meshes until it reaches the max polygon count
Yes this will be possible in the future.
hey so i tried verifying myself for the first time and its so bad
a selfie AND government issued id, just so I can use the already nerfed editable api???
I’m not gonna give roblox all that, theres no way
due to this experience I am now in agreement with you lmao
I’m aware, they have talked about it, however I’m not sure how performant that will be. Maybe the process of going from Editable > Static > Editable wont be that taxing as I assume it will be. This is especially important when you want to have a world that can be changed by the user at their will without much delay.
I don’t like the fact that we are being told “yeah it will be possible in the future”. As if it wasn’t very possible before they imposed this “dynamic” memory budgeting system. Not to mention they released this with such a vital feature missing. It really should have just been delayed.
It’s an amazing feature with a lot of work put into it, but these recent decisions are very questionable and disappointing. I’m honestly surprised nobody is talking about just how criminally limiting this feature is now compared to before. I’m honestly considering making a post about it.
Is this the same issue as the one in the below video? It looks like the same thing but with occlusion culling, but this is in a published experience, outside of studio.
Is there a way to create a fixed size editable mesh without using a URI?
If i use FixedSize = true when using AssetService:CreateEditableMesh(), would it just have a fixed size of 0 vertices or how would that work if there is no way to describe how many vertices I want the editable mesh to have
Or is this not possible yet
Just curious, for whenever if it even will: when will this not require id’s, also would it be possible to somehow store an editable image in a datastore so we could turn captures into like a photo album?
In the future, we are planning on supporting sharing captures to the platform and allowing you to reload them in game to display for use cases like this. We wouldn’t want you to store this in DataStores because it would be unmoderated and having the captures shared to the platform would allow this to be supported in a safer way.
In the future, consider a better security system or whatever you did, they damaged the API and the beautiful uses that could be given to this. A new disappointment from the Roblox team. I looked forward to each update of this API, but they come out with this and make you lose jobs, they limit your use if you are not verified and you cannot use other people’s assets. Anyway, Nerfing the Roblox engine.
I think there are valid use cases for wanting to save an EditableImage from a capture into a DataStore, such as generating thumbnails for user creations. Being forced to interact with an out-of-place CoreGui modal to upload a random capture whenever you want to save a creation in-game would be pretty awkward UX.
Cool! But would this require an additional prompt / one different from the normal save to device one, since if theres one that works similarly to normal one as a sperate method it could be nice so it saves to the device and uploads to roblox? but again this feature isnt even out yet so i doubt you’ll know
During the early beta of the EditableMesh & EditableImage API I made a camera system which utilises the CaptureService feature, uses CreateEditableImageAsync() from the capture and crops it to the capture region (in this case a phone) however I’m now getting the error “CaptureService: Unexpected error while invoking callback: AssetService:CreateEditableImageAsync cannot currently create editable image from temporary texture id.” this system is paramount for a revamp of my game as it was one of the key features to set us aside from other games. Is there any other methods to achieve the same results?