Jump to content


Popular Content

Showing most liked content on 11/15/2016 in all areas

  1. 2 points
    I'm not sure if this is the problem you're trying to solve, but the emitter works if you turn off the gasresizefluiddynamic1 node. You can give the emission a chance to start by setting the Delay Frames to something like 10. I would also make the initial pyro box bigger. Delaying, and increasing the pyro size both give the resize node a chance to sense some density before collapsing the pyro box on itself, if that makes sense. There's also something weird going on with the timeline for me. If I step through manually I can see the sim, but if I press play I end up at frame 2.63, 3.63 etc, and there is no density to see in the viewport. ???
  2. 1 point
    Hi all, I have SOP geometry that contains about 50 groups, and I need to convert each group into a scene object. I guess each scene object will use a Object Merge SOP for one of the groups. Is there an automated way of doing this? I tried to do this by hand, but after about 20 objects I started forgetting which groups I already used.
  3. 1 point
    What simulations specifically are you looking to speed up? That matters a lot. You're looking for a unicorn, a silver bullet, a holy grail...
  4. 1 point
    And some more work. Here I experimented some more with shortest path and directing the growth via custom cost attributes, so that the branches do not go straight to the endpoints but prefer the centre: A similar test on a sphere with happy-accident-leaves that were the result of converting the triangulated mesh to nurbs curves. I also did put in sliders to control random deletion of polygons on the underlying mesh to get more interesting paths: Something completely different - a Reaction-Diffusion structure created in "Ready" (https://t.co/t6Br2BuxD4) and rendered as Displacement in Mantra: Experimenting with point advected lines again, this time trying a very stylised look in black and white. The image reacts badly to scaling in the browser so you may want to look at the original. "The big Divide": And finally a combination of Reda Borchardts chain link tutorial applied to some Differential Line Growth... ;-) These are all rendered in Mantra. Cheers, Tom
  5. 1 point
    alright, so far i got it how to stamp the attribute. I created my_rotation, gave it a 20 as value and then, into a transform added on the first input, i wrote in the Rotate Z: stamp("../copy1","my_rotation", 0) The attribute works, but it rotate every instance with the same value, guess it's the Attribute Wrangle part missing, which i suppose i need to tell that every point in the curve have to get a differente value.... EDIT: I finally did it. Since i wanted every instance rotated by 15 degrees, i just put 15*$PT as Value of the Stamp attribute. I probably didn't make myself clear and @Atom thought i needed something more complex ^^
  6. 1 point
    That is what stamping is for. On input 2 add an attribute wrangle which runs over the points of the curve. Create a new attribute called my_rotation for each point. Then stamp that information into a transform that you also add to input 1.
  7. 1 point
    Sorry for my late reply. The Masterclass because of its nature couldn't be streamed. The conference however will, please check link below.
  8. 1 point
    Another shot in the can. Loving the detailed swirls at the end of the shot. Heavy sim times on this one, but worth it. Next update will be fun. This is all building toward something...
  9. 1 point
    int inpointgroup(int input, string groupname, int pointnum) All geometry lookup functions take geometry argument, where to perform search. It may be file/operator paths, or input number if integer value was used. Input means geometry on the upstream node plugged into the wrangle. So, if there is no such group with this point member on this node, result will be false. Instead, use variables you just created, since they exist in the current scope and already initialized with proper values. @group_a = expression1; @group_b = expression2; @group_c = !(@group_a || @group_b); While it may work in general, in case you simplified your real example to such snippet, it seems, in this particular case the code will mark all green colors as both green and blue. If we check for both red and green groups membership, it will mark yellow color {1.0, 1.0, 0.0} as blue. Since there is no groups for 3 intermediate colors, grayscale, black and white values, this code snippets may work better: @group_r = @Cd.r == max(@Cd); @group_g = @Cd.g == max(@Cd); @group_b = @Cd.b == max(@Cd); if (@Cd.r == max(@Cd)) @group_r = true; else if (@Cd.g == max(@Cd)) @group_g = true; else @group_b = true; First one will set r, g, b groups based on value, and it is possible for point with colors like {1.0, 1.0, 0.0} to be in red and green groups at the same time. Grayscale values will be placed into all three groups. If you need to divide everything into three exclusive groups, use second one, it will mark {1.0, 1.0, 0.0} {1.0, 0.0, 1.0} {0.0, 1.0, 1.0} as red, red and green, preferring the first occurrence of the maximum value, so, grayscales will be placed into red.
  10. 1 point
    Register here: https://attendee.gotowebinar.com/register/7789605953914422787 Michael Lyndon - from game developer The Coalition - is our guest host, joining SideFX's Luiz Kruel in this webinar on Houdini for Games - featuring examples from the just-released Gears of War 4. Topics include: • Transitioning from Film to Video Games as a Houdini Artist • Differences between real-time and offline VFX for a Houdini artist • How to work within the constraints of real-time • Rigid body destruction – building and optimizing a pipeline for speed and detail • Creating velocity fields and flowmaps • Creating looping fire sequences • Using Houdini to Prototype ideas • How we improved our rain system
  11. 1 point
    Small gains yes. Huge gains like 50-100% are very unlikely unless there's a fundamental problem with the implementation in Windows (like mental ray...). It's likely that the simulation parameters are the cause of the difference in performance. OpenCL isn't used for the whole simulation, just parts of it.
  12. 1 point
    64 bits support seems to work in HAPI since : Houdini 15.5.439 Houdini 15.5.439 HAPI: Added 64-bit int and float attribute data getters and setters: HAPI_GetAttributeInt64Data() HAPI_GetAttributeFloat64Data() HAPI_SetAttributeInt64Data() HAPI_SetAttributeFloat64Data() HAPI_Int64 typedef HAPI_STORAGETYPE_INT64 enum HAPI_STORAGETYPE_FLOAT64 enum https://www.sidefx.com/changelog/Main/?journal=&categories=&body=64&version=&build_0=&build_1=656&show_versions=on&show_compatibility=on&items_per_page=
  13. 1 point
    Here are a couple of example files to check out. One demonstrates copy/instancing of volumes along points. Try out the various switch options. The other one is really cool in that it demonstrates smoke clustering by instancing volume domains. This is how you keep your volumes from getting really large. ap_cluster_smoke_on_path_128.hipnc ap_popnet_missile_trail_1e.hipnc
  14. 1 point
    If you convert the nine boxes into binary sequence, it will be more intuitive: Binary Decimal Axes SSSRRRTTT zyxzyxzyx 000000000 0 None 000000001 1 Tx 000000010 2 Ty 000000100 4 Tz 000001000 8 Rx 000010000 16 Ry 000100000 32 Rz 001000000 64 Sx 010000000 128 Sy 100000000 256 Sz 111111111 511 All 100010001 273 TxRySz 000010111 23 TxTyTzRy Note the reversed order Houdini uses internally (Sz Sy Sx Rz Ry Rx Tz Ty Tx) for the mask. By using bitwise OR operator, you build up axes you need: # Using decimal numbers. bmask.set(273) bmask.set(1 | 16 | 256) # Using binary numbers. bmask.set(0b100010001) bmask.set(0b000000001 | 0b000010000 | 0b100000000) # Using named constants. TX = 0b000000001 RY = 0b000010000 SZ = 0b100000000 bmask.set(TX | RY | SZ) The last one is how it's usually being used. It's human-readable in code. You may also make use of AND and other bitwise operators: NO_SCALE = 0b000111111 bmask.set(bmask.eval() & NO_SCALE)
  15. 1 point
    Really interesting presentation of a paper about Multiple-Scattering Microfacet BSDFs
  16. 1 point
    Hello. Since Houdini 12.5 and the addition of the cvex_bsdf() function the user base is no longer restricted to the confines of Phong and Blinn. While these models are tried and true over the past few years newer reflectance models have stepped into the spotlight (pun!), notably the ever so popular GGX. So for the lulz I implemented a variety of the newer ones and would like to share. Ultimately this is an incredibly huge topic and would take a significant amount of writing to explain all the fun bits so instead I'm going to link spam because I got TF2 to play. Background & Learning Physically Based Rendering for Artists (youtubez) Physically Based Specular for Artists Basic Theory of Physically-Based Rendering Cook-Torrance Model in Mantra Shader Microfacet BRDF (This is quite "mathy" but gives a nice overview of what is going on inside the Microfacet VOP) Disney BRDF (Disney's BRDF from Siggraph 2012, minimal parameters with a fair bit of flexibility. Required reading for the Disney VOP and also the GTR VOP) Siggraph 2010 Course Notes Siggraph 2012 Course Notes Siggraph 2013 Course Notes So with that all that background info out of the way on to the toys. In the attach OTL there are a few different VOPs, I've included a brief description here, but I actually (gasp) wrote documentation for each of the VOPs so I suggest you read them. Physically Based GGX (cvex) Microfacet BSDF with a GGX distribution, Schlick Fresnel, and Smith Masking. If you set the model to be "Distribution Only" it disables Fresnel and Masking and is purely just a distribution similar to how Phong, Blinn work. This model also supports anisotropic distributions. Physically Based GTR (cvex) A more generalized version of GGX. (GTR stands for Generalized Trowbridge & Reitz). In fact GGX == GTR when GTR's gamma parameter is 2. This is isotropic, Mathematica and I are still having a disagreement over possible anisotropic solutions. Physically Based Microfacet (cvex) This is everything and the kitchen sink. Its slower and not really meant for production cause it has all the options. But its good for exploring the various models and what they look like. Once a nice combination is found you'd would make a more dedicated and optimized version similar to the GGX/GTR ones above. You might get some fireflies with this for certain combinations as some of the formulas will converge on infinity faster than others. Generally the easiest way to fix it is to increase your Roughness G. The Roughness G parameter allows you to control the roughness Geometry Masking term independently of the distribution. Think of it as a multiplier for how much "micro-occlusion" you want. Disney (cvex) Direct port of the Disney BRDF. The parameters for this are suppose to be generally kept between 0 and 1 however I find the sheen to be way under powered when at a value of 1, so you might need to crank it to 11 to see it. Please read the help card for this VOP, there is some special sauce overriding functionality I added. Disney Mixer VOP for mixing collections of Disney BRDR parameters. (Or BSDFs) How My Versioning Works major.minor.hotfix.build Majors: are full rewrites and I'd be amazed if the look stays the same. Minors: are important changes that might affect the look but I'll try to avoid it as much as possible. Basically I'll only change the look if I'm fixing a flaw. Hotfix optional: is for cases where some bug that needed fixing but doesn't change the look. Build: Builds are the number of commits since the previous release object. These will go up during development and once a release is frozen the build will stop. These don't affect namespacing and only show up in the otversion. Reporting Issues If you have a issue/bug/question please ask, I (we) are using variants of these in production so there will be continued support. When asking tho I ask/plead that you post what version of the shaders you are using. That way I know exactly where to took. You can get this info by middle mousing on one of the VOP nodes or running 'opinfo' on it. For example- / -> opinfo /shop/vopsurface1/pbrdisney1pbrdisney1: Full Name: /shop/vopsurface1/pbrdisney1 Operator type: pbrdisney Version: 1.1.55 Branch: release-1.1 Date: 2014-08-06 Commit: 6fc9e7f All that version, branch, and commit info is music to my ears. (If nothing else, please provide the commit.) Obligatory Renders of Smooth Objects Both these wedges are of the GTR model. One with varying roughness, the other with varying gamma. (Gamma on the GTR model controls how fast the specular tail falls off.) OTLs There are two OTLs, both with the same shaders but one OTL has namespaces and versions on the type names the other one doesn't. If you are going to use these in production or what-not I recommend the namespaced version that way if there is an update later one they can live side by side. If you don't care and are playing just go for the non-namespaced one. All of this stuff currently sits in a private git repo on bitbucket, once everyone bangs on it a bit and I get everything rock solid I'll switch it to a public repo so others can contribute. v-1.2 (devel) bsdf-v1.2.otl bsdf_namespaced-v1.2.otl v-1.1.1 (stable) bsdf-v1.1.1.otl bsdf_namespaced-v1.1.1.otl v-1.1 (stable) bsdf.otl namespaced_bsdf.otl Release Notes: 1.2: Removed roughness masking remapping on the Disney BSDF. (Edges will reflect more light now.) 1.1.1: Workaround for Houdini LLVM bug #63368 Added an Ashikhmin Diffuse VOP which handles microfacet masking 1.1: Initial Public Offering Known Issues: Calculation of albedo needs some thought. Currently the albedo returned is the normalization factor for the distribution function. While this matches how phong() and blinn() are setup, it should instead return the full reflectivity over the hemisphere taking into account frensnel (and masking?).
  17. 1 point
    Try this... Put down a measure SOP and set it to measure the perimeter of your curves. After that a primitive wrangle and write. #include <groom.h> adjustPrimLength(0, @primnum, @perimeter, @perimeter*@dist); groom.h is a included file containing some functions used in the grooming tools and one of the functions is... void adjustPrimLength(const int geo, prim; const float currentlength, targetlength)
  18. 1 point
    Jim is the shit. Just wanted to share a few test renders using his Disney (cvex) shader. I've been working on a nice little otl wrapper for Jim's work, just something to quickly accept texture paths, with built in HSV remaps, displacement, normals, tangent space normals, etc. For my money, this shading model puts the Mantra aesthetic ahead of the other commercially available tracers out there. Quixel Suite model and textures. Uncomposited raw renders + LUT. Last one shows how well this surface model does against the flash bulb test. Also been putting together another wrapper for it that does double sided shading for things like trees, very nice results from that as well. Pardon my scattering a single tree model here to make a forest, but I am a lazy man. Also just a raw render + LUT. Available in 4k if you click. And I sincerely apologize if this formatting ends up looking as awful on the forum as it does in my post preview.
  19. 1 point
    One method is to sculpt your fuel and advect it about with some injected velocity then introduce a very hot source in the middle and watch it go. This means you are advecting your fuel so you will be tweaking a lot to get the look to go. This results in a more organic explosion. When you see the word "organic" it means less direct-able. You can drive things with a particle simulation if you wish. Once thing about injecting a fixed amount of fuel is that you don't have to fuss around with the Gas Expansion parameter. Just set it at a constant value along with the temperature released. These two are key in getting the right explosion dynamics. Once dialled in to your scene scale and fuel amount, you are good to repeat. One thing you have to watch out for is that Disturbance maps in to temperature when using the shelf Explosion and Fireball presets. This will cause your fuel to ignite all over the place before you add your hot igniter. Just set Disturbance to drive in to Velocity instead. ---- Once you get the hang of igniting fixed amount of fuel and advecting it through the simulation, you can then do what they do. Put the fuel source in a bowl on the ground and then let the force of the explosion blow it upward. It is best to map in a large amount of upward velocity yourself as the divergence field may blow down right through your ground collider. Hope this helps. Re-uploaded file: ignite_fuel_explosion.hip
  20. 1 point
    it looks like this is what you want not sure about range of the loop though myNode = hou.node("obj/geo") for index in range(1,12): newNode = hou.copyNodesTo( (myNode,), myNode.parent() )[0] newNode.parm("CHIPID").set(index) [/CODE]
  21. 1 point
    Peter Quint's "Particle Leaves Instancing" video tutorial might be of some help for an overview of the various orientation methods for copied geometry
  22. 1 point
    Sorry if I'm stating the obvious here but using Attribute Promote sum attributes to Detail class is pretty handily the speed and ease of use champion. If you can work that in as a precursor to whatever you're putting together you'll be well ahead of any other solution I can imagine.
  23. 1 point
    Basically it won't work, unless you're in POPs, or inside SolverSOP. VEX virtual machine has a very specific architecture: 1) Copy attributes from geometry into Vex memory arrays. 2) Split array into chunks. 3) Run vex code in one thread per chunk, one time per point. 4) Copy all modified arrays back onto geometry. Accumulating values, recursion etc, are possible only outside VEX. As to attributes, you can access detail's in the same way as points' attributes. VEX will find it by name.
  24. 1 point
    If you want exactly a random 20% how about you just use the randomize sort trick and then in the group sop set max range to 0.2*$N with the 0.2 possibly being a chanel reference to a slider below.
  25. 1 point
    Hi, in Houdini, similar to Maya as I thought, you can think about two or even three languages: 1. Languages: - Hscript (look for help in Texport via "help") - Expressions (look for help in Texport via "exhelp") - Python -(gosh, lets add the forth: VEX) 2. Differences in use: - Hscript executes commands (add operator, delete, rename, link) - expressions computes a value (compute angle, matrix etx) - (Python does both) - (VEX modifies variable's value like point position, surface colour, pixel value etc) 3. Backticks usage: - backticks allows you to place expressions in hscript... - or execute expression in a parameter that does NOT expect numeric value (like string parameter) for example, in file input path, you could write: op:/`opinputpath(".",0)` or: ./my_great_texture.`padzero($F-10)`.rat since this input file field expect string and it couldn't recognize padzero() as an expression in other way. But in case of translation parameter you need just an expression: fit01(rand($PT), 0.5, 1)) without backticks, since a parameter expects numeric value anyway. So: - using expressions inside hscript requires `` - you also need `` to evaluate an expression in non-numeric neighborhood, like strings, paths etc. - but you don't need it if expression is evaluated in numeric parameter. - you can also in opposite use hscript in expression with "run()" or "execute()" functions. - both expressions and hscript are accessible in Python with hou.hscript() or hou.hscriptExpression() (Unless they have pure equivalents in Python like opadd == hou.createNode() ). hope this helps, Simon. PS There are also expressions returning strings like points(), chs() and they need backticks also to be executed in parameters but not taken "as is".