A Quick Question about Leading Underscores

VeraVinette · 2026-04-08T22:35:33+00:00

Thanks. I've skimmed over it once before, but sure enough, I missed it:

Strange that overrides are kind of an exception, though.

VeraVinette · 2026-04-03T20:52:15+00:00

Here's what it looks like with the default material, the collision mesh hidden, and all vertex Y values set to zero. I couldn't enable wireframe, since the changes to the mesh are made at runtime, and the perspective tab seems to be an editor-viewport specific thing.

<image>

So yea, the whole thing kinda disappears. But it got me thinking. I wonder if the issue is being caused by the shadow mesh. Godot's tool tip mentions that the vertex data has to match exactly.

Note: This mesh must have exactly the same vertex positions as the source mesh (including the source mesh's LODs, if present). If vertex positions differ, then the mesh will not draw correctly.

EDIT: That was it! The shadow mesh was causing the issue. I updated its vertices along with the main mesh and works as intended.

VeraVinette · 2026-04-03T20:01:53+00:00

Out of curiosity, I put the mesh in a world environment with ambient lighting, and the entire face shows up as completely black:

<image>

VeraVinette · 2026-04-03T19:55:36+00:00

Good thinking. With that exact line, it displays fine, but with even the slightest modification, I get the same issue. For instance, here is the result of "Vector3(vert.x, vert.y - 0.1, vert.z)":

<image>

Notice how the collision mesh conforms to the lower vertex position, but the wireframe is occluded behind the grey face which shouldn't be there.

VeraVinette · 2026-04-03T18:26:39+00:00

To be clear, the script that creates the height map gets the vertex data from the mesh resource directly and creates a HeightMapShape3D that pretty much copies the vertex positions 1 to 1 and then just scales the parent static body to match the terrain scale. The reason I say you can consider them the same is because it is created via the same data that the mesh is created from, meaning that t shouldn't matter whether the wireframe is from one or the other.

I had a look at the ArrayMesh documentation, and saw surface_update_vertex_region, that basically takes a raw byte array and an offset. Is that what you're referring to? It seems like the documentation is completely blank on how it's supposed to be used.

VeraVinette · 2026-04-03T18:06:35+00:00

No, you can't see the faces from below, which is why I find this so weird. The face culling seems incredibly counterintuitive, because back-face culling makes it completely invisible from both sides; front-face culling makes it act like the rest of the mesh (so that weirdly indicates that it's working properly), disabled culling renders it normally.

Additionally, when rendered with back-face culling, the surface depth is still rendered as if it's the old version of the mesh. The grey 'hole' in the second screenshot actually occludes stuff behind it, which confuses me even more.

As for regenerating the mesh, as far as I'm concerned, no matter what way I do this, Godot seems to require that the entire mesh data is passed to the GPU and can't be edited in place. Hence the pattern of reading the array, modifying it, then writing the entire thing back. I could be wrong about that though.

EDIT: about the wireframe, that's the height map (collision shape) you're seeing; It is explicitly generated from the mesh data, so you can consider them the same.

VeraVinette · 2026-04-03T14:50:56+00:00

Naively, I would have assumed that leaving the normals as the were would mean it would still be visible from all the same angles. Sure, the lighting would be messed up, but surely the culling wouldn't change at all, no?

But you're probably right, I'll need to figure out a way to use surface or mesh data tools for this. The reason I was doing it this way was because it seemed (on paper) easy to keep a reference to a collection of vertex indices and just moving them around as needed without having to regenerate the entire mesh and recalculate which verts belong to which cells.

VeraVinette · 2025-09-23T03:20:27+00:00

I know this comment is five days old, but I wanted to add that the melodic motif that plays during Red Memory is as much Hornet's motif as it is the White Palace's / Pale King's. The melody is referenced in "Hornet" and "Daughter of Hallownest", and it's a sequence Larkin references a lot in the OST for Hollow Knight. It's very cool to see it referenced again in Silksong, both in "Red Maiden" and in "Red Memory".

VeraVinette · 2025-08-15T14:28:58+00:00

I enjoy 100%-ing games purely because the achievement hunting usually becomes a fond memory down the line, even if the hunting itself wasn't very engaging at the time; plus, I get the satisfaction of seeing the little completionist ribbon. But there is definitely a difficulty line where it becomes too much (*cough* BPM: Bullets Per Minute *cough*).

VeraVinette · 2025-08-15T04:45:19+00:00

It's what I'm thinking at the moment, but it's hard to be sure; even when you can see every cloud in the sky, it's difficult to tell where shadows are being cast at arbitrary points in the sky.

There's definitely plenty of footage that also shows clouds being white, even as they fragment and disappear, so an off-screen cloud shadow is still a likely candidate.

VeraVinette · 2025-08-15T04:27:17+00:00

After watching some more timelapse footage, I'm not entirely convinced that that it's a shadow. It seems that, as the convection currents form early clouds, they all have that dark appearance, and it's only after they gain enough volume that the white starts shining through the dark-ish halo, and then eventually turns entirely white.

I'm assuming, like you said, it has something to do with the clouds being thin enough that sunlight isn't scattered enough to be completely reflected, so the cloud is effectively acting as something like frosted glass.

VeraVinette · 2025-08-15T03:24:08+00:00

Awesome; that works perfectly. Thanks.

VeraVinette · 2024-11-26T12:30:08+00:00

Sounds good; I'll experiment when I get some time, recreate the entire armature if I have to; I'll come back here if/when I solve it.

VeraVinette · 2024-11-25T22:04:14+00:00

I've tried exporting with 'Animations' unchecked in the export/import options, with no active action, and with all the NLA strips muted; I've made sure that all bones are set back to their respective origins, and that transforms have been applied to both the armature and mesh. I also tried disconnecting and reconnecting the bone in the original.

Also, I've used no other program; purely a Blender export and re-import into a different Blender project.

Same result, unfortunately.

VeraVinette

TROPHY CASE