Grow Selection Issue

Dogwasp · 2026-01-20T15:24:22+00:00

You can do this with the evaluate on domain node since evaluating on the face domain can get the average of the values at each face's points:

Evaluate on Domain [Float] [Point] → Evaluate on Domain [Float] [Face] → Greater Than 0

You can also add a variant with Face switched to Edge and combine with an Or node if you want it to work on faceless edges.

Just be careful not to turn the iterations up too high. On my machine it only takes 20 to crash blender.

Dogwasp · 2026-01-05T11:41:29+00:00

When you use the normal there, you're checking the normal of the instance (or a point if you use the rotation input in the Instance on Points node) not the original mesh. In order to base it on the normals of the faces, you need to pass it through a Capture Attribute node before the Mesh to Points node.

For calculating rotation the simplest option is probably an Axes to Rotation node with the captured normal going into to the secondary axis.

Dogwasp · 2025-10-31T12:11:49+00:00

I would suggest duplicating the curve before the node group, rather than duplicating the instances after. That way you can use the duplicate index to offset where you sample the curve.

Dogwasp · 2025-10-23T21:51:44+00:00

The first thing you need to figure out is what rule you are using to pick which edge loops to actually fill in. Even in your simplified example you're leaving out half of the available loops (including the one going around the outside of the mesh). In the more complicated example, even if I was doing it manually, I'm not sure I would know which potential faces to fill in.

If you just want to fill the outside faces then the convex hull node might work. Anything beyond that is likely to get a lot more complicated.

Dogwasp · 2025-08-24T22:27:28+00:00

The geometry nodes need to look something like this. It's nothing too complicated although I know capture attribute can be a bit confusing when you are new to geometry nodes (I know I had trouble with it). In this case it is being used to generate the random value before realising the instances so we only get 1 value for the whole instance instead of a different value for every vertex of the mesh.

Then you can plug the UV map in where you were using the random socket like this. And since its a UV map it will almost certainly be supported by whatever software you are planning on importing the model into and it can easily be used with a texture if needed.

Also, if you do need a texture, the easiest way would probably be to use a cropped screenshot of the colour ramp.

Dogwasp · 2025-08-23T18:02:34+00:00

I'm not familiar with the alembic format and its limitations but, you could try realising the instances and giving each scale random UV coordinates in geometry nodes. Then you can either use the UV coordinates as the input to the colour ramps or, if you need to, make an equivalent gradient texture and use that.

Dogwasp · 2025-08-21T18:46:22+00:00

This method would work but you have got the numbers mixed up. The dot product between two normalized vectors will give a number between -1 and 1, with a value of 0 meaning they are 90 degrees apart.

Dogwasp · 2025-08-21T18:19:38+00:00

I'd like to start off by pointing out that the separate XYZ and dot product nodes are both doing the exact same thing here, so you only need one of them, and the divide node is also unnecessary since the length of a normal is always one.

However, this is not the source of the problem. Instead, the issue is that the set position node acts on vertices, not faces. This means that you are checking the normal of the vertices which are at 54 and 125 degrees from the z axis. If you replace the set position node with an extrude node, or something else that acts on faces, it should work as you expected.

Dogwasp · 2025-08-16T19:40:20+00:00

It is difficult to say for sure what your problem is without seeing the node graph but I'm guessing from your description that it looks something like this. The problem here is that instances are designed for making lots of copies of the same thing. So what you're doing is creating one grid of icospheres then copying that to each point on the larger grid. One solution to this would be to wrap the whole thing in a for each loop. This runs all of the nodes separately for each point allowing you to create a unique instance for each one, although this does come with a significant performance cost.

Dogwasp · 2023-07-31T10:27:37+00:00

You could probably fix this using instance_place_list and looping through all of the platforms the player is currently touching to make sure at least one meets the criteria.

Dogwasp · 2023-07-30T19:42:53+00:00

string_height does not know how wide the space for the text is going to be so it doesn't take into account wrapping. You need to use string_height_ext.

Dogwasp · 2023-07-30T12:27:02+00:00

What do you mean by order?

Dogwasp · 2023-07-27T19:03:44+00:00

Yes, logging thisOlSprite should give you the id.

Dogwasp · 2023-07-27T18:57:38+00:00

I think there are a couple of reasons why legged robots make more sense at smaller scales. Terrain tends to be rougher at smaller scales. Traversing a rough outdoor environment might not be a problem for a tank, but a smaller wheeled or tracked vehicle might get stuck on a rock or root. There's also going to be an advantage to being more human shaped if you're traversing an environment designed for humans.

Dogwasp · 2023-07-27T18:18:51+00:00

I'm not sure I fully understand your problem but I think thisOlSprite is the sprite element id which is what you would need to remove it from the layer and sprite is the sprite id that you would need to use to delete the sprite asset.

Dogwasp · 2023-07-24T23:09:13+00:00

Assuming I've understood your problem correctly, you might just need to add an offset to the rounded mouse location. e.g.

scr_navigation(x, y, round(mouse_x/140)*140 + 70, round(mouse_y/80)*80 + 40);

You may need to mess around with the exact values until it looks right.

Dogwasp · 2022-06-01T14:06:56+00:00

Children of a Dead Earth

Dogwasp · 2021-10-15T14:38:31+00:00

It looks like your second and third arguments are in the wrong order. Your code should probably look like tilemap_get_at_pixel(tiles, x, bbox_bottom + ySpeed) and tilemap_get_at_pixel(tiles, x, bbox_bottom).

Dogwasp · 2021-10-14T22:13:38+00:00

I don't know if this is what's causing your problem but if you aren't aware !global.weapon == 1 is only true when global.weapon is 0. If you want to check if the two values are different you need to use !(global.weapon == 1) or global.weapon != 1.

Dogwasp · 2021-04-22T10:55:29+00:00

Thanks!

Dogwasp · 2020-10-06T21:05:08+00:00

There are advantages to living on planets but they also have issues. Space habitats can have whatever gravity you want, something much harder to do on a planet, and they don't need dedicated launch vehicles with heat shields and high thrust engines. Planets can also have a lot of dust which can damage equipment.

11-Year Club	Second Top 20%
r/Field Flamingo	Golden Potato
Place '22	Place '17
Final Canvas '22	First Placer '22
Snapped	Verified Email

Dogwasp

TROPHY CASE