Leaderboard
Popular Content
Showing most liked content on 12/01/2017 in all areas

2 pointsHello I've started with this around H 16 release. Basically wanted to explore, to which level I'd be able to use procedural modeling when it comes to characters. So, "non procedural" part here belongs to another app, exactly Maya, where I've created a base body model, rig, posing  while Houdini part is hair of all sorts (hair, eyelashes, eyebrows..), also a lot of suit. Detailed map, what exactly belongs to which app is here. Let's say that 'harness system' is what I'm considering as most successful part. Later, started with Mantra renders, which turned out in kind of addiction  here are few of around hundred renders of this thing, I did in Mantra.

2 points

2 pointsHere is hiplc with complete ground with ground shader, I've cleaned scene a bit. For distribution of rocks, I think there are better methods described in tutorials around. I've used a sort of simple repeating by modulo to get multiple instances into positions of scattered points. Shader is somewhat special, I've tried to get as much bright 'dry' look, together with as much dark shadows from sun, typical for NASA photos of Mars. So finally there's mix of two PBR diffuse VOPs, one has faded front face to act as a 'dry reflection'. Mix is a bit modified screen blending of these two  instead of 'classic screen blending' where colors are subtracted from RGB 1, here's arbitrary value, I called it 'pedestal'. Effect is exaggerated brightness compared to standard diffuse shading, while color still can't go over 'pedestal' value, also bright parts are gradually blended to that max color, here it is some bright orange. Normally, someone will do such things in post. Doing that directly in render is a bit risky business  as it is for now, I'm not sure is it able to respond correctly to possible additional indirect light. Anyway it seems that Mantra is nicely resistant to such methods.

1 pointGlad you are liking the tool and I appreciate the purchase. The shell is an interesting idea, I’ll add it too my list. I’m thinking I’ll start doing tutorials for how I actually make tools, the not super complex ones anyway.

1 pointThis one should also work if you increase the substeps. LoopParticlesTEST.hip

1 pointIn vex: s@path = "/shop/blablabla"; s@path = re_replace("blablabla", "mat", s@path);

1 pointlike this? I tried a few... failed. One switched from vex to nodes in the middle, expecting me to figure that out. I'm like... can't I just buy the tool!? So.. Aragatory?

1 pointThat 'presets' parameter is calling a callback python script. You could try this: theGeo = hou.node('/obj/geo1/dopio1') # Keyword argument needed by the internal invokePresetMenu function myArgs = {'node': theGeo, 'script_value0': 'pyro'} # The internal python function called by the presets parameter. theGeo.hm().invokePresetMenu(myArgs)

1 pointThank you. I have done multiple tree building tutorials, and it has made me understand not only Houdini better, but also on how a tree, like a central nervous system, is not a simple item once you look at growth, age, materials etc. A tool such as yours, is a welcome addition to the powerful things that Houdini does.... depending on the work put in. So I ponied up the full amount $$ even though I am running the NC edition. You deserve it for the work put in..... Now if only I can find a decent sea shell tutorial, based on the work that Deborah Fowler uses for her students. Again, I dont want to hijack anything, I want to learn how and I think this is a good revenue stream for everyone that is using Gumroad etc. Sorry to ramble. Thanks again for the tool.

1 pointThe standard smooth sop has a dropdown menu in which you can specify what kinds of borders should be constrained. if the uvsmooth doesn't have that same dropdown, you may be able to use a standard smooth sop instead.

1 pointDidn't know it was changed. Works fine for point uvs. Vertex Split by uv with promote > Subdivide > Promote back to vertex > copy in Vertex Wrangle. subdivide_uvs.hipnc

1 pointwhat about uvpelt, Tutte Barycentric, crank up the Boundary Spring ?

1 pointI have some notes on making a camera shader here, and the game shelf has a cool fly eye/imposter generator camera you can pull apart. http://www.tokeru.com/cgwiki/?title=HoudiniOculusWip

1 pointEven though @trandzik already has an amazing solution for creating these patterns, I wanted to take a shot at it myself and ended up with the following. I didn't clean up any of the code, so this is just a mess but it works . divide_grid_2.hipnc

1 pointok this had me scratching my head a bit. for the diagonal section ive used a copysop and switchsop to switch between two diagonals which are copied across the grid using the primitive number. now obviously when i copy this set again across a grid its going to give the same instances of the pattern. so for the first time in my houdini learning, i've had copy stamp a copy stamp

