Eddy

Thank you @symek so much! SESI said me they use other methods and complex caching mechanism which unfortunately is not published as part of public API! Using op:/path/to/geometry style is not causing to access geometry data in vex either for user defined C++ VEX functions... BTW the case is still open and I couldn't find any solution for this problem so far.

Dear @symek Thank you so much! Dear @symek now two questions are coming: 1- Does volume sample function access to current geometry via IFD file in shader context? 2- Why backing and rereading geometry afterward are so slow when we are using in Point Wrangle SOP in SOP context? Is this normal? No matter if I pointing to a light or a very dense SDF it is always slow! If I comment out rereading geometry section from the code, speed increases noticeably! When I rewind and play, in couple of first frames it is fast but afterward Houdini starts lagging and getting slow quickly! Thank you so much again for the great responses!

Thank you so much dear @symek! Are you sure about this? because I used Volume Sample VOP and pass it address of node which contains SDF volume and everything works as expected! Also here: https://www.tokeru.com/cgwiki/index.php?title=Houdini_Lighting_Shading#Trail_from_sampling_an_SDF_and_a_material_wrangle Shows that volumesample function can access to node's geometry succesfully! So how volumesample can access to node's geometry? Thanks again dude!

Thank you so much@symek! My goal is to create a function called wetmap in VEX (which should be used in shader context) so that it can create wetmap looking in rendering instead of using traditional way which is scattering lots of points on model and then use Solver SOP to create an attribute then use point clouds to access this attribute in shading context... So I decided to create a function called wetmap and pass it these arguments: vector wetmap(string address, vector position, vector color); address is node contains surface field of simulated fluid. position is the position of current ray which is hit to the surface of the geometry which is being shading. color is the current color of the surface which is being shading. When I pass node address as the first argument I need to access to geometry in different frames to check whether current position is in fluid field or not. So in this case I can't only use VEX_VexOpInit as I need to access to geometry in different frames! I update the code based on your suggestions: #include <iostream> #include <VEX/VEX_VexOp.h> #include <OP/OP_Director.h> #include <OP/OP_AutoLockInputs.h> #include <SOP/SOP_Node.h> #include <GEO/GEO_VolumeSampler.h> #include <GEO/GEO_PrimVolume.h> #include <GU/GU_PrimVolume.h> #include <GU/GU_SopResolver.h> #include <VM/VM_Math.h> #include <UT/UT_Map.h> #include <UT/UT_Lock.h> #include <UT/UT_UniquePtr.h> #include <UT/UT_LockUtil.h> using volumeCache = UT_SortedMap<exint, UT_UniquePtr<const GU_Detail>, std::greater<exint>>; template <VEX_Precision PREC> static void* construction() { CH_Manager *mgr = OPgetDirector()->getChannelManager(); std::cout << "Start frame is: " << CHgetFrameFromTime(mgr->getGlobalStart()) << '\n'; std::cout << "End frame is: " <<CHgetFrameFromTime(mgr->getGlobalEnd()) << '\n'; void* map = new volumeCache{}; return map; } template <VEX_Precision PREC> static void destruction(void* data) { delete static_cast<volumeCache*> (data); } template <VEX_Precision PREC> static void wetmap(int argc, void *argv[], void *data) { VEXvec3<PREC> *resultCd = static_cast<VEXvec3<PREC>*>(argv[0]); const char *surfaceAddress = static_cast<const char *>(argv[1]); VEXvec3<PREC> *P = static_cast<VEXvec3<PREC>*>(argv[2]); VEXvec3<PREC> *Cd = static_cast<VEXvec3<PREC>*>(argv[3]); volumeCache* map = static_cast<volumeCache*> (data); *resultCd = VEXvec3<PREC>{0, 1, 0}; SOP_Node *surfaceNode = OPgetDirector()->findSOPNode(surfaceAddress); exint currentFrame = CHgetFrameFromTime(CHgetEvalTime()); OP_Context context{CHgetEvalTime()}; VEXvec3<PREC> color{0, 0, 1}; for (exint i = currentFrame; i > 0; --i) { if(map->contains(i) != true) { context.setTime(CHgetTimeFromFrame(i)); OP_AutoLockInputs inputs{surfaceNode}; inputs.lock(context); const GU_Detail *gdp = surfaceNode->getCookedGeo(context); if (gdp != nullptr) { UT_UniquePtr<GU_Detail> temp {new GU_Detail}; temp->duplicate(*gdp); (*map)[i] = std::move(temp); } } const GEO_PrimVolume* volume = static_cast<const GEO_PrimVolume *>(map->at(i).get()->getGEOPrimitive(0)); GEO_VolumeSampler volumeSampler{volume}; fpreal sample = volumeSampler.getValueF(*P); if (sample < 0) { *resultCd = color * (currentFrame - i) * 0.01; break; } } } void newVEXOp(void *) { using UT::Literal::operator""_sh; new VEX_VexOp("wetness@&VSVV"_sh, wetmap<VEX_32>, wetmap<VEX_64>, VEX_ALL_CONTEXT, construction<VEX_32>, construction<VEX_64>, destruction<VEX_32>, destruction<VEX_64> ); } I tried to access to fluild field geometry at different frames on the fly but I find out that for each request Houdini cooks the geometry for that frame and it become costly since for each position on surface this process should be repeated! So I create a map of items which first (key) is frame number and second (value) is pointer to GU_Detail which holds a deep copy of cooked flip fluid geometry! Now speed increased but still there is a huge difference between C++ and pure VEX implementation version! Again thank you so much dear @symek for your great answer. I highly yearn for the further help!

