The range of the edge crease values exported in Alembic is incompatible with other software #99855

Open
opened 2022-07-20 02:00:47 +02:00 by Giuseppe Bufalo · 20 comments

Blender exports edge crease values in the range [0, 1], while other software seems to expect it in the range [0, 10] similar to OpenSubDiv, making the exported alembic file incompatible with other software.

Original Report

System Information
Operating system: Windows 10
Graphics card: Nvidia GeForce RTX 2080

Blender Version
Broken: 3.2.1
Worked: 3.1

Short description of error

when exporting Alembic file the crease value doesn't get read properly by other softwares. (it works when importing back to Blender though) the creased edges get recognised but not their values (they all have the same value). (I tried this with Modo Maya and 3DsMax).

I think this was also a problem of the version 2.9 and when I reported the bug it was fixed after, the problem at that time was that the values didn't correspond to the values that other softwares use. They all use a values that correspond, like for example 0.3 in Modo is 3 in Maya or 3 in 3Ds Max but in Blender for some reason is 0.6. - it would be also nice that this problem is addressed and we can have the same type of creasing values so the files get exported properly.

But right now the problem is that the values don't even get recognised by other softwares. Please let me know if you need any help to fix this problem I can run some tests. I think it is very important that the edge creasing workflow is aligned with the one that other softwares use.

Blender exports edge crease values in the range [0, 1], while other software seems to expect it in the range [0, 10] similar to OpenSubDiv, making the exported alembic file incompatible with other software. ### Original Report **System Information** Operating system: Windows 10 Graphics card: Nvidia GeForce RTX 2080 **Blender Version** Broken: 3.2.1 Worked: 3.1 **Short description of error** when exporting Alembic file the crease value doesn't get read properly by other softwares. (it works when importing back to Blender though) the creased edges get recognised but not their values (they all have the same value). (I tried this with Modo Maya and 3DsMax). I think this was also a problem of the version 2.9 and when I reported the bug it was fixed after, the problem at that time was that the values didn't correspond to the values that other softwares use. They all use a values that correspond, like for example 0.3 in Modo is 3 in Maya or 3 in 3Ds Max but in Blender for some reason is 0.6. - it would be also nice that this problem is addressed and we can have the same type of creasing values so the files get exported properly. But right now the problem is that the values don't even get recognised by other softwares. Please let me know if you need any help to fix this problem I can run some tests. I think it is very important that the edge creasing workflow is aligned with the one that other softwares use.

Added subscriber: @giuseppebufalo

Added subscriber: @giuseppebufalo
Member

Added subscriber: @OmarEmaraDev

Added subscriber: @OmarEmaraDev
Member

Changed status from 'Needs Triage' to: 'Needs User Info'

Changed status from 'Needs Triage' to: 'Needs User Info'
Member

Just to double check, can you make sure that 1) Your object have a subdivision modifier. 2) You have Apply Subdivisions disable. 3) You have Use Subdivision Schema enabled. Otherwise, crease data might not be written.

If yes, can you attach a simple file that is correct and can be imported into other software? Just to compare it with Blender's export and see what might be wrong.

Just to double check, can you make sure that 1) Your object have a subdivision modifier. 2) You have Apply Subdivisions disable. 3) You have Use Subdivision Schema enabled. Otherwise, crease data might not be written. If yes, can you attach a simple file that is correct and can be imported into other software? Just to compare it with Blender's export and see what might be wrong.

yes I did the steps 1, 2 and 3. Here are the files attached.

I realised when I was in Maya that the problem is still the same of the one I reported long time ago.

So the values get imported correctly but Blender use other values that don't correspond to the one that other softwares use. Blender uses values from -1 to 1 which also doesn't make sense because creases are only positive values. While Maya and other softwares use 0 to 10.

The creases I used in my file are 0.6, 0.4, and 0.2 which correspond visually to 3.00, 2.00 and 1.00 in Maya. When I import the alembic file into Maya I actually get the Blender values correctly but the problem here is that the maximum value in blender is 1 so I can't really use the value 2, 3,4 etc.

So blender values 0-1 should correspond to 0-10 in Maya so for example 0.3 in blender correspond to 3.00 in Maya and so on..

Hope it make sense.

test_crease.zip

