MrScienceOfficer

Yes you can store arbitrary data, you need to subclass PRM_DataItem, and PRM_DataFactory. Then you can allocate your DataItem, put it in a PRM_DataItemHandle and set the parm.

My implementation of a bezier handle using new custom states in H17. Please don't hesitate to criticize/suggest features. Thanks! ao_utility__bezierhandle__1_0.hdalc

I think it's probably the best approach. A KD-Tree, which is what GEO_PointTree is, is a good choice for nearest neighbor searches. If you look at the implementation of UT_KDTree(if im not mistaken) you should be able to find an appropriate query function for your needs.

I don't think your point loop is formatted correctly.... C++ requires braces around loops with more then one line... GA_FOR_ALL_PTOFF and all similar variations are just macros around a for loop, I think you just need to add the braces.

What I would do is create an array of the positions in the state and use that to render points class PointsHandles { void draw(RE_Render* r); UT_Int32Array mySelection; UT_Vector3FArray myPoints; RE_Geometry* myReGeo = nullptr; } void PointsHandles::draw(RE_Render* r) { if (myReGeo) myReGeo = new RE_Geometry(myPoints.size()); myReGeo->createAttribute(r, "P", RE_GPU_FLOAT32, 3, myPoints.data()); myReGeo->createAttribute(r, "Sel", RE_GPU_INT32, 1, mySelection.data()); myReGeo->connectAllPrims(r, 0, RE_PRIM_POINTS); myReGeo->draw(r, 0); } that should basically work, you'll need a shader that uses the "Sel" attribute and creates some visual feedback for the user.(let me know if you need help with the shader) I would do something like sort points by collinearity with the results of the vector from mapToWorld() for the selection, that's a personal preference though (it's easy to implement and I find it very intuitive as a user as well). Then use a GU_RayIntersect to intersect with the geometry your creating loops on, and just write the positions to the parameters.

What are you intending to accomplish? If you use a valid shader for the purpose, you should be able to render anything you like. Though you may need to push the Viewer and Perspective matrices first something like this pseudocode. r->assignUniformMatrix(RE_UNIFORM_PROJECT_MATRIX, getViewportProjectionTransform()); r->assignUniformMatrix(RE_UNIFORM_VIEW_MATRIX, getViewportTransform()); I haven't tested any of that though. What I would do is create a DM_SceneRenderHook instead if you just want to render some spheres, though without knowing your intention it's hard to comment on best practice.

Does the SOP_WindingNumber sample not show what your looking for? A GU_Detail is a collection of attributes(like a position attribute but also for topology) so when your asking if a geometry has changed, your really asking what attributes in the GU_Detail have changed. All attributes are tracked with GA_DataId, so caching the data id of the attribute you're interested in and checking that against the incoming geometry will allow you to check for any relevant changes. The SOP_WindingNumberCache::update3D function in particular seems to show a way to do what your describing.

I believe a curve mesh is a geometry made only of polygon curves. It took me a while to figure that out, but it seems the intersection nodes only don't complain when using polygon curves.

Yes, yes, yes, in general, no. When you write code in VEX (or use VOPs) you are reading attributes from the input geometry, not the geometry you are currently processing. This is the mechanism that allows VEX to run multi threaded SIMD code. Though that's just high level theory; you can't read and write to the same data from different threads haphazardly.

Why would it match (and why would you need it to?), your rounding to the .001th decimal place and testing for a tolerance to .00001th place.

def theLooper(curNode): for thePrim in curNode.geometry().prims(): primColor = thePrim.floatListAttribValue("Cd") rounded = tuple((round(total,3)) for total in primColor) print(thePrim.number()) print(primColor) print("Theese are the rounded numbers\n"+str(rounded)) #print(round(primColor,3)) dot = hou.Vector3(primColor).dot(hou.Vector3((rounded))) # closing parentheses was missing tolerance = 0.000001 if dot >= 1.0-tolerance and dot <=1.0+tolerance: print("match") else: print("no match") if curNode.geometry().findPrimAttrib("Cd"): print("yes") else: print("no") Python tends to throw a syntax error on the following line when a line doesn't complete it's statement i.e. parentheses block not closed.

int primCount = detailintrinsic(concat("op:", opfullpath("../myInputedGeo")), "primitivecount"); // or just int primCount = detailintrinsic("op:../myInputedGeo", "primitivecount"); opfullpath is a VEX function (as well as an hscript function), your attempting to call the hscript version(by putting it in backticks), int primCount = detailintrinsic("op:`opfullpath("../myInputedGeo")`", "primitivecount"); either version should work though I recommend the VEX version as it's much easier to debug. Looking at your post again point #2 is correct and should work, unless I'm not seeing how it's different from my version (which works for me).

PolyFrame works well in this situation, just change the tangent to 'N'. A vex solution would look like if (@ptnum != npoints(0)-1) @N = @P - point(0, "P", @ptnum+1); else @N = point(0, "P", @ptnum-1) - @P; @N = normalize(@N); . This handles the case of the last point by inverting the vector towards the previous point.

I looked at what your saying about exporting paths, I've never heard of that before. I don't believe what you did actually changed the paths in Houdini. Your path needs to be '/Users/gfx03/HDK/custom;&' you need add ';&' to tell houdini to keep searching for more paths. It's probably best to just edit the houdini.env file though.

Pinging forums.odforce.net [208.79.239.212] with 32 bytes of data: Reply from 208.79.239.212: bytes=32 time=49ms TTL=58 Reply from 208.79.239.212: bytes=32 time=43ms TTL=58 Reply from 208.79.239.212: bytes=32 time=41ms TTL=58 Reply from 208.79.239.212: bytes=32 time=45ms TTL=58 Ping statistics for 208.79.239.212: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 41ms, Maximum = 49ms, Average = 44ms It taking about ten seconds to load a page.