Members

2

3

Members

1

826

Members

1

314

Members

1

73

## Popular Content

Showing most liked content on 03/01/2015 in all areas

1. 2 points

## mbPlumage version 1.1 released

Hi folks, I'm proud to announce the newest update of my digital asset, mbPlumage. Let me know what you think about it. For more info, please visit http://tools.haybyte.com/ The asset is available on orbolt. Cheers, Michael
2. 1 point

## Construction visualisation

One more architectural visualisation work. Entirely done with Houdini. Trees and picker are purchased models, everything else is done with Houdini. Some of the grass is Houdini some painted later. A lot of post-work is there using Affinity Photo beta. This is one of WIP images.
3. 1 point

## Note from journals

For those who missed it
4. 1 point

## FLIP smorganic/sheeter effect?

Ok! First - the most important part of the method. Check this diagram and attached file - they are the core algorithm I came up with. 1. Let's say we have a simple 2d point cloud. What we want is to add some points between them. 2. We can just scatter some random points (yellow). The tricky part here is to isolate only the ones that lay between the original point cloud and remove the rest. 3. Now we will focus just on one of the points and will check if it is valid to stay.Let's open point cloud with certain radius (green border) and isolate only tiny part of the original points. 4. What we want now is to find the center of the isolated point cloud (blue dot) and create vector from our point to the center (purple vector). 5. Next step is to go through all points of the point cloud and to create vector from yellow point to them (dark red). Then check the dot product between the [normalized] center vector (purple) and each one of them. Then keep only the smallest dot product. Why smallest - well that's the trick here. To determine if our point is inside or outside the point cloud we need only the minimum result. If all the points are outside , then the resulted minimum dot will always be above zero- the vectors will tends to be closer to the center vector. If we are outside the point cloud the result will always be above zero. On the border it will be closer to 0 and inside - below. So we are isolating the dot product corresponding to the brightest red vector. 6. In this case the minimum dot product is above 0 so we should delete our point. Then we should go to another one and just do the same check. Thats basically all what you need. I know - probably not the most accurate solution but still a good approximation. Check the attachment for simpler example. In the original example this is done using pointCloudDot function. First to speedup things I'm deleting most of the original points and I'm trying to isolate only the boundary ones (as I assume that they are closer to gaps) and try not to use the ones that are very close together (as we don't need more points in dense areas). Then I scatter some random points around them using simple spherical distribution. Then I'm trying to flatten them and to keep them closer to the original sheets - this step is not essential, but this may produce more valid points instead of just relying on the original distribution. I'm using 2 different methods - the first one ( projectToPcPlane ) just searches for closest 3 points and create plane from them. Then our scattered points are projected to these closest planes and in some cases it may produce very thin sheets (when colliding with ground for example). There is a parameter that controls the projection. Then second one is just approximation to closest points from original point cloud. Unfortunately this may produce more overlapping points, so I'm creating Fuse SOP after this step if I'm using this. The balance between these 2 projections may produce very different distributions, but I like the first one more, so when I did the tests the second one was almost always 0. Then there is THE MAIN CHECK! The same thing that I did with the original points I'm doing here again. In 2 steps with smaller and bigger radius - to ensure that there won't be any points left outside or some of them scattered lonely deep inside some hole. I'm also checking for other criteria - what I fond that may give better control. There may be left some checks that I'm not using - I think I forgot some point count check, but instead of removing it I just added +1 to ensure that it won't do anything - I just tried to see what works and what not. Oh and there are also some unused vex functions - I just made them for fun, but eventually didn't used. So there it is. If you need to know anything else just ask. Cheers EDIT: just edited some mistakes... EDIT2:file attached pointCloudDotCheck.hiplc
5. 1 point

## vertex UV in GLSL

OpenGL natively supports two attribute classes - detail and point attributes. Primitive and Vertex attributes are not natively supported and require extra shader support. Vertex attributes in particular require a geometry shader stage to assign the vertex attribute to each vertex of the triangle primitive. If you do a File > New Operator Type, then SHOP:GLSL, you'll see a sample GLSL shader in the Code tab which shows how this is accomplished. The relevant code in the geometry shader is: in parms { vec4 pos; vec3 normal; vec4 color; vec2 texcoord0; float selected; } gsIn[]; out wparms { vec4 pos; vec3 normal; vec4 color; vec2 texcoord0; noperspective out vec3 edgedist; flat out int edgeflags; float selected; } gsOut; uniform int attrmodeuv; uniform samplerBuffer attruv; int HOUprimitiveInfo(out ivec3 vertex); // will be linked in void main() { .... ivec3 vertex; int prim = HOUprimitiveInfo(vertex); if(attrmodeuv == 0) // point gsOut.texcoord0 = gsIn[0].texcoord0; else // vertex gsOut.texcoord0 = texelFetch(attruv, vertex.r).rg; .... } The 'attrmodeuv' uniform selects between point and vertex normals. The attruv texture buffer object contains the uv vertex data. The code assigning to gsOut needs to be done once per vertex, though with gsIn[0] and vertex.r, gsIn[1] and vertex.g, and gsIn[2] and vertex.b.
6. 1 point

## SLI for openCL

The memory limitations on GPU have definitely persisted longer than we expected. And unfortunately even if you can get a 12GB NVIDIA card, their OpenCL driver is still 32-bit at the moment so you're still limited to 4GB per process. The silver lining here is that there are some production-level sims that can fit in 4GB, and we still get a very nice speedup for Pyro / Smoke using OpenCL on the CPU without the memory limitations (particularly with some of the more accurate advection schemes introduced in H14). And the newer uses of OpenCL in H14 for the grain solver and FLIP solver only accelerate smaller-but-expensive iterative parts of the sim and are less memory hungry. For example I think production-scale sims are absolutely possible on the GPU with the grain solver. If you're in a big studio where almost all sims are done on the farm, the lack of GPUs on most render farms is obviously an issue. The OpenCL CPU driver can help there, but there's a bit of chicken-and-egg issue on getting more GPUs on the farm. But these days (especially with Indie) a lot of production/commercial quality work is being done by small studios or individuals; for them running a big grain sim overnight on a GTX 980 is a really nice option.
7. 1 point

## CopySop with POPs. Triggering animation when the particle collides&#33

you can add "hittime" attribute in Collision POP then use that information to offset animation in Timeshift SOP to be able to use \$HITTIME variable in Copy SOP you need to add Attribute Create SOP after POP Network (point attribute "hittime", variable "HITTIME") and uncheck Write Values then create stamp variable something like \$T-\$HITTIME of if(\$HITTIME==-1, 0, \$T-\$HITTIME) then stamp this in Timeshift SOP in Time parameter (Method: By Time)
8. 1 point