For those who don’t know the tool: Think of the Elemental Suite as a real-time VFX kit that exports flipbooks, image sequences, VDB, and caches for DCC and engine work, with EmberGen, LiquiGen, IlluGen, and GeoGen sharing the same ecosystem.

The program, now with a permanent spot

The Layoff Assistance Program is now a permanent offering, built around a simple promise: artists affected by layoffs or studio closures can request licenses to the elemental tool suite free of charge for up to six months, specifically to rebuild portfolio work.

What you actually get for six months

When a layoff license is approved, it grants access to the toolset that sits under the Elemental Suite. That includes the core apps named for the program in current materials: EmberGen, LiquiGen, IlluGen, and GeoGen.

Each tool targets a different kind of content, EmberGen is positioned as a real-time volumetric fire simulation tool that can simulate, render, and export flipbooks, image sequences, and VDB volumes. The value proposition is iteration speed, with real-time tweaking while looping a timeline and a built-in renderer for immediate results.

LiquiGen focuses on liquids, with real-time meshing, forces, sparse simulation domains, and a real-time path tracer. It is described as able to generate flipbooks, image sequences, and Alembic caches, and it explicitly calls out foam, spray, and bubbles as controllable elements.

GeoGen is framed as a node-based workflow for terrain and planet generation, built with games in mind, and presented as part of the same suite.

The net effect for an artist in rebuild mode is straightforward: six months of hands-on time with tools that cover volumetrics, liquids, procedural asset generation, and terrain workflows, under one licensing umbrella, without paying during that period if approved.

Rules that matter when you are building a reel

The program terms are not hand-wavy. The Layoff Assistance Program spells out the intended use and the boundary conditions.

The layoff licenses are strictly for non-commercial use. They are meant to help upgrade skills with new tools and assist with new portfolio pieces. Approval is discretionary. A request can be denied. Commercial use requires a purchased license. That clarity is useful because it prevents the most common licensing misunderstanding: portfolio work is still work, but portfolio work is not automatically commercial work. The program draws the line itself, and you are expected to stay on the correct side of it.

It also means studios should not treat the program as a back door for production seats. If your use case is client deliverables, the license you want is not the one that comes through the layoff portal. If you are rebuilding a porftolio, the terms match the real-world need: get access, make work, learn, and do it in a way that does not collide with commercial licensing.

How to apply without turning it into a side quest

The application flow described in the official program materials is short. You create an account, or you log into an existing one. You submit a request for a layoff license through the portal linked from the program page, using the Apply Now button. Requests are reviewed. If approved, a license key is issued by email and also appears in the account. That is the whole process , with no extra hoops listed on the program page itself.

The program messaging also asks people to share the page with anyone who might need it, which is a rare example of a support initiative that is designed to spread by simple forwarding rather than by gatekept referrals.

Pricing, for when you are back on your feet

Even if you are applying for the six-month program, pricing matters because it tells you what comes next when the clock runs out, or if you need commercial usage.

The official pricing page lays out an Indie and Hobby tier for revenue or funding under 1 million USD. For the Elemental Suite, the price shown is 525 USD for the first year, with 315 USD for optional maintenance annually. For individual tools, the page lists 300 USD for the first year for EmberGen, 300 USD for the first year for LiquiGen, and 300 USD for the first year for IlluGen, each with 180 USD for optional maintenance annually. For GeoGen, the page labels it as beta and lists 150 USD for the first year, with 90 USD for optional maintenance annually.

The pricing page also notes that displayed prices do not include taxes and that final prices are shown during checkout. It states that tier calculations use revenue, project budgets, and funding depending on whichever is greater. For artists who are currently laid off, the immediate takeaway is that the program offers a time-limited, no-cost runway. For artists who land a contract mid-runway, it is also a clean reminder to switch to a commercial license if the work moves beyond non-commercial portfolio building.

A note on intent, and a note on reality

In the accompanying message around the program, the founder describes frustration with recurring layoffs across the industry and positions the program as a way to help artists stand back up, using tool access to support portfolio rebuilding. The same message states that over 100 artists were assisted with free licenses last year.

None of this changes the usual production reality: every new pipeline ingredient should be tested before you depend on it. Even when a tool is fast, friendly, and installed locally, you still validate exports, check integration points, and run a small end-to-end test before you bet a deadline on it.

If you qualify and you are rebuilding, the offer is practical: time, access, and a clearly labeled license boundary. That is not a job, but it can be the difference between stalling out and shipping that next reel shot.

https://jangafx.com/layoff-assistance-program

The post JangaFX makes its layoff assistance programme permanent first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

LOOKSfilm brought Overmind Studios in as the sole VFX vendor for all six episodes of A World Divided, a historical drama following six real figures from World War II through the 1960s. The series blended archival material with recreated drama and moved across locations from New Mexico and China to Russia, Israel and French Algeria.

Shot in Germany, Belgium, Luxembourg, and Poland, the project demanded constant geographic reshaping and period-authentic cleanup to sell multiple continents and decades, all while working to rolling episodic deadlines.

Tobias Kummer was VFX lead on A World Divided at Overmind Studios. He supervised on set on key shoot days, built the project pipeline and delivered the work alongside André Gerhardt as a two-person VFX team. (Site | IMDB | Linkedin | Xing)

DP: How did you come onto A World Divided, and what was the overall scope?

Tobias Kummer: LOOKSfilm brought us in as the sole VFX vendor for all six episodes. We’ve worked with them before, so there was already trust there. The series was a historical drama following six real figures from World War II through the 1960s. It wove archival material together with recreated drama and jumped across locations from New Mexico and China to Russia, Israel and French Algeria.

André Gerhardt and I handled the VFX work as a two-person team, with me also covering on-set supervision on key days. Across the season, we delivered around 125 shots in total.

