Jump to content
[[Template core/front/profile/profileHeader is throwing an error. This theme may be out of date. Run the support tool in the AdminCP to restore the default theme.]]

haki last won the day on January 17 2020

haki had the most liked content!

Community Reputation

20 Excellent

About haki

  • Rank
  • Birthday 06/25/1988

Contact Methods

  • Website URL

Personal Information

  • Name
    Hristo Arabadzhiyski
  • Location
    The Netherlands

Recent Profile Visitors

638 profile views
  1. Brilliant! I didn't even know the error node existed. Thanks for that! It's easier to understand what's going on that way. - I saved it with the stashed curve, didn't I?
  2. Hi Alain, This is fantastic! Much appreciated! I played around a little to find a way to get the error message to propagate upwards without throwing to the consol onInputChanged. I combined the 2 methods you wrote about (thanks for the great detail btw!). I left the python SOP alone in a separate branch and I run the cook() method on it onInputChanged. I don't know if that takes care of the cook-on-every-frame issue. This is what I've got: https://github.com/arabadzhiyski/update_curve_coordinates It must be the most useless, useful thing I've done yet.. Thanks again, Hristo
  3. Hey folks, Is it possible to make an HDA error out if the input node type is not of a particular required node type? Cheers, Hristo
  4. Hi, I've some experience with VEX in SOP land but I'm new to Mantra shading and I want to get better at writing vex shaders. What would be the modern way of doing that? In particular, I'm not entirely sure if I could simply write my code and hit compile (the way I would with OSL in RenderMan) without ever leaving Houdini or restarting the renderer for that matter. For instance, I managed to compile the following from a vfl (a modified sidefx example) into an HDA (.\vcc -l "%HOME%\houdini18.5\vex\hcartoon.hda" "%HOME%\houdini18.5\vex\hcartoon.vfl") and it's available under /SHOP/Digital Assets and it works. #include <shading.h> #pragma opname hcartoon #pragma oplabel "HCartoon" #pragma opicon SHOP_surface #pragma label colora "Color A" #pragma label colorb "Color B" #pragma hint colora color #pragma hint colorb color #pragma hint Cd hidden surface hcartoon( vector colora={0.2, 0.5, 0}; vector colorb={0, 0.2, 0.8}; vector Cd=1; ) { vector Cx; illuminance(P){ Cx = Cl; shadow(Cl); if (Cl == Cx){ Cf = colora; } else{ Cf = colorb; } } } However, isn't there a more straightforward way? Do I always have to compile to HDA and write all those pragmas? I was hoping for something like an attribute wrangler approach. So, there's the Surface Shader Builder (vopsurface) that I have to admit I don't quite get as far as writing code goes. Snippet? Inline? How about inputs and outputs in it? Surely not with pragmas in there, right? I tried with a snippet, got a compile error 'Invalid return type (surface)'. If anyone can help me with it, that'd be awesome! Thanks, Hristo
  5. Hi, Say there were an existing hip with hdaAsset::1.0 used multiple times throughout various node graphs inside. hdaAsset is now in version ::2:0 and there's been a parameter name change, say from 'inputFloat' to 'inputF'. Would there be a way, upon hip load, to catch that? Maybe an event handler script with a condition in there for that hdaAsset::1.0 node type and parm? The goal is to read the connectors of all hdaAsset::1.0 instanced before the assets gets synced to ::2.0 upon scene load and then wire them into the newly named 'inputF' after sync. Manual rewiring of broken node graphs avoided. Everybody happy. Or, looked at differently, prevent hda sync to the latest version for that particular node type definition, just so the connectors would stay in place. Has anybody dealt with something like that before? Thanks, Hristo
  6. So, here's the diagnosis : I messed up with wrong parameter references to the multiparm block list. Most of the prim() and point() functions were trying to read attributes that didn't exist [embarrassed]. I revised almost all variable names. It's neater and working now. Also revised the PythonModule functions. They won't throw now if the attribute name string filed is cleared (by hand). Also took care of the attribute drop down menu scipts. Vector attribs won't be listed if the Attribute to Operate on is a float. That's true also for the lerp operation attrib menu. (Don't ever try a vector2 or vector4 by manually typing its name. It probably won't go well.) Finally, a description parm with a python script gives you the input/output attrib names at a glance. attribute_scrambler_beta_v3.hda Just for comparison, a demo of v2.0 (the previous version) here, which was before vector3 support. It makes it a bit clearer what I mean by attrib blending (scrambling):
  7. Sounds like a good plan for KineFx. (Yet to take a deeper look at 18.5 on my end, to be honest.) And, yeah there was a bear near a treehouse some time ago, to appear in renderman, indeed.
  8. Wow! That's good idea! (and a surprise because I can't remember to have ever mentioned I was a renderman user, haha )
  9. Hi, A hobby project as a vex and python challenge for myself mostly. So, the idea is to "mix" (scramble) attributes like layers in photoshop. If you feel like sinking your teeth into it there's the hda in attachment... and of course, critique and comments are very welcome! V1 and V2 didn't support vectors and things were simpler. This is V3 that I decided to take to the next level. There are 2 functions in the python module for checking the type of attribute being used (float or vector). They toggle invisible parameters in the multiparm, which control the visibility of ramp parameters. (haki.h is embedded into the hda, just so you can see its contents. the attrib wrangle WILL FAIL without it (that is unless you put a copy in $HOME/houdiniXX.X/vex/include), but the attrib VOP won't because it's in its outer code. there's no other difference between the two.) [EDIT 20 Nov 2020] : This is totally broken right now. It outputs the wrong values. Cheers! Hristo
  10. I love the curve capture idea! I adapted your VEX a bit to control front and back of the wave. Do you know how to stack those rotations? I mean, chain them so that you get 2-3 waves with 2-3 extra curves? See my v1 geo - I do like the xform matrix approach there although matrices confuse me to hell most of the time. Anyway, I appreciate you help. Cheers! wavelike_deform.hiplc
  11. Insane! Thanks! Wrote the vop sop to a wrangle: matrix xform = detail(1, "xform"); matrix rot = ident(); float z_bias = chf("z_bias"); float range = chf("range"); float angle = radians(chf("angle")); @P *= invert(xform); vector domain = set(@P.x, @P.y, @P.z * z_bias); float dangle = length(domain) / range; dangle = exp(-dangle) * angle; rotate(rot, dangle, 4); @P *= rot; @P *= xform; I'll see how to build on top of that. wavelike_deform.hiplc
  12. Very interesting! Thanks for the hip. I'm looking at the VOP and to be honest I'm not good at 'reading' vop networks. I'll convert it to a wrangle see if I can get a better understanding of what's going on. The wavy lines aren't coming out of that vop, are they? Cheers!
  13. Hey everybody, I want to get better at maths and houdini seems like a fun way to do that. So, (ocean) waves are interesting and I want to make a tool that can draw stylized waves. Alright, I think I got the a classic cycloid: float x = @P.x + cos(2 * PI / wave_length * @P.x) * scale; float y = sin(2 * PI / wave_length * @P.x) * amplitude; float z = @P.z; @P = set(x, y, z); And now it gets interesting: Well, how about barrel waves? What should I be looking at to make the peaks curl, parametrically? Fourier? - which I find fascinating, but know nothing in practice. I graphed a squared cosine and my intuition is that if the blue line function were to be known... (and here it gets fuzzy) do something to the wave. Done. :)) Wave and trigonometry experts out there? A little help? Cheers!
  14. Thanks, skybar. It works great on rigid parts when you pick them by hand. I'm looking for a way to automate the detection of digid parts in a character (or characters which have both soft deforming and rigid meshes) and separate those. I've just discovered that the string abcanim primintrinsic may be what I need. It seems that abcanim on my character is set to "attribute" for the props (which are all rigid) and "transform" for all parts which are soft point-deforming, although the latter is questionable really. Anyway, I tested the 4 steps I had described. It seems it could work especially when one may not necessarily care for tiny point-deformations and would rather treat them as digid. I'll see if I can post a scene or a more accurate description these days.
  15. Hey folks, would there be a way to identify and extract, procedurally, animated rigid pieces from soft point deforming pieces? Say, you have a character alembic cache and several meshes on that character are rigid (i.e. their points don't change positions relative to each other). For example: the weapon of a warrior, or the plate armour, the shield... etc. I want to find those meshes procedurally and extract their transformations (and of course replace their point deformations with object-level transformations, duh...) Would you have a clue how to approach that? There wouldn't be a node for it already, would it? I'm thinking what heuristic to employ to differentiate between pieces which points do change positions relative to each other vs such that don't. Maybe just maybe... extract transformation matrices for every piece for some arbitrary prim, be it rigid or not multiply by the inverse to set each piece to the origin and... compute velocity in the result? all inversely tranformed points of rigid pieces have 0 velocity, some points (other than the points on the arbitrary prim from #1) of soft deforming pieces have v>0. tag them.