An experimental temporal ghosting / long-exposure toolkit for TouchDesigner, built for turning prerecorded and real-time footage into smeared, split-exposure, echo-like motion.

The system layers delayed frames, masks the active subject region, and adds optional feedback persistence to generate distorted portrait, face, and full-body trails that sit somewhere between long exposure, temporal rupture, and spectral motion blur.

This release also includes:

— a custom FLUX-2 LoRA trained on experimental photography [the one used in this demonstration]
— the pertinent ComfyUI workflow for FLUX-2.dev + LoRA text-to-image generation

Available now through my Tools Store.

Both music and visuals by myself, deeply inspired by the recent BoC-related events.

With VFX graph you can render nearly infinite grass since they are just particle looks like grass living on gpu.

There are 5 million individual grass blade in the video with 120 fps

I've been experimenting with local 3D AI more lately, and I honestly think TRELLIS 2 + UltraShape 1.0 is one of the strongest free local combinations available right now.

The biggest reason is that the two models solve different parts of the problem.

TRELLIS 2 works as the main image-to-3D generator.

It can generate:

• complex 3D geometry from a single image
• thin and open surfaces
• detailed shapes with fairly complex topology
• full PBR materials
• textured GLB assets that are already easy to move into a normal 3D workflow

But another huge advantage of TRELLIS 2 is the community around it.

There are already several alternative ways to run it locally:

• the original Microsoft implementation
• community C++ / GGML implementations
• GGUF / quantized versions aimed at making local inference more accessible
• CUDA and Vulkan implementations
• multiple ComfyUI nodes and workflows

So you don't necessarily have to use the original heavy Python setup forever.

If you already use ComfyUI for image generation, upscaling, segmentation or other AI workflows, TRELLIS 2 can basically become another node in the same pipeline instead of a completely separate application.

Then you can add UltraShape 1.0 as the geometry refinement stage.

UltraShape takes a reference image together with an existing coarse mesh and focuses specifically on improving the geometry.

That means a practical pipeline can look like:

reference image → TRELLIS 2 → UltraShape geometry refinement → TRELLIS 2 / other tools for PBR

TRELLIS gives you the initial 3D structure quickly.

UltraShape then gets another chance to reconstruct the small forms and geometric details that the first generation missed.

And this is probably the part I like most about the combination: you're not asking a single AI model to somehow solve generation, geometry and materials perfectly in one pass.

You're splitting the workflow into stages and using a model that is good at each stage.

For local generation the advantages are pretty obvious:

• free generation
• no credits or subscriptions
• no API cost per model
• everything can stay on your own machine
• you can iterate as much as your GPU allows
• TRELLIS 2 already has a pretty large community ecosystem
• ComfyUI makes it possible to build much larger automated workflows around it
• UltraShape gives you a dedicated second pass for geometry instead of accepting the first mesh as final

Commercial generators are still much easier if you just want to upload an image and get something back in 30 seconds.

But if we're talking specifically about free + local + customizable 3D AI generation in 2026, TRELLIS 2 + UltraShape is probably the setup I'd start with.

UltraShape:
https://pku-yuangroup.github.io/UltraShape-1.0/

TRELLIS 2:
https://github.com/microsoft/TRELLIS.2

I've been experimenting with AI-generated characters lately and wanted to see how far I could push facial expressions while still keeping everything usable with native Unreal Engine tools.

I built the character as 4 separate parts instead of trying to generate everything as one mesh, which gave me much more control over the final result.

For the 3D generation I used 3DAIStudio to generate all of the character parts. What I liked here was being able to switch between different 3D AI generators in one place depending on which model handled a specific part better, rather than constantly jumping between separate platforms. I also generated the reference images directly inside 3DAIStudio, so most of the early concept-to-3D workflow stayed in the same place.

After that I brought everything into Blender, assembled the parts and did the usual manual cleanup and geometry fixes.

One thing that surprised me was baking the high-poly details onto the generated low-poly character. It worked much better than I expected, and the final result ended up at around 34k triangles while still keeping a lot of the original detail.

The facial setup was definitely the harder part.

I created 58 different facial expression references and used them as a guide for building the blendshapes. It still needed a fair amount of manual work, but generating the head with an open mouth helped a lot with preserving details around the mouth, teeth and inner geometry.

