BabaJ You could use the pointvertices() function that returns a list of vertices belonging to the point.
Decide which vertice you want to use and get its attribute with vertex()/vertexattrib() and assign that value to the point with setpointattrib().
Similarly going from point to prims.
Thank you for painting the broad strokes.I appreciate it.
Though, I am still chewing on loops to get them down pat. Does someone suppose they could show the structure how they would loop through all that in vex please?
Do you suppose someone could show the way they would handle promoting a Vertex Attribute to Point Attribute, or a Point Attribute to Primitive Attribute in a Wrangle please?
It sounds like the getbbox_center is more precise but the @P gives a nice weighted result. If the points are somewhat evenly distributed the @P will prevent one weird point from swaying the result too much. However if the points are lopsided in the wrong way one could definitely get an inaccurate center.
We got lured by Apple tooting full OpenGL an OpenCL in a professional and quiet setup. So we foolishly got the trash cans for the texture dept after Pixar demoed Mari on it saying it was the best thing since sliced bread. After that Apple showed their true colors when they stopped supporting OpenGL and OpenCL. Then their driver update process was lacking for all the bugs they have. There is literally a petition regarding this whole issue. The final kicker is a standing bug for Mari since they released it for the macpro trash can is that Mari under performs for its hardware spec and it still isn't fixed with version 4.x. Speaking of Mari 4.x if you know they have released it for win/linux but are having trouble releasing it for the mac and have been struggling for a month to get it to even beta. The only reason we got them is sometimes the artists need photoshop and thought this would solve that. We regret very much getting them. For the price we paid we could have gotten two linux boxes that were more powerful and better supported. Maya, Houdini, Nuke and Mari are slower on the trash cans compared to the other linux boxes in the studio.
The only good thing is you can run adobe software which is basically saying if adobe put their crap on linux, windows and mac would disappear from our industry.
I think empathy needs to be given to this subject for any Maya user coming to Houdini, one could achieve 95% of their needs using nice shelf buttons in their native program.
When ever I look at a shelf tool in Houdini I question if I should use it or set it up myself or build my own shelf button. I never know if the button is for my convenience to actually use or a demonstration.
I think this highlights a dilemma in Houdini's UX. The shelf portrays how user friendly Houdini can be when wrapped by a more technically adept artist who is taking care of it. It is not a statement of how user friendly it actually is or how much end to end coverage exists for an artist coming from a more conventional friendly program.
Using Mari thrashes the system ram continuously as all the textures have to go back and forth between the gpu and main ram while painting/baking and navigating…
NOPE! I was right it does as well too in houdini 16.5.
It has to do with the fixed scale value. If it makes part of uv island leave the udim frame. Then it lines up all the packed udim's linearly instead of the mari style stack.
There is a way around it using a vertex wrangle though.
In Fixed Scale mode I am trying to use the UV Layout SOP to organize my uv's but I noticed that if I increase the scale enough that it overshoots the Mari Ten Base UDIM and doesn't go up vertically to the next row once the first ten UDIM's are filled.
Is there a way to change the scale and lay them out respecting the UDIM ten base requirement for mari?
I keep hearing people mention that a Wrangle SOP performs much faster than doing the same operations in an AttributeVOP SOP. How true is this?
For fun when ever I make a Wrangle I recreate next to it the same operation in VOPs and compare. Initially it seemed true as there was always a 0.1 second difference in favor of the Wrangle. I assumed the small gap was due to how small of a data set I was dealing with. I then upped the size of the data sets into the millions and still only saw that tiny fraction of a second difference. Which leaves me to wonder in what cases does the Wrangle truly perform that much faster? As of now it only looks like there is a hair of overhead for initializing the VOP layer.
You need a tangent vector of the surface which I like to comb the surface normal as a “flow” vector(which you probably want the crossproduct of so it bends into the flow). From there you need to loop over the whole hair and rotate all the cvs from one cv at a time. So if you have 5 cv's rotate all 4 from the root cv0, then rotate the 3 remaining from cv1 then do the same from cv2 until you are done.
That would be great as my aging laptop is slowly dying and I am trying to figure out if it might be worth holding out for the Raven Ridge APU's coming 2017 as I want something that is lightweight/power efficient but still has a little graphical/compute punch.