Tagging to Geometry Nodes so it shows in the project dashboard.

I haven't looked into the code in more depth yet, but it seems like the node could easily share code with the modifier.

@Sebastian Parborg (zeddb) how did you test this?

I plugged a simple volume object (made from a mesh) but I get nothing:

In D10243#257467, @Jacques Lucke (JacquesLucke) wrote:

I haven't looked into the code in more depth yet, but it seems like the node could easily share code with the modifier.

I do agree that we should try to share as much code as possible.
However I did it this way as there are a few smaller differences that could lead to messy code if we try to just quickly separate out the code into a generic function.
The code is basically copy pasted with a modifications to make it work with the node API.

So my plan of attack was:

1. Write the node code
2. Get feedback that it works as we want
3. Refactor the node and modifier to use the same "volume -> mesh" boilerplate code.
4. Commit to master

That sounds ok :)

I wonder if I should take over this patch since you might be working on different projects now?

In D10243#257476, @Jacques Lucke (JacquesLucke) wrote:

That sounds ok :)

I wonder if I should take over this patch since you might be working on different projects now?

Please do if you have time! :)

In D10243#257471, @Dalai Felinto (dfelinto) wrote:

@Sebastian Parborg (zeddb) how did you test this?

I plugged a simple volume object (made from a mesh) but I get nothing:

volume_to_mesh.blend152 KBDownload

You are using the object info node. This means that the object is instanced. We can't read any geometry data from instanced objects yet. That is why it is not working.
To try it out, use the "point to volume" node and plug that into this node.

The code makes sense as far as I can tell, and it works as advertised in my tests. Two comments:

• We can't change the whether or not the mesh uses smooth shading here. That's too bad, but just highlights that we're going to have to properly deal with that at some point.
• Maybe this is a good candidate for going in two categories in the add menu? If we follow the logic that the points to volume is in the volume category, the volume to mesh would be in the mesh category.

We can't change the whether or not the mesh uses smooth shading here.

We could do it in this node. I was just saying that this should not be this nodes responsibility. Also, it is not important for our use case. Besides that, yeah, we have to figure out how to do it in a separate node.

If we follow the logic that the points to volume is in the volume category, the volume to mesh would be in the mesh category.

I see your point, but I don't necessarily agree (although I don't have a strong opinion on that). Currently I think that nodes that are somewhat related to volumes should be in the Volume submenu. That is where I would look. Obviously, putting it in the mesh category or some conversion category would also make sense. This is one node (among many others) that just don't fit into a single category..

In D10243#258518, @Jacques Lucke (JacquesLucke) wrote:

We could do it in this node. I was just saying that this should not be this nodes responsibility. Also, it is not important for our use case. Besides that, yeah, we have to figure out how to do it in a separate node.

Agh, another case of not properly reading the patch description. I agree, a smooth shading option in the node is not a proper solution anyway.

I see your point, but I don't necessarily agree (although I don't have a strong opinion on that). Currently I think that nodes that are somewhat related to volumes should be in the Volume submenu. That is where I would look. Obviously, putting it in the mesh category or some conversion category would also make sense. This is one node (among many others) that just don't fit into a single category..

I don't have strong feelings about it either. It's easy to adjust later anyway.