I am having this weird shading/color issue all the vertexes are the same color and all of them have the VertexNormal attribute set to Vector3.zero(It doesn’t seem to change anything when I leave this attribute untouched)
Some things I need to note there are 4 meshes in the image and that weird gradient is the 0 x axis and the 0 y axis on the corresponding mesh
All vertexes are shown as a white cube
All vertexes have the same color and normals
Also it’s not overlap since the weird gradient stays even when I move the meshes away but it’s just harder to spot
My current guess is that the affected vertexes have a different normal or aren’t affected by some other attribute
Not sure if this is a bug but any help would be appriciated
I was already working on a project similar to blender but using very thin wedges as triangles. Any triangle can be decomposed into two right triangles, so I heavily used that, although the new update is SO GOOD and I’m totally rewriting my code now.
God am I excited to see further development of this as it goes. The ability to edit meshes will open up tons of new and performant ways of control and will overall open up just a hell of a lot more possibilities, and on top of that, to be able to use an “EditableImage” in the same way of editing a bitmap, is such a lifesaver, it means games that involve drawing like “Pls Donate” or “Fine Arts” could upgrade their picture sizes allowing for even more freedom for the users, without the performance issues we have with current strategies.
On top of that, I’ve been following some Renderers built in Roblox, and personally also dabbled with it, and one major drawback I’ve found is editing 256x256 instances (65536 instances) can be very difficult, and slow on both client and server, and even with methods like using Gradient Colors to get more pixels, doesn’t suffice, so the ability to directly interact with an Image API could open up a whole new world of possibilities for users, like making a custom renderer for Roblox. I really hope the Image API’s don’t get rate limits, at least on the client.
Much love to the team who are working on these features to make them a reality!
I can’t wait to see the new experiences along with updates to current experiences that leverage these new awesome features!
This is a pretty great feature. Can you also consider adding the ability to read the number of triangles in specialmeshes and meshparts as well, or better yet the ability to get lists of triangles and verticies for both of those classes? It could make optimizing builds easier and will highlight to new developers the importance of not using unnecessary geometry.
@FGmm_r2 this is great! I am a little confused about moderation though, specifically at runtime.
Obviously it’s needed, or anyone can do anything, like I just did (extracted data from a random image):
But how will you deal with situations where edits are made every frame?
I tried it, to see how fast it is, and it works really well. It’s sufficiently quick and smooth, and I assume it will be even better in the future. That opens up a world of exciting possibilities, I’m tempted to start creating a 2D game right away, and there are many other valid reasons for someone to edit a mesh or an image every frame without ever wanting to publish (water waves, UI effects, swinging trees, and so on).
Moderating these would be very resource intensive for both Roblox and developers (I assume the high data throughput would do harm), and it would give the moderation bot plenty of occasions to misfire, as it does, so unjust terminations would be very frequent. Not moderating would be… well… there’s no shortage of abuses and abusers as is, it would definitely be taken advantage of asap.
So do you guys have an idea how you’re gonna work this out, or is this simply not intended to be used in the way I described at all?
Do EditableMeshes not render in ViewportFrames? They’re rendering normally when the Meshpart is in the workspace, but when the Meshpart is placed in a ViewportFrame, it renders the base Meshpart without the edited EditableMesh visuals.
Basically you can read and write pixels to the image using some built in functions (look up the documentation)
If it’s of any help WritePixels takes in a table formatted as {R,G,B,A,R,G,B,A, etc…} where the numbers are raw (0-1 instead of 0-255) and each repeat is a new pixel
It’s actually quite similar to SDL in terms of drawing if you want a reference
Any details on how moderation will work? Because right now you could write a script to convert an image file (like a bmp file) to an editableimage which would bypass any moderation
Also is there a reason that WritePixels and ReadPixels use number arrays and would buffer support be considered? Uncompressed image data is already inefficient enough without adding tons of padding with a table
EditableMesh and EditableImage should be seperate topics in my opinion, however I am very excited for the new possibilities brought by EditableMesh, the only issue I have right now is texturing each face (using an rbxassetid). I was hoping for functionality similar to that of like minecraft with their texture atlas, and filtering options like NearestNeighbor algorithm for sharp low resolution textures (16x16, 32x32, 64x64, etc) instead of MIP which smudges and blurs everything that isn’t 1024x1024.
Oh, this is already possible!
To anyone curious (whoever wants to make image editors and such, you can use StudioService:PromptImportFile in conjunction with File:GetTemporaryId, and just simply use AssetService:CreateEditableImageAsync with it.
EDIT: CreateEditableImageAsync doesn’t work with it… major oversight on my part
They did mention in the post though that we will be getting more studio apis in the future so look out for that!!!
