Hi guys,
We're often making procedural assets in SOPs that output variants by connecting iteration to random seed and noise offset, or other params. To call the iteration, we usually use a detail HScript expression that is a bit cumbersome to write. Just saw that the LOPs foreach loop has the option to assign a local variable to the iteration that would simplify that a lot, is it possible to get it in the SOPs loop too?
Thanks
Found 57 posts.
Search results Show results as topic list.
Technical Discussion » Local variable for iteration in SOP loop
- HristoVelev
- 59 posts
- Offline
Technical Discussion » Stability with Alembics
- HristoVelev
- 59 posts
- Offline
My bad - had an error with an asset, where there was some live geometry together with the Alembics - removed that and things improved dramatically, haven't had a crash since the morning
Technical Discussion » Stability with Alembics
- HristoVelev
- 59 posts
- Offline
I see, thanks. We're on the way to start pushing through Solaris and Karma and it would be useful to know if it's much more reliable and a fast track is worth the trouble, if you have an idea about that
Technical Discussion » Stability with Alembics
- HristoVelev
- 59 posts
- Offline
Technical Discussion » Stability with Alembics
- HristoVelev
- 59 posts
- Offline
Technical Discussion » Stability with Alembics
- HristoVelev
- 59 posts
- Offline
No comparable stability problems with other apps or Houdini either, when not using Alembics. It's not a single one either, happens all the time.
OS is Windows. Feeling like GPU might be the problem, but driver update didn't solve it.
OS is Windows. Feeling like GPU might be the problem, but driver update didn't solve it.
Technical Discussion » Stability with Alembics
- HristoVelev
- 59 posts
- Offline
Hi guys,
We're working with alembics and standalone rendering a lot. Even more recently, with the new world building tools we're developing. A major problem is stabilty with Alembics in the viewport, Houdini crashes very often when the alembics change scale or other basic operations. Viewport representation messes up but that gets reset when changing a view and is not as much of a showstopper as the crashes.
Build is 18.5.596, there's V-Ray 4.3 in there too.
Anything we can do to make things better?
Thanks
We're working with alembics and standalone rendering a lot. Even more recently, with the new world building tools we're developing. A major problem is stabilty with Alembics in the viewport, Houdini crashes very often when the alembics change scale or other basic operations. Viewport representation messes up but that gets reset when changing a view and is not as much of a showstopper as the crashes.
Build is 18.5.596, there's V-Ray 4.3 in there too.
Anything we can do to make things better?
Thanks
Technical Discussion » Saving rest transform to Alembic
- HristoVelev
- 59 posts
- Offline
Is there a good place to read about how these all work? There are some cases where my current setup is breaking, so it would be great to learn more
Thanks!
Thanks!
Technical Discussion » Saving rest transform to Alembic
- HristoVelev
- 59 posts
- Offline
Looks like it's working - it's putting the centroid at zero unlike the original rest that lines up y min to zero, but that shouldn't be much of a problem. Thanks!
Technical Discussion » Saving rest transform to Alembic
- HristoVelev
- 59 posts
- Offline
OK so if I've transformed it from rest, inverting the packedfulltransform should get it back to rest - I'll try that, thanks!
Technical Discussion » alembic ROP progress + Thinkbox Deadline
- HristoVelev
- 59 posts
- Offline
Sorry if that's reviving a topic that's too old, but - we're doing that by printing the current frame to the console, and since Deadline is picking up on that, it's showing as progress
Technical Discussion » Saving rest transform to Alembic
- HristoVelev
- 59 posts
- Offline
Hi guys,
I've been using alembic a lot in recent projects, and very comfortable with the ROPs based lighting pipeline around it, with Mantra and V-Ray. Not done much with managing the transforms in it though, usually just loading in SOP. I know the way forward is USD/Solaris, but while we're waiting for renderers to catch up, would be great to address some current limitations with Alembic too.
Consider transforming, not deforming geometry. It's very useful to have access to a reset pose of animated assets. That seems not trivial to extract from animated asset - match size does a great job for the translations, but the rotations seem difficult. If I have a rest pose - at zero with no rotations, it would be easy to do some work on it and reapply the animation to the new geometry.
It would be best if this rest transform can be saved in the animation's alembic - not another file, so the transport of files is simpler. Seems like Alembic has sophisticated transforms management, but I'm not finding a way to do that. Checking out layered alembics too, but the examples in the reference are saving layers to separate files, and not several things in a file. In the Alembic ROP's layering tab, I can pick objects but I can't tell it to use shape from one object and transform from another. And it would be best if I don't save two shapes, one at rest and one animated, because this would double the file size
Any ideas? Thanks!
I've been using alembic a lot in recent projects, and very comfortable with the ROPs based lighting pipeline around it, with Mantra and V-Ray. Not done much with managing the transforms in it though, usually just loading in SOP. I know the way forward is USD/Solaris, but while we're waiting for renderers to catch up, would be great to address some current limitations with Alembic too.
Consider transforming, not deforming geometry. It's very useful to have access to a reset pose of animated assets. That seems not trivial to extract from animated asset - match size does a great job for the translations, but the rotations seem difficult. If I have a rest pose - at zero with no rotations, it would be easy to do some work on it and reapply the animation to the new geometry.
It would be best if this rest transform can be saved in the animation's alembic - not another file, so the transport of files is simpler. Seems like Alembic has sophisticated transforms management, but I'm not finding a way to do that. Checking out layered alembics too, but the examples in the reference are saving layers to separate files, and not several things in a file. In the Alembic ROP's layering tab, I can pick objects but I can't tell it to use shape from one object and transform from another. And it would be best if I don't save two shapes, one at rest and one animated, because this would double the file size
Any ideas? Thanks!
Technical Discussion » Rop Alembic output (alfred style) progress
- HristoVelev
- 59 posts
- Offline
Yes we need that too - currently hacking with a print of current frame from Python preframe script, but Alfred progress would be great, will let us monitor from the Deadline Monitor. And alembics are ubiquitous now.
Houdini Lounge » Feedback on PyroBakeVolume etc Pyro workflow updates in 18.5
- HristoVelev
- 59 posts
- Offline
Hi guys,
I'm Hristo, Bottleship founder. Context - we are a team of 20, 5 of which are FX. We are using Houdini with V-Ray, for all our 3D on some projects, mixed with Katana/Blender/Vray on some too. We do lots of simulation work. We're trying out 18.5 after checking out most of the info in the documentation, webinars etc. Here's our first impressions - basically notes from the meeting with the artists:
- burst and trail sources are cool, quick and easy to set up, thanks for these!
- pyro bake - the quick setups not using HDAs, the subnets it adds don't feel like part of the same toolset. You can only invoke them from the quick setups menu, not from the tab menu as parts of a bigger toolset like for example the groom tools. That's fragmenting things in a way that's a bit unpleasant
- pyro bake is writing out many volumes. That might be ok for a mantra workflow where all these are used in the shader, though we like to optimize our VDBs so we can handle higher resolutions with the same footprint, so we end up with density, color ramp (float, remapped to color in the shader, so decisions are made by the lighting artist), emissive and velocity. Writing out more volumes very quickly baloons the VDB size
- The scatter volume is color vector - we feel like that's a shader decision that's being made in the volume bake step, which is limiting what the lighting guy can do downstream.
- We learned a lot from the Axiom examples, like multiplying emissive by remapped flame and density, blending in sharpened emissive locally where it's higher values, etc - feels like much more of these could have gone in the pyro bake
These are our thoughts, from our perspective, hopefully it's useful. We're implementing our own pyro post process tools that are more like granular HDAs that do all that steps, so the FX artist can do a preliminary look design using the OpenGL shader, and pass data in an optimized form downstream to lighting.
Thanks!
I'm Hristo, Bottleship founder. Context - we are a team of 20, 5 of which are FX. We are using Houdini with V-Ray, for all our 3D on some projects, mixed with Katana/Blender/Vray on some too. We do lots of simulation work. We're trying out 18.5 after checking out most of the info in the documentation, webinars etc. Here's our first impressions - basically notes from the meeting with the artists:
- burst and trail sources are cool, quick and easy to set up, thanks for these!
- pyro bake - the quick setups not using HDAs, the subnets it adds don't feel like part of the same toolset. You can only invoke them from the quick setups menu, not from the tab menu as parts of a bigger toolset like for example the groom tools. That's fragmenting things in a way that's a bit unpleasant
- pyro bake is writing out many volumes. That might be ok for a mantra workflow where all these are used in the shader, though we like to optimize our VDBs so we can handle higher resolutions with the same footprint, so we end up with density, color ramp (float, remapped to color in the shader, so decisions are made by the lighting artist), emissive and velocity. Writing out more volumes very quickly baloons the VDB size
- The scatter volume is color vector - we feel like that's a shader decision that's being made in the volume bake step, which is limiting what the lighting guy can do downstream.
- We learned a lot from the Axiom examples, like multiplying emissive by remapped flame and density, blending in sharpened emissive locally where it's higher values, etc - feels like much more of these could have gone in the pyro bake
These are our thoughts, from our perspective, hopefully it's useful. We're implementing our own pyro post process tools that are more like granular HDAs that do all that steps, so the FX artist can do a preliminary look design using the OpenGL shader, and pass data in an optimized form downstream to lighting.
Thanks!
Technical Discussion » String replacement in VEX
- HristoVelev
- 59 posts
- Offline
Houdini Indie and Apprentice » Delay in Node Instancing and overall Houdini Sluggishness
- HristoVelev
- 59 posts
- Offline
Technical Discussion » LOPs - variants from name attribute?
- HristoVelev
- 59 posts
- Offline
Hi guys,
It would be great to automatically build variants from all the named geometry, any idea how to do that?
Thanks
It would be great to automatically build variants from all the named geometry, any idea how to do that?
Thanks
-
- Quick Links