Hello guys! I have a simple C++ code which should be used by VEX in Houdini. I need to access to geometry data in specific node from current frame till frame 1 in backward direction until certain condition is met. The problem is that this access cause a huge impact on runtime when using wetmap function in a point wrangle node! Here is the sample: #include <iostream> #include <VEX/VEX_VexOp.h> #include <OP/OP_Director.h> #include <GU/GU_Detail.h> #include <SOP/SOP_Node.h> #include <GEO/GEO_VolumeSampler.h> #include <GU/GU_PrimVolume.h> #include <GU/GU_SopResolver.h> #include <VM/VM_Math.h> #include <OP/OP_AutoLockInputs.h> template <VEX_Precision PREC> static void wetmap(int argc, void *argv[], void *) { VEXvec3<PREC> *resultCd = static_cast<VEXvec3<PREC>*>(argv[0]); const char *surfaceAddress = static_cast<const char *>(argv[1]); VEXvec3<PREC> *P = static_cast<VEXvec3<PREC>*>(argv[2]); VEXvec3<PREC> *Cd = static_cast<VEXvec3<PREC>*>(argv[3]); *resultCd = VEXvec3<PREC>{0, 1, 0}; SOP_Node *surfaceNode = OPgetDirector()->findSOPNode(surfaceAddress); exint currentFrame = CHgetFrameFromTime(CHgetEvalTime()); OP_Context context; VEXvec3<PREC> color{0, 0, 1}; if(surfaceNode != nullptr) { for (exint i = currentFrame; i > 0; --i) { context.setTime(CHgetTimeFromFrame(i)); GU_DetailHandle gd_handle = surfaceNode->getCookedGeoHandle(context); } } } void newVEXOp(void *) { using UT::Literal::operator""_sh; new VEX_VexOp("wetness@&VSVV"_sh, // Signature wetmap<VEX_32>, // Evaluator 32 wetmap<VEX_64> // Evaluator 64 ); } I also try to lock the referenced node input just like SOP node examples in HDK but it makes no difference! This is an image of use case: After couple of frames pointwrangle1 become slow to cook and I don't know why! Can anyone help me? Thanks in advance!

Can you upload your HIP file? Thank you. Edit: I uploaded my new test. At frame 40 constraint anchors place in wrong position. Can anyone help to fix it? spring_to_glue_test.hipnc

Yes, Exactly.

Thanks dear Jesper. I knew this. I think it is a good optimization for RBD simulations where we can switch to glue when any collisions happen and switch back to spring when collision are coming. Also we can ensure in glue constraint any wobbles would happen unlike spring or hard constraint... So I'm looking for a way to maintain the shape after switching from glue to spring or hard constraint.

Hello guys. I have a question about bullet constraint in Houdini. I think it is a good issue in simulating RBDs and constraints. The goal is to change constraint type from hard, spring, cone twist, etc to glue dynamically during simulation via SOP Solver. I can change constraint_name primitive attribute from spring to glue successfully. But after a moment when I want to back to spring constraint all deformation which I have in glue constraint will be reset to original shape! I attached a HIP file to see what I'm looking for. In this HIP file that I take this from Houdini 13 Bullet Masterclass, at frame 14 constraint type will be changed to glue when wall is bend. At frame 40 I change constraint_name to spring again but wall returns to original shape whereas I want to maintain bending. Can I do this with Bullet? If we can't do this, it would be a great RFE to optimize RBD simulations and creating nice effects. Thank you so much. spring_to_glue.hipnc

hey guys i have question about compound geometry representation. how can use this option in bullet for have correct collision in Houdini?because when i set geometry representation to compound my active object is not active any more! any help will be appreciated.