Finally, I brought the character into Unreal Engine / UEFN and used Control Rig for the animation setup, so the finished character still works inside a pretty normal Unreal workflow.

I Compared 3 AI Retopology Tools: Tripo vs Rodin vs Free Hunyuan3D

I wanted to see how current AI retopology tools handle something more complicated than a basic character.

For the test I used the same character with a mix of different shapes: organic parts, clothing, a backpack, staff and some more hard-surface-like elements.

Same source model and the same general conditions for all three.

Final mesh:

• Rodin: 35K faces
• Tripo: 46K faces
• Hunyuan3D: 66K faces

Polygon count

🥇 Rodin — 35K
Rodin was the most aggressive with optimization. It managed to simplify a lot of areas while still keeping the character recognizable and most important shapes intact.

🥈 Tripo — 46K
Tripo kept noticeably more geometry than Rodin, but a lot of those extra polygons seem to be used more intentionally around important shapes and transitions.

🥉 Hunyuan3D — 66K
Hunyuan preserved a huge amount of the original geometry. That's good for detail preservation, but not so good if your main goal is actually reducing the model.

Shape & detail preservation

🥇 Hunyuan3D
This was probably Hunyuan's strongest point. It tries to preserve almost every shape and small element from the source model.

The downside is that it doesn't really decide what needs to stay geometry. Details that could easily be represented with a normal map or texture often remain fully modeled.

🥈 Tripo
Tripo found a pretty good middle ground. Most important forms survived, while some unnecessary smaller details were simplified.

It loses a little more compared to Hunyuan, but the result feels more optimized rather than simply copied.

🥉 Rodin
Rodin simplifies the model much more aggressively. Major silhouettes and important forms are still there, but smaller shapes and secondary details can get noticeably reduced.

That's partly why it managed to reach the lowest polycount.

Topology quality

🥇 Tripo
This was the strongest result for me.

The topology feels much more intentional. Different elements are logically separated and the edge distribution generally makes more sense around the actual forms.

Out of the three, this was the closest to something I would expect from a manually planned retopology workflow.

🥈 Rodin
Rodin's topology is surprisingly decent considering how aggressively it reduces the model.

The main problem is that some areas still feel like one continuous remesh rather than topology designed specifically around individual parts.

Still, it's relatively clean and very usable for an automatic result.

🥉 Hunyuan3D
Hunyuan feels much closer to a traditional quad remesh.

It follows the source surface very closely, but doesn't seem to make many decisions about where geometry could be simplified or where topology should be structured differently.

Good surface preservation, weaker actual optimization.

Generation time

🥇 Tripo — ~1 min
Very fast. For iteration this is probably the biggest advantage because you can test multiple versions without waiting much.

🥈 Rodin — ~3 min
Still fast enough for normal production use. Slightly slower than Tripo, but considering the lower final polycount, the result is pretty reasonable.

🥉 Hunyuan3D — ~5–10 min
Definitely the slowest in my tests. Not terrible, especially considering it's free, but it becomes noticeable when you're testing multiple models.

Price

🥇 Hunyuan3D — Free
This is obviously its biggest advantage.

You can get a fully retopologized quad mesh without paying anything, which makes the result pretty impressive despite its weaknesses.

🥈 Rodin
Rodin sits somewhere in the middle for me. You pay for the generation itself, but the result is generally predictable and already fairly optimized.

🥉 Tripo
Tripo gave me the best topology, but it can become the most expensive when experimenting.

You're effectively spending credits on attempts, so if you need several generations to get the result you want, the cost starts adding up.

UVs

🥇 Rodin
Rodin produced the cleanest UV layout in this test.

The islands looked relatively organized and usable without immediately feeling like they needed to be completely redone.

🥈 Tripo
Tripo's UVs were still usable, but not as clean or organized as Rodin's.

For quick production they would probably be fine, but I would still prefer Rodin here.

🥉 Hunyuan3D
The UV result was the weakest of the three.

It works, but just like the topology itself, it feels more automatically generated and would probably need more cleanup for a serious production asset.

So for me:

Paid: Rodin 🥇
Free: Hunyuan3D 🥇

NVIDIA just released MotionBricks, a generative framework for real-time character animation.

A single neural backbone handles more than 350,000 motion clips while reportedly reaching 15,000 FPS with 2 ms latency.

