anim
-
Content count
2,320 -
Donations
0.00 CAD -
Joined
-
Last visited
-
Days Won
127
Recent Profile Visitors
14,910 profile views
-
the extreme amounts of points were actually just to get some complexity not a requirement as otherwise it's super fast, it'd cut at any interopolated value even on very sparse curves/meshes
-
thanks for testing, maybe it's time for sidefx to optimize Clip SOP and Poly Cut SOP as both more or less can be used in this way, but it's not nice to be paying speed penalty over more custom VEX solutions
-
here is a simple example ts_carve_by_clip.hip
-
Yes, performance wise, I've been using Clip as it's pretty versatile and you can perform as many cuts as you want with a single Clip SOP too, it's just the matter of transforming the curves in Y for example, using the attribute which can be offset or modified per curve) then Clip once and transform back, attribs are interpolated automatically so the main question is whether there is more speedup to be gained using pure VEX, which seems like a bit more work on the other hand
-
how does it compare to Clip SOP technique?
-
you can get @force from anchor pieces per constraint and compute the difference in any way you seem fit to get the strain acting on the constraint and then break it if it's higher than threshold
-
Well, if it's just about blurring pattern values together and not iteratively smooth previous results, you can sample that pattern on multiple positions per point and get some weighted average of the values depending on kernel you want, but that may be even more tedious and less efficient depending on how complex the pattern function is
-
it's not possible to efficiently blur within a single wrangle, since you can't access the results of other points (and doing it in detail wrangle and keeping track of value using arrays would probably be overkill also not very efficient) I'd use Attrib Blur as that's using OpenCL so possibly the fastest
-
nowadays you can use quaterniontoeuler() VEX function, which returns radians however
-
How can I read value of a SOP parameter, inside a wrangle?
anim replied to Masoud's topic in Scripting
I'd recommend against using parameter paths that point different nodes in VEX like Roznick said, create all UI you need on your wrangle and just channel reference those parameters to external parameters, this way Houdini will be able to track dependencies and if you rename your line1 node everything will still work -
How could I unpin points in vellum, from target animation?
anim replied to Masoud's topic in Effects
you don't have to use mass to determine what's pinned you can also use i@stopped attribute, which has advantage of keeping the original mass value once unpinned (stopped==0) also you can use explicit constraints (soft) as pins, which may be preferred method all of these methods are part of Vellum Constraints/Pin To Target, so no need to create them manually -
you can use Match Topology SOP to try to sort points/prims of one geo using another as a template buildingFrames_issue_fix.hipnc
-
v@force and v@v in POPs are very close to force and velocity in physics, so if you read more about force and velocity in physics in general, you'll get better idea about what you are dealing with there is many ways to describe them, so for example you can think of them like this v@v is the current velocity per second, or in other words change of position per second v@force is change of momentum per second, in simple case if @mass is 1 then v@force is the same as acceleration which is change of velocity per second, but more generally v@force describes change of velocity per second proportional to mass so in other words, they are not the same, and in similar way to how velocity affects position, force affects velocity
-
you'll need to provide some more info or file as while(@P.x <= 10) { @P.x += .1; } seems to work perfectly fine when executed on a single point in SOPs, what's your solver setup? while_loop.hip
-
solver not working on animated mesh
anim replied to ashu_tosh_m's topic in General Houdini Questions
or most of the times you may want to do the opposite, keep your Input_1 as your main stream, but copy the attributes you are accumulating from Prev_Frame geo as a first step as most of the times there is more animated attributes on your source geo than just P, this will keep them all being updated, just selected attribs will be accumulated
