Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

Leaderboard


Popular Content

Showing most liked content since 03/18/2017 in all areas

  1. Hello Everyone, This is a recording of the presentation I gave at the sidefx booth at GDC. Topic: Creating a custom grooming system in Houdini for VFX and Games. Chapters: --Hair grooming For VFX. --Auto generating cards with texture for Real-time rendering. --Exporting the hair for real-time rendering using Nvidia Hairworks. I hope you guys like it! If you have any questions please feel free to email me at sabervfx@gmail.com Link: https://vimeo.com/sabervfx/hairfx Thanks Saber
    10 likes
  2. drive.google.com/open?id=0B5Ol7zmvIewTQlRVYkN0cWVDUnc
    7 likes
  3. please take a look at the attached file. it´s an example how you could create bezier curves with arbitrary degree and another one relying on beziers in hermite form since you wrote about blending curves... petz curves_vex.hipnc
    6 likes
  4. http://www.openvdb.org/download/openvdb_particle_storage_2015.pdf
    3 likes
  5. You can use a Sop Solver DOP to set forces for your points. H16.0.550 Indie - WindDirection_v2.zip
    3 likes
  6. 2 likes
  7. In H16 we finally dropped the requirement that C and A must exist regardless of the actual file contents. This is good in a lot of cases (why create C and A when an EXR contains only Pz) and was pushed by the Terrain project. It was also the original intent of COPs, so I'm glad that this change finally happened. Unfortunately, due to the fact that this restriction has been in place for a dozen versions or so, a few cases that expect A to exist have now broken, the lumakey and chromakey among them.
    2 likes
  8. Here is my revision of your scene. I added an Extrude Volume to the landscape, instead of the polyextrude to make the terrain have a lot of boxy space to insure better collision. I returned Gravity to the defaults. I enabled hits on the particles and set their collision state to Slide. I added Drag to the particle system and reset Friction to the default of 1.0 for the collision surface and the popobject. I added the temperature field to the resize_container node so it better detects the bounds. I also disabled Max Bounds so the box can grow as needed. I lowered the Scale Source Volume and the Scale Temperature inside the Smoke Simulation drastically. I set it to 0.05 instead of 1.0. Keep these two values matched. If you change one, change the other. Inside the smoke source I disabled Curl Noise on the Density and enabled Curl Noise on the vel field. I reduced Bouancy Lift and reset the Simulation parameters to their default. This removed the time scale and viscosity attempts you had in place. I think the key to keeping the smoke from getting too far ahead of the moving mass is the scale parameters on the Source Volume inside the Smoke Simulation. You may want to add a RBD tumbling simulation along the leading edge as well. I'm not really sure how to detect that in this setup, however? ap_Pyro_Flow_6.hipnc
    2 likes
  9. 2 likes
  10. well, there are many different ways of doing it. the crude one is to just recursively sample the curve and search for the point with the smallest deviation angle. this should what works for any case. the more elegant method however, would be to use a polynomial and solve it for the position on the curve at which the angle deviation is 0. hth. petz curve_find_point.hipnc
    2 likes
  11. MMB on digital assets and subnetworks show actual total cook time of all nodes encapsulated inside. Right now it's always a small number that isn't an accurate representation.
    2 likes
  12. Put all point positions into an array and make parameter "t" slide e.g. from 0 to 1 inside a for loop. int steps = chi('steps'); vector all_points[]; resize(all_points, npoints(0)); for (int i = 0; i < npoints(0); i++){ all_points[i] = point(0, "P", i); } int prim = addprim(0, "polyline"); for(int i = 0; i < steps; i++){ float slide = i / float(steps - 1); vector pos = spline("catrom", slide, all_points); int inter_pt = addpoint(0, pos); addvertex(0, prim, inter_pt); } Also a simple function for interpolating 4 points to a curve by yourself would be: int steps = chi('steps'); vector pt0 = point(0, "P", 0); vector pt1 = point(0, "P", 1); vector pt2 = point(0, "P", 2); vector pt3 = point(0, "P", 3); int prim = addprim(0, "polyline"); for(int i = 0; i < steps; i++) { float slide = i / float(steps - 1); vector pos0 = lerp(pt0, pt1, slide); vector pos1 = lerp(pt2, pt3, slide); vector ipol = lerp(pos0, pos1, slide); int inter_pt = addpoint(0, ipol); addvertex(0, prim, inter_pt); } VEX_spline.hipnc
    2 likes
  13. It's okay, I found out! For those who might want to know, you have to write your flip fluid's name in the fluid force node, and then play with the object's mass to make it influenced. And this node only works for Cloth Dynamics (not FEM for exemple).
    1 like
  14. Those Xeons are very nice - better than the i7s I could find, for total Ghz frequency, ~0.2 Ghz slower per core, more than double the cache and can access way more ram. 2 processors will work very well for nicely threaded stuff. Also maybe the pcie lanes are better suited when you have lots of GPUs but not sure on that. Check out the compiled blocks nodes to see where Houdini is going. Your rig will probably last between 2-4 years, so that's H16-H20, and SideFx simply keep optimising their tools. You can't lose. The AVX 512 may become optional like the current 'Houdini supports MMX and Streaming SIMD (SSE2) where present'. I assume it will be first supported by the Intel OpenCL compiler, so that part will automatically use it. Avatar Ren, above, knows much more about this though Guide to Automatic Vectorization with Intel AVX-512 Instructions in Knights Landing Processors https://colfaxresearch.com/knl-avx512/ Compiling for the Intel® Xeon Phi™ Processor and the Intel® Advanced Vector Extensions 512 ISA https://software.intel.com/en-us/articles/compiling-for-the-intel-xeon-phi-processor-and-the-intel-avx-512-isa
    1 like
  15. Here's a very quick example file - and a low res quick render example. There's a neat way to customise the colours and quite a bit of control over the shape, and I'm sure with a bit of time and thought it could be improved greatly! Hope this is helpful! Matt. cloud_burst_setup_basic_H16.hip
    1 like
  16. Hm... Im pretty sure I never had to delete any groups to make it working, but... I rarely use H and once I jump back in I tend to forget its a different soft and forget how to investigate things Yeah we do have that But if you had a chance working in max you would probably have the same. Plus need those renders by tomorrow, so its stresful Thank you so much!
    1 like
  17. Haven't looked into the current line ups but you want faster single core speed over slower mulit-cores as ops aren't perfectly threaded and fast single speed will improve every bit of Houdini including the gui interaction. Memory bound ops can be affected by mult-core transfers so very large sims may need a different setup to generalized 3d work. Naples may be super-wicked for that. Rendering is the most improved part with multi-core but that should be weighed against using Redshift instead of Mantra, and with openCL starting to play more of a role in Sops and Dops too, which will run very well on the GPU. Then there is the newer 512bit vector ops in the high-end Intel chips. If Houdini can use that then it will also change the equations.
    1 like
  18. It seems they don't work in 16.0.547 (don't produce any Alpha as you discovered). Only LumaMatte works. Bug submitted.
    1 like
  19. If you are using the default setup, it will use the surface field as well to fill in. Thats probably what you are seeing.
    1 like
  20. Good question ! theoretically you can use in a (point context) wrangler : setprimintrinsic(0, "pivot", @ptnum, set(6,6,6) ); But that will move your geometry and update your "packedfulltranform" attributes into the inverse of your new pivot offset. >> If you import an alembic from Maya you get the same values on : - Point Position - intrinsic "packfulltransform" - intrinsic "pivot" >> If you export an alembic from houdini /out on which you animated objects nodes on the /obj level you get the same behaviour as the above, all attributes are updated in same manner. >> But if you have 1000 objects inside an object node and you want to tweak and set correct "packedfulltransform" + "pivot" + having the correct translation on your points, you will find out that there is some secret magic that takes : the "pivot" and tries to compensate on the point position and packedfulltransform matrix ? one to the other every time you change something . (and of course updating the packedfulltransform) -- It would be great if someone could tell us, how intrinsics update exactly ? -- Is there a way to set your own pivots that follow your pack object ? -- The "centroid" option on the "pack" node looks like the correct thing (gives you an animated intrinsic:pivot ), is there a way that can be initialized with an offset ? -- Using "origin" option on the pack node gives you 0 values on pivot, packedfulltransform and point P, but the object still moves in the viewport (voodoo?), does that mean there are other attributes that are not exposed to the user ? Thank you , Best!
    1 like
  21. There is a Mantra procedural written for it but it hasn't really been requested to be integrated into Houdini/Mantra natively yet. There will likely need to be a bunch of work done regardless . See https://github.com/dreamworksanimation/openvdb/pull/107
    1 like
  22. Ce is Emission and doesn`t belong in the surface color. If you are using physical based rendering, just connect the yellow BSDF ports. In case you are layering shaders, make sure to finish with layerunpack node and connect its F to the surface output. http://www.sidefx.com/docs/houdini/shade/build#generating-outputs
    1 like
  23. Works like a charm - you guys are awesome - OD Force rules, as usual! Posted it on SESI forums as well (crediting you guys, of course) perhaps it'll help someone else with this issue some day. Much appreciated, guys! On a sidenote, I really gotta get into HOM, hehe, I've just pushed it forward for years now...
    1 like
  24. This one will toggle the guides for all visible Scene Viewers: panes = hou.ui.currentPaneTabs() for p in panes: if p.type().name() == 'SceneViewer': guide = hou.viewportGuide.NodeGuides val = p.curViewport().settings().guideEnabled(guide) p.curViewport().settings().enableGuide(guide, not val) Thanks again to Tom, for the general code to toggle the guides. The documentation currently seems to incorrectly list guideEnabled as enableGudie (notice two entries of enableGuide in GeometryViewportSettings). RFE'd! H16.0.550
    1 like
  25. connect the floor points to the foot points by an id and then manipulate those curves?
    1 like
  26. I was walking by a buddies machine the other day, and saw this as his houdini UI theme. I asked if he would share it. so here it is Slate_houdiniTheme.zip
    1 like
  27. This is my first test on a pretty simple setup. I did it with some pop nodes so it's not heavy like a flip solver. I'm not really happy with the floating parts, but maybe I will forget them because if there is no water where they are floating in the final sim it will be weird... Tell me what you think of this. =) FakeWaterTest01.mov
    1 like
  28. Thanks for doing this, the video looks like it covers all sorts of really cool techniques. Can't say how nice this is to see.
    1 like
  29. This tutorial goes over from start to finish the creation of a rudimentary fence asset that can easily be expanded upon. This is an introductory lecture on procedural modeling in Houdini I gave at Drexel University's SIGGRAPH chapter as a Junior Animation & FX major. Let me know if you have any questions, enjoy! Link To Demo File: drive.google.com/open?id=0B--RBrg9u--oWkNDU2ZUYnFpUjQ Link to Documented File: drive.google.com/open?id=0B--RBrg9u--odEhVYnluaFRGeGs
    1 like
  30. with H16 what you can do is just rename your "perm" attribute to "segment_length" (or "num_segments" alternatively) and enable overriding attributes (should be enabled by default I think)
    1 like
  31. Thanks, you are right,. If I lower both the Scale Source Volume and the Scale Temperature, I do get a "cooler" burn in my pyro. I guess I'll keep dialing them down till it looks right.
    1 like
  32. there's a few different things going on here - the first post is a Vop ramp, which doesn't render to GLSL, the second is a material that most likely doesn't have a OpenGL tag for the texture but it does bring up that H16 is meant to have better OpenGL tagging. haven't seen how this works in practice yet.
    1 like
  33. v is the explicit type cast for the attribute. v= vector, f = float, i = integer and s= string. So you may see those other prefixes in posted code as well. Most common attributes, such as, P, v, ptnum, Cd etc don't need explicit casting but every once in a while you will find that VEX may complain about automatic type casting not working. In those cases you need to specify the type or explicitly convert to the destination type manually by using int() or float() functions.
    1 like
  34. it wouldn´t be too hard to implement but if you need the actual distance along a mesh it´s most probably the geodesic distance what you want. the advantage of using biharmonic distance is that it´s rather smooth but not necessarily exact ... petz
    1 like
  35. It wasn't loading the reflection map size properly from the display options save file. As of build 552, set it to 512 and Save as Defaults again, and it should be good to go.
    1 like
  36. 1 like
  37. For non-gray colors, you should vary the seed value for each color component, e.g: @Cd = set (random(@ptnum + 123),random(@ptnum + 456),random(@ptnum + 789));
    1 like
  38. @scale = set(1, noise(@P) * 2-1, 1); You are missing @P
    1 like
  39. Create stretched noise based on UV coordinates to displace the surface (either shader or geometry based). A ramp node after the noise can help to further define the gills. Play around with different types of noise, too. gills.hipnc
    1 like
  40. 1 like
  41. hey houdinaughts i am trying to do a full project from scratch all made by me, including the shooting on chroma of the players that will be composited directly in houdini. The concept is simple, a player does a power shot and the goal catch it, it is basically a power trip. -The scene include smoke, rbd, fur, particles i am still working and undecided on the lighting. anyway here is some renders i did today. here is the preview animation: https://vimeo.com/72697674 criticism is very welcome PS: thanks to people who are helping on the forum for your great tips
    1 like
  42. ...or the internal editor could be brought up to snuff, would be even better... ;-) (sorry, couldn't resist) Cheers, Tom
    1 like
  43. Re-rendered the ocean with the noise mask off and now it loops perfectly: Cheers, Tom
    1 like
  44. Hello, I've revamped this thing in H16. Basically it's same, just changed a long distance geometry query to VDB sampling, it seems to fits best. Also added some auxiliary functionalities, like reversing polygons if needed, uv creation and such. It's created by H SOP and VOP arsenal. Get hiplc here. How it works: First step is volume sample of VDB representation of another mesh. Sampled SDF is saved as float attribute, zero SDF is used by PolyCut SOP to create intersection curve. Final offset Cuts on meshes are also PolyCut SOP done by spatial query, XYZ Distance VOP and such. Intersection curve is re-sampled down and converted to NURBS, to get as much smooth fillet. From that curve, there's spatial query to cuts on meshes, to get closed points. In next step, curve is re-sampled again to final fillet resolution, also there's new spatial query to cuts, this time only to match the final position, while orientations are derived from low res curve. This is to avoid 'bulging', invoked by linear cuts over polygons. Last step is six point bezier curve, well known as G2 blend in NurbS world, used to loft the fillets, by Skin SOP. More specific, what it can and can not do: - it automatically creates NURBS style fillets around intersections of two polygon meshes. - it wants two closed meshes as inputs, while second mesh has to be perfectly closed (no boundary edges) - will see is there a simple way to improve that. - it is able to perform fillets over fillets - only in case of closed second input. - it is able to deal with multiple intersections, or multiple (closed) volumes, let's say created by Merge SOP. - it creates fillets from union, intersection or subtraction. Default is union. - it creates UVs on fillets. If there are existing UVs on inputs, H will keep them. - it aligns normals (or exactly, vertex order) of created fillet, to first input. - each intersection has to be 'closed', that is, resulting in closed curve, in order to work properly. - meshes has to be nicely subdivided before inputs. It's just cutting over supplied inputs, it won't create new, smaller polygons. - it does not work well with sharp curvature - will see is there a way to improve that. - fillets should not overlap. - resulting meshes are just stacked, there is no any re-meshing, at this point.
    1 like
  45. 1 like
  46. Funny story folks. I actually just figured it out within 15 minutes of posting this. Here is the solution: COLLISION_GEO_01 || COLLISION_GEO_02 || COLLISION_GEO_03 || COLLISION_GEO_04 One trigger and one transition. Use double pipes "||" to separate the RBD objects. Apparently the || expression meaning OR works in the triggers. Hope this helps others in the future! Best regards, Sam Welker
    1 like
  47. 1 like
  48. 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
    1 like
  49. I think it is kind of one-trick pony setup. All that additional FOREACH is doing is scaling the 3 spheres by zero to use their center point for the fracture points. In this quick modification I have scattered a few points across a grid and introduced some random size. The logic behind this network kind of breaks down. Not sure why? Perhaps clipping needs to take size into account? ap_bubbles.hipnc
    1 like
  50. 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)
    1 like