HDK class prefixes

[mrWolf]

hi there,

I am learning HDK and I am reading the whole documentation that comes with HDK.

At the moment the only big obstacle I find in learning HDK is the documentation but the examples provided are helping to shed some light in the overall darkness, they are really useful.

So here it comes my first question:

Is there anywhere where it is explaines what the various pre-fixes to clases like

...

GA_...

MB_...

DU_...

etc etc etc etc

mean ?

Or is there maybe a criteria that could help me figure out myself ?

This would help me immensely to understand the semantic of those classes, and stick them in my brain for later use..

If this question has been asked and answer already, I apologize. I've searched on this forum and google quite a bit before posting this.

(I've several hundreds of additional questions about HDK to be honest, but I guess I'll start with this ... )

Alessandro

[Guest mantragora]

I think Houdini Geometry is a good overview of some of the classes. After that you may jump into Houdini Operators. There are some diagrams here and there but I don't remember that I saw full diagram of all classes anywhere. Take a look also into:

$HFS\toolkit\slides

There is some interesting stuff there too.

Once you break thru couple operators yourself it will all start to make more sense... hopefully .

EDIT: fixed links .

Edited June 4, 2013 by mantragora

[mrWolf]

Dear Mantragora,

the slides are massively helping my understading of HDK ! I feel like Neo when he's learning Ju-Jitsu !! (Almost)

Thank you a lot for your help dude.

P.S.

I am afraid I'll have a few more questions soon ... cough cough ...

Alessandro

I think Houdini Geometry is a good overview of some of the classes. After that you may jump into Houdini Operators. There are some diagrams here and there but I don't remember that I saw full diagram of all classes anywhere. Take a look also into

There is some interesting stuff there too. Once you break thru couple operators yourself it will all start to make more sense... hopefully .

EDIT: fixed links .

[Guest mantragora]

Yeah, the slides are really cool. Unfortunately for me, I found them after I gone thru standard documentation .

[mrWolf]

Mantragora !!

I managed to write my first plugin and this was mainly cause of the docs directions you gave me !

I wrote a HDK prototype of this OTL I wrote a few weeks ago , and it works great !

Seriously, this thing is FAST ... I mean, really fast !!

Now, I'd like to ask a few questions cause I am sure it could be even faster cause I am using a deprecated systemo to loop through points.

unsigned int seedsnumpoints=seedsInput->getNumPoints();
for (int seedn=0; seedn < seedsnumpoints; seedn++)
{
	 const GEO_Point *seedcurpoint = seedsInput->points().entry(seedn);
	 UT_Vector3 scpos = seedcurpoint->getPos();
	 ....
}
[/CODE]

When I compile I get the warning about the fact the GEO_Point way to access points has been deprecated in favour of the GA_Offset.

Now , I know there are macros to loop through points , like ...

