C4D crashes on alembic import because of UVs [wordaround found]


#1

So I made good progress on my big project today - a nice animated clothing for my main char, made in Marvelous Designer.

Problem:
The exported alembic file is around 2.5 Gbyte for 240 frames of animated clothing.
When opening or merging the file in C4D, both S22 and R23 crash instantly.

What I tried:

  • FBX (does not show animation at all)

  • OBJ sequence (canceled that one, as each frame was almost 200 Mbyte)

  • Lower the simulation settings in MD signifcantly, but that resultet only in a 50 Mbyte lowering of the alembic

  • I looked around for alternative ways to get the animation data into c4d (pc2, maya cache), but there seem to be no tools for the newer C4D-Versions around

Since I plan to simulate a lot of sequences in MD, I’d much prefer to have the versatility of the alembic-file-referencing in C4D.

Do you guys have any idea how to lower the file size or get C4D to read the file?

Thanks in advance!


#2

Yeah ok, I figured it out in the minute after I posted this :smile:
I deselected the import-options

  • cameras
  • visibility
  • normals
  • UVs

… and now it loads the alembic, and with better performance than I hoped.
Will we get those wasted hours back in CG-Heaven? :sweat_smile:


#3

Ok, the UVs are the culprit. As soon as I import those, crash again.
Unfortunately, to assign materials in C4D, I need those UVs.
At least, the problem is now more focused.
Anyone got an idea?


Best practice for big projects?
#4

I think I found a workaround at least.

In MD:

  • Export Animation as Alembic Ogawa
  • Export Still as OBJ with UVs and Selections

In C4D

  • Import Alembic with animation, but without UVs
  • Import OBJ, copy UV-Tag and Selection-Tags on the alembic to assign materials.

I just hope, that I can keep this alembic-setup and just
cycle through the exported animation scenes without
having to do all those steps again and again.


#5

Hi Keppn
Thanks for sharing your workflow.
I’ve been stuck trying to get MD alembics into C4D without crashing for a while…
I’ve tried to copy the UV tags and textures from an OBJ as you suggest but it still crashes.
I had a bit of luck double baking the alembic down to keyframes in the timeline
and then transferring the UV’s to the alembic layer.
I now get these geo artifacts but that’s another issue to solve.

Did you have any other insights to your MD to C4D alembic process that
might be useful?


#6

Hi Vakante,

oh, indeed I found the source of the problems for my files. I only posted that to the Redshift Forums, but I’ll just paste it here, for forum wisdom :slight_smile:


At last, I think I found the solution. I’ll summarize shortly, if anyone encounters the same problem:

Export from Marvelous with “Thin” setting, then add Thickness in C4D with Cloth Surface Object.
The “Thick” setting produces UVs that crash C4D and Redshift.

Export without “Buttons”. I only found this with C4Ds mesh-inspector. The marvelous-buttons are
super-dense objects with horrible geo. I didn’t notice that during UV-Inspection before, because
those islands were so dense with points, that I didn’t really see those were points at all :
I modeled clean replacements and placed them with a Mograph-Cloner to the deformed cloth-surface.
That works quite well, and finally I have clean lo-poly geo, nice Tesselation and Motionblur on top.

Man, that was exhausting! :smiley:

Thanks again, Team Redshift! I’m sorry I constantly bring up things that totally aren’t your fault,
but it’s the renderer were a lot of pipeline-problems surface. Your hints about UVs were supervaluable
for solving this!



#7

Hi Keppn
Thanks for the quick reply. Good advice.
I do export as thin as my projects are all closed garments, no flaps or belts that need thickness.
I’m also importing full pattern sets with linings from CLO so I delete the linings and all surfaces
that the camera won’t see.
I have the same problem with all the added OBJ parts (zip sliders, grommets, buckles) that you had with buttons, too much bad geo.
These parts were modeled in Rhino with triangles not quads, Rhino is NURBS based so it’s easy to make
shapes but not useful for simulations. I too have been adding these in C4D and constraining to the main mesh.

I got a good animation out last week but didn’t document the process properly so I spent the last week
trying to find the recipe again. Your post helped steer away from certain failures. Thanks.
Curiously, that alembic was triangle geo from MD and it worked fine in C4D/Redshift.

Importing the MD alembic into R23 crashed every time. I then imported the same alembic into R21 with success (one time only)
and re-exported another alembic back over to R23 and got my successful animation out with no rendering artifacts.
Now when I import the alembics back into R23, I hit the ‘C’ key to make it editable and just transfer the
UV textures and selections from the OBJ layer. No crashes this way and progress.

I tried rebaking the alembic using the bake function in the timeline and got these rendering artifacts.
(this method converts the alembic animation to keyframes)
I also tried re-exporting the alembic (file export) for a ‘proper’ rebake and still got artifacts.
And I tried the ‘bake as alembic’ under the object menu with the same bad results.

Todays challenge will be finding out what causes the geometry artifacts. I’ve read in some places that it is a normals issue.
There are also stray bad polys out side of the selections that are random and don’t render properly.
When I zoom in I get this strange pattern…
I don’t have any idea where this comes from.
I checked in the Redshift object tag to see if any settings there changed anything but no luck…

(I’ve attached a couple of screengrabs to show the artifacts)
The artifacts only show up on the UV textures, not a plain Redshift material.

Could you recommend any other online resources you have come across that might help my situation?


#8

I was lucky to not encounter such problems… hmmm, maybe try C4Ds mesh inspector for clues. Also, you could try to generate quads in MD, maybe that solves the mesh problems altogether.
I didn’t find MD’s support or community to be super-responsive, but give that a shot as well. Good luck, the problem solving between software packages can be really frustrating, but I still have not encountered an unsolvable problem :slight_smile:


#9

My workflow is as follows:

  1. Export Alembic (ogawa) from MD
  2. Export OBJ from MD for texture UV’s
  3. Import MD alembic (without UV’s) into C4D
  4. File > export Alembic from C4D with UV’s and normals checked
  5. Re-import C4D alembic back into C4D with UV’s, normals and all other options checked
  6. Hit ‘C’ key to make editable.
  7. Bake in timeline with PLA checked to make keyframe animation.
  8. Merge OBJ and reset the selections and *relink the textures in Redshift
  9. Drag theUV tag, selection tags and textures over to the alembic layer.
    (curiously it crashes if I copy over the UV’s, selections tags and textures…) I just drag them over.
  • I found that my OBJ loses some of the saved selections so I rebuild them by selecting the polygons
    in the - Window menu > Bodypaint 3D > New Texture View - and redoing the set selection tag.
    This is a good trick and saves the day.

This is the workaround for me right now.
It would be much better if the alembic just came in! A lot less work!
This solved the weird artifacts and the slipping textures that others had talked about too.

I’ve sent my bug report to Maxon and they replied hours later which was very encouraging.
I believe the problem is with the MD alembic baker and it’s handling of UV’s…
I will send a bug report to CLO/MD and see what happens… I have a contact there so that
might get some response.

Thanks for your help.


#10

Thank you for posting your detailed resolution - that might come in mighty handy for other folks with simikar problems :slight_smile: