https://github.com/sideeffects/houdinialembic

Houdini Alembic integration
https://github.com/sideeffects/houdinialembic

Last synced: 12 days ago
JSON representation

Houdini Alembic integration

• Host: GitHub
• URL: https://github.com/sideeffects/houdinialembic
• Owner: sideeffects
• Created: 2017-07-21T17:07:48.000Z (over 7 years ago)
• Default Branch: Houdini16.5
• Last Pushed: 2024-05-08T04:00:02.000Z (8 months ago)
• Last Synced: 2024-05-08T05:21:55.959Z (8 months ago)
• Language: C
• Homepage:
• Size: 2.3 MB
• Stars: 20
• Watchers: 19
• Forks: 10
• Open Issues: 1
• Metadata Files:
  • Readme: README.txt

Awesome Lists containing this project

README

        
This directory contains unpolished files which show how it's possible to use a

custom Alembic library with Houdini.  This has been minimally tested with

Linux.  Additional work would have to be done for other platforms.

- MakeHuge

    Makefile to make a "packed" Alembic library for use with the custom code.

    Since Linux will only load a .so file one time (based on the soname), you

    will need to create a different set of libraries (i.e. other than

    libAlembic_sidefx.so.

    Instructions are embedded in the file.

- Makefile

    Example of a makefile which will untar the source code shipped with Houdini

    and make custom versions using the alternate Alembic libraries (created

    with MakeHuge).

    You might have to fix library paths etc.

    Instructions are embedded in the file.

If the Alembic library is ABI compliant with the version of Houdini's

versions, you should be able to just replace the Alembic libraries shipped

with Houdini (or preload the alternate libraries).

In the complicated case where the Alembic library is *not* ABI compliant, you

will likely have to put the Alembic code in a separate namespace (if it's not

already).

There are at least two different strategies to customizing the Alembic code:

1)  Replace all Houdini .so files

    With this strategy, you would replace GU_Alembic.so, SOP_AlembicIn.so,

    etc. with your versions (removing them from the distribution, and using

    your custom versions).

    Provided your code is linked against a different Alembic library, you

    should be good to go -- with a small caveat.  We ship *almost* all of the

    Alembic code.  At the current time, there are one or two calls outside the

    shipped public code:

	- One call to GABC_Util::getObjectList() in the

	    "File->Import->Alembic Scene" code

	- gabc.C

    If any of these code-paths get invoked after you replace GU_Alembic or

    GABC, your mileage may vary.

2)  Run in parallel with Houdini

    With this strategy, the custom versions of plug-ins (GU_Alembic,

    SOP_AlembicIn, etc.) are given unique internal names.  This means that

    your code will be working with a different primitive type, while the

    Houdini primitive remains in place.

    The Makefile included here is set up to use this strategy.