I have nodes basically adding differences in point positions from one mesh to another -
I can see the mesh updating in edit mode -
However, in sculpt mode I need to exit to object mode to see any upodates:
I that an “just how it works” scenario or can I do anything to allow for seeing my changes while in sculpt mode? If not, are there any plans for this kind of thing to be supported?
Hi,
can anyone explain me why in the world does the UV Unwrap node have margin?!
Right now, Blender is borderline unusable for unwrapping meshes that are not straight up lowpoly, not because the unwrapping in Blender is slow, but because packing is insanely slow, for example:
https://developer.blender.org/T102843
The problem is caused by the fact that pretty much every operator in Blender which does some sort of unwrapping also does packing. There is no separation between the unwrapping step and the packing step.
It’s somewhat (but barely) understandable for the legacy UI operators, but it’s absolutely not understandable for Geometry Nodes:
Since the packing step usually takes order of magnitude more time than the unwrapping step, the workflow here is to wait for Blender to finish insanely long packing step just to provide the user with inferior UV pack, which then has to be fixed by a third party packing addon.
If we can not unwrap without waiting sometimes up to hours for a poor, slow, throwaway pack which is to be replaced with a proper UV pack when using the UI unwrap operators, why can we not at the very least skip the packing step in the GN, which is supposed to provide us with lower level atomic tools?
I can say that when working with Geonodes in Python. Changes I make to attributes via python don’t update immediately and I need to call an update function. This could be something similiar where that update graph isn’t called regularly in sculpt mode.
Currently the Object Info node has the Geometry output at the bottom. If you use node wrangler’s lazy connect it will connect Location to Position. It would be nice at the top like this ^
Hey Devs. Just wanted to say hi and thanks for creating such an amazing toolset in Geometry Nodes.
Here are a couple of bits I’ve been messing with over the last few weeks. There are a few breakdown videos on my channel too:
Think this feedback is worth been mentioned here: https://devtalk.blender.org/t/node-wrangler-geometry-nodes-preview-feature-removed/27568?u=slowk1d
Hi all. Is it possible to sample index at field? Like the sample index node or the field at index node, I’m trying to do the reverse. say I have a discrete set of attributes on a domain and I want to retrieve the index at a particular value of the attribute. I haven’t spent enough time to figure out if it’s possible yet but I assume this should be its own dedicated node. Or maybe it’s a trivial task and I’m just an idiot 
Hmmm this kind of reverse lookup I think would be possible with one of the nodes made by @modmoderVAAAA. I can’t remember the name and I can’t figure out how to search the new repo. What was it again ?
Ah yes, that’s the one. I’m far from being technical enough to understand the other potential applications of this node. The discussion on the diff didn’t help much… would you be so kind as to provide a couple examples ? (imagine I am five years old)
You can have set of some papers with notes of some numbers on face side. On back side of this papers his indices also noted. Now, if you have set of number, you will get paper with this numbers on face side and from back side you can know index of this paper.
Alright, thanks but this is still a bit obscure for me. I’ll wait for some demos of it in action to make complete sense of it
How does it handle if the field has the same value multiple times?
Does it just return the first index with the corresponding field value?
Yes. This is one of the design issues.
For now, we need to manually accumulate groups of overlaped indices and implement another layer of indexes for this.
I see this is not as trivial as I thought. I spent the past couple of days trying to implement this with many nodes but nothing really worked. Time to terminate weeks of work and start something else I guess 
You can recreate this now by finding nearest one, if positing all on indices locations
You mean ‘position all on the search field locations’ I guess?
@Astronet I was thinking about something like that to do this (I think this is what Iliya means):
I am seeing Lukas’ pr for matrix type and operations, as well as the discussion about it, and I’d like to voice my support for it. Direct manipulation of matrices is going to be very much welcome when it comes to node-based rigging. I imagine it would be the backbone of node-based constraints. It is already quite central in other rigging software, where the rigging person can be picky how they mix transforms instead of relying on an obscure combination of hardcoded constraints. And probably a million more things…?
I wonder how a matrix compares to a set of loc rot scale with rotation being a quaternion, in terms of storage ? if each piece in a particle simulation with debris stores a matrix instead, does that make the whole thing heavier ?
Might be wrong but I thought that everything is stored as a matrix. Eulers, local coordinates and all that kind of stuff are just there to make it easier for the user to interact with the matrix.
I meant this question with regard to geometry nodes specifically, and storing matrix attributes on geometry. But as far as I know you’re right
