Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About meeotch

  • Rank

Personal Information

  • Name
  1. Is it possible to make certain hotkeys dependent on the pane mode? Specifically, the new quickmarks (finally! and there was much rejoicing...) hotkeys 1/2/3/etc. I'd prefer that they were only active in "view mode", so that they become space+1, space+2, etc. - after which I can re-re-bind 1/2/etc. back to the display/render flag commands that now have a decade+ of muscle memory behind them. (C'mon SESI - changing something that basic with no thought toward a "classic mode" is a total Autodesk move, yo.) Quickmarking seems like it's more properly a viewing operation, anyway. In the same way that space+g in a 3D view is a viewing operation. But I'm not trying to start a hotkey flame war - just wondering if users have access to the panel mode logic.
  2. reading from arbitrary geo in a shader

    D'oh! Dude - nice one. You're like a psychic for boneheaded mistakes. Reading the curve geo from a file seems to work, with that fix. op: syntax still doesn't work, which is not entirely surprising. Anyone know if that's is something that's been implemented, and maybe it's another "PEBKAC" issue?
  3. Is it possible to access an arbitrary piece of geo (i.e., not the one being shaded) from a shader? I know that you can read data from pointclouds on disk. I also read somewhere that the "op:" syntax doesn't work for shaders (although it does work for referencing COPs from a shader, yes?). Presumably, you'd have to alert houdini somehow to the fact that there was non-rendered geo that needed to be pushed to the ifd. The context is that I'm trying to write a shader that does coloring based on distance from a set of guide curves. The color transitions need to be sharp, not blurry, therefore baking the colors into the shaded surface's points in SOPs isn't an option, unless I dice it up into a zillion polys. (I suppose a fallback plan would be cooking the color info down into a very large texture. But all of this is animated, so I'd prefer not to render a few hundred frames of textures.) I can confirm that using the xyzdistance VOP from within the shader doesn't seem to work - neither with op: syntax, nor reading the curves from a file on disk.
  4. shadows and normals

    So here's a weird one. While going thorough the H15 Rendering Masterclass, I noticed some weird artifacts in the example scene renders. Eventually tracked it down to the background geo, which was just a box with most of the faces removed. Check out the attached hip file... If you render the mantra node (which is set to all defaults, I believe), everything looks fine. Run the render in the Render View, for reasons I'll get to in a minute. Shadows from the grid and the ball are casting on the box. Now go into the box object, and turn off Cusp Normals on the Facet node. (Or alternatively, put the render flag on the Blast node.) Now the shadows are totally wrong! o.k., so at first I was thinking - maybe it has something to do with the fact that, in PBR, everything is driven by BSDF's, and lighting effects come "free" with the global physical simulation of light. Maybe it's the fact that the normals on the box are smoothly interpolated by default, so that along the edges, you get a normal which isn't actually perpendicular to the sides of the box - and presumably, the normals are affecting the BSDF. (Problems with this theory below.) So, o.k. - switch to Micropolygon rendering. Shadows are still wrong - wtf? But wait - now turn off Preview mode, and in fact Micropolygon rendering displays the correct shadows. Again, wtf? So, a decent theory - but here's my problem with it: no matter which direction the BSDF was "pointing" (based on the normal), it's not going to change the set of overall directions on the surface that can "see" the light. The geometry hasn't moved, so the shadow should be falling in the same place. So can someone explain what I'm missing? (Also, what's up with Preview mode, that causes Micropoly to give PBR-like results?) shadows_and_normals.hip
  5. Yes - I have the same experience, w.r.t. environment. Unfortunately, I'm a freelancer & don't have any control over that in this case. I think the thing that confused me is above $JOB, which shows up in the Aliases+Variables window in houdini, even when it's set as a system environment var. Whereas the other sys env vars don't show up there (but are still usable in the file dialog). I take it $JOB is a special case? p.s. - I'm almost 100% sure that on my work machine, $JOB wasn't inheriting its value (in a blank, new houdini session) from the system env var that I set up for it - it seemed to default to my windows profile dir. But I just tested it on my home workstation, and it does inherit here.
  6. Michael - thanks for the response. I'd thought about doing something with variables as a workaround, but hadn't had time to play around with it. When you say "environment variable" - you mean a variable that's global to & saved with the file itself, correct? After poking through the docs, I'm still a bit unclear on the interaction between file globals and "true" (system) environment vars. The docs use the term "environment variable" both for things like $JOB, which appears to not carry over from the system environment on Windows (it defaults to Windows %PROFILEDIR% on an empty file, even if it exists in the system environment) - as well as for things like $HFS, which isn't a windows env var; and $HOME, which (on my system) is. In this case, I'm not actually sure which would be preferable... Reading $NIKE from a Windows system env var would be the most convenient, but might also require altering the environment on machines facility-wide, for rendering. Reading $NIKE from a file global var would be safer, but would require setting it every time I start a new file.
  7. Does anyone know if it's possible to save the layout of the Houdini file chooser windows (running Windows 7)? The problem is that the "Favorites" pane (lower left of the file window) is too small to display the full path of favorited directories, and I end up having to drag-expand the window, and then drag the vertical pane divider bar to the right every time I use the file browser in a new context. (Layout seems to be persistent for a single context in a single session. For instance, choosing a file for a File SOP. But all contexts seem to revert with a new Houdini session.) Or I can guess my way into a bunch of identical-looking links like this: S:/projects/119999_Nike_Buy_Our_Shoes/prod/sequences/... S:/projects/119999_Nike_Buy_Our_Shoes/prod/sequences/... S:/projects/119999_Nike_Buy_Our_Shoes/prod/sequences/... It's maddening, I tell you, maddening.
  8. vdb to poly topology

    Nope - Bluesky. So it's entirely possible that it's an in-house mod. (My buddy is sharp enough to know the difference - but he did make his claim from memory, he wasn't at work.)
  9. vdb to poly topology

    Thanks for the reply. That does seem to work for the simple example. (Though you can break it pretty easily - for instance, by turning up the frequency on the sphere.) My guess is that if this function does exist somewhere in the built-in nodes, it would involve some relatively dark magic. Seems like a difficult problem, in the case of arbitrary geometry. Even once you identify more or less which areas are close enough to the reference geo to be considered "the same", you've still got the task of joining it in a reasonable way to the parts that don't match. Or I guess you could loop through the reference geo and tag points in the vdb-generated mesh that are within a certain tolerance of 1) the reference polys and 2) reference points. The dissolve away 1, while preserving 2. Still doesn't guarantee you edges in the same place, though. Anyway, I guess this functionality isn't built-in, then?
  10. So a buddy of mine swears up & down that there's a built-in way (as in a checkbox somewhere) to round-trip from polys to vdb and back to polys while maintaining the topology of the polygons in areas where the vdb hasn't changed from the original shape. I've tried twiddling every button and slider on the Convert VDB node (with the original geo as a reference surface in the second input), and I can't get anything out other than the "quilted" converted VDB topology we all know and love. (See attached file, wireframe mode.) So my question to you, the collected houdini cognoscenti, is this: which one of us is smokin' the crack rock? polytovdbtopoly.hip
  11. point clouds and vex

    Yeah - that's exactly the weird gut feeling I was getting about this issue, but couldn't put my finger on. (btw - hi, tomas!) I'll try cross-posting this to the sidefx forum, and see if anyone from sesi chimes in with a more detailed under-the-hood explanation.
  12. point clouds and vex

    Hmmm... interesting. I wonder why that code needs to be repeated for it to work? There's clearly something I'm missing about how the vex is compiled. Or maybe a bug?
  13. point clouds and vex

    Interesting - thanks for the replies. Is opening both clouds might be less efficient - or not, because they're "shared" between input points? (This whole thing actually comes from inside a flip sim, which has a bunch of pcfilter()s and other stuff going on - so speed is a concern there, where it isn't in my little demo scene.) Maybe someone with a bigger brain than mine can explain the difference between what's going on behind the scenes with pcfind() vs pcopen()? My gut tells me there's an efficiency / parallelization issue there as well (pcfind doesn't require a matching pcclose, for instance), and possibly the same thing that allows the former to work where the latter fails. Meantime, I'm just doing it with two Wrangles, group-constrained. Which works and probably is efficient, but is a fair amount of duplicated code.
  14. Can someone fill me in on why the scheme in the attached file doesn't work? Basically, I'm using a wrangle to do some point cloud searching. I want to switch the searched geometry based on some attribute on the wrangle's input geo. The vex for that looks like this: float radius = ch("radius"); int npts = chi("numpts"); int handle; if (@side > 0) { handle = pcopen(@OpInput2,"P",@P,radius,npts); } else { handle = pcopen(@OpInput3,"P",@P,radius,npts); } v@Cd = pcimportbyidxv(handle,"Cd", 0); i@num = pcnumfound(handle); pcclose(handle); I'm guessing that my implementation doesn't play nicely with the way that vex / point clouds parallelize, or something. The result is that half of the points don't find any matched points at all (pcnumfound gives 0). The attached file demonstrates it visually. The code above (node "pc_broke") results in half of the points failing to find matches. If I use the same search geo for both groups (node "pc_works"), then all points find matches. And if I do it in two wrangles, each constrained to one group of points and one search geometry, I get the desired result (node "CORRECT"). Removing the pcclose() has no effect, btw. pc_vex.hip
  15. vdb from particles error

    Support is reporting that the vdb "holes" thing is fixed in VDB 3.1 & we'll see it in Houdini 16, so I guess the problem was further down the rabbit hole. In the meantime, it's good to know that changing Renormalization is a workaround.