I would like to get the location/position of a node (geometry SOP) inside a “Pop Attract” node's VEXpression code block.
each point is @P yes…
but some other object from it's path /obj/null1 etc.

Could be from…
http://www.sidefx.com/docs/houdini13.0/vex/functions/ [sidefx.com]
that there is this…
http://www.sidefx.com/docs/houdini13.0/vex/functions/prim [sidefx.com]


float targX = prim(“opobj/null1”, “tx”, 0);
float targY = prim(“opobj/null1”, “ty”, 0);
float targZ = prim(“opobj/null1”, “tz”, 0);
vector targ = (targX, targY, targZ);
float dist = distance(@P, targ);
printf(“targPos: %s\n”, targ);


Unfortunately this just returns 0 which means it failed.
so Null's have no Primitives or something?

I tried “P” on a torus even though it's clearly tx ty tz in the parameter inspector and it almost seemed to work but not reliably? something there one second and gone the next.

Ya if I put
vector targ = prim(“opobj/sphere/sphere1”, “P”, 0);
printf(“targPos: %s\n”, targ);

VEXpression code into the AutoDopNet's attrack_source_particles
it might put out something like.
targPos: {0.0333333,0.0458794,-0.180087}
but it's real position is 2.033 1.462 2.157
weather I follow the null1 via Path Object or parenting this value gotten via prim is wrong and unchanging? so this does not work.

I'm assuming it's the first point of the geo and unaware of the frame.
So it finds the first point if you drop the sphere1 and even if you use /obj/null/point1 it also defaults to an unmoving point at 0,0,0
changing the position of point0 in point1 does not result in my expectations either?! nor adding points in null and priming the other items.

You're only getting the local space positions. If you want the world space position then you need to multiply it by world transform of the owner object. eg. using optransform() for example.

I'm looking at the
/obj/AutoDopNetwork/attract_location_particles/sopnet1
for insight and thinking this looks like a complete mess to me?
It seems to be promoting Detail attributes to “P” and “v” on the primitive level?
but of @OpInput2
definitely lost here.
There are so many nulls ans switches disorganized and tangled together it really can't be the most efficient bit of work in houdini.
switch1 has null2 in it twice and that null has only a switch with a switch? It would seem the one null isn't even needed and two switches could be one but I'm just a beginner.
Still even or maybe only the likes of Socrates might have us rethink this one guys.

If I Google
houdini +dopnodeobjs
there are no results?
If I could turn this into a question how about for starters.
Why is the documentation hidden from Google for “dopnodeobjs”?
I guess I don't understand Google?
http://www.sidefx.com/docs/houdini13.0/expressions/dopnodeobjs [sidefx.com]
Maybe it's hidding because it's replaced by things like…
http://www.sidefx.com/docs/houdini13.0/hom/hou/DopSimulation#objects [sidefx.com]
but version 13 is still using messy legacy code like what we see here in an attract_location_particles/sopnet1

Searching something like opstreamname also leaves one with little to go on.

edward
You're only getting the local space positions. If you want the world space position then you need to multiply it by world transform of the owner object. eg. using optransform() for example.

looking now…
http://www.sidefx.com/docs/houdini13.0/vex/functions/optransform [sidefx.com]
Oh thank you for helping!
In the meantime…
I guess my next question would be how do you get the position from a transform matrix?

okay well that's definitely helping in this case…

vector targ = prim(“opobj/sphere”, “P”, 0);
matrix tm = optransform(“opobj/sphere”);
printf(“targPos: %s and %s\n”, targ, tm);
float dist = distance(@P, targ);
forcescale = dist * dist;
printf(“fs:%f\n”, forcescale);

Wait my original code is partly resolving somehow?

vector targ = prim(“opobj/sphere”, “P”, 0);
float dist = distance(@P, targ);
forcescale = (dist * dist) * 2;
if (forcescale < 0.2) {
forcescale = 0.0;
}
printf(“fs:%f\n”, forcescale);

I'll need to experiment more.
The irony is all I really wanted was for the particle attraction to a geometry/sop or null to have diminished strength as it gets closer so there's no bouncing spring effect. squared etc. what exists for that without using chops or something odd and also overly complicated?

okay so my original thing was partly working there was another attractor in there for some reason causing confusion.
I've added similar code to the popdrag1 node below the attractor.

vector targ = prim(“opobj/sphere”, “P”, 0);
float dist = distance(@P, targ);
airresist = (6 - pow(dist, 3));
if(airresist < 0) {
airresist = 0;
}
printf(“ar:%f\n”, airresist);

So then how one would access the this other popdrag node, from the VEXpression (of the other attractor node) to avoid redundant calls to the same code (for getting the distance in this toy example).

{rant begins}
It's my real major burning question that's been plaguing my mind with this stuff (on and off) for years now.

I've mostly learned to resort to using python module globals to store something like that, but it's an ugly block of code to set and extract too.
That and some really lame justification that it's never slower then rendering to call the same (sometimes rather lengthy pass through say all particles) over and over for every value you might stamp to copies or whatever.
So then I look painfully pretty much without success for a place to put the script block before things in the node tree. For instance with a primitive like a sphere if some complex code was needed to calculate the primary parameters that node does not have an input (to plug a script node before it ~ maybe with a merge - script first input?) and so you have to rig one parameter to call a python module script to set globals and then extract them down the tree particularly in the case of a “copy node” since it's pretty hidden where the actual copies are so I can't just write it into them there (in my pyModScripts).
Then you think ya what exactly is the point of all this node stuff and then you say well there is a point. Still it seems to lack a good entry point to write efficient code that doesn't need cutting and pasting all over or some global py mod dance, which I'm fine with but I'd rather write it into the nodes, which in the case of copy stamp stuff is not as simple as it should be since every parameter in the chain of nodes needs to go out to globals.
In this case I'm sure I'll find a way to plug the airresist into that node from the forcescale or in this case the faster more difficult VEXpressions. I've also not been able to find a typical Script or Snippet node in DOPs, what gives there? what do other people do, the best houdini gurus must have a better solution then putting repetitious code in each and every parameter box. Where do I put a master controller code block (preferable python) that sets the things together at once? {rant ends}