DP: What were the main categories of VFX work across the season?

Tobias Kummer: Most of the work fell into a handful of categories. The biggest chunk was geographic transformations and set extension work. The show was shot in Germany, Belgium, Luxembourg, and Poland, but it needed to represent locations across multiple continents, so we were constantly reshaping the world. We made the Pustynia Błędowska desert in Poland read as New Mexico in some scenes and as Israel in others. We replaced window views with believable locations and extended sets to fit both the period and the geography.

Period cleanup was the other constant. Removing anachronisms took up a steady portion of the workload, such as power lines, phone masts, wind turbines, modern signage, contemporary vehicles, basically anything that didn’t exist between the 1940s and 1960s. Some removals were straightforward paint-outs, while others required proper tracking and reconstruction for moving shots, especially given the anamorphic lens characteristics to account for.

Beyond that, there was a lot of environmental and atmospheric work. We added snow to summer shoots where winter was required, enhanced practical smoke and explosions with additional elements, and built the nuclear explosion sequence. There were also the smaller, problem-solving shots that always appeared on a show like this, including window inserts, moon replacements, damage work, retouching visible wig seams and removing on-set facilities from reflections. Many shots weren’t just one technique. A single exterior might have needed cleanup, set extension and atmos all layered in one comp.

DP: What constraints shaped the work most?

Tobias Kummer: What shaped the work was the schedule and the fact that we were a two-person team delivering an episodic shot count with rolling deadlines. Episodes moved into colour on a rolling basis, which meant we had to work sequentially and finish each episode properly before moving on to the next. We couldn’t cherry-pick shots across the whole season when we needed breathing room. There was a clear rhythm to the work. However, we had to maintain strict discipline.

“What shaped the work was the schedule, and the reality of being a two-person team delivering an episodic shot count with rolling deadlines.”

DP: How did the anamorphic photography affect VFX, especially cleanup?

Tobias Kummer: The anamorphic photography added complexity in places you might not expect. Distortion and breathing made tracking more challenging than it would have been with spherical lenses, particularly on handheld or more dynamic shots. We had everything from locked-off tripod plates to dolly moves, cranes, and handheld coverage, so even simple cleanup could have become complicated if you wanted it to sit cleanly while preserving the anamorphic feel.

DP: What did on-set supervision change for you in practical terms?

Tobias Kummer: On-set supervision helped in practical ways. Sometimes it was about making sure we had clean plates and tracking markers. At other times, it was flagging modern details before they became post problems. Or it was a small camera placement decision that saved hours of rotoscoping later. We had an initial planning phase with the DOP and directors in May 2023, and on-set supervision ran through the shoot from May to July.

Then there was a long gap. We didn’t receive VFX plates until May 2024, nearly a year after wrapping, because production was working through the edit in the meantime. That delay reinforced something I always try to stress. Write everything down during on-set supervision. No matter how certain you are that you’ll remember something, you won’t a year later. Good notes made it possible to pick the work up again without having to guess.

DP: How did the schedule work once plates started arriving?

Tobias Kummer: Once plates started arriving, we had roughly two weeks per episode, regardless of complexity. VFX production ran for over 12 weeks across the six episodes. Shot complexity varied widely. Some cleanups were quick, while sequences with multiple iterations took longer, but the template system helped. The first shot of a new type might have taken time to establish the approach, but similar shots afterwards moved much faster.

Approvals were efficient. Most shots were approved in versions 1 or 2, and only a handful needed additional revisions. When revisions did happen, they were usually about creative direction rather than technical fixes, which came back to communication and understanding intent early.

DP: How did you split responsibilities as a two-person team?

Tobias Kummer: André and I divided the work in a clear way, but we kept shot ownership flexible. I handled on-set supervision, project planning, client communication and pipeline setup, and I also did shot work as well. André focused on shot execution and handled the motion graphics. We didn’t rigidly assign shot types. It was more fluid. Whoever was free took the next thing that needed doing. Because we were working remotely, communication was essential. We stayed connected throughout the day, and if one of us got stuck, a quick call and a screen share often solved what might have taken hours otherwise in minutes.

DP: What did you use for project management?

Tobias Kummer: For project management, we used Ramses by RxLaboratory. That was our central truth for what was in progress, what was out for review, and what was approved.

I wanted to avoid the usual folder wrangling that came with episodic work, so I built a small Fusion plugin that connected directly to the Ramses API. In practice, it meant that when you opened a shot, the setup was already done. Correct plates, correct naming, correct version number, correct saver paths, and comp settings that matched the show spec. It wasn’t glamorous work, but it prevented mistakes and kept us moving. Templates were the other foundation. I kept them rigid where mistakes were expensive and flexible where a shot needed freedom.

DP: Can you break down the plate specs and colour pipeline?

Tobias Kummer: Plates came from Avid as 4K MXF containers in DNxHR HQX 12-bit with a 1.8 anamorphic squeeze, in ARRI Wide Gamut 4 and LogC4.
We composited in scene-referred linear, so the input linearisation was standardised. Output was standardised too. For review, we rendered previews in Rec.709 using the client reference LUT, so the work looked close to the intended look. Finals went out in ARRI Wide Gamut 4 and LogC4 so the grade could treat VFX shots like any other plate. The LUTs were helpful for context, but we couldn’t bake them into the finals without limiting the colourist’s downstream options.

DP: Why Fusion Studio, and what tools mattered most?

Tobias Kummer: All compositing happened in Fusion Studio, because it was what we knew and because the node-based approach was genuinely flexible under episodic revision pressure. When notes came back, you could restructure a comp non-destructively. Insert processing, reroute parts of the tree, try alternatives, without rebuilding from scratch.

