Jump to content

Leaderboard


Popular Content

Showing most liked content since 09/11/2018 in all areas

  1. 3 points
    no loops necessary and you should try to avoid them if you can also first point of the primitive doesn't guarantee that it's at the start or at the end or even that the primitive has any start or end if it's closed, so you are better off using points belonging to first or last vertex and either checking if the prim is closed or using the neighbourcount() test so to detect all you can combine first test with test whether point belongs to the first or the last vertex of the primitive int pts[] = primpoints(0, @primnum); int isend = neighbourcount(0, @ptnum) == 1; int isfirst = @ptnum == pts[0]; int islast = @ptnum == pts[-1]; i@group_ends = isend; i@group_start = isend && isfirst; i@group_end = isend && islast; OR mentioned open/closed poly test int pts[] = primpoints(0, @primnum); int isopen = !primintrinsic(0, "closed", @primnum); int isfirst = @ptnum == pts[0]; int islast = @ptnum == pts[-1]; i@group_ends = isopen && (isfirst || islast); i@group_start = isopen && isfirst; i@group_end = isopen && islast;
  2. 2 points
    In a pointwrangle or a group expression SOP: neighbourcount(0, @ptnum) < 2
  3. 2 points
    Because neighbours function return array. Henry just forgot type square brackets after n variable.
  4. 2 points
    The worst thing is shortcuts, navigation and stuff like that. Yeah, I know you can basically redo it completely after spending an hour or two in settings, but damn the original settings are beyond idiotic and they are loosing a lot of newbies because of it. You open the program and the LM button sets weird 3D cursor what is not like any other 3D soft, the selection is on RM button (I know no one who isn't switching it back in Blender) and so on and so on. Blender is AMAZING, but it's biggest problem I'd say in default settings.
  5. 2 points
    It's coming... https://www.eventbrite.com/e/houdini-17-launch-event-tickets-49857673644
  6. 2 points
    Woop I just made a matcap GLSL shader for the Houdini viewport! Will be sharing the shader with some info & explanations soon when I have time.
  7. 2 points
    Woop I just made a matcap GLSL shader for the Houdini viewport! Will be sharing the shader with some info & explanations soon when I have time.
  8. 2 points
    As people above have mentioned the tasks involved in making a shot like this to work, is a team work , fx, lighting, comp and grading to get something like this done , but do not get discouraged, you can always try making something similar if time and resources are a constraint, so quickly put together a hip file , so you can play around with and modify to your needs , and there is a post related this topic in the effects forum, lava flow, so you can refer to that as well , clothsetup.hiplc
  9. 2 points
    Check breakdown of this element without comp. And don't waste time trying recreate this, repeat just similar and simpler, this fx was done by high level team with dozents iterations not newbie. of
  10. 1 point
    Maybe check out the Tokeru file. http://www.tokeru.com/cgwiki/index.php?title=HoudiniDops#Grow_trees_with_particles
  11. 1 point
    Hi Marian, EDIT: sorry for the previous code, this one is better: $HIP/render/${HIPNAME}_`opname(chs("RS_renderCamera"))`_$F4.exr Those curly brackets are needed, because without them $ searches for the variable HIPNAME_ ... because _ can be included in the variable name.
  12. 1 point
    Hi. this is UV boundaries you see in the viewport. press D on viewport and in the first tab (markers) there is a drop down in the lower right. choose No Boundaries. hope this fixes it.
  13. 1 point
    I already did something like that using a SOP Solver and POP Grain, adding geometry on the fly and building constraints on the fly as well (it was for a kind of cloth simulation : a carpet unwinding over stairs). Anyway, what you can do inside the DOP network is : add a SOP Solver, and for each iteration, measure the length of each primitive (the "constraints"), and if it exceeds a certain threshold (a variable to play with), delete the primitve (in a Primitive Wrangle, with removeprim()), but keep the points (the last parameter of removeprim() must be 0); add a new point at the center of the two remaining points, and create 2 new primitives (using addprim(), of type "polyline"), with a restlength attribute and all the other necessary ones : stiffness etc... It means that each time your constraint / primitive exceed the threshold, it dissappears and creates new geo, more detailed, that is added to the sim. Maybe you'll have to play with the newly created restlength attribute of your new constraints, to create tension in your rope (by multiplying the restlength of newly created prims by some factor < 1). The factor should depend on how the rope was stretched at first. It should depend on your threshold as well : if you create geometry once the length is twice the restlength, then use 0.5 on the restlentgh of the newly created constraints... I can upload an example tonight but you have the main directions.
  14. 1 point
    Hi, I have been doing FX using Houdini for almost 1.5 year now, and I have over than 10 years of experience in C++ programming/algorithms. I am wondering what could be improved in Houdini Effects using C++? Is there any kind of effects that require more logic than just using simple VEX or Python scripts? I know there are many translators between Houdini/Arnold/etc. integration that could be written, but I am more interested in Effects programming, i.e. a program that would create hard to create effects using Houdini current built-in tools. Any ideas are really appreciated
  15. 1 point
    from the picture, I can also see you're using GGX specular distribution. that is the most noise prone specular you can have. Try using Phong. It may not give as plausible results but should reduce noise significantly and in most cases looks perfectly fine.
  16. 1 point
    Not sure how much noise vs. render time are we talking about, but refraction rendering in Mantra is currently somewhat more noisy than competitive raytracers. I hope this issue to be addressed in upcoming Houdini release as that should be focused towards rendering (at least that's what I've heard). Right now, you have to bump up render samples to get rid of the noise. Note that you can manipulate direct and indirect samples separately (Quality multipliers on Mantra are only affecting indirect samples). Light samples should help too but beyond 3 samples it usually has no additional effect other than increasing render time. cheers.
  17. 1 point
  18. 1 point
    Or just i@group_ends = neighbourcount(0, @ptnum) < 2;
  19. 1 point
    And looks like you have problems with building constraints. Some pieces hang in the air. It happens when point name attribute of constraint pointing to piece that not exist.
  20. 1 point
    Just another reminder that, if you are too old for discord shananigans, you hate talking about Houdini or VFX, if you feel like supplementing your daily autism by socializing with others like you, than you may like IRC channel #odforce @freenode, which is getting the more 1337 the less users there are. See you on the channel. P.S. Traditionally, everybody gets a moderator.
  21. 1 point
    there's probably an easier way to do this with SOPs, but in VEX: int n = neighbours(0, @ptnum); if(len(n) < 2) { @group_ends = 1; }
  22. 1 point
    Maybe just RBD inherit @v and @w after initial frame http://www.tokeru.com/cgwiki/index.php?title=HoudiniDops
  23. 1 point
    Check out some of the example files here. http://www.tokeru.com/cgwiki/index.php?title=HoudiniDops#RBD_inherit_.40v_and_.40w_after_initial_frame
  24. 1 point
    Hey Amaya, I'm guessing that your code probably works, it's just that you can't have a point ( . ), nor a comma ( , ) in a group name. So in your setup every points of your lines must have had some non-int value, resulting in no groups created at all. Try multiplying the position by 100 and add it as an integer to your group name, or anything that eliminates the point. This is my attempt. Keep in mind that you need to set your wrangle to Run Over Detail. int ptCount = detailintrinsic(0, "pointcount"); // Get the point count // Initial attributes setup vector thePos = {0,0,0}; string groupName = ""; for(int i=0; i<ptCount; i++) { thePos = point(0, "P", i); // Get the position groupName = sprintf("group_%d", thePos[1]*100); // Create the groupName variable // For some reasons, the groups doesn't accept commas, nor points ( , . ) //printf("%d ", groupName); setpointgroup(0, groupName, i, 1); } Here's a quick scene with that code. set_group_by_Y.hip EDIT : .. Actually, here's the same scene but with your code, working. s@test = sprintf("%d", @P.y*100); // %d to have an integer s@groupname = concat("group_", @test); setpointgroup(0, @groupname, @ptnum, 1); set_group_by_Y_1.hip
  25. 1 point
  26. 1 point
    New updates! A quick list of what's new: Automatic update feature for easy future updates! New "Spread Falloff" for growing, crawling effects! spread_falloff_01.hip example file included. Instancer now automatically uses relative paths. Quick Add function in Instancer to add all your objects at once! Instancer now supports scatter density attribute when scattering on meshes. Instancer now supports different merge types ("Into This Object", etc). Falloff Preview now shows points only to prevent crashing. Disable Preview shelf tool turns off all Falloff previews for the entire current SOP chain. Lag and Area added to Audio Falloff.
  27. 1 point
    I think you're right! I was attempting to copy onto the center of the primitive using it's normal to get the direction of the new copy, but I think using the previous matrices will give me more control. Instead of having to manipulate each normal. Thank you so much for a look into some of your work! It's very inspiring. I'm currently in finals week, so I might not be able to post the rework soon, but thank you so much for your help!
  28. 1 point
    Hi Mitch How about this approach? You only need to consider logic of growth direction. triangleGrowth_01.hipnc
  29. 1 point
    Maybe someone will be interested in testing something new. Here in Russia(for this reason render is still little known), a group of people develop new GPU biased+unbiased render(it's absolutely free and open source https://github.com/Ray-Tracing-Systems/). Some features: - Standalone core implemented. - Hydra API. - Plug-in для Autodesk 3ds Max 2017-2019. - OpenCL = GPU + CPU. - PT (path tracing), IBPT (bidirectional PT). - Post processing. - Render elements. There is a version for 3dsmax,Blender's version is already being tested. People wrote to the developers about Houdini's version(that it would be relevant), and they said that they would consider this. Unfortunately, the site is only in Russian,but this does not stop from downloading(especially with google translate). http://www.raytracing.ru/ http://www.raytracing.ru/gallery.html https://www.facebook.com/hydrarenderer https://www.youtube.com/user/RayTracingSystems/videos https://vk.com/hydrarenderer
  30. 1 point
    Hi guys! I would like to share here my latest personal project. Everything done in Houdini and Mantra Hope you like it. Youtube Version: Shark_Youtube.mp4
  31. 1 point
    I typically install an expression into the SmokeObject or the FluidObject which estimates the voxels based upon the box area and the divsize. You can see how to set this up around 23 minutes in this video. The expressions I use are also available in the video description. When I am developing a sim I typically run about 1-4 million voxels for fluid or pyro. When I am happy with the setup I'll kick that up to anywhere from 20-80 million voxels and write that out to a file cache.
  32. 1 point
  33. 1 point
    Hi Yundaz, gave a quick stab at your scene, see if this works for you ,adjusted the collision geo with the same viscous fluid you had and seems to work without any collision artefacts , reduced the velocity scale in the collisions , volume motion tab in the flip solver, but mainly this reacted well as soon as the collision vdb were scaled to the right size as the collision geo, and any minor artefacts i reckon could be reduced with the meshing adjustments Fluid_sim_Test9_solverMod3.hiplc
  34. 1 point
    Scene with test tornado. https://vimeo.com/58393324 tornado_v02.hip
  35. 1 point
    Hey You could create a lens shader (http://mattebb.com/blog/weblog/houdini-fisheye-camera/) or then model your custom lens as an object. Here's a scene showing a sphere with a refracting material and soft edges acting as a mysterious ray bender. distortion_field.hip
  36. 1 point
  37. 1 point
    Few tips and tricks to manipulate gas simulation. 1. Independent resolution grid. E.g. Overriding vel grid size independent to a density grid. 2. Creating additional utilities. E.g. gradient, speed, vorticity and etc which can be used to manipulate forces. 3. Forces via VEX and some example snippets. smokesolver_v1.hipnc P.S. Some of this technique are not Open CL friendly though.
  38. 1 point
    Quick tip about converting dense SDF volumes to VDB SDF volumes.
  39. 1 point
    Houdini tip | Assets versioning workflow
  40. 1 point
    Hello, check out my latest article: Remote debugging of Python running in VFX applications (Houdini, Maya, Blender, Nuke..)
  41. 1 point
    Hey guys, I found the solution now. So even in duveil's file there were some problems that didn't make it work in the end. The first block has to have "fetch feedback" instead of "fetch input" to make it work just like the old loop. File atattched. ForLoop_wrong_done_right.hipnc
  42. 1 point
    Hey There! Any difference if you switch (treat as solid to surface) on top of the boolean tab ? Cheers,
  43. 1 point
    After working for "Velvet" in Munich on a motion graphics job for some weeks, doing mostly finishing, shading and rendering, I can finally do some personal explorations again. :-) "Structures" Playing with Voronoi, rendered with Octane this time (could not decide between Redshift and Octane, so got both in the end ;-) ). The spikes are a funny bug in Houdini that comes up when you are using the local transform on per-polygon polyextrusion... Done in my brandnew Houdini Core license, served from my "mobile license server" (an older Netbook with low powerconsumption I no longer use). Cheers, Tom
  44. 1 point
    Since I couldn't figure out how to really fuse and connect points of different wires while still getting the wire solver to work properly I just connected the points with spring contraints. Much easier solution even though there's still lots of space for improvement... wire_constraints.hipnc
  45. 1 point
    I couldn't let this one go; python sop is a little slow (though having a built in complex type is super handy), thought I'd try and port it to vex. This is substantially faster than the python one, the code is a little messy. Tried to get a complex struct happening too, but that got boring really quickly, so just abused some vector2 variables instead. Interesting that there's some errors in the vex one that aren't apparent in the python one; not sure if that's due to vex precision errors, or because my complex divide function isn't doing the right thing; I found a few C examples of dealing with complex number, some did lots of tests within their divide functions for when values were near 0, I went lazy and found another example that did no testing at all....) -matt complex_v02.hip
  46. 1 point
    for shrinking, modifying your rest geo is the way to go ts_shrink_cloth.hip
  47. 1 point
    There was an error in pop_too_close wrangle. It deleted both intersecting bubbles, not just the smaller one, drastically reducing bubblecount. Normally it should remove only degenerate bubbles almost enclosed by neighbours. It also seems that whole loop can be replaced with a point wrangle. So, it cooks instantly now, retains topology and scales better. Scattering and pscale setup really matters. You need to generate a good foam first, before doing intersections. The current setup should be improved somehow. bubbles2.hipnc
  48. 1 point
    would you please know how to: enable Use Menu on menu tab change it to Toggle (Field + Multiple) set it to Python Script and use this script inside? node = hou.pwd() geo = node.geometry() res = list() groups = geo.primGroups() for i in range(len(groups)): name = groups[i].name() res.append(name) if name in (kwargs['parm'].eval().split(' ')): name += ' *' res.append(name) return res thats the last piece im missing
  49. 1 point
    This sorta thing? dop_rotation_via_sop_solver.hipnc There might be a way to do it as you were describing, but I think this way might be a bit easier (unless I'm misunderstanding your question again). @v is recognised by houdini as velocity, when this is on particles and packed objects it will push them around. @w is recognised as a rotation force, not very interesting for particles and points, but handy for things with shape and volume, like dops. I've got 2 setups in this file, a simple one and a less-than-simple one. The first shows what happens when you set @w, and feed it to a packed rbd setup; it does an impulse force, so the shapes get rocked on the first frame, then stop. The other dopnet incorporates a sop solver. In it all I do is set @w the same way as the first one outside of dops, however because this gets an updated position every frame, and its recalculated every frame, it acs as a constant rotational force. I guessed this might be for more of your trundling object experiments, hence the ground plane and gravity forces. There were a few other things in your setup that weren't quite right: -You copied the boxes, packed, then attrib copied orient onto the packed boxes. The problem was that attrib copy matches by ptnum by default; you had 10 packed boxes, but 80 points (10 boxes * 8 points each = 80). It was just doing a straight match of the first 10 to the first 10, so the orient values were all wrong. The copy sop can pack geo, so I enabled that to ensure the point counts were identical -your vop force didn't seem to be reading in the orient values at all. you could disconnect the first getattrib vop, the behaviour didn't change -I just used @w = @N, you could probably unpack @orient and extract the axis you want as you already did, but @N is easier.
  50. 1 point
    Project Non-Divergent Step and Mushrooms The Project Non-Divergent DOP is responsible for 99.9% of the simulation's behaviour. Yes hundreds of DOPs inside the Pyro Solver all playing a part but all funnelling through that single Non-Divergent step. This means that if you don't like the look of your sim and the mushrooms, it's ultimately because of the Non-Divergent step creating a vel field that doesn't do it for you. If you want to see for yourself, unlock the Pyro Solver, dive in, find the Smoke Solver, unlock that, dive in and find the projectmultigrid DOP and bypass it, then play. Nothing. For most all Pyro sims, this is the Project Non-Divergent Multigrid as it is the fastest of the Non-Divergent micro-solvers. This specific implementation only takes the vel and divergence field and assuming across the timestep that the gas is non-compressible when divergence is 0, will create a counter field called Pressure and then apply that pressure field to the incoming vel to remove any compression or expansion and that gives you your velocity, nice turbulent and swirly, or combed straight out. Just tab-add a Project Non-Divergent Multigrid DOP in any dop network and look at the fields: Velocity Field, Goal Divergence Field and Pressure Field (generated every timestep, used, then removed later on). All the other fields in Pyro are there to affect vel and divergence. Period. Nothing else. At this point I don't care about rendering and the additional fields you can use there. It's about vel and divergence used to advect those fields in to interesting shapes, or mushrooms. If you want to create your own Pyro Solver taking in say previous and new vel, density, temperature, and then in a single Gas Field VOP network, create an interesting vel and divergence field, then pass that straight on to the Project Non-Divergent Multigrid microsolver, then advect density, temperature and divergence afterward, go for it. Knowing that only vel and divergence drive the simulation is very important. All the other fields are there to alter the vel and divergence field. So if you have vel vectors that are combed straight, divergence (combustion model in Pyro) or buoyancy (Gas Buoyancy DOP on temperature driving vel) have a lot to do with it. Or a fast moving object affecting vel...
×