Houdini Feather Animation: Creating a Seamless Loop with a UV-Space Conveyor Belt
Updated: 3 days ago
By Timo Lenton, Houdini 3D generalist and FX artist
Houdini Feather Animation at a Glance
Timo Lenton, a Houdini 3D generalist and FX artist based in Auckland, New Zealand, created
Feathered Ouroboros, a self-initiated animation of a continuously moving, seamlessly looping mass of feathers. Instead of simulating the movement, he kept the surface static and moved around 30,000 feather points across it in UV space, like a conveyor belt. Working from a laptop while travelling, he rendered the final 200 frames on GridMarkets in 17 minutes and 49 seconds.
Artist: Timo Lenton, Houdini 3D generalist / FX artist (Auckland, New Zealand)
Project: Feathered Ouroboros, a self-initiated looping feather animation
Inspiration: Kate McGwire’s Murmur, Summer Exhibition, London
Software: Houdini (Vellum, feather tools, COPs) and Redshift
Technique: Static UV-flattened surface with a wrapping point offset, mapped back using Attribute Interpolate
Scale: Approximately 30,000 feather instances across 200 frames
Look Variations: Twilight, Metal and Cloud
Local Hardware: MacBook Pro M4 Pro
Estimated Local Render Time: Approximately 4–6 hours, based on test renders
GridMarkets Render Time: 17 minutes and 49 seconds for all 200 frames, using the Standard plan (up to 50 nodes) with an OB1800 configuration
Output: RAW EXR files, maintaining the same compositing and grading workflow
About the project
What was the idea behind Feathered Ouroboros?
Feathered Ouroboros is a self-initiated Houdini feather animation exploring how to create an organic, continuously moving mass of feathers.
The project was inspired by seeing Kate McGwire's Murmur at the Summer Exhibition in London. I found the sculpture incredibly striking. It has this almost organic, living quality to it, and it immediately made me wonder if I could recreate some of that feeling in Houdini, but take it a step further and make it move.
The challenge was to capture that organic, almost living quality while creating a continuously moving, seamless loop. I wanted the feathers to feel like a single flowing form rather than a collection of individual elements, and I wanted to achieve that through a procedural setup that was efficient enough to experiment with.
I was working on the project while travelling in the UK, so I only had my laptop with me. That was fine for most of the Houdini work and look development, but rendering the final animation was a different story. GridMarkets allowed me to keep the project lightweight and portable while sending the heavy Redshift rendering to the cloud when I needed it.
I love working on self-initiated projects. They're a great way to test out ideas, do a bit of R&D for upcoming projects, and build portfolio work that isn't client-driven.
A lot of my self-initiated work starts this way: I'll see something outside of 3D that interests me, try to recreate the idea in Houdini, and then see where I can take it.
In this case, the challenge was figuring out how to make something that felt like a living mass of feathers actually move.
My initial idea was to create an infinite, looping feathered Ouroboros. After quite a bit of testing, I eventually found a surprisingly simple solution.
Reference images for my project:
Ouroboros reference image 
iridescent feathers reference image 
feathers reference image
The process
How did you create the Ouroboros base geometry?
To create the knotted Ouroboros base geometry, I started with two separate sweeps and ran them through Vellum using Tetrahedral Stretch constraints.
Initially I tried just modelling the base forms, but being a Houdini user I wanted to find a more efficient, procedural way of creating them. That's what led me to Vellum.
In this case I was using Vellum to treat the two interlocking forms almost like soft bodies, allowing me to squash them together while maintaining their volume. It gave me a much more organic result than I was getting from trying to model the final shape directly.
This gave me the base shape. Once it's covered in feathers, the distinction between the two forms disappears and they read as one continuous, endlessly looping form.
Why did you rebuild the simulated geometry?
I only needed a single frame from this sim, so I could run it for 100 frames and then use a Time Shift to choose a frame that gave me a good base shape.
I then created clean swept geometry with UVs and Point Deformed it onto the tetrahedral mesh.
This is a very important part of the setup. I needed clean UVs for everything to work downstream.
How did you approach the movement in your Houdini feather animation?
I tested a few different ideas for the movement. Initially I tried a much more complicated Vellum setup, where I was running velocity forces along each twisted torus and trying to get them to slide along each other.
It was very heavy to simulate and, more importantly, the results weren't particularly good. I kept thinking there must be a simpler way to approach it. One of the nice things about Houdini is that there's often a way to solve a problem without simulating everything.
That led me to the idea of keeping the underlying surface completely static and just moving the feather points across it. All of the animation happens on top of this static geometry. I'm essentially using it as a surface for running the feather points along.
I created a "honeycomb" grid of points that defines the arrangement and density of the feathers. These points are what move across the surface, rather than the surface itself moving. The other important requirement was that the whole animation needed to be a seamless loop. A procedural approach made that much easier to control than trying to get a simulation to return to exactly the same state at the end of the animation.
How does the UV-space conveyor belt work?
Attribute interpolation is a really useful technique in Houdini and something I've used in various ways on a lot of jobs. It allows you to separate the position of something from the geometry it belongs to, which can be incredibly useful for building more complicated procedural setups.
For this project, I essentially turned the surface into a 2D coordinate system so I could treat the feather points like a simple 2D conveyor belt.
I could move the points through UV space and then use their primitive and UV coordinates to map them back onto the original 3D surface using Attribute Interpolate. This meant I didn't need to animate or deform the actual surface at all. I was just moving a relatively lightweight set of points across it.
It also gave me a very straightforward way to create the seamless loop. Once a point reached the end of the UV space, I could simply wrap it back to the beginning and continue the movement.
I then flattened the clean geometry into UV space, so both the geometry and my point grid occupied the same 0–1 space. I could then Ray the points onto the flattened geometry and capture the hitPrim and hitUV attributes. Using Attribute Interpolate, I could then transfer those points back onto the original clean geometry.
To get the points moving along the surface, I simply offset their Y position before the ray operation. I used a solver to continuously advance this offset and, importantly, make the points loop back around when they reached the end. So when a point moves beyond 1 in the Y direction, it wraps back around to 0.
The conveyor-belt approach turned out to be extremely efficient and lightweight. The main advantage was really a combination of speed, simplicity and control. Because the movement was just an offset in UV space, I could change things like the feather density, arrangement and speed without having to rerun a simulation. It also made it very easy to experiment with the look.
The procedural nature of the setup also meant the loop was effectively built into the system. I wasn't trying to force a simulation to match its starting point at the end. The points simply travel through the UV space and wrap back around, so the animation naturally loops.
It's definitely a slightly hacky solution, but that's one of the things I like about Houdini. Sometimes a simple workaround ends up being much more useful than a technically complicated solution. The solution was extremely fast and effective. It essentially gave me a procedural conveyor belt of points travelling around the surface of the Ouroboros.
How did you turn the moving points into a feather system?
From there, I just needed to tweak some tangents, set the scale of the feathers, and use Copy to Points to instance the feather geometry.
The whole setup was extremely lightweight, so I could quickly experiment with different feather densities and looks without having to wait for simulations. I eventually settled on roughly 30,000 feather instances.
Feather test Feather test Feather test Feather test
The setup was capable of handling considerably more while remaining responsive. I think I tested up to around 90,000 at one point, but around 30,000 gave me a good balance between the scale of the individual feathers and the overall density of the form. I was also adjusting the pscale of the feathers at the same time, so density and feather size were both part of finding the final look.
How did you create the feathers themselves?
For the feathers themselves, I got to experiment with some of Houdini's feather tools. The tools are actually surprisingly straightforward, so it didn't take long to get familiar with them. I was able to generate the low-poly feather geometry and also feed some of the outputs directly into COPs to generate the textures. I was keen to explore what Houdini's relatively new feather tools could do. They are actually surprisingly straightforward to work with.
One of the challenges was figuring out the most efficient way to render the feathers. Karma can render Houdini feathers as procedural objects, but I was using Redshift. To render the feathers directly, I would need to convert them to curves and render them as hair.
That became very expensive. With around 30,000 feathers, each made up of roughly 400 barbs, and each barb containing multiple points, the amount of geometry quickly became quite large.
Again, I thought there must be a simpler approach. I didn't need to see the individual feathers extremely close up, so I used the feather tools primarily to design the shape and look of the feathers, then converted them into low-poly geometry that could be copied onto my points.
How did you build the feather textures?
I also converted the Houdini feathers into dense curves and brought those into COPs. I've really enjoyed the new COPs workflow in Houdini. It's incredibly capable, and it meant I could take those very dense feather curves and generate a range of useful textures and masks that worked with the low-poly feather geometry. In COPs, I used the rasterized curves generated by the feather tools to create various masks as well as the normal map for the feather material.
Once I had that system set up, I could experiment with lots of different feather shapes and looks very quickly, which was probably the most fun part of the process.
Feathers Feathers
Rendering
Why Redshift, and how did you handle the final render?
Redshift is my primary renderer, so it was the natural choice for this project. It's very fast, particularly with GPU rendering, and handles instancing and packed geometry very well, which suited this setup. I also know the renderer well, so I could concentrate on the look rather than spending time solving technical problems in an unfamiliar rendering workflow.
I do like Karma, but for this particular project Redshift made more sense for me, especially given the large number of feather instances and the fact that I already had an established Redshift workflow. My laptop was perfectly capable of handling the Houdini work and look development, but the final renders were a different story. I rendered the project using Redshift, and the feather count and overall complexity meant that rendering the final animation locally would have taken an unreasonable amount of time. The final animation is 200 frames long.
During the look development phase, rendering was fast enough on my laptop that I could work locally. I could just about render the sequence at half resolution overnight. At full resolution, individual frames could take up to around five minutes on the laptop, so rendering the entire sequence locally would have been a significant amount of time.
This is where GridMarkets fitted really nicely into the workflow. I could send my Redshift renders directly to the GridMarkets render farm without having to change the way I was working. The process felt very seamless: I could continue working locally while the heavy lifting was happening remotely. With GridMarkets, I could use up to 50 render nodes and have the sequence rendering in parallel. Instead of leaving my laptop rendering for hours, I could submit the job to GridMarkets and have a large amount of the sequence rendered by the time I'd gone out to get a coffee.
Based on my test renders, rendering the final 200-frame sequence locally on my MacBook Pro M4 Pro would have taken approximately 4 to 6 hours, depending on the material and shader setup. I rendered the animation in several material variations.
Twilight took the longest to render, while Metal was the quickest. With GridMarkets, all 200 render tasks were completed in just 17 minutes and 49 seconds using an OB1800 configuration (a high-performance GPU machine rated at approximately 1,800 OctaneBench points). The final renders from GridMarkets looked consistent with those produced locally, with no noticeable visual differences. By rendering to RAW EXR files, I could use the same compositing and colour grading workflow for both, achieving a consistent final result.
This was particularly useful because I was travelling and working entirely from my laptop. I could do all of the Houdini work and look at development locally, then send the final rendering to GridMarkets when I needed the extra horsepower. I didn't need to carry a desktop workstation or compromise on the complexity of the project. I could build and test everything locally on my laptop, then send the final renders to GridMarkets when I was ready.
The setup was also straightforward because I could keep working with my existing Houdini and Redshift workflow rather than having to redesign the project specifically for cloud rendering.
Having access to that additional rendering power definitely made me more comfortable experimenting with the project. I could push the feather density and try different looks knowing that I wasn't going to be stuck waiting hours for my laptop to finish every test.
For me, that's probably the biggest benefit of GridMarkets on this project. It meant that travelling with a laptop didn't necessarily mean having to design the project around the limitations of that hardware.
GridMarkets Job Submission
Once I had the scene ready to render, I cleaned up the Houdini file and cached out the geometry. This simplifies the scene down to what I actually need for rendering: the cached geometry, lights, camera and material shaders.
I then use the GridMarkets submit tool, which collects the files required for the job and presents a preflight window showing what will be uploaded and whether there are any warnings. In this case, the only warning was related to the use of backticks in my ROP. I'm not actually using backticks in the scene, so I believe this is related to something happening behind the scenes with the Redshift setup. It doesn't affect the render, so I can safely continue.
Once I click Save and Continue, GridMarkets Envoy takes care of the file transfers in the background securely. I can then monitor the progress through the GridMarkets web interface.
Here you can see the job syncing. It takes a little time for the files to be transferred to the Cloud and the required machines to start up, but once the job gets going it moves through the frames very quickly.
Looking back
What was the biggest technical challenge?
The biggest challenge was probably finding a way to make the feathers move convincingly without creating a huge simulation.
My first Vellum approach was far too heavy, and the results weren't particularly good. The UV-space conveyor belt was a much simpler solution and gave me far more control over the movement, density and looping.
What would you do differently?
I'd really like to test out rendering with Karma, so that I can test out the procedural feather prim. Maybe try adding some dynamics to the feathers too?
Would you use the same workflow again?
Definitely. The main thing I'd take from this project is the general approach of keeping the underlying geometry and animation as lightweight as possible, then building the complexity on top.
The procedural setup made it very easy to experiment and iterate, and the fact that the animation was driven by points rather than a heavy simulation made the seamless loop much easier to achieve.
About Timo
I'm a 3D generalist with more than 20 years of experience working across VFX, broadcast, motion graphics and television. I originally got into 3D in the 1990s after getting interested in building levels for Quake, and I've been fascinated ever since by the process of creating things that don't exist.
These days I spend a lot of my time working in Houdini, particularly on procedural setups, FX and technical problem solving. I enjoy the process of figuring out how to build something rather than simply working towards a predefined result, finding efficient ways to solve complex problems, and creating systems that give me the freedom to experiment.
Look my work at Instagram
Comments