Fusion’s tracker and planar tracker held up well on the anamorphic plates, which mattered for both cleanup and set extension work on moving shots. Magic Mask helped as well. It wasn’t perfect in every case, but it saved us more than once from manual roto. We supplemented with a handful of Reactor tools and some custom tools we’d built, but the aim was to rely on Fusion’s core toolset and maintain a consistent pipeline for broadcast delivery.

We also used Blender for 3D elements and set extension geometry, EmberGen for pyro and atmospheric simulations, SynthEyes for more complex camera solves and Affinity Photo for detailed paint work. All rendering was done locally rather than on a farm, which gave us more control and faster iteration.

DP: Pick one shot that best represented the season. What was it, and how did you approach it?

Tobias Kummer: If I had to pick one shot that summed up the work, it was a vast desert establishing shot where we turned the Polish Pustynia Błędowska into an Israeli desert landscape. The plate was shot on a crane mount, so there was a slight shake, and the camera racked focus between foreground and background. In the original plate, you could see the forest at the edges of the location, which didn’t sell the intended geography at all.

This was a case where on-set supervision paid off. Had we gone with the initial framing, we would have had the actors’ heads and the car crossing the horizon line, which would have meant rotoscoping them out to replace the background. I asked for a slight adjustment to the camera placement so everything stayed below the horizon. That saved hours of roto later and made the background replacement much cleaner.

In Fusion Studio, we used a few point tracks to stabilise and reapply the move, and we paid close attention to the rack focus because anamorphic lenses can shift and breathe, causing the background to drift if you ignore it. We built a matte painting from Israeli desert reference photos for the mountainous backdrop. We added blowing sand using an EmberGen simulation we had created and reused across multiple desert shots, and we added heat haze with a simple Fast Noise feeding a Displace node. The focus rack was matched by hand with keyframes. The shot was approved in version two.

DP: What were the key lessons you took from delivering this as a small team?

Tobias Kummer: If I had to distil it down to what kept us on time while maintaining quality, it came down to a few habits. First, learn some scripting, Python or whatever your tools support, and automate the repetitive, error-prone parts of the job. The time savings compounded quickly, especially for a small team, and you don’t need to build for massive scale to benefit.

Second, organise everything and document it. When you’re juggling episodes, you can’t waste time on version mix-ups or folder hunting, and the year gap between shoot and plate delivery made that even more important. Lastly, don’t waste time being stuck. Fresh eyes solved problems faster and a quick screen share could save hours. And honestly, sometimes the best decision was to stop and sleep. If you weren’t making progress, you’d often solve it faster in the morning.

The post A World Divided: Shaping a Global WWII Epic at Overmind Studios first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

JangaFX has launched IlluGen, a new node-based tool for procedural VFX asset generation, aimed directly at real-time games and technical artists. Released on July 28, 2025, IlluGen is now live and available to anyone via a 14-day free trial—no credit card or pre-commitment required. The tool is immediately included in the Elemental Suite, alongside EmberGen, LiquiGen, and GeoGen.

Core Features and Pipeline Integration

IlluGen enables procedural creation and manipulation of the core assets used in game VFX: 2D and 3D flipbooks, tiling noise, flowmaps, normal maps, caustics, procedural geometry, mesh trails, and more. The workflow centers on a node graph interface—familiar territory for anyone with Houdini or Substance Designer experience, but focused exclusively on VFX asset creation for games.

Infinite variations of a magic impact in IlluGen. Build your graph, set your parameter bounds, and roll the dice! pic.twitter.com/VUlpMEZL31

— Nick Seavert (@nickseavert) May 7, 2025

Typical use cases include decoding EmberGen flipbooks, tiling or looping them (for example, with Voronoi nodes), and exporting the results back as optimized, game-engine-ready flipbook sheets. The April 2025 livestream demo, , covered a “smoke flipbook” pipeline completed in minutes: decode a sheet, tile and loop it, then re-encode for seamless playback. Other nodes shown include mesh generators for energy beams, impact craters, UV distortions, and stylized effects like mana orbs and animated wings. Node graphs are fully animatable.

Exports support the standard VFX formats: Alembic caches, flipbooks, and baked textures, ready for Unreal, Unity, Godot, or in-house engines. Direct pipeline links to EmberGen, LiquiGen, and future JangaFX products are included by design. Batch and hand-painted texture support is confirmed.

Elemental Suite Pricing and Access

The 14-day free trial applies to the full suite—users get full export capabilities and support (JangaFX Pricing). A Permanent License is 300 Dollars in the first year, with a 150 Dollar Maintenance after that. Or 20 Dollars per Month in a Subscription.

What’s Next for IlluGen?

JangaFX has announced further feature development for IlluGen, including destruction simulation tools and deeper direct exports to Unreal, Unity, and Godot. Upcoming updates across the Elemental Suite will be presented during JangaFX’s “Elemental Week,” running soon.

Not a “Do Everything” Tool—But Built for Game VFX

Nick Seavert, JangaFX CEO, states that IlluGen’s target is not simulation or rendering, but asset authoring—procedural, flexible, and designed for the fast-moving needs of real-time VFX teams. The node graph replaces the “chain of Photoshop, Maya, and Substance” in many classic FX workflows, condensing mesh, texture, and flipbook asset prep into a single tool.

Production Artists: Always Test Before Rollout

As with any new tool, the usual caveat applies: test before deploying IlluGen in production environments. Check export quality, node graph flexibility, engine compatibility, and support for non-standard asset needs. As of launch, all claims are based on live demos and official feature lists—further stress-testing in studio workflows is essential.

The post IlluGen Drops: Node-Based VFX Tool from JangaFX Now Public, and Free for 14 Days first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

