Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

3 Neutral

About meeotch

  • Rank

Personal Information

  • Name
  1. Thanks for the replies. @jason - An interesting point about printf possibly preventing optimization. Would be interesting to test, though I'm not sure how off the top of my head. But I'm unclear what you were referring to w.r.t. texprintf - it seems to just be a sprintf that does UDIM substitution automatically? @oldschool - point taken about the shader being evaluated for every ray. It still feels like this wouldn't prevent optimization of non-changing values at various levels. But I'm not sure how the parameter-override mechanism is implemented. With packed geo, presumably you can't know if a value is overridden until render time. But mantra also knows which object / prim is currently being shaded, so once it's determined that parameter X isn't overridden at the point level, it presumably doesn't need to make that determination again. I guess it comes down to how clever the compiler is about arranging things to execute the minimum number of times, as jason mentioned. In the absence of an "optimization hinting" mechanism, it would be great to at least have an explanation in the docs re how the compiler / mantra work together to optimize stuff. Then you could attempt to arrange your input in a way that was efficient to render, and avoid pathological cases like doing string mangling on every sample.
  2. Do shader VOPS have a sense of "class", in the way that old-school Renderman SL parameters do? Specifically, is there a way to limit some block of shader stuff to not calculate on every sample? The context is that I've got packed alembics coming in. Inside those packed objects is a detail ID attribute (int, but saved as a float) that specifies a group of texture maps. In the shader, I need to construct the texture paths based on this integer, which I'm currently doing in an Inline VOP. This works, but when I insert a printf() into the Inline as a test, it appears that it's getting evaluated many thousands of times. What I'd like is evaluation once-per-alembic, or once-per-packed-prim, or something. I know that this could be done with style sheets, or by baking the texture paths into the alembics, or by unpacking the alembics and adding the texture paths, or by having many dozens of individual materials. But for reasons unspecified, we're not doing any of that.
  3. renderstate vs packed fragments

    Nice - thanks for the info.
  4. So am I correct in understanding that the Render State VOP can be used to read attributes on packed *geos* in a shader. (Where "attributes" means attributes you've added to the top-level packed points themselves, not the underlying packed geometry.)... But that the same doesn't work with packed fragments? Or is this a bug? See attached file. Render and inspect the "noiseColor" image plane. If you turn on "create packed fragments" on the Pack node, and re-render, you'll notice that the shader is no longer rendering colors into this plane. I understand that packed fragments are references into a larger geo, whereas packed geos are entire geos. But I don't see why this would prevent you from using Render State with both of them. If a technical explanation exists, I'd be glad to hear it. packedRenderState.hip
  5. 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.
  6. 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?
  7. 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.
  8. 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
  9. 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.
  10. 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.
  11. 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.
  12. 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.)
  13. 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?
  14. 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