1 pointIt is easier to understand if you simplify setup: for (int i = 0; i < res_lat ; i++) { for (int j = 0; j < res_lon; j++) { // Calculate longitude arc point position. float theta = start_theta + theta_step * j; float phi = start_phi + phi_step * i; matrix r = ident(); vector pos = set(cos(theta), 0, sin(theta)) * r_min; vector axis = cross(normalize(pos), {0, 1, 0}); rotate(r, phi, axis); pt = addpoint(geoself(), pos * r); } } At first, you create points at positions computed by certain algorithm. I guess, you understand what's going on there, since it is mostly your own code. Algorithm itself is unrelated, it's just returning some position given bounds as minimum and maximum angles and iteration numbers, which is common technique for doing such stuff in for loops. Then you just look at the points and their numbers and decide when and how you will start to create quads: It seems, you can create a new quad at each point (ignore corner cases for now). Then we need to compute numbers. Given point 11, for example, we need to compute numbers 1, 0 and 10. To get 1, you need to compute and subtract some value equal to 10. It is necessary to decide this value based on our parameters, rather than hardcode it. It turns out, that this value is the length of the point's row that we specified. Apply same guessing for the rest points going counterclockwise to compute numbers 0 and 10. Then we create a new prim after each point created: int prim = addprim(geoself(), "poly"); addvertex(geoself(), prim, pt); addvertex(geoself(), prim, pt  res_lon); addvertex(geoself(), prim, pt  res_lon  1); addvertex(geoself(), prim, pt  1); Returning to corner cases, we must decide how to skip creation of quads when there are not enough points. So, we must skip 0, 1, ..., 9 and 0, 10, ..., 90. In this points either i of j variables are equal to zero. All we need is to add such check: if (i > 0 && j > 0) { } And final code: for (int i = 0; i < res_lat ; i++) { for (int j = 0; j < res_lon; j++) { // Calculate longitude arc point position. float theta = start_theta + theta_step * j; float phi = start_phi + phi_step * i; matrix r = ident(); vector pos = set(cos(theta), 0, sin(theta)) * r_min; vector axis = cross(normalize(pos), {0,1,0}); rotate(r, phi, axis); int pt = addpoint(geoself(), pos * r); if (i > 0 && j > 0) { // Create a new quad. int prim = addprim(geoself(), "poly"); addvertex(geoself(), prim, pt); addvertex(geoself(), prim, pt  res_lon); addvertex(geoself(), prim, pt  res_lon  1); addvertex(geoself(), prim, pt  1); } } } Same scheme for side surfaces, but you don't need to create points, so, it is simpler. We iterate over longitude divisions to create top and bottom, and over latitude divisions to create sides. We can create two primitives in each iteration. for (int i = 0; i < res_lon; i++) { if (i > 0) { // Create bottom code. // Create top code. } } Notice that check is useless there, since we don't create points and do any other stuff outside it's scope. So, we could set our initial variable right to 1: for (int i = 1; i < res_lon; i++) { // Create bottom code. // Create top code. } Observing the point numbers, when we start at point 1, we need to compute points 0, 100 and 101. What is the hundred we need to offset? It turns out that it is number of points per surface: longitude divisions multiplied with latitude divisions. Using other parameters, we can get different offset value, but it will always be computed by this formula. And the code to create bottom surface: int surface_ptnum = res_lon * res_lat; int prim = addprim(geoself(), "poly"); addvertex(geoself(), prim, i  1); addvertex(geoself(), prim, i); addvertex(geoself(), prim, i + surface_ptnum); addvertex(geoself(), prim, i  1 + surface_ptnum); Same logic for top. When we build multiple segments, we cannot start from i=1, because in this example we need to somehow start from 801: So, easiest way to get this offset, is to keep track of created points in pt variable. The last created point was 999, so, we need to compute 801 from it using parameters we have. By guessing, we choose certain formula: int surface_ptnum = res_lon * res_lat; int start_pt = i + pt  surface_ptnum  surface_ptnum + 1; And final code for top and bottom creation: // Side surfaces. for (int i = 1; i < res_lon; i++) { int prim; int surface_ptnum = res_lon * res_lat; int start_pt = i + pt  surface_ptnum  surface_ptnum + 1; // Bottom. prim = addprim(geoself(), "poly"); addvertex(geoself(), prim, start_pt  1); addvertex(geoself(), prim, start_pt); addvertex(geoself(), prim, start_pt + surface_ptnum); addvertex(geoself(), prim, start_pt  1 + surface_ptnum); // Top. prim = addprim(geoself(), "poly"); addvertex(geoself(), prim, start_pt + surface_ptnum  res_lon); addvertex(geoself(), prim, start_pt  1 + surface_ptnum  res_lon); addvertex(geoself(), prim, start_pt  1 + surface_ptnum + surface_ptnum  res_lon); addvertex(geoself(), prim, start_pt + surface_ptnum + surface_ptnum  res_lon); } And absolutely same logic for the left and right sides, but formulas are different, determined by looking at numbers and available parameters. Formulas, vertex creation order and parameters may be different. But they will always evaluate to same result.

1 pointit is probable that in UVtexture SOP you have mode set to Natural Location this will create Point Attribute for Orthographic but for Polar and Cylindrical it is Vertex Attribute and vertex attributes will not be read automatically by parameter VOP and it should produce nothing but single color but if you are getting noisy color maybe try increasing polygon resolution anyways try to change the mode to Point texture and see if it does anything or append Attribute Promote and promote UV attribute from Vertex to Point since you are creating point Cd anyways, vertex uvs are no use (even though they are more accurate) if you want to use vertex uvs, use Facet SOP to make unique points, then promote Vertex uvs to Point, then your VOPSOP which will create point Cd then promote Point Cd to Vertex then fuse points