4
$\begingroup$

I need to programmatically export the UVs of a lot of .objs. I am using the bpy.ops.uv.export_layout() fn.

Since this step is part of a more complex pipeline, I am launching Python from the command line passing the script as a -P parameter.

I run into a pretty important issue: if I launch Blender manually and run the script, or from a terminal as explained above, I obtain two different images. I am using the same parameters while exporting.

I run some tests on Suzanne. Here are the images:

The difference is especially clear if you check their alpha channels:

from Blender

from terminal

You will see that in the command line one the wire is visible in the alpha, and this breaks the rest of the workflow that I need to perform on the image.

Any idea on what's going on? Thank you!

Ps: here's a minimal example script to replicate the issue.

Set the export path. On Macos, launch with "blender_path -P script_path". Comment last line when launching from Blender!

import bpy

output_path = "YOUR_EXPORT_PATH_HERE"

if __name__ == "__main__":

    for o in bpy.data.objects:
        bpy.data.objects.remove(o, do_unlink=True)

    bpy.ops.mesh.primitive_monkey_add(enter_editmode=True, location=(0, 0, 0))

    bpy.ops.uv.export_layout(filepath=str(output_path), export_all=False, modified=False, mode='PNG',
                             size=(1024, 1024), opacity=1)

    print ("Done")

    bpy.ops.wm.quit_blender()
$\endgroup$
5
  • $\begingroup$ Not sure re main issue. If you run from command line in background mode blender -b the quit blender operator will not be required then either. IMO No need to enter edit mode. Also think could ditch the if statement too. $\endgroup$
    – batFINGER
    Feb 3 '20 at 11:03
  • $\begingroup$ Hi @batFINGER, thanks for the reply. I cannot use blender -b as it will complain when I export the Uvs ("GPU functions for drawing are not available in background mode"). Launching without edit_mode doesn't solve the issue. if statement: just an old python habit. Ty $\endgroup$ Feb 3 '20 at 11:31
  • $\begingroup$ Thanks re GPU, should have tested. As mentioned no suggestion was put up to "solve the issue" Less overhead in object mode. $\endgroup$
    – batFINGER
    Feb 3 '20 at 11:56
  • $\begingroup$ appreciate! thanks :) $\endgroup$ Feb 3 '20 at 12:40
  • $\begingroup$ It's me again... I am running background mode on a VM without GPU. It looks as if export_layout now requires the GPU (Blender 2.82 (sub 7)). I think I may have to drop back to 2.79. Has this issue been raised as a bug? "export_layout" "background" only returns one result in Google. And (right now) it isn't this page! $\endgroup$
    – Tim Owens
    Aug 7 '20 at 0:28
0
$\begingroup$

I did exactly the same thing you did, exported the UVs from the Suzanne.

Though i did export it twice with once default opacity 0.25 and once with it set to 1 as you use in the script.

The code is taken from the Scripting Tab bottom left window. Here we can see as in the picture below, the default 0.25 function framed red(default value is optional and does not show up in the function used), the value of 1 (is not default, so the value shows up as parameter) in green:

enter image description here

bpy.ops.uv.export_layout(filepath="..\\Suzanne.png", size=(1024, 1024))

When compared to the one you use, there is a significant difference. Opacity by default when using the menu is 0.25, while in your script you use "opacity=1".

default opacity used when exporting UVs is 0.25

Using:

bpy.ops.uv.export_layout(filepath="..\\Suzanne1.png", size=(1024, 1024), opacity=0.25)

i got the exact same image as i got from when i used the menu function without changing the opacity.

So i would suggest you try your script with the adjustment of the opacity to "0.25". That should do the trick.

$\endgroup$
5
  • $\begingroup$ Hello Xylvier, sadly the problem persists - but at 0.25 the image is more subtle, so the problem is less visible. in the test at https://imgur.com/a/mV5EMkP , you can see on the left the alpha of the image obtain from cmd, and on the right the one of the image obtain from within Blender. Both images had opacity = 0.25. When called from cmd, the alpha channel shows again some weird aliasing on the wire - thing that does not happen when running the script from blender or using the GUI tool. $\endgroup$ Feb 3 '20 at 16:47
  • $\begingroup$ I guess that they may use the final image (filtered) as it's shown in the Blender viewer when using it from inside the program, should have an AA running on it. Whilst using cmd it only gives you the raw data before it would be filtered when shown in the viewer. Only way to be sure is either a dev answering or searching through the source code. $\endgroup$
    – Xylvier
    Feb 3 '20 at 17:24
  • $\begingroup$ Just went through some code and found here Export_Layout the "python code" for the function i first thought would be, but could not find in the source of Blender. Maybe you can take some from there to build your script. But as there is a separation for already UVs in memory or else... it may still be related on how Blender prepares the UV (before) displayed by it's internal functions. $\endgroup$
    – Xylvier
    Feb 3 '20 at 17:56
  • $\begingroup$ Hi, thanks for the insights. I will take a look at the code. I think there is something nuanced going on here, more than a missing AA filtering. It seems that in the blender export the wires have no alpha at all, while in the cmd one they have the alpha set to transparent, and they look "superimposed" on the islands. I'm wondering if I should open a ticket to track the issue. Thanks! $\endgroup$ Feb 4 '20 at 8:20
  • 1
    $\begingroup$ You may have a chance with that, i believe that the functionality/result should not be different be it run from inside Blender or console, yes. $\endgroup$
    – Xylvier
    Feb 4 '20 at 16:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.