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.


  • Content count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About GeneralLethal

  • Rank

Personal Information

  • Name Anto
  1. Thanks Sokratis, yes I went through the same thought process, once the geometry is packed there's no way of changing point position without moving the packed geometry as well, since that would in fact change the geometry in relation to its "pivot", so it has to be done before it's packed. For now the workaround I found was to: - Pack the geometry with pivot at centroid - Set @P to (0,0,0) - Unpack - Offset the geometry - Repack it with its pivot at origin - Set @P to initial position minus offset. I'm thinking there must be a more efficient way to do this.
  2. Hey all! I'm packing imported geometry into thousands of primitives using a connectivity attribute. What would be the best way to set custom pivot locations in the process, instead of the centroid or origin options? Something as simple as using the centroid for X and Z and 0 for Y., for example?
  3. You could use a point VOP, or just timeshift to your desired length then use a wrangle node: f@frameFraction = ((@Frame - firstFrame) * (oldLength / newLength)) % 1; @P += @v * @frameFraction * @TimeInc;
  4. Did you cache @v? Can't try this right now, but let's say: oldFrameNumber/newFrameNumber = 500/700. So your new frame 75, for example, would be old frame 53.57. You sample P at frame 53 and add 0.57 times your velocity per frame to get your position. It'll be jerky but should work despite varying id's.
  5. Thanks a lot everyone, lots of useful ideas! @LaidlawFX: I'll sometimes use Mantra for FX only shots, but our studio is mostly Maya so most rendering ends up being Arnold. Your idea of a single shader still applies though, and it would probably make it much easier for the development team to make a tool for the lighters that would allow them to override the material's parameters in Maya if needed. Good to know Mantra doesn't compile unused parts of the materials, I wonder if Arnold does the same when creating .ass files? Lots to think about, thanks! @Matt_K: Thanks, indeed a linear workflow is essential. Luckily, Houdini makes it very easy to implement, and my company made sure that very plate is interpreted correctly when it is imported in Houdini. Just have to make sure it's the same with artist created or downloaded images. @Skybar: You're right. Haven't had much character work up to now, but it wouldn't hurt to have a basic workflow ready. @fuat: Absolutely! Luckily, my company pretty much has this down already for scenes, published assets and renders, but cache folders still tend to be a bit messy and some guidelines would make them much easier to navigate. What about importing and re-exporting Alembic files, anybody has a fail-safe way of ensuring object structure and hierarchy is always preserved through their Houdini trip? Tends to be case-by-case with me but I'd love to hear of a more standardized way that would work through merges, packing, unpacking and whatnot, if such a thing exists. Any other ideas are much appreciated!
  6. Thanks Michael, indeed this is crucial, especially when the work involves several different software. We do a good job up to now of keeping a standard scale except for very specific shots, but it's a very good point to add so that potential new employees know where to stand.
  7. Sorry for the delay. Thanks a lot Skip, this does work with a POP VOP, but I was trying to achieve it with a VOP Force that was also affecting other systems than the particles.
  8. So our relatively small VFX company is asking each department to come up with a checklist guide to standardize the transfer of material between departments and minimize technical problems. As the newly appointed lead of the small FX team, I do have several ideas about what I expect when I get material from other departments (mainly layout and modelling) and how to make it as easy as possible down the line (lighting and comp) with the material we produce (simulated meshes, VDB'S, ASS's and renders). The respective leads of these departments also gave me their input about their expectations. Even then, I'm sure there are a lot of ideas I haven't thought of, and I would love to have your input.
  9. I've been trying to use an attribute in a VOP Force network to multiply the force by, and have come to the conclusion that atttributes are invisible to it, except for the global variables. I've tried mutiplying the force in a separate POP VOP, no luck either. Somebody knows of a way to achieve this?
  10. @Dave: Thanks! I'm not sure that would work in this case though, as particles are emitted throughout the scene, so the noise wouldn't be applied to those born after frame 2. Woodenduck solution's worked, though: add the attribute in the emitter before they're copied in the DOP network.-
  11. @woodenduck: Thanks a lot, it makes a lot of sense, I'll try that. @nigelgardiner: Oh thanks! That'll come in handy.
  12. What would be the best way of setting an attribute at birth to FLIP particles, using a noise, so that its value is then retained for its life duration? With normal particles I'd probably use the "just born" group, but as FLIP particles don't have an age attribute, I'm a bit over my head in how I could achieve the same result.