yes I did the steps 1, 2 and 3. Here are the files attached. I realised when I was in Maya that the problem is still the same of the one I reported long time ago. So the values get imported correctly but Blender use other values that don't correspond to the one that other softwares use. Blender uses values from -1 to 1 which also doesn't make sense because creases are only positive values. While Maya and other softwares use 0 to 10. The creases I used in my file are 0.6, 0.4, and 0.2 which correspond visually to 3.00, 2.00 and 1.00 in Maya. When I import the alembic file into Maya I actually get the Blender values correctly but the problem here is that the maximum value in blender is 1 so I can't really use the value 2, 3,4 etc. So blender values 0-1 should correspond to 0-10 in Maya so for example 0.3 in blender correspond to 3.00 in Maya and so on.. Hope it make sense. [test_crease.zip](https://archive.blender.org/developer/F13305267/test_crease.zip)
Member

The trouble is, different software have different ranges for the crease value. Maya have 0 to 7, Max have 0 to 1, OpenSubDiv have 0 to 10, Blender have 0 to 1.
Alembic is not an exchange format between different softwares, so it does not specify standard value ranges as far as I can tell. So I suspect there isn't much we can do here.
What do you think?

The trouble is, different software have different ranges for the crease value. Maya have 0 to 7, Max have 0 to 1, OpenSubDiv have 0 to 10, Blender have 0 to 1. Alembic is not an exchange format between different softwares, so it does not specify standard value ranges as far as I can tell. So I suspect there isn't much we can do here. What do you think?

I always used this workflow with different softwares, it usually always matches, even Modo, Houdini and cinema4D. usually the values go always from 0 to 1 or 0 to 10, it was actually working In the older versions of Blender but now it is broken. the problem was that the values were a bit off and I had to crease 0.6 to make it look like crease 3.00 in Maya. Check with Campbell Barton I think he solved the problem last time.

At the moment the values are exported correctly (0.6 is imported as a 0.6 in Maya) but 0.6 value in blender viewport look like a 3.00 value in Maya. On top of that the maximum value in blender is 1 so we are not able to export value 3 for Maya.

Let me know what you think. if you don't want to change how crease appear in the viewport and their corresponding values we should have a conversion before the file get exported as and Alembic file. I think this was the problem we addressed in the last bug.

I always used this workflow with different softwares, it usually always matches, even Modo, Houdini and cinema4D. usually the values go always from 0 to 1 or 0 to 10, it was actually working In the older versions of Blender but now it is broken. the problem was that the values were a bit off and I had to crease 0.6 to make it look like crease 3.00 in Maya. Check with Campbell Barton I think he solved the problem last time. At the moment the values are exported correctly (0.6 is imported as a 0.6 in Maya) but 0.6 value in blender viewport look like a 3.00 value in Maya. On top of that the maximum value in blender is 1 so we are not able to export value 3 for Maya. Let me know what you think. if you don't want to change how crease appear in the viewport and their corresponding values we should have a conversion before the file get exported as and Alembic file. I think this was the problem we addressed in the last bug.
Member

I guess the report in question is #70298 with the associated patch D5930. That patch seems to only concern itself with squaring the value, not adjusting the range to 0-10.
Did you test 3DMax by any chance? Since it expects values in the range 0 to 1. If we change the range to 0 to 10, what would happen to Max in this case?

I guess the report in question is #70298 with the associated patch [D5930](https://archive.blender.org/developer/D5930). That patch seems to only concern itself with squaring the value, not adjusting the range to 0-10. Did you test 3DMax by any chance? Since it expects values in the range 0 to 1. If we change the range to 0 to 10, what would happen to Max in this case?

yep I tested it in Modo, Maya and Max. I haven't tested it in Houdini but I can give it a go :)

yep I tested it in Modo, Maya and Max. I haven't tested it in Houdini but I can give it a go :)
Member

Changed status from 'Needs User Info' to: 'Needs Developer To Reproduce'

Changed status from 'Needs User Info' to: 'Needs Developer To Reproduce'
Member

Okay, so I guess Max corrects the crease values upon import. In that case, I think it would be best if we get the opinion of the module.

Okay, so I guess Max corrects the crease values upon import. In that case, I think it would be best if we get the opinion of the module.
Omar Emara changed title from Edge crease values don't even get recognised by other softwares when exporting with Alembic to The range of the edge crease values exported in Alembic is incompatible with other software 2022-07-21 11:11:56 +02:00

Added subscriber: @SteffenD

Added subscriber: @SteffenD

Very interesting and important topic here.

I can successfully round-trip Alembic files with creases from Blender to Houdini and vice versa. I just have to make sure I use subdivision schema in both of them during export.
The output of abcinfo looks very similar.

Blender:

/home/steffen/Downloads/Alembic_Creases/Creases_Blender_SubD.abc, version: 10803 (1 timings)
   TimeSample[0]      1 samples:  t0=0 (frame 0.0 @ 24fps)

Objects:
/Cube (Xform)
    Constant-Identity
