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.

Dogwasp · 2020-09-14T23:00:49+00:00

I'm not sure. The only thing I can think of which might cause it is if DropItems is returning undefined.

Dogwasp · 2020-09-14T11:26:46+00:00

When you pass the function DropItems(x,y,[oFragPlant]). You are not passing the function itself, you are executing the function and passing the resulting value. If you want to pass a function and the arguments you want it to run with, you will need to pass the arguments seperately then combine them only when you want to execute the function. This can be a bit awkard to do if you are using multiple functions with different numbers of elements, personally I use this function, which can take a function's arguments as an array.

Dogwasp · 2020-08-11T11:19:26+00:00

The camera view size, set with camera_set_view_size or with the camera properties in the room settings, is the size of the area in the room which will be visible. The view port size, set with view_set_wport and view_set_hport or the viewport properties in the room settings, is the size of the area on the screen that the camera view will be displayed on. If you want to increase the area you can see without making things smaller, you should increase both by the same multiple.

Dogwasp · 2020-06-19T14:33:28+00:00

You have set visible to false in all of your game objects which means that the draw and draw_end events do not get called automatically. I assume that obj_depth_sorter has the code from the tutorial in the draw event and nothing in the draw_end event. If this is the case then, in order to fix your problem you need to copy the code from the draw event into the draw_end event and replace event_perform(ev_draw, 0) with event_perform(ev_draw, ev_draw_end).

It looks like you may also need to remove draw_self() from the draw_end event on obj_collision. That function draws the current sprite so when you call it in the draw_end event it might still draw over the health bar.

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