When Red One dropped last this year, audiences got get a holiday cocktail of Jumanji-style action (The director was the same – Jake Kasdan), Christmas mythology, and CG hellhounds. Behind the visual spectacle: RISE FX, tasked with bringing a gooey portal system, guard monsters, and an actual magic chicken to life. We caught up with VFX Supervisor Michael Wortmann at FMX2025, to talk creature design, feather grooming in Houdini, and what happens when Krampus goes full-screen. From Atlanta to EmberGen simulations—here’s how RISE tackled 280 shots for Amazon MGM’s festive actioner.

DP: What was RISE FX‘s scope on Red One, and when did you get involved in the project?

Michael Wortmann: RISE came aboard the production during the shoot in Atlanta, Georgia in March 2023. We were tasked with some sequences for the new, secret Amazon christmas movie alongside Sony Imageworks and Rodeo FX. We had already worked with VFX Producer Cari Thomas on Shazam but we never worked with Jerome Cheng, the overall VFX Supervisor of the show. We ended up delivering 280 vfx shots for Red One over the course of twelve months requiring a mix of CG creatures, digital set extensions and a lot of hardcore 2D augmentations.

DP: Red One walks a fine line between Christmas fairy tale and action film. How did that tone influence the visual style and your VFX approach?

Michael Wortmann: We knew that production vfx supervisor Jerome Cheng and director Jake Kasdan had already worked together on Jumanji: Welcome to the jungle so it was clear that they would expect topnotch photoreal vfx work and a colorful phantastical design at the same time. But overall this movie would be a comedy so everything needed to help that and action would not be considered the most important thing.

 
DP: So, how duo you get that “fairyle” style in a story like this? 

Michael Wortmann: For example: the Krampus castle was conceived as a matte painting for the shot when Cal and Jack enter the realm of Krampus. When the second wide shot was added later, we did another matte painting because we never built the whole asset. Iterating the matte painting was straightforward and didn’t require so many rounds, in contrast to the design of the portals. Portals are not a new idea, so we needed to come up with something that would be funny and cool looking at the same time. 

The key requirement was to create something that happens fast because if something is overly complex or too long-lasting it is a) NOT funny and b) hard to read and understand by the audience. We started with the membrane simulation and made it feel gooey, later we refined it by adding ice crystal structures and depth blur. The last step was to foreshadow a bit of what is behind the portal. Our compositor Cintia Coll went through all the steps and then distributed the setup to other artists.

DP: How do you plan and prepare when a sequence might end up being full-CG—even if that’s not the original plan?
Michael Wortmann: Creating a full set or shot in CG is very expensive and time-consuming. As soon as directors or producers know that something is fully digital, they suddenly feel different about it. So we always try to shoot anything and keep it in there, so we might just end up with a 99% digital shot – just out of pure psychology. 

The big difference is when something is planned as digital from scratch it’s a long but more controlled process because it will be designed and relevant data will be acquired. However, if a shot turns from footage to full digital, it’s more likely to not have all the reference we would need. If we are lucky, we can reference a lot from the shot that cannot be used but still might help us get it right. All this factors into the bidding, planning and execution of a given shot. However, I have to admit that this can happen, but it is very rare that a shot is going overboard, and we need to rescue it.

DP: What were the most iteration-heavy sequences in Red One, and how did you manage creative feedback?
Michael Wortmann: The most iterations on Red One happened in character animation, especially the hellhounds and the chicken were a big challenge. When you do character animation the pressure is up because the director will ask for a certain performance and that means your shot is suddenly focussed on in a very different way as if you are doing a wire removal. So both, internal and external review iterations are really high in comparison to other vfx shots because it really needs to be perfect because one shot of bad character animation and the illusion is ruined.

DP: Can you walk us through the guard monsters? What went into designing and animating them?
Michael Wortmann: We received a ZBrush sculpt from the production with a design that was relatively close to the final design. So the first thing was to retopologize the model to make it suitable for rigging. 

Our modeller Marius Pörsel took care of that and also refined muscles, facial details and the porcupine spikes that are growing from the neck like a lion’s mane. After that texture artist Timo Scheu started to build shaders and paint textures based on the hires displacement maps generated from the ZBrush model. 

The tricky bit was to combine subsurface shading for the skin with rhinoceros-like armoured skin parts. As we knew that the hellhounds would only be visible in night scenes we developed shaders for the eyes that would give us nice reflections and even catlike yellow reflections also called Tapetum Lucidum. 

Rigging was rather traditional, we tested Houdini’s skin simulation tools but eventually found that we would not see much at night and the camera distance to the hellhounds. So our rigger Thorsten Schulz took care of this and adjusted the rig based on feedback from our animation supervisor Thorsten Kesse.

DP: We’ve heard tales of “The Chicken”. You must explain.
Michael Wortmann: The chicken in Red One is one of the funniest characters. In the story, the chicken is a bewitched agent of the E.L.F. agency and can be turned from a rubber chicken key ring to an actual live chicken by Callum’s actualizer.

Because of the interaction with the CG hellhounds, it was clear we needed a digital chicken. The director Jake Kasdan even owns chickens himself and sent us video footage of his favourite chicken, which is called Ellen.

We used Ellen as reference but, as Ellen is of brown colour, we had to make her white eventually because the brown colour was cancelled out by the blue night colours. Our FX artist Luca Schippmann used Houdini’s new set of feather tools to groom Ellen. This required a lot of development time as the tools were new. Ultimately, we could simulate all feathers and render Ellen with feathers made from curves, which allowed for the closeup shots we needed.

