Page MenuHome

Cycles: Allow to render curve object as hair system
Needs ReviewPublic

Authored by Sergey Sharybin (sergey) on Apr 14 2017, 6:18 PM.

Details

Summary

While this seems to be useless for Blender itself, it becomes more useful
for inter-application interoperability using Alewmbic, which doesn't have
simple way of storing and restoring hair system as Blender's hair system.
Even more, default IO type for hair is curves for Alembic as far as i can
see, so this change allows following:

  • Being able to render hair system currently exported from Blender as a proper hair system.
  • Being able to render hair saved from an external applications.

There are following limitations:

  • No vertex color or UV coordinates are synchronized to such hair.
  • NURBS are not fully supported -- they are only exporting CV without midpoints which is enough for Alembic.

    This is simple to solve, but lets first have a bigger picture discussion about whether this patch is a complete rubbish or not.

The option is found below Cycles panel settings of Curve objects.

Diff Detail

Repository
rB Blender
Branch
cycles_render_as_hair
Build Status
Buildable 567
Build 567: arc lint + arc unit

Event Timeline

intern/cycles/blender/blender_curves.cpp
1115

Are the extra () necessary?

intern/cycles/blender/blender_curves.cpp
1115

Quick answer: no :)

So assuming Alembic has no concept of hair attached to a surface, I think that means:

  • The curves are already baked onto a deformed, subdivided and displaced surface. Maybe pushed a little into the surface to be sure it's connected.
  • UVs and other data are attributes on the curves, which ideally would be imported as curves custom data (which we do not support currently).

I guess the alternative is importing this as hair particles, but that doesn't support custom data either is assumed to be attached to a mesh. I wonder if the dedicated hair object type that we talked about for 2.8 could in fact be a curves object with extra data / modifiers, and it eventually gets unified again that way? Just an idea that I haven't thought through deeply.

Sybren A. Stüvel (sybren) edited edge metadata.EditedApr 15 2017, 3:50 PM

So assuming Alembic has no concept of hair attached to a surface,

Correct (as far as I've seen -- Alembic isn't the most-documented file format I've come across).

I think that means:

  • The curves are already baked onto a deformed, subdivided and displaced surface.

Correct.

Maybe pushed a little into the surface to be sure it's connected.

I don't think this happens. It would also be a topic for the exporter, not the importer.

  • UVs and other data are attributes on the curves, which ideally would be imported as curves custom data (which we do not support currently).

Yes, although I don't think we export UVs for curves now. I also don't know if Alembic has built-in support for this (if it does, it'll only be for a single UV map like with meshes).

I guess the alternative is importing this as hair particles, but that doesn't support custom data either is assumed to be attached to a mesh.

Talking about generic Alembic meshes, these aren't even guaranteed to be the same topology between timesteps. I'm also not sure vertex/edge/face indices are stable over time. As a result, attaching a hair system on top of an Alembic mesh could cause glitches with hairs jumping around.

Is this patch still relevant?