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.

StopTheRain

Members
  • Content count

    5
  • Joined

  • Last visited

Community Reputation

0 Neutral

About StopTheRain

  • Rank
    Peon

Personal Information

  • Name
    Konstantin
  • Location
    USA
  1. Animated source point cloud might be in the range of millions of points. So far I have abandoned idea to do the whole transformation form set of points to texture in shader. Manipulating source points in SOPs and exporting the resulting point cloud for use in shader works better so far. Here is static example of my source points and the texture that is created from them. Possible flickering due to the fact that source set of points is the result of particle simulation is a big concern now. Have not tested yet on sequence, but some sort of accumulation using SOP solver would be probably necessary.
  2. kleer001, Thanks a lot for your reply. I certailny need to investigate possible use of findshortestpath SOP for what I am trying to accomplish. Though I am more after some sort of Delaunay triangulation for randomly distributed set of points, but not creating random shapes based on that set. One thing I guess I am agree with you is that this could be easier (though slower) done in geometry context then in shader and then passed into shader afterwards. Particularly after seeing tutorial on cmivfx.com called "Houdini vein work". There is lots of VEX inline code in that tutorial instead of VOP networks, but results are looking somewhat closer to what I need to achieve
  3. Still no luck. Here is another example with the same data of trying to connect points from point cloud file in shader. This time instead of using distancePointToLine VOP, direction of vectors is used: first - between 2 points of point cloud, second - between one of those point cloud points and shaded point. The final goal of those exersises is creating some cool looking dynamic textures based on relatively sparse particle simulations. So far I am stuck at the base level of "connecting the dots". lines2.hipnc
  4. Hello, I am trying to create lace-looking texture on a grid using positions of the points scattered on that grid instead of some UV-based noise VOP. I use point cloud VOPs and distancePointToLine VOP to create a texture where each point is connected to its neighbors with one line. And by changing search radius in pointCloudOpen VOP I can make it so that only close neighbors are connected. It works fine for 3 points or for more then 3 points as long as they are equidistant. And I am getting lines overlapped sharply when I am using point cloud with somewhat random point distribution. Could someone please suggest how to fix that or maybe use another way of connecting points other then with distancePointToLine VOP. So that there is no sharp gaps where lines intersect. lines.hipnc
  5. Just wanted to add something to that year old thread. Topic starter mentioned problem when large groups of foam particles disappear suddenly and re-appear again. I have encountered the same problem with my simulation and no recipe described here (short of sticking particles to the surface with GasParticleMoveToIso DOP) helps. And I have seen the same problem with white water simulatios that other people are working on. Particles in whitewater solver DOP get classified into foam, spray and bubbles classes based on their proximity to surface. That surface volume is generated in whitewater source SOP and gets pulled into DOPs in whiteWaterSolver DOP | fetch_surface DOP | object_merge_1 SOP. Sometimes at least in my case that object merge fails to read "surface volume", and as a result particles at current time step get classified based on their proximity to the surface generated for one of the previous time steps. My fix for that is to generate separate output from white water source object consisting only of "surface" volume and set that as an input for above mentioned object merge SOP inside whitewater solver. Not sure that I will have luck re-creating that situation in simple example .hip file to send bug report to SIde Effects. Anyway that fix might help somebody.