DP: What was the most unexpected challenge during the show—something you couldn’t have planned for?
Michael Wortmann: I think the biggest challenge was Krampus. When we were confronted with the Krampus sequence and briefed on the work, everybody was a bit concerned if we could pull this off. The approach was to rotoscope the Krampus character including fur and hair from the plates, scale him up and digitally recreate the areas that were missing in the plates now. 

We decided that we could do this, and after we completed the first couple of shots we became more confident. The shots turned out beautiful because we had nearly no chroma keying going on and everything looked great from the beginning as in the provided plates. There were a lot of test screenings, but for the biggest part this didn’t affect our part of the work.

DP: What kind of tools or workflows did you use to prepare for test screenings?
Michael Wortmann: For the first test screening, we worked completely on Quicktime proxies. We made sure to set everything up in a way that we could refine match moves and roto we created for this. However, this doesn’t always work – so we had to redo some work later on the high-res plates.

DP: Any clever uses of real-time tools or GPU-based solutions—like EmberGen?
Michael Wortmann: We used GPUs for simulating the storm clouds in Embergen. It seemed like a good test case as we never used it before in production, and because our clouds needed a lot of detail but not a very complicated behaviour or interaction we gave it a shot.

When we had our voxel cache VDB files we found it was nearly impossible to render in Karma, our standard renderer in Houdini, so we tested rendering on GPUs as well using Karma GPU. This gave us the power we needed, but there were still some limitations at that time when it comes to AOVs, deep output and image resolution constraints of which I believe most are fixed by now.

DP: What’s your approach to making sure “annoying shots” don’t end up in the final cut?
Michael Wortmann: This is not really an option. If we face a shot or briefing that seems not doable, we start a discussion about it and offer options to satisfy our client’s needs. “No” is not really an option…

DP: How do you adapt when today’s final delivery deadline is also… for Netflix?
Michael Wortmann: This has hardly changed, we still deliver ACES Linear EXRs that contain enough range for HDR grades. It’s more likely to work in 4k now than some years ago, but this is not really a problem.

DP: What good resources or tools were essential in your workflow—and which would you recommend to others?
Michael Wortmann: We have a lot of custom tools for our pipeline which starts with our own database Risebase and continues through all departments with customizations for Nuke, Houdini and OpenRV. These help us get through these big shows and are tailored for our needs more than any software we could buy.

DP: Can you tell us what’s next for you or RISE FX—if it’s not under NDA?
Michael Wortmann: I recently wrapped work on Michael Ende’s Momo, a really cool project that I supervised completely including the shoot, coming to theatres later this year.

The post Rise FX saves christmas? first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

“Red Poppies” (original title: “Czerwone Maki”) is a 2024 Polish war drama directed by Krzysztof Łukaszewicz. The film portrays the legendary Battle of Monte Cassino through the eyes of Jędrek, a young man who endures the harrowing experiences of a Soviet gulag and later joins the Polish II Corps.

The cinematography is crafted by Arkadiusz Tomiak, with Marek Warszewski serving as the art director and Agnieszka Sobiecka designing the costumes. The screenplay is also penned by director Krzysztof Łukaszewicz.

Produced by Wytwórnia Filmów Dokumentalnych i Fabularnych (WFDiF), “Red Poppies” is co-produced by ORKA, a company that expressed pride in contributing to the first Polish feature film about the Battle of Monte Cassino. The film’s visual effects were handled by Imaginary Pixels, a Polish VFX studio responsible for over 120 shots involving 3D tanks, set extensions, and the digital recreation of Wojtek the bear, a historical figure known for aiding Polish soldiers during World War II. https://kinoswiat.pl/film/czerwone-maki

The VFX team for “Red Poppies” included:​

Maciek Wojtkiewicz – Senior Animator
Lukas Remis – VFX Supervisor​
Artem Huza, Kajetan Czarnecki, Trendafil Kirilov, Jorge Grandes, Siarhei Talashka – Compositing Artists​
Severi Kamppi – 3D Lead​
Jyri Kataja – 3D Generalist​
Patryk Ptasiński – FX Artist​

DP: Let’s start with Red Poppies: How did you get involved with that production?
Lukas Remis: Red Poppies was a Polish production with one of the biggest budgets in recent years. It’s a war movie with over 400 VFX shots. Imaginary Pixels was one of 3 vendors, and we were brought in by the production company, that we have worked with in the past. For this project we’ve delivered over 120 shots, with a team of 12 artists, in about 4 months. Our work involved 3D set extensions, crowd and tanks multiplication, 3D creature creation and animation, and a lot of explosions and bullet hits.
The most complex part of the work was creating and animating a 3D version of Wojtek the bear. Wojtek was a Syrian brown bear adopted by Polish soldiers during World War II. There were about 15 shots with the creature, and many of them included interaction with the actors. Blender was our main and only tool for that. All aspects, from modelling, rigging, grooming, to animation and rendering were done in Blender. Our rig had some elements that were calculated automatically, like skin around the mouth or the ears. The goal was to have more physically accurate movement and faster workflow.

Another large part of our work were set extensions – usually mountains in the midground or background. For the background mountains, we have created a 360-degree environment in Blender, matching the terrain and foliage of Monte Casino in Italy, where the action should take place. We’ve rendered that as a 22K equirectangular image (Nuke wasn’t able to handle a larger render with AOVs) with some passes and different light direction versions. That way, the compositing team was able to use it as projections, for any angle in multiple shots, without involving the 3D artists each time.

DP: Can you break down your postproduction pipeline—from asset creation to final render—and specify which tools you used at each step?
Lukas Remis: Our pipeline is based on Ubuntu Linux. Projects are managed using Kitsu – an open source production management and review platform. We’re using Blender exclusively for all 3D tasks, and it’s native renderer – Cycles – for rendering. Render management is done with CGRU Afanasy. Compositing in Nuke. We’ve used Houdini in the past for FX, but currently we’re using mostly Embergen. Additionally we’re using Krita for photo or textures editing and MRV2 for playback and review. We’re also using Davinci Resolve for editing.