/Cube/Cube (SubD)
    box fpreal64 .selfBounds[6]
    int32 .face-counts
    int32 .face-indices
    point float32 P[3]
    FaceVarying float32 uv[2]
    int32 .creaseLengths
    int32 .creaseIndices
    float32 .creaseSharpness

2 Objects displayed

Houdini:

/home/steffen/Downloads/Alembic_Creases/Creases_Houdini_SubD.abc, version: 10803 (2 timings)
   TimeSample[0]      1 samples:  t0=0 (frame 0.0 @ 24fps)
   TimeSample[1]      1 samples:  t0=0.04 (frame 1.0 @ 24fps)

Objects:
/geo1 (Xform)
    Constant-Identity
/geo1/convert1 (SubD)
    box fpreal64 .selfBounds[6]
    int32 .face-counts
    int32 .face-indices
    point float32 P[3]
    FaceVarying float32 uv[2]
    int32 .creaseLengths
    int32 .creaseIndices
    float32 .creaseSharpness
    Uniform string path

2 Objects displayed

Only real problem is the range of the creases as mentioned above. Blender uses a 0-1 range while Houdini a 0-10 range.

Very interesting and important topic here. I can successfully round-trip Alembic files with creases from Blender to Houdini and vice versa. I just have to make sure I use subdivision schema in both of them during export. The output of abcinfo looks very similar. Blender: ``` /home/steffen/Downloads/Alembic_Creases/Creases_Blender_SubD.abc, version: 10803 (1 timings) TimeSample[0] 1 samples: t0=0 (frame 0.0 @ 24fps) Objects: /Cube (Xform) Constant-Identity /Cube/Cube (SubD) box fpreal64 .selfBounds[6] int32 .face-counts int32 .face-indices point float32 P[3] FaceVarying float32 uv[2] int32 .creaseLengths int32 .creaseIndices float32 .creaseSharpness 2 Objects displayed ``` Houdini: ``` /home/steffen/Downloads/Alembic_Creases/Creases_Houdini_SubD.abc, version: 10803 (2 timings) TimeSample[0] 1 samples: t0=0 (frame 0.0 @ 24fps) TimeSample[1] 1 samples: t0=0.04 (frame 1.0 @ 24fps) Objects: /geo1 (Xform) Constant-Identity /geo1/convert1 (SubD) box fpreal64 .selfBounds[6] int32 .face-counts int32 .face-indices point float32 P[3] FaceVarying float32 uv[2] int32 .creaseLengths int32 .creaseIndices float32 .creaseSharpness Uniform string path 2 Objects displayed ``` Only real problem is the range of the creases as mentioned above. Blender uses a 0-1 range while Houdini a 0-10 range.

Hi Steffen - Could you take a screenshot of the meshes with subD level of 4 in both Blender and Houdini and see if they look the same ?

I noticed that the crease values are exported correctly even between Blender and the other softwares but they don't look the same in the viewport.

Hi Steffen - Could you take a screenshot of the meshes with subD level of 4 in both Blender and Houdini and see if they look the same ? I noticed that the crease values are exported correctly even between Blender and the other softwares but they don't look the same in the viewport.

Sure... the current geometry is super simple (a cube with an intrusion) but it should work to show the difference.

Blender:
image.png

Houdini (the "creaseweight" attribute is read correctly as "1.0"):
image.png

Houdini with the creaseweight on the creased edges set to 10.0 instead of 1.0:
image.png

(Houdini has some automatic hard edge shading in the viewport. The actual geometry is the same as in Blender)

