Using Pointrefarray

[sibarrick]

Ok so this is probably very easy but my C++ skills are still weak.

I want to loop through all the points connected to a specified point.

I'm using

void findPrimsUsingPoint(const GEO_Point *pt,

UT_IntArray &primlist,

GB_PointRefArray &prefarr,

unsigned int primmask=GEOPRIMALL);

and hoping that "prefarr" returns the connected points.

Assuming this is correct how do you loop through the points in a GB_PointRefArray? are there any built in macros for this, any pointers??

If this is not the best way to do it is there another function I could use.

cheers

[Mario Marengo]

Hey Simon,

Never used this, so I could be all wrong, but, from the class definition, looping should go something like this:

// prefarr  is presumably created by findPrimsUsingPoint() ?
// GB_PointRefArray prefarr(/*...*/); 

//...//

for(unsigned i=0; i < prefarr.entries(); i++) {
   // convenience: GB_PointRef const reference (const optional)
   GB_PointRef const &pref = *prefarr(i);  
   // convenience: GB_Primitive const reference (const optional)
   GB_Primitive const &prim = *pref.prim; 
   //convenience: GB_Vertex const reference
   GB_Vertex const &vtx = *pref.vtx; 
   //convenience GEO_Point const reference (assumes gdp available)
   GEO_Point const &vpt = *gdp->points().entry(vtx.getBasePt()->getNum());

   // now you can use the vertex's point in some expression (as long
   // as you don't change its value, since I declared it const)...
   UT_Vector3 p = vpt.getPos()  /* + ... blah, blah, blah ... */;
}

// may need some cleanup here depending on who owns prefarr (?)

Alternatively, I guess you could use the prev/next pointers and walk through the array as a list -- the above uses the indexing operator (i.e: the functor GB_PointRef const *GB_PointRefArray::operator()(unsigned idx) const; )

Again, I haven't actually used any of this, and I could have gotten one of the many levels of indirection wrong (ie: "." vs "->") -- I'm just going by the headers, so caveat emptor!

Cheers.

[sibarrick]

Hi Mario,

That's basically what I'm trying so I'll go through what you have there and keep plugging away, at least I think on on the right path, should get there in the end.

Cheers!

[sibarrick]

GB_PointRef const &pref = *prefarr(i);

This line is giving me the same error as I was getting

term does not evaluate to a function taking 1 argument

I don't understand, according to the header it certainly should take 1 argument

const GB_PointRef	*operator()(unsigned idx) const
    {
       return (idx < size) ? array[idx] : 0;
    }

[Mario Marengo]

GB_PointRef const &pref = *prefarr(i);

This line is giving me the same error as I was getting

23752[/snapback]

Hmmm... I don't see anything wrong with that assignment (from the point of view of data types at least). You can try *(prefarr(i)) if you want, but dereferencing should happen after the function call, so I don't think it's complaining about that...

Could it be that something else is not being initialized properly?

The closure object would need a reference to the gdp, so its declaration should look something like

GEO_Closure closure(*gdp);

and maybe you need a properly constructed GB_PointRefArray, like

GB_PointRefArray prefarr(gdp,0);

If that last is true, then maybe prefarr is *not* being filled by findPrimsUsingPoint, but instead it's using it as a reference and only filling the prim list (?)

Got a bare-bones version to test?

I'm thinking you should try something like this inside the cook method:

GEO_Closure closure(*gdp);
UT_IntArray primlist;
GB_PointRefArray prefarr(gdp,0);
FOR_ALL_GPOINTS(gdp,ppt) {
   closure.findPrimsUsingPoint(ppt,primlist,prefarr);
   cerr<<"PT: "<<ppt->getNum() 
       << " ConnPrims: "<<primlist.entries()
       << " ConnPts: "<<prefarr.entries()<<"\n";
}

just to get some idea of what might be going on in there...

And again, the above is untested.

[sibarrick]

I've got it compiling now, but I haven't tested it yet. I'll let you know.

I change it to this

GB_PointRef const pref = *(*prefarr)(i);

which makes some sense

prefarr is a pointer so dereference it, then pass it i, then dereference the pointer passed back.

or

GB_PointRef const *pref = (*prefarr)(i);

works to

cheers, watch this space

[Mario Marengo]

GB_PointRef const pref = *(*prefarr)(i);

or

GB_PointRef const *pref = (*prefarr)(i);

23756[/snapback]

That only makes sense if prefarr is a pointer... I was assuming it was just a local object, as in

GB_PointRefArray prefarr(/*...*/);

in which case the compiler shouldn't complain about

GB_PointRef const &pref = *prefarr(i);

Anywhoo... whatever works

BTW: which compiler are you using (windoze's MSVC.NET ? )

[sibarrick]

Yup, my fault.

I was passing prefarr as a pointer, which I shouldn't have been.

Sorry missed that line in your original post.

Thanks again for all the help.

BTW: which compiler are you using (windoze's MSVC.NET ?)

yup

edit:

Also turns out prefarr doesn't get updated, it's just a filter.

Still I can use the returned primlist instead.

[sibarrick]

Hey Mario here's the fruits of my labour, and yours.

It's a sop for creating an attribute that stores the distance from a source point group counting along edges rather than just world space. It's not fully tested but I think it works.

Thanks again - invaluble help as ever.

EdgeFalloff.zip

[Mario Marengo]

HA-HAAAAAA!!

That's great, Simon!!! Thanks a lot for sharing!

Who-da-man?!?

So... this reminded me of this paper in the last siggraph proceedings -- a method for measuring distance from a point along a surface. I'm sure you've seen that already, but just in case... looked pretty cool

Thanks again!

[sibarrick]

I probably have seen that paper before but never paid it the attention it deserved

What I'm doing is no where near as clever. I'm using using built in HDK functions to incrementally expand the source group and then checking back to the previous step to calculate the distance. It's therefore a little sensitive to the actually arrangement of edges, and won't be very accurate as you move far away from the source group.

I'll have a good look at that paper and see if I can do anything with it, maybe I can have an option to calculate accurate distances but at slower cooking speed.