DP: Why did Imaginary Pixels as a full, working VFX shift toward open-source tools? Was this a gradual evolution or a clear strategic decision?
Lukas Remis: Personally, I have always been interested in the open source community and software, long before starting a career in VFX. I’ve been testing and playing with different Linux distributions in the past. Since a couple of years Linux, and Ubuntu as my personal favourite, has surpassed Windows functionality and stability, so it was a natural choice for an OS for all our machines. As for the other tools, like Blender, Kitsu or MRV2, the financial aspect is of course very important, but we only adopt an open source solution if it’s really capable of delivering what we need, efficiently. Blender was there from the beginning, the other tools came gradually, while we were looking for solutions to different areas.

Kitsu, the project management platform, is definitely worth mentioning here. It’s a wonderful software, with great people behind it. It was used, together with Blender, for this year’s Oscar winner: Flow.

DP: Are there areas in your pipeline where proprietary tools remain essential? What can’t be replaced by open-source alternatives—yet?
Lukas Remis: Obviously, in compositing we are stuck with proprietary software – and Nuke as the industry standard. And even the alternatives are not open source. Recently, I’ve been reaching out to several VFX studios to build a Natron development group, because I believe this software could take over a large part of Nuke compositing if the development would be revived. Natron’s similarity to Nuke makes it a great candidate for a compositing software alternative. Almost all the studios that I talked to expressed an interest in this initiative, and I have also talked to a “large” open source organization that would be interested in taking over Natron development – if appropriate funding is provided of course. I think a “Blender-like” development fund, with some VFX companies behind it, could provide the necessary funds for this.

FX software is another proprietary area. Houdini is fantastic software, but for a small studio like us, it’s expensive, especially that simulations are not our daily tasks. That’s why we’ve started working with Embergen. It’s still not close to the level of Houdini, but it successfully manages many of our tasks. And with the announced updates it will be even more useful.

DP: How do you manage bugs or tool limitations during production? Do you patch internally, rely on community support, or contract developers?
Lukas Remis: We don’t have inhouse developers, so we must rely on the development team behind each software. This can be difficult – for example I’ve reported a Blender bug over 7 years ago – it was about Blender not importing focal length animation of cameras in Alembic format – and it’s still not fixed! I can imagine this is a relatively simple fix, but the bug is a pretty big problem. On Red Poppies we also had some issues with the bear’s fur and alembic caches, but we just found some workarounds. But bugs are a thing, no matter if it’s open source or proprietary software. I have reached out to Nuke’s support several times without getting a solution to a problem. For example with the license server not working properly and they were unable to provide a solution. I can understand a bug in a free software, but certainly not in a crazy-expensive software like Nuke.

On the other hand, I had an amazing experience with the developers behind Kitsu and MRV2. They are very responsive and fast. I was especially blown away with Gonzalo Garramuño, the creator of MRV2. A couple of times he reacted within minutes from posting a bug, and provided a fixed version of the software. I think the open source developers and community are in general more approachable.

DP: What’s your perspective on open file formats like USD, OpenEXR, Alembic, or OpenTimelineIO?  Do they streamline your pipeline, or cause compatibility challenges?
Lukas Remis: Those are a “must”. OpenEXR and Alembic are standard daily-used formats, even to exchange data between different software internally. As for USD, we’ve used it on several occasions, where we needed to exchange 3D scenes with other studios – for example on “Return to Silent Hill”, for which we’ve been mostly building environments, using Blender.

DP: How much custom development went into making your pipeline as a whole work? Are you using off-the-shelf pipeline tools or building your own solutions?
Lukas Remis: Kitsu is great as a management and review platform, but it lacks software integration. So I’ve developed a program, which connects with Kitsu database, using it’s API, and at the same time it manages all our project and media files. It allows us to load specific project versions to DCC software, and submit output for review directly to Kitsu. This was created with Python. I know several programming languages, but I’ve never done anything in Python, so I wrote the software with chatGPT.

Also I’ve decided to have Kitsu installed on our own internal server, which makes it free. But you can also choose Kitsu’s hosting and management, with some monthly fee, if you want to avoid any technical work.

DP: Open source reduces licensing costs – and no licence server means an easy cloud deployment – are you using tools on Cloud or Hybrid infrastructure?
Lukas Remis: At the moment, considering we’re a small studio, I feel more comfortable with on-premise hardware. Especially that it’s hard to calculate the actual costs of cloud solutions – it’s more like estimations. I prefer to invest in our workstations or local render farm, because it’s going to be here and waiting for another project even during a down time. And our workstations are prepared for freelancers to work remotely. But I’ve talked with Mihai Satmarean from skylitetek.com about the possibilities of implementing their cloud solutions, and this will definitely be a thing if we grow bigger or need a quick ramp up. Skylitetek expertise is really valuable because they have experience working with VFX studios and their pipelines, not just delivering some generic cloud solutions.
In the meantime their team has helped us with some network and user management configuration. We don’t have any of the DCC software installed directly on the workstations. We’re using a “central” NAS which is hosting it for all our users. This was a thing I’ve implemented a long time ago, but now we needed to make it more advanced and add an LDAP user management.

DP: How reliant are you on cloud infrastructure? Are you using it for rendering, collaboration, asset management—or all of the above?
Lukas Remis: I’ve used some cloud/online rendering solutions in the past, but currently we’re fully relying on our hardware. Remote artists can connect with our VPN and “stream” a workstation, and they have access to all project data.

