Is it possible to flip the normals of a metaball?

I’m creating this model of the Pokemon Reuniclus, and I realized it’d work much better if I modeled it slime parts with metaballs, but part of the slime texture I made uses one model with a normal slime material for the parts covering its body and another model with a less transparent slime, but one that uses backface culling so that it’ll only appear behind the internal body. However, I don’t know how to flip the normals of the slime using metaballs, if it’s even possible. If it’s not, is there an addon for it? And if there isn’t that either, is there some sort of workaround just in material nodes?

Even though I feel like the issue is simple enough here’s some pics anyway lol

Here’s the model with the metaballs and the normal material

And here’s the mesh model with the normal material and the backface culling material, personally a major upgrade IMO even though it doesn’t deform as well as the metaballs would

Here is one version… Best in Cycles as there is too much noise in EeVee.

Metaballs is very basic old stuff.
Contrary to meshes, there is no normal editing in Edit mode or normal editing modifier support.
Metaballs don’t support any modifier.

But metaballs are supported by Geometry Nodes.
That means that you can add a GN modifier on a mesh that will replace mesh geometry by metaball geometry.
You just need to use an Object Info node to retrieve metaball geometry and a Flip Faces node.

Thanks for the reply! It’s mostly worked, however for some reason when the original metaballs are visible they overwrite the material somehow.

Here’s what it looks with only the geonodes model visible (honestly pretty good on its own):

However, once I make the original metaballs visible again, even though the material is transparent the geonodes model isn’t showing through like it should

I’m not really experienced enough with geometry nodes but I’d have to guess it’s still overriding the stuff being inserted into the geonodes even with the set material node I put in

Yes. That is the downside of this workaround.
You have to hide the original metaballs in render.

I thought that could be possible to hide original metaballs in render, and keep them in viewport for animation.
But I neglected that F12 render is requiring metaballs to be visible in Render, to be used by geometry nodes.

So, you have to precise material through geometry nodes, as you did.
Plus, you have to assign a different, totally transparent, material to original metaball, to render it invisible.
That material should be overwritten by material node, precising pretty material, for geometry nodes mesh. So, GN metaball with inversed normals should be rendered correctly ; and original metaball should be invisible, transparent.

Thanks, that does seem to work as you say… But I somehow managed to find a perfect solution? Just by accident?

So at first I realized that when I hid the metaball being referenced in the geonodes it looked like this in the render, where the ball I hid is gone but the rest of it is somehow working exactly as I want. Don’t know why.

So then I thought, if it works when that ball is hidden, can’t I just copy another ball and put it in its place? And sure enough, that does actually work perfectly

This is what it looks like in the viewport though, where it’s weirdly bulged because of the overlapping balls and the materials don’t work, but frankly I don’t care cuz it works in the render. You can see the first metaball is hidden in the render (and if I hide it in the viewport, it still looks bulged, but only shows the backface material

So uh yeah anyway I have no idea how to explain what’s going on here but it doesn’t matter because it works!

So while this worked for a neutral pose, for some reason when I move any bone using the rig it all looks normal in the viewport, but when I go to render it looks like this. This is the geonodes mesh following as normal but the metaball version sliding out of place.

Which doesn’t really make sense, since the way I rigged it was that I parented every metaball to the bone closest to it, each individually… so not rendering one of them logically shouldn’t affect the others. If anything, the geonodes version should be messed up, as if the rig is applying double the movement to it (one for the movement of the balls and one for its own movement) but it’s the only one that’s working here.

Since this is more of a weirder issue, here’s the .blend file with the idle animation I was working on.

Reuniclus.blend (4.6 MB)

EDIT: An even stranger developement, I rendered the faulty animation to see if that makes it more clear what’s going on, but the still image renderer and the animated renderer are giving different results even though I honestly thought the animated render was just rendering still images without any extra bells and whistles, and just strung them together

In the animated render, it looked only as if the arms/other extremities just weren’t following the rig, but with the still image it looks more like the torso and everything attached to it is somehow just lower (although the first frame somehow is normal?)

ANOTHER developement, I rendered the above animation as a video file (as in, not frames) but then I tried to render the animation as frames and it gave ANOTHER different result, where the first frame was broken but the rest of it was messed up like the non-animated render was

For reference, here’s the first frame of the animation rendered as frames:
ReuniclusIdleX0000

But here’s the same first frame if I rendered only the single image alone, which is exactly what I’m aiming for (but later frames are messed up even when rendered this way):
image

I guess Blender really doesn’t like metaballs huh

Kind of found a solution, more just a workaround

I created a separate geonodes mesh that just uses the other slime material instead of the backfacing one. At first I tried this and thought it didn’t work because it didn’t show the backfacing slime underneath the normal one, but then I switched the setting of the normal one from Alpha Blend to Alpha Hashed and for some reason that worked, although I also had to put it through a denoiser in the compositor. Don’t know why I had to do that now, even though it worked with the normal mesh I made first, but whatever. For now, I’ll take it.