why does mine just return Expected Object, got nil. Note that the Object must not inherit from Instance. it isnt even empty i think i draw pixels and everything
I dont care about these updates, my game has the whole world and the terrain requires editable meshes, PLEASE can i have some sort of ETA like i need it to release
Iām even surprised there isnāt any support for SpecialMeshes. Hope that we should see support for it soon!
Thatās part of Robloxās processing, if you have any flat or custom normals anywhere that can screw up the indices, for instance. You should try to figure out what modifications are being made to potentially compensate for it.
1 Like
The sorts of things you can do with this capability in Roblox are pretty amazing.
3 Likes
This is going to make Content and Object variable names unusable going forward? If so thats a big thing that needs to be changed. Put it under game.Content or something, dont makes those variable names unusable. Especially in game development Id imagine they are very commonly used, I do anyway.
Alternatively make it so if the variable gets defined manually, dont highlight the variable as blue anymore since it wont be accessing the global Content object
amazing work to make the API much more cleaner, still sucks that I have to make changes to my code that previously worked
What do you mean? All iām doing right now is creating a cube with a subdivide and triangulate modifier applied. I use that as a basemesh then drag a few vertices in random directions and import both of those meshes to roblox. I donāt think theres anything going on with the normals etc.
Will there be a DrawText function in the future for writing text to the canvas? I plan on using this for a ladder logic editor to avoid having many instances of GUI objects to reduce memory footprint, and for ease of programming.
Was this a typo? Thereās no Object data type, so I assume this was meant to be Content.fromObject()
1 Like
Normals are still kind of messed up with this build. As an example, hereās a smooth plastic flat surface with all of the vertices at the same Y height.
Even if I go and specify that every face should be Vector3.up normal, I get this behavior. So it seems like the normals might be getting set, but the light computations on them might be fishy.
I know this post clarifies that permissions are starting out restrictive to test things out but Iām honestly confused why thereāre even restrictions being put in place at all
If weāre allowed to load meshes and decals not owned by us, why is it a problem if we can edit them too? This holds back a ton of the potential that the new editable apis introduced. I really hope roblox just eliminates editable api permissions as a whole because itās already screwed it up for me (I canāt even detect the skybox pixel that the cameraās looking at anymore because I donāt own the default skybox images). I canāt see how itād be āmisusedā besides potential copyright laws? But if thatās the case I see no point in giving us such an awesome library in the first place if youāre just gonna strip 80% of its usecases. We could already make custom images (even if it wasnāt the most performant) before this api. So the current permissions turn this api into a less laggy alternative to something we could already do.
PLEASE ROBLOX do not mess this api up
2 Likes
ā¦ what? I canāt find the APIs to do this at allā¦ who decided it was a good idea to totally scrap the existing APIs randomly?? This is unacceptable because the post is not clear at all and now I canāt do my job.
Anything I can do in the meantime? This is pretty infuriating because now a lot of my UI doesnāt look like it should and thereās no talk on the new APIs or how to otherwise fix itā¦
3 Likes
I donāt believe thatāll be changed; you can already do this with other globals.
local pcall = 7
print(pcall) --> 7
Make sure the mesh part is the same size and position as the editable mesh, it fixed the issue for me
This probably belongs in #help-and-feedback:scripting-support if you havenāt already posted it there, also it would probably be useful if we could see your code 
Hm, that should be fixed with this release. Is there a way you could send that mesh?
This is an unfortunate side effect of the import process. Long-term weād like to fix that, but there are several steps before that will work end-to-end, unfortunately.
One of the main things that happens during FBX import is duplicating vertices that have different attributes. For example, if a vertex is a sharp corner, or exists on the boundary of different bone set regions of influence, the vertex will be duplicated.
However, in many cases that splitting can be reversed by calling EditableMesh:MergeVertices with a tolerance of 0.0. This will seal up your mesh, but unfortunately the indices wonāt be the same after merging as they were in the input FBX.
There are a few different ways to handle this. One is to import each blendshape as a separate mesh, which should each go through the same vertex splitting, and then blend between those imported meshes. Another way is to do a lookup based on things that donāt change during import. For example, to get back the vertex mapping you could go through the triangle indices, or UV coordinates. I realize that this is a pain, sorry that I donāt have a better answer at the moment.
Iāll see if I can find some time to create a blendshape example.
Blendshapes can be expensive, in compute time and memory use. Sometimes packages convert them to use skinning for fast rendering and modification, but there are no current plans to expose that in-engine.
1 Like
Could you share more details about this, even if itās off platform?
Iām very confused about this as well considering Content.fromObject requires an Instance but it seems the whole point of this change was to make EditableImages not inherit from Instance?
With none of the documentation updated and almost all existing scripts using unavailable API it feels like Iām wandering in the dark looking for a light switch here, lol.