Sure... the current geometry is super simple (a cube with an intrusion) but it should work to show the difference. Blender: ![image.png](https://archive.blender.org/developer/F13307855/image.png) Houdini (the "creaseweight" attribute is read correctly as "1.0"): ![image.png](https://archive.blender.org/developer/F13307909/image.png) Houdini with the creaseweight on the creased edges set to 10.0 instead of 1.0: ![image.png](https://archive.blender.org/developer/F13307924/image.png) (Houdini has some automatic hard edge shading in the viewport. The actual geometry is the same as in Blender)

I ve been using this workflow in movies production for 10 years, when we model we rarely use the maximum value for creasing. In Maya Modo, Houdini and Max we usually set it to 3 but when I moved to Blender for some reason (visually) that value translate in 0.6 not in 0.3 ( something that you can divided or multiply by 10)

in fact if you notice the crease value 1 in Houdini doesn't look that hard edge while blender that's the maximum.

anyway as you can see there is something that is not working here. If we want to keep the same system of values in Blender it should be automatically divided by 2 and multiply by 10 before exporting in alembic

For example 0.6 value will be 0.6/2 = 0.3*10 = 3 and in this way visually ( in the viewport) they will match

I ve been using this workflow in movies production for 10 years, when we model we rarely use the maximum value for creasing. In Maya Modo, Houdini and Max we usually set it to 3 but when I moved to Blender for some reason (visually) that value translate in 0.6 not in 0.3 ( something that you can divided or multiply by 10) in fact if you notice the crease value 1 in Houdini doesn't look that hard edge while blender that's the maximum. anyway as you can see there is something that is not working here. If we want to keep the same system of values in Blender it should be automatically divided by 2 and multiply by 10 before exporting in alembic For example 0.6 value will be 0.6/2 = 0.3*10 = 3 and in this way visually ( in the viewport) they will match

do you guys have any update on this task?

do you guys have any update on this task?
Bastien Montagne added this to the Pipeline, Assets & IO project 2023-02-09 15:39:30 +01:00
Philipp Oeser removed the
Interest
Pipeline, Assets & IO
label 2023-02-10 08:54:02 +01:00

Hi I still have problems exporting creases to other softwares even using the version 3.6. do you think it's possible to solve this issue before the version 4.0 comes out. I would suggest to change the crease system and instead having it going from -1 to +1 ( which I think the negative crease numbers don't make sense) it will go from 0 to 10 so making it compatible with the one of other softwares.

otherwise the solution would be fixing the conversion in the alembic export.

Thanks !

Hi I still have problems exporting creases to other softwares even using the version 3.6. do you think it's possible to solve this issue before the version 4.0 comes out. I would suggest to change the crease system and instead having it going from -1 to +1 ( which I think the negative crease numbers don't make sense) it will go from 0 to 10 so making it compatible with the one of other softwares. otherwise the solution would be fixing the conversion in the alembic export. Thanks !

I was missing for this ability today and got surprised to see it actually writes creases to the exported file under these combination of settings. Even vertex creases was done successfully!

Note: importing it back to Blender I noticed crazy high values, like 255 for creases originally exported as 1.0.

Wish: ability export Bevel Weights too!!

I'm using this workflow to bake deforming simulations of simple geometries (quick to simulate and file is small), importing the .abc back (trough the Mesh Sequence Cache modifier) and reconstructing the parametric modifiers that generates geometry (like subdivision with creases, solidfy, bevels with manual weigths, etc). Then I can make the simulations looping seamlessly by offsetting the frame on a second instance of the .abc and make use of geometry nodes to lerp the indices of the vertices in a certain way that these animations feels constantly simulated, but seamlessly.

And having the ability to preserve creases (and maybe bevel weights) are time savers for these cases.

I was missing for this ability today and got surprised to see it actually writes creases to the exported file under these combination of settings. Even vertex creases was done successfully! Note: importing it back to Blender I noticed crazy high values, like 255 for creases originally exported as 1.0. Wish: ability export Bevel Weights too!! I'm using this workflow to bake deforming simulations of simple geometries (quick to simulate and file is small), importing the .abc back (trough the Mesh Sequence Cache modifier) and reconstructing the parametric modifiers that generates geometry (like subdivision with creases, solidfy, bevels with manual weigths, etc). Then I can make the simulations looping seamlessly by offsetting the frame on a second instance of the .abc and make use of geometry nodes to lerp the indices of the vertices in a certain way that these animations feels constantly simulated, but seamlessly. And having the ability to preserve creases (and maybe bevel weights) are time savers for these cases.

... going from -1 to +1 ( which I think the negative crease numbers don't make sense)

Actually I think Blender treats edge creasing from 0.0 to 1.0. The reason for the negative values are displayed when you edit them trough the shortcut Shift+E, in the viewport, makes sense when you are editing multiple pre-existing creases with different values. So then you can increase or decrease their values by the same amount relatively.

For example: you are adding -1 to a crease with a value of 1.0 to make it 0.0.
Other case: two creases: 0.6 and 0.2 got edited simultaneously by -0.1. Result: 0.5 and 0.1.

>... going from -1 to +1 ( which I think the negative crease numbers don't make sense) Actually I think Blender treats edge creasing from 0.0 to 1.0. The reason for the negative values are displayed when you edit them trough the shortcut Shift+E, in the viewport, makes sense when you are editing multiple pre-existing creases with different values. So then you can increase or decrease their values by the same amount relatively. For example: you are adding -1 to a crease with a value of 1.0 to make it 0.0. Other case: two creases: 0.6 and 0.2 got edited simultaneously by -0.1. Result: 0.5 and 0.1.
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#99855
No description provided.