DP: How do you find and train artists comfortable with open-source tools like Blender or Gaffer? Is the talent pool growing—or do you invest heavily in onboarding?
Lukas Remis: At the moment Blender is our only open-source app that requires artists to know it. We have amazing Blender generalists, and the software is so popular that it’s not that hard to find new talent. For Red Poppies we needed a senior animator for some of the bear shots, and I’ve reached out to a friend of mine, who’s a Maya animator. He was willing to try animating in Blender, and all he needed was some Youtube tutorial about Blender basics, and introduction to our pipeline. After getting familiar with the interface he said he doesn’t see much difference for the animation process.

DP: Is Imaginary Pixels contributing to the open-source projects you use—via code, bug fixes, or documentation?
Lukas Remis:  As mentioned we don’t have developers in our team, so we can only report bugs. But of course we are financially supporting Blender, Krita or Kitsu. Kitsu also has a nice system for recommending new features, so we can suggest changes based on real-world cases.

DP: Are you planning to expand your open-source pipeline for future projects? Any new workflows—real-time rendering, AI, virtual production—on the horizon?
Lukas Remis:  Of course like everyone we’re thinking about AI and it’s possible applications. However, so far, most of the generative tools that I’ve tested are nowhere near being production ready. The main issue is complete randomness and lack of output control. But the media are completely hyped with AI, presenting it as the downfall of VFX and Hollywood in general :)

We’re using some AI tools integrated with Nuke, and planning to implement some generative AI with ComfyUI.

DP: What are your criteria when evaluating a new open-source tool for adoption? How do you assess codebase health, community size, or long-term viability?
Lukas Remis: The easiest way is to check the software’s GitHub page, and see how many people are contributing to the code and how often. That’s something you never know when using commercial closed-source software.

DP: Open-source projects can be abandoned. How do you hedge against that risk?
Lukas Remis: Yes, there’s always a risk that an open-source project can be abandoned. However, as we have recently seen with Foundry’s Modo, you’re not getting any guarantees with commercial software as well. Modo’s users have not only been abandoned, but also their licences are going to be cancelled. So they won’t be able to even use the old versions. With open-source, the code is still there, even if it’s abandoned. And you can continue developing it by yourself.

DP: How has the shift to open-source tools changed your studio culture—especially in terms of collaboration, experimentation, and problem-solving?
Lukas Remis:  I think using open source software encourages everyone to experiment. There is no “correct way” of doing things, you should always search for new possibilities and stay creative. Our artists often send me links to some new, interesting tools they found, so we can consider if that would be useful for us.

DP: Would you say your current pipeline is fully production-ready—or still evolving? What advice would you give to other studios considering a similar move?
Lukas Remis:  Yes, it is production ready. We’re using it on all our projects. Of course, it’s still evolving, as things that work for us now, might not work when we grow bigger or when we meet different tasks. But the beauty of open-source software is that you can try it for free. If it turns out that a tool is not meeting your requirements, you can just move on, or perhaps help to develop the tool. With commercial software, usually when you invest large amounts of money in some solutions, it might not be possible to just move to something else. Obviously, it’s not possible to be completely open-source when you want to make professional VFX, but there’s a lot of great free software out there.

DP: What good resources are out there to learn more about it?
Lukas Remis:  For Blender, your best source of information will be YouTube and Stack Exchange. And for general information about open source VFX tools, I recommend this page:github.com/cgwire/awesome-cg-vfx-pipeline – it’s an extensive list of different projects, covering any aspect of a VFX pipeline.

DP: What is the next project you are working on (insofar as you can talk about it)?
Lukas Remis:  At the moment we’re working on some Polish projects: a TV series and a feature film: Vinci 2. At the beginning of this year, we worked on several commercials for the Super Bowl, and before that we were focused on Return to Silent Hill, which should have a premiere at the end of this year.

The post Red Poppies, Bears and Open Source! first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

In the course of the “Elemental Week” JangaFX has presented updates – and they look interesting. Here is the keynote:

EmberGen 1.2: Movable simulation domains and mouse recording

Version 1.2 of EmberGen introduces movable simulation domains that allow the simulation volume to be keyframed or bound to objects and characters. An example shows a fire simulation on a character rig, which is supported by the ability to parent emitters to bones. Another new feature is mouse recording. This allows quick test animations by moving an emitter in the viewport, with the results being recorded in the timeline. This function significantly improves the workflow.

EmberGen 1.2 also brings several workflow improvements and bug fixes. The Curve Editor has been reworked and the ability to snap to individual frames in the timeline has been added. The software continues to support the export of data in OpenVDB and Alembic formats and can output rendered flipbook image sequences for game engines such as Unity and Unreal Engine 5.

The minimum requirements are low: an NVIDIA GeForce GTX 1060 or an AMD equivalent is sufficient. EmberGen 1.2 is compatible with Windows 10 and Linux. Prices start at 19.99 USD per month for indie subscriptions, with a perpetual licence after 18 months. More information can be found on the JangaFX website and in the product documentation.

LiquiGen 0.3: New functions for fluid simulations

LiquiGen, the real-time fluid simulation software from JangaFX, is now available in version 0.3 as a public alpha. This version brings a new PIC/FLIP solver that enables more realistic and detailed simulations.

A significant new feature is the Whitewater system, which supports the simulation of spray, foam and bubbles. These particles can be exported separately from the main body of the fluid, allowing targeted control and application of forces. New view options show wave crests or bubbles where whitewater particles are created. Support for surface tension is another important new feature that improves the simulation of liquid splashes. A revised rasterisation renderer provides a practical alternative to the path tracer for production work and now supports refraction and transmission colour.

The overall performance and quality of the simulations have been improved, resulting in an increased maximum particle count and improved meshing and volume preservation. New force nodes such as line force and toroidal force as well as a revised turbulence node are also included. LiquiGen 0.3 is compatible with Windows 10 and Linux and supports NVIDIA and AMD GPUs. Prices start at 19.99 USD per month for indie subscriptions. Further information can be found on the manufacturer’s website and in the product documentation.

GeoGen 0.3: New beta version for terrain artists

GeoGen 0.3, the real-time terrain generation tool from JangaFX, is now available as a public beta. This version offers spline-based terrain control, which makes it possible to define specific features such as mountain ranges, rivers or roads. These splines can branch out and form complex networks that update the terrain in real time. A new directional colour blur system generates surface colour gradients and provides options for terrain detailing, such as layering and blending procedural noise types. Subgraphs support merging an entire node graph into a single node, which helps keep large projects organised.

GeoGen’s key nodes have received updates, especially the Rock and Splatter nodes. Gizmo controls for key nodes make it easier to edit terrain in the viewport. The render engine update increases the level of detail in the preview renderings. GeoGen 0.3 runs on Windows 10 and Linux and supports NVIDIA and AMD GPUs. Pricing starts at 9.99 USD per month for indie subscriptions. For more information, visit the JangaFX website.

Links

GeoGen on JangaFX

Manufacturer page of EmberGen

Documentation of EmberGen

Manufacturer page of LiquiGen

Documentation of LiquiGen

GeoGen Beta Announcement

The post Ember-, Liquid- and Geo-Gen now available! first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

In nuce: Software developer Otoy has revised the licensing model for its OctaneRenderer – by abolishing perpetual licences and previous subscription variants in favour of a single, so-called Studio Plus subscription. This is according to a recent press release.

Cost point: The Studio Plus subscriptions for OctaneRenderer will be priced at either 23.95 euros per month or 239.88 euros per year. Previously, the perpetual licence was priced at 699 euros, while the subscription variants ranged in price from 199 to just under 480 euros per year.

In toto: Studio-Plus offers access to a wide range of assets and software solutions from third-party providers. These software solutions include: the modelling software Mol 3D, the AI-supported animation software Cascadeur, the terrain generation software World Creator, the beta build of the simulation software EmberGenFX ( for which the complete commercial licence is to follow the full version in the course of 2023), the hard-surface modelling toolkit Architron (formerly LWCAD) for Cinema 4D and LightWave, or Otoy’s own Sculptron software for animation caches. Assets included in the Studio Plus subscription include 3D face and body scans from LightStage and kitbashing assets from KitBash3D. Vectron VFX packs will be added throughout 2023.

Click further: All further information on the new payment model can be found at home.otoy.com .

Source: cgchannel.com ( report by Jim Thacker)

The post New pricing for OctaneRenderer! first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.

In nuce: arse in a cinema seat. An explosion on the screen. Then a second, even more bombastic explosion that presses you into the seat leather. Anyone who finds themselves here is sitting in the new Michael Bay after work – and pulling explosions with JangaFX out of the pipeline during working hours. For all bang-and-bang fans: at the beginning of July, JangaFX presented EmberGen version 1.0 in a livestream. EmberGen is a real-time GPU-based tool that allows users to simulate fire, smoke and other particle systems.

What can EmberGen 1.0 do? Perhaps the most exciting new feature announced is the complete overhaul of EmberGen’s GPU particle system! The associated innovations are said to include: a particle trail system, improved particle lighting, flames and smoke emitted from particles, and the ability to export particles to other DCC tools – in Alembic file format. According to the JangaFX roadmap, version 1.0 will be followed by further innovations – including Support for Deep EXR, a completely revised export function, or the ability to import multiple meshes.

Click further: The JangaFX roadmap. In the following one-and-a-half-hour video, interested parties can find out all about the new features of EmberGen 1.0. We last reported on EmberGen on 7 October 2021 , when it went into pre-release with version 0.7.5.

EmberGen 1.0: GPU particle overhaul, learn our most powerful feature ever!

The post JangaFX introduces EmberGen 1.0! first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.

In nuce: Software developer EmberGen recently used a Twitter video to demonstrate the realistic flames that the volumetric simulation tool JangaFX is capable of. EmberGen is a real-time GPU-based tool with which you can simulate fire, explosions, smoke and other particle effects.

What does the Twitter post show? The Twitter post shows you what spectacularly realistic fire simulations EmberGen is capable of. Both fire and particle effects are simulated in the demonstration.

We reported last: We last reported on EmberGen in October 2021, when version 0.7.5 went into pre-release. The pre-release at that time was accompanied by various attractive features – including an improved export function, a revamped user interface, a new renderer and twenty new presets.

Click further: If you want to find outall about JangaFX, you can literally go up in flames by clicking over to jangafx.com . The following video will amaze you, because the release trailer for version 0.7.5 is on fire – and so is the pipeline!

EmberGen 0.7.5 release trailer

The post Here JangaFX demonstrates its fire effects! first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.

New features

The latest version of the engine comes with a number of new features. These include an improved particle simulation, optimised physics performance, more control over landscape terrain details, the Airport and Industrial content add-ons and other features.

For example, with the new Visual Curve Editor, it is now possible to set up the particle parameters more intuitively. This is because the new editor can be used to directly control the different values of the particles. Some of them can be customised via curves. In addition, some new parameters, such as Particle Position, have been added.

Furthermore, Unigine now contains new motion textures. These include vectors that provide smoother animations for sprite-to-sprite transitions. The motion textures can be set up with EmberGen or Houdini.

Feature demonstration

For a list of all the new features, we recommend reading the corresponding Unigine website. One of these new features is the Earthworks demo. A demonstration of this can be seen in the video below:

The post Unigine 2.12 released first appeared on DIGITAL PRODUCTION and was written by Patrick Poti.