bpy_lambda
bpy_lambda copied to clipboard
bcongdon
Missing remesh operation
I am aware that some things have been stripped out such as FFMPEG. However unlike FFMPEG, when calling bpy.ops.object.modifier_add(type='REMESH') no error is returned, meaning it took a while to figure out why the below script wasn't working:
bpy.ops.object.modifier_add(type='REMESH')
bpy.context.object.modifiers["Remesh"].octree_depth = 6
bpy.context.object.modifiers["Remesh"].scale = 0.9
bpy.context.object.modifiers["Remesh"].threshold = 1
bpy.context.object.modifiers["Remesh"].sharpness = 0
bpy.context.object.modifiers["Remesh"].mode = 'SMOOTH'
bpy.ops.object.modifier_apply(apply_as='DATA', modifier="Remesh")
Is there a specific reason for omitting Remesh or was it just caught up in the cull? Is there a better way for dealing with missing operations in case other people get caught out?
Many thanks, H
I wish I had better information, but I really don't know why that operation would silently fail... 😞
Possibly, whatever "remesh" is doing relies on some library that isn't loaded.
Dockerfile contains -DWITH_MOD_REMESH=OFF \ and remesh function has a check in the code that looks at the build flags, failing silently if remesh wasn't built in.
Actually it would be really convenient if remesh would be included into the default build as it's one of the fundamental bpy operations. Do you think you could add it to the default build? Or is it a bad idea for some reason?
Ah, good find @QuteBits. 👍
It'd be great if we could enable that flag. I don't think I'll have the bandwidth to do it in the coming week(s), but if you want to experiment with it and make a PR, that'd be awesome.
Otherwise, I'll add it to my backlog of things to try
Hi @bcongdon I'm still really keen to have this as is @QuteBits it seems. Do you think you'd be able to find the time over the next few weeks at all? I'd also be happy to remunerate you if that would help haha
I can take another look. Could you send me what you'd expect the output of bpy.ops.object.modifier_apply to be? (i.e. to make sure that remesh is working, and not silently failing)
Great thank you!
If you change 6 to 1 on
bpy.context.object.modifiers["Remesh"].octree_depth = 6
Then the output mesh will have a significantly lower number of vertices than the input. If it fails then the mesh will be the same. You could run
print(len(bpy.context.object.data.vertices))
before and after to see if it's changed
output should be:
>>>482
>>>8
if it fails I imagine:
>>>482
>>>482
bpy.ops.object.select_all(action='SELECT')
bpy.ops.object.delete()
bpy.ops.mesh.primitive_uv_sphere_add()
print(len(bpy.context.object.data.vertices))
bpy.ops.object.modifier_add(type='REMESH')
bpy.context.object.modifiers["Remesh"].octree_depth = 1
bpy.context.object.modifiers["Remesh"].scale = 0.9
bpy.context.object.modifiers["Remesh"].threshold = 1
bpy.context.object.modifiers["Remesh"].sharpness = 0
bpy.context.object.modifiers["Remesh"].mode = 'SMOOTH'
bpy.ops.object.modifier_apply(apply_as='DATA', modifier="Remesh")
print(len(bpy.context.object.data.vertices))```
Thanks! That's very helpful. I just pushed a commit to master that flips on the remesh operation, and it seems to pass the condition you describe.
Can you try it out before I push out a new release?
hello - just tried to build a new release off master. It seemed to compile and all tests seemed to pass. When I try to use it, it instantly fails on something that seems one of its basic operations that should be in the build:
I assume that something simply went wrong when building it. Could you please make a new release off of master in the same way you did previous releases so that I could compare both?
hello again - could you please build a new release from master? I tried to build the whole thing against a fresh EC2 instance again and my build doesn't work despite compiling (and, well, just from taking a look at the amount of things it depends on, it seems to be a lot of work to debug what went wrong during the compilation time).
ahh, so great - as I'm recompiling the whole thing manually on an EC2 instance for the last 6 hours, going through each line from the docker image 1-by-1 :) let me have a quick look at the release you just pushed.
could it be that it also failed silently somewhere while you were compiling it? For me, running python test.py after the build was finished, failed too - does it work/fail on your side?
What happens if you run test.sh? I'm not getting any failures on a clean build.
When you tried to recreate the build on EC2, were you using amazonlinux? The docker build uses amazonlinux version 2017.03 -- I don't know what the compatability is like with newer versions, but I'm pretty confident that if you're using a linux distro that isn't amazonlinux, you'll probably run into issues running the resulting build artifacts on lambda.
Thank you for a quick response.
I did it on 2018.03 one (as 2017.03 was not on their OS list anymore when creating new EC2 instances) and when building against it, lots of commands from Dockerfile didn't run unless I added sudo in front of them. Also, this:
I will try to find 2017.03 and compile bpy against it. Could you please, if you find some free time, try to build a release against 2018.03 too?
hmm, it still shows the same error as before:
I will take a look if it's not importing it correctly or something. I'm still using python 3.6 on my functions (other runtimes: python 3.7 results in segmentation fault, python 3.8 in some libGL error)
Hmm... Well, I'm sorry it's still not working 😞 I'll take a look and see if I can reproduce your error on different versions of Python on Monday.
I've also been meaning to update this package to Blender 2.8 at some point, maybe that would fix the issue 🤷♂