Jump to content

Search the Community

Showing results for tags 'intersect'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Lounge/General chat
    • Education
    • Jobs
    • Marketplace
  • Houdini
    • General Houdini Questions
    • Effects
    • Modeling
    • Animation & Rigging
    • Lighting & Rendering + Solaris!
    • Compositing
    • Games
    • Tools (HDA's etc.)
  • Coders Corner
    • HDK : Houdini Development Kit
    • Scripting
    • Shaders
  • Art and Challenges
    • Finished Work
    • Work in Progress
    • VFX Challenge
    • Effects Challenge Archive
  • Systems and Other Applications
    • Other 3d Packages
    • Operating Systems
    • Hardware
    • Pipeline
  • od|force
    • Feedback, Suggestions, Bugs

Product Groups

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Skype


Name


Location


Interests

Found 9 results

  1. I have a scene with a lot of particles that I am trying to optimize. I've already culled the particles outside of the camera, but I want to get rid of the ones that aren't seen by the camera's rays (the shape is blobby, so I can't just use the z position). What I'm trying to do is take into account the pscale and delete the particles that are hidden behind others. I have a basic working solution in sops via a for each, but it's painfully slow. I want to try and do this with vex. The end result would need to work on millions of particles. The basic steps I thought of are: 1- find direction to cam 2- ray particles to cam (rayline) 3- find neighbors along the rayline 4- use pscale to determine if this intersects with neighbors' pscale 5- if it intersects multiple times, remove the original point I've attached a file for what I used in sops. If anyone has any ideas on how to make it faster or a way to get it working with vex it would mean the world to me. I assume it would be with the intersect() function, but I'm not very familiar with it. Thanks particle_intersect.hip
  2. I've scattered randomly sized and colored metaballs onto a grid (some of which merge), converted them to polygons and then boolean intersected them with the grid, to get colored slices as attached. The slices have color striations (attached). Does anyone know what's causing the striations and how to avoid or get rid of them so that I have flat colors?
  3. Hi everyone, I posted some progress in another thread (Sidewalks - PathDeform? - Modeling - od|forum (odforce.net)). My VEX code for detecting intersecting geometry only seems to work on some parts of the model, whereas on others it does not seem to work at all. My idea for the code was to iterate over all points and fire a ray each up and down, to see if there is more than one intersection (it seems it generates always 1 intersection, for the self intersection), and if the point intersects with the geo, its added to a point group, so it can be fused at a later point. What could be the reason, that it only works on some parts of the model? vector RayDDown = {0,-100,0}; vector RayDUp= {0,100,0}; vector hitPos[]; int hitPrims[]; vector hitUVW[]; float tol = 0.00001; float ttol = 0.00001; int expand = 0; int stepping = 2; expand = expand * stepping; i@IntersectDown = intersect_all(0,@P, RayDDown, hitPos, hitPrims, hitUVW, tol, ttol); if (@IntersectDown > 1) { setpointgroup(0,"Intersecting", @ptnum-expand, 1, "set"); setpointgroup(0,"Intersecting", @ptnum, 1, "set"); setpointgroup(0,"Intersecting", @ptnum+expand, 1, "set"); } i@IntersectUp = intersect_all(0,@P, RayDUp, hitPos, hitPrims, hitUVW, tol, ttol); if (@IntersectUp >1) { setpointgroup(0,"Intersecting", @ptnum-expand, 1, "set"); setpointgroup(0,"Intersecting", @ptnum, 1, "set"); setpointgroup(0,"Intersecting", @ptnum+expand, 1, "set"); } I also included a screenshot illustrating the problem. Thanks in advance!
  4. Hi After reading this article on scratchapixel, where they talk about an efficient algorithm for finding intersections of a ray and a box I wanted to see how it compared to the built in intersect function. To my knowledge, the built in intersect function is looping over all the prims given in no particular order - I infer this information from the description of the primfind function, which states that it should be used with intersect, because"primfind uses an underlying tree structure to speed up search" (so I take it intersect does not). My test scene creates boxes on n scattered points in a volume. On one attribute wrangle I use the built in intersect function, on another one I use the one from scratchapixel. I would expect the scratchapixel one to be faster, also because the intersect has to loop over n * 6 prims (6 prims per box) whereas the scratchapixel one only has to iterate over n points. However the intersect is magnitudes (!) faster than the custom one. Does anybody have ideas why?
  5. Hi, I'd like to sample the UVs and texture from the models i intersect with but don't know how... Any advice ? Thanks Escherisation.hipnc
  6. Hi, is there a faster way to check 10000+ objects for some attributes? Im making a tool that uses intersect_all() I want to make a tool that looks at the objects and see if it is visible by the camera position. And if it isnt, it can be delete the object ( not only the prims or points). So what I did now is to give it a color promoteToDetail in a for each to MAX and promote it back down to have the object the max value. But is there a better and quicker way if there are so much objects? thnx
  7. Hi, How could I measure vector distance to another surface like you see here. Not just closest point distance, but distance following the vector. I would like to use this as length point attribute in hairgen to control the shape of groom with geo. Cheers Janis Vector_length.hip
  8. Hi! Can anyone point me in the right direction for how to determine on air-tight geometry the distance it would take to push each point inward along the normal (like the Peak nodes does, if you give it negative numbers) until it hits the other side, getting pushed in at the same rate? Right now if you use the Peak node with negative numbers of increasing magnitude on a mesh that has parts of variable thickness, the thinner parts will eventually start turning inside-out. What I want is for them to stop right before that happens and stay at a thickness of zero, so they squeeze down to invisibility, while the thicker parts of the mesh continue to push inward. Specifically what I need is a value that is that distance, which I can transfer over to vertex colors, because this is for a game asset where the actual squeeze along the normal direction will take place in the game engine, not in Houdini, and I need a value to clamp the push distance for, on a per-vertex basis. Thanks!
  9. I have a RaySOP that is doing exactly what I want. It is shooting rays per point along a direction defined by point attribute 'rdir' and is returning the hitprims I'd expect. Hitprims are the green numbers in the images below, yellow lines are visualisation of attribute 'rdir' (raySop shown below) I want to be better about doing things with VEX so I tried doing the same thing with the same set of points, with the same 'rdir' attribute and same collision geo. I get wildly different results for my hitprims as shown below. heres the tiny bit of VEX I've got: vector p; vector hitprimuvw; vector dir = @rdir; int hitted; hitted = intersect(1, @P, dir, p, hitprimuvw); @hitprim = hitted; What am I missing?
×
×
  • Create New...