[CODE]
GA_FOR_ALL_GPOINTS_NC(gdp, GEO_Point, ppt)
{...
[/CODE]

But I'd like to avoid macros at this stage. I prefer to be forced to write the code myself before using the macros. But because of my little C++ knowledge I am having issues in reproducing the iterator using the GA_Offset way.

Anyone could write the little snippet of code to loop through points using the GA_Offset method (on a non-const gdp) , without the macro ?

Alessandro

Yeah, the slides are really cool. Unfortunately for me, I found them after I gone thru standard documentation .

Edited June 7, 2013 by mrWolf

[Guest mantragora]

Eleven slide shows iterator way of looping thru points with offset.

On my vimeo there are couple code examples that uses iterator to loop thru points.

[mrWolf]

Found the slider, just implemented it and worked great, thank you man.

I'll test if the Offset method is faster.

I'm looking at your videos too, very well done and handy.

Eleven slide shows iterator way of looping thru points with offset.

On my vimeo there are couple code examples that uses iterator to loop thru points.

[mrWolf]

I just tested it quickly and in my specific case I gained a 2.21x speed increase using GA_Offset opposed to the GEO_Point method !

[symek]

I just tested it quickly and in my specific case I gained a 2.21x speed increase using GA_Offset opposed to the GEO_Point method !

GEO_Point is obsolete for a reason.

[mrWolf]

I can totally see that now Symek !

I've another question:

At the moment I am using an array of vector<type> to store and process data about points cause I need to store a list of float3 for each point.

Example:

	 // npoints = number of points I'm looping on
	 vector<UT_Vector3> *pointcolorlist;
	 pointcolorlist=new vector<UT_Vector3>[npoints];
	 ...
	 for (int currpoint=0; currpoint<npoints; currpoint++)
	 {
			 ...
			 UT_Vector3 color1;
			 UT_Vector3 color2;
			 ...
			 pointcolorlist[currpoint].push_back(color1);
			 pointcolorlist[currpoint].push_back(color2);
	 }
	 ...
	 // and when I am done ...
	 for (int currpoint=0; currpoint<npoints; currpoint++)
	 {
			 pointcolorlist[currpoint].clear();
	 }
	 delete [] pointcolorlist;
[/CODE]

Is this an efficient (fast) way to store temp data about points or I should use, for instance, [b]point groups[/b], or blind data to attach data to points ?

note:

this data doesn't need to be accessible to the user, I use it only internally in the sop to calculate the end result so I want it to be as fast as possible.

GEO_Point is obsolete for a reason.

Edited June 7, 2013 by mrWolf

[symek]

Well, much depends on your algorithm, but first attempt should be not to copy data. New GEO_Details' internal storage was designed to feel as much as possible as an array (but paged for additional boost). You normally work directly on attributes in which case Houdini can help you with threading, paging and vectorizing.

As to vector, afaik it's never a good idea of using new with std::vectors. They were designed to manage memory automatically for you. Most of the cases you should be able to create an object, allocating size at front (as you do) to avoid the most expensive part, and access elements with []. Theoretically and practically vectors are the same as arrays.

Simple math operations are mostly bonded by memory access, not algebraic operations, and so cache-friendly data patters are crucial (math expression will be optimized by a compiler anyway). This task is easier wth HDK attribute containers.

[mrWolf]

Symek,

thank you a lot for your explanation. It makes sense.

I changed my algorythm so that it doesn't need anymore a list of lists (before I was storing a list of vectors for each point, and then summing them afterwards, now I add each new vector to the previous replacing it).

This way I replaced the vector<UT_Vector3> with a nice point attribute and i notice a slight improvement in performance too. Plus as you say with attribute containers I can take advantage of threading etc. That's great.

I've another question related to the attibutes.

I have a loop where I populate two point attributes, use them, and in the end of the loop I zero them all out for the next iteration.

So at every iteration I explicitly do this :

	 ...
	 UT_Vector3 zerovect(0.0,0.0,0.0);
	 ...
	 // reset attribute to zero
	 for (GA_Iterator itroot(gdp->getPointRange()); !itroot.atEnd(); itroot.advance())
	 {
		  rootdirvectorattribtouple->set(rootdirvectorattrib, itroot.getOffset(), zerovect.data(),3);
		  rootvisitedattribtouple->set(rootvisitedattrib, itroot.getOffset(), 0.0, 0);
	 }
[/CODE]

[/size]

I guess this is a cpu consuming operation to perform millions of times. I might be wrong

Instead of doing this I tried to destroy the attribute and recreate it. But i didn't notice any improvement in the performance.

My question is:

is this the proper way to quickly reset to default (zero in this case) a point/primitive attribute or there is a more efficient way ?

Well, much depends on your algorithm, but first attempt should be not to copy data. New GEO_Details' internal storage was designed to feel as much as possible as an array (but paged for additional boost). You normally work directly on attributes in which case Houdini can help you with threading, paging and vectorizing.

As to vector, afaik it's never a good idea of using [b]new [/b]with[b] std::vectors[/b]. They were designed to manage memory automatically for you. Most of the cases you should be able to create an object, allocating size at front (as you do) to avoid the most expensive part, and access elements with []. Theoretically and practicallyvectors are the same as arrays.

Simple math operations are mostly bonded by memory access, not algebraic operations, and so cache-friendly data patters are crucial (math expression will be optimized by a compiler anyway). This task is easier wth HDK attribute containers.

Edited June 10, 2013 by mrWolf