Instead of manually building huge animation graphs, MotionBricks uses “smart primitives” to combine locomotion, style changes and interactions directly inside Unreal Engine 5.

• Walk, run, strafe and switch styles in real time
• Pick up objects, sit, fall or jump over obstacles
• Generates approach, contact and follow-through automatically
• No manual motion blending or hand-authored transitions in the UE5 demo
• Works with both game characters and humanoid robots

The best part is that you can already start experimenting with it in your own projects today. NVIDIA has released the code and pretrained checkpoints, giving developers a new way to create more responsive, natural character movement and make games, simulations and virtual worlds feel much more alive.

The initial code, pretrained checkpoints and training tools are already available.
source; https://nvlabs.github.io/motionbricks/

manic is a tiny language for making animations. You write a short text file; manic renders a smooth, glowing video. No timeline scrubbing, no keyframes by hand — you describe what’s on screen and when things happen, and the engine does the rest, deterministically.

• Try manic
• manic docs

Manic Animation code

// glsl-fractal-nebula — a twigl-style 3D fractal fold as a soft gold dawn field
// with blue frost-ferns (raw `glsl`, accumulated into a LOCAL vec3 — the `o.rgb +=`
// in-loop idiom miscompiles on the Metal backend), and a murmuration `cloud`
// sweeping across it: a per-pixel field and a particle system sharing one frame.
// Both pure in (pixel/i, t), so the whole scene scrubs and records.
//
//   manic examples/glsl-fractal-nebula.manic
title("A fractal dawn, and a murmuration");
canvas("16:9");
template("black");

glsl(scene, `
mat3 rotate3D(float angle, vec3 axis){
    axis = normalize(axis);
    float s = sin(angle), c = cos(angle), oc = 1.0 - c;
    return mat3(
        oc*axis.x*axis.x + c,        oc*axis.x*axis.y - axis.z*s, oc*axis.z*axis.x + axis.y*s,
        oc*axis.x*axis.y + axis.z*s, oc*axis.y*axis.y + c,        oc*axis.y*axis.z - axis.x*s,
        oc*axis.z*axis.x - axis.y*s, oc*axis.y*axis.z + axis.x*s, oc*axis.z*axis.z + c
    );
}
vec3 hsv(float h, float s, float v){
    vec3 rgb = clamp(abs(mod(h*6.0 + vec3(0.0,4.0,2.0), 6.0) - 3.0) - 1.0, 0.0, 1.0);
    return v * mix(vec3(1.0), rgb, s);
}

void mainImage(out vec4 o, in vec2 FC){
    vec2  r = iResolution.xy;
    float t = iTime;

    vec3  col = vec3(0.0);            // accumulate here, not into o
    float i = 0., g = 0., e = 0., s = 0.;
    for(int n = 0; n < 98; n++){
        i += 1.0;
        vec3 p = vec3((FC.xy-.5*r)/r.y*5. + vec2(0,9), g)
               * rotate3D(-1.1 - cos(t*.15)*.1, vec3(1, 11.+sin(t)*.15, -1.5));
        s = 2.;
        for(int j = 0; j < 19; j++){
            s *= e = 7.1/dot(p, p*.51);
            p = vec3(.08,4,-1) - abs(abs(p)*e - vec3(3,4,3));
        }
        g += p.y/s;
        s = log2(s)/exp(e);
        col += .01 - hsv(.1, g*.016 - e*.3, s/2e2);   // original's o.rgb += …, into the local
    }

    o = vec4(col, 1.0);
}
`);

// a murmuration sweeping across the still dawn field — a cohesive blob of birds
// (golden-angle scatter, denser core) whose centre sweeps a path, stretched along
// motion and banked into each turn, breathing organically. Pure in (i, t).
cloud(flock, 9000, #e8f6ff, 0.8) {
  let s = i/9000;                              // 0..1 through the flock
  let ang = i*2.39996;                         // golden-angle scatter
  let rad = sqrt(s);                           // wispy toward the edge
  let sw = ang + rad*3*sin(t*0.5) + t*0.6;     // the interior swirls (shape-shifting)
  let taper = 1 - 0.45*s;                      // tail thins out
  let ex = rad*cos(sw)*235*taper;              // elongated along motion…
  let ey = rad*sin(sw)*88*taper;               // …narrower across
  let turb = 70*rad*rad;                       // tendrils: turbulence grows at the edge
  let bx = ex + turb*sin(i*0.7 + t*2.2);
  let by = ey + turb*cos(i*0.9 + t*1.9);
  let phase = t*0.45;
  let cx = 640 + 330*sin(phase);               // the flock sweeps left↔right…
  let cy = 250 + 80*sin(phase*1.6 + 0.7);      // …rising and dipping
  let bank = 0.6*cos(phase);                   // and banks into each turn
  let rx = bx*cos(bank) - by*sin(bank);
  let ry = bx*sin(bank) + by*cos(bank);
  let grow = tanh(t*0.6 + 0.1);
  let x = cx + rx*grow;
  let y = cy + ry*grow;
  let hue = mod(210 + s*14 + t*5, 360);
}

wait(12);

These are fractal flames, the Draves algorithm, but the engine is written from scratch in Metal rather than built on flam3. The reason was that I wanted them running live, not rendered out: on the Mac these are the actual desktop wallpaper.

Two things in here that took the longest to get right, if anyone is interested:

Metal has no float atomics, so the histogram accumulates in u32 fixed point at a colour scale of 64 and the tone map divides it back out. And the motion drifts the GENOME rather than the camera. Rotating a roughly symmetric cloud barely changes the picture however fast you spin it, so instead each transform's affine matrix rotates on its own slow sine with a golden-angle phase offset. That is what makes them breathe instead of just turn.

There are 16 of them rendering live in a browser here, WebGPU, no signup, and each one has a share code you can copy:

https://atheria.app/flames

The iOS app is free and has the flame editor plus an MSL editor if you want to write shaders on a phone. Here is a share code for the fourth one in the video, paste it into the flame editor to keep it:

Fourfold Disc-Swirl Trio - a living flame from Atheria

ATHERIA-FLAME:2:rZRNb9swDIb/SqFelYCSKJHMbU1a7LzusA/sYKTOZiCJC8dbBwT576OUZbG7Dc2A6USRlN6HNOW96btqu1u13WZnZh/3Ztmu2+7+sa4fzAym0ZpvVddUfdNuNb43nL0M0SUK1oS8c4IcfOKDNdVq1WxrvUe9STyysxOYpggRRWK2xQtTTHbgHeViAEAJn+wRRO+35qluPn/pzcxPI8UAGA72Mk4VwoigQQd57zFEjBLHpNGH6IkzRwTwsZichCJTRhp4T6kFNHl0OACdhuPCM7GekBBZgC5AzoxujJYg+ECYewQuUHIg7oikJF6yefaP0il7SWjIl8qiIR6jRySXLsCjUqKWL4lPDU1IXjWH0Lk1CTl5Lh3V1iHlT5BRmSiRx1LBMPDrwLE00BGIZ3A3BCYHjuj3CXhO+7yXNNVhI6knoCraK+vs0AV/HDinAxc4yL/LqcRET4PON6sAZcHhNiP8Z0mnD1FfEbtSUC5RRcbOlyQ1/Fit676vX9ff9UpzLa84zG+MNddBPOE8W3e3wLeLYi38zVyMHlOGap2pXkLWEfr520AWr09jPPDCgMmlVCZBkn7tELSS4eac85dy9MZG1Y0SLqvN/F2JqvWm7U/mh7bdFBZO+rDdMfF9iW6rjaKYu/Zrt2rXD1eLZrec3D813frqbde05vAD

To bring it to life: copy this whole message, open Atheria's Flame Creator, and press Paste Code.

Hi folks,
I realized that the SSAO implementation from LearnOpenGL had become a real bottleneck in my renderer.

I was getting around 45 FPS, so I profiled the pass and made a few changes:
● Reduced the SSAO framebuffer resolution
● Got rid of position/depth reconstruction
● Reduced the kernel size

After the changes, I’m getting around 77 FPS with very little noticeable visual difference.
45 FPS → 77 FPS just by making the SSAO pass do less work.

It’s a good reminder that tutorial implementations are great for learning, but once you’re building an actual renderer, you eventually have to question every piece of work you’re asking the GPU to do.

Github: https://github.com/xms0g/abra

https://www.deviantart.com/pgmatg/art/fractal-Fractint-Mini-Mandelbrot-raytrace-1364505683