Yep - I'm still in H19.0. So I guess that explains the missing savedstashgeo. No input wired to the Curve SOP in any case.
I may try it again with H19.5 - or I may try to reverse-engineer the parmpoints protocol, and build a new hou.Geometry from scratch to stuff in there. For a simple poly curve, it seems like it shouldn't be too hard: optype = appendpoints, and addpoints = a string with the point positions. Most of the other attributes seem to be zero/default values.
Out of curiosity - where in the code did you find the geo ID logic? I'm always interested to discover more gory details about houdini stuff that I haven't had to dive into before.
Found 33 posts.
Search results Show results as topic list.
Technical Discussion » changing curve geometry from a script
- meeotch
- 33 posts
- Offline
Technical Discussion » changing curve geometry from a script
- meeotch
- 33 posts
- Offline
Ha - you posted your answer while I was laboriously revising my original post to reflect the hidden parameters.
Unfortunately, I'm not seeing a hidden "savedstashgeo" parameter on Curve. Only "parmpoints" (which appears to be history), and "stashgeo". If I set "stashgeo" to editsop.geometry(), it does in fact move the output points to where they're supposed to be. But I think this is because it's loading them into a *second* Stash inside the Curve node, called "stashed_geo", and sets the "cache_switch" Switch to ignore the main processing chain.
You can then move the points around, and everything looks fine... But since the edit history is still in the parm_points Stash, but then it messes things up when the node recooks.
I thought I could set stashgeo, and then zero out parmpoints, but that just clears the entire curve.
So it feels like what's needed is some way of converting the stashgeo back into history entries in parmpoints.
Unfortunately, I'm not seeing a hidden "savedstashgeo" parameter on Curve. Only "parmpoints" (which appears to be history), and "stashgeo". If I set "stashgeo" to editsop.geometry(), it does in fact move the output points to where they're supposed to be. But I think this is because it's loading them into a *second* Stash inside the Curve node, called "stashed_geo", and sets the "cache_switch" Switch to ignore the main processing chain.
You can then move the points around, and everything looks fine... But since the edit history is still in the parm_points Stash, but then it messes things up when the node recooks.
I thought I could set stashgeo, and then zero out parmpoints, but that just clears the entire curve.
So it feels like what's needed is some way of converting the stashgeo back into history entries in parmpoints.
Technical Discussion » changing curve geometry from a script
- meeotch
- 33 posts
- Offline
With the old Curve node, you could change the geometry from python like so:
I had a working python shelf tool that would grab the point positions from some node further down the chain (for instance, an Edit SOP), then copy them back up to the original Curve SOP, allowing you to delete subsequent Edits, Transforms, etc. and bake them into the original curve. This was really useful in the case where you're drawing a bunch of control curves, then having to adjust them a bunch of times, and you don't want a pile of extra nodes cluttering up your network.
With Curve 2.0, the points seem to be generated by a zillion wrangles, operating on history entries that are stored as points in an internal Stash SOP (called parm_points). I say "history entries", because there are a lot more of them than the number of points on the curve itself, and have an "optype" attribute with values like append/delete/transform/etc.
The docs say that hou.Geometry objects are read-only except within a Python SOP, and that a Python SOP actually operates on a frozen copy of any hou.Geometry that it operates on. I assume this means that it doesn't change the contents of the original Geometry.
The Curve SOP also has a hidden parameter "parmpoints" that when you call eval() on it returns a frozen Geometry that corresponds to the "history" Geometry in the parm_points Stash. Setting the parmpoints parameter to None clears out the Stash. So there's clearly some mechanism tying the two together. But the frozen parmpoints Geometry gives read-only errors when you attempt to clear or edit it.
So I guess maybe the way to reset the Curve 2.0 node to a simple set of points with given positions would be: create a new Geometry object from scratch, populate it with the appropriate "append" and "transform" entries, then set the parmpoints parameter to the new Geometry, and hope whatever magic is in there pushes it to the Stash?
Note: While the Curve 2.0 does have better controls for editing, it's still not fully-featured: you can't select and move multiple points without it resulting in an Edit SOP being created, you can't add points to the ends of the curve (I think?) without adding them somewhere in the middle, moving the old end point, then moving the new inserted point to where the end used to be, etc. So baking subsequent changes back to the original Curve is still a useful operation.
node.parm('coords').set(string_of_coords)
I had a working python shelf tool that would grab the point positions from some node further down the chain (for instance, an Edit SOP), then copy them back up to the original Curve SOP, allowing you to delete subsequent Edits, Transforms, etc. and bake them into the original curve. This was really useful in the case where you're drawing a bunch of control curves, then having to adjust them a bunch of times, and you don't want a pile of extra nodes cluttering up your network.
With Curve 2.0, the points seem to be generated by a zillion wrangles, operating on history entries that are stored as points in an internal Stash SOP (called parm_points). I say "history entries", because there are a lot more of them than the number of points on the curve itself, and have an "optype" attribute with values like append/delete/transform/etc.
The docs say that hou.Geometry objects are read-only except within a Python SOP, and that a Python SOP actually operates on a frozen copy of any hou.Geometry that it operates on. I assume this means that it doesn't change the contents of the original Geometry.
The Curve SOP also has a hidden parameter "parmpoints" that when you call eval() on it returns a frozen Geometry that corresponds to the "history" Geometry in the parm_points Stash. Setting the parmpoints parameter to None clears out the Stash. So there's clearly some mechanism tying the two together. But the frozen parmpoints Geometry gives read-only errors when you attempt to clear or edit it.
So I guess maybe the way to reset the Curve 2.0 node to a simple set of points with given positions would be: create a new Geometry object from scratch, populate it with the appropriate "append" and "transform" entries, then set the parmpoints parameter to the new Geometry, and hope whatever magic is in there pushes it to the Stash?
Note: While the Curve 2.0 does have better controls for editing, it's still not fully-featured: you can't select and move multiple points without it resulting in an Edit SOP being created, you can't add points to the ends of the curve (I think?) without adding them somewhere in the middle, moving the old end point, then moving the new inserted point to where the end used to be, etc. So baking subsequent changes back to the original Curve is still a useful operation.
Edited by meeotch - Dec. 4, 2022 21:57:12
Technical Discussion » displacement coving artifacts
- meeotch
- 33 posts
- Offline
Here's a scene with some pieces that are the result of a voronoi shatter. I've got a principled shader on them, with noise displacement turned on. If you render 10 frames of the "close" ROP, you'll see geometry flickering at the edges of the pieces.
Weirder still, if you do a single frame render (in Render View, or to mplay), then save the frame and render it again, you'll see that the geo artifacts are *not deterministic*. The same frame renders differently each time.
Now dive into the RENDER_test node, and instead render it with one of the pieces blasted. Suddenly, the frame renders pretty much the same each time. Doesn't seem to matter which piece you delete.
Now go back to the original file node with all the pieces, and render it with coving disabled on the Geometry tab of the RENDER_test object. Again, the frame renders the same way each time. So it appears that coving is acting nondeterministically, depending on how much geo is in the object - WTF?
Sure - I expect a little geo weirdness when displacing geo with sharp edges. But I at least expect each frame to render the same every time - and I'm pretty sure that's where the flickering is coming from. If you look at it closely over many frames, it appears that it's happening in certain spots, always on the edges, and that it's flipping back and forth between two different coving solutions at each spot - though each spot flips independently of the others.
I've tried everything to eliminate the flickering: all the various dicing parameters, ray predicing, shading quality, flatness, re-dicing, uniform measuring, sample coving, sample lock. I've also tried pre-dividing the pieces to get more polys in the geo. No love.
Any bright ideas? (The actual shot that this comes from involves a large number of these pieces that move slowly and then come to a stop. Even when they are completely static, and the camera is static, they flicker from frame to frame.)
Weirder still, if you do a single frame render (in Render View, or to mplay), then save the frame and render it again, you'll see that the geo artifacts are *not deterministic*. The same frame renders differently each time.
Now dive into the RENDER_test node, and instead render it with one of the pieces blasted. Suddenly, the frame renders pretty much the same each time. Doesn't seem to matter which piece you delete.
Now go back to the original file node with all the pieces, and render it with coving disabled on the Geometry tab of the RENDER_test object. Again, the frame renders the same way each time. So it appears that coving is acting nondeterministically, depending on how much geo is in the object - WTF?
Sure - I expect a little geo weirdness when displacing geo with sharp edges. But I at least expect each frame to render the same every time - and I'm pretty sure that's where the flickering is coming from. If you look at it closely over many frames, it appears that it's happening in certain spots, always on the edges, and that it's flipping back and forth between two different coving solutions at each spot - though each spot flips independently of the others.
I've tried everything to eliminate the flickering: all the various dicing parameters, ray predicing, shading quality, flatness, re-dicing, uniform measuring, sample coving, sample lock. I've also tried pre-dividing the pieces to get more polys in the geo. No love.
Any bright ideas? (The actual shot that this comes from involves a large number of these pieces that move slowly and then come to a stop. Even when they are completely static, and the camera is static, they flicker from frame to frame.)
Edited by meeotch - May 6, 2022 20:32:24
Technical Discussion » Mantra starting too slowly
- meeotch
- 33 posts
- Offline
Are you running with any plugins/shelves - Shotgun, in particular? At my current gig, I've noticed that Shotgun integration slows down not only Houdini start-up times, but also just firing off a render in the Render View. Why Shotgun needs to be consulted every time I do a local render, I have no idea.
If you're able, try starting Houdini "plain" - i.e. from a shell, without whatever wrappers or launchers load up the extra plugins, and see if that fixes it.
If you're able, try starting Houdini "plain" - i.e. from a shell, without whatever wrappers or launchers load up the extra plugins, and see if that fixes it.
Technical Discussion » camera unlinking from view in H17
- meeotch
- 33 posts
- Offline
For anyone following / finding this thread: SESI claims that the bug is fixed in build 548.
Technical Discussion » camera unlinking from view in H17
- meeotch
- 33 posts
- Offline
My officemate just tried 17.0.515, and he's still seeing the “unlinking camera” issue. We're on CentOS 7.6.1810, if that's relevant.
I guess I'll submit it as a bug.
Sort of relatedly: I could have sworn that H17 fixed the “can't see SOPs when inside a DOP net” thing, but trying it just now, I guess not. Bummer.
I guess I'll submit it as a bug.
Sort of relatedly: I could have sworn that H17 fixed the “can't see SOPs when inside a DOP net” thing, but trying it just now, I guess not. Bummer.
Edited by meeotch - March 12, 2019 19:58:03
Technical Discussion » camera unlinking from view in H17
- meeotch
- 33 posts
- Offline
Thanks for the reply. Yes - what I meant was that the view is still locked to the camera (camera name listed in the little drop-down bubble, background image shows in the viewport). *Not* that the camera is locked to the view (lock icon is lit).
We're on 17.0.459. I'll see if I can get them to download the latest production build.
We're on 17.0.459. I'll see if I can get them to download the latest production build.
Technical Discussion » camera unlinking from view in H17
- meeotch
- 33 posts
- Offline
This has been driving me nuts, and it seems to be H17 specific: 1) view through camera, 2) dive into a geo node, 3) switch from “Show All Objects” to “Hide All Objects” or vice-versa. 4) Camera view becomes unlinked.
Is there a setting somewhere, or a workaround to change the view mode without unlinking the camera view? Or is this a bug? It seems like a minor thing, but when you're working with a background plate or an animated camera, it's maddening.
Is there a setting somewhere, or a workaround to change the view mode without unlinking the camera view? Or is this a bug? It seems like a minor thing, but when you're working with a background plate or an animated camera, it's maddening.
Technical Discussion » grid settings won't "stick" when switching from persp to ortho
- meeotch
- 33 posts
- Offline
Has anyone had an issue getting grid prefs to “stick”? My grid keeps resetting itself to 0.1, no rulers. I change it, hit Save Defaults, then goes right back to 0.1.
It seems to happen when I switch from an ortho view to persp, turn off grid, then switch back to ortho (with grid off). Pulling up the grid settings dialog at this point shows (greyed out) 0.1, no rulers. And sure enough, if I turn grid back on, it's reset itself.
I can confirm that the prefs file gets written with Save Defaults, and that the grid setting is in there & correct.
This is H15 15.0.326 on Windows 7. And it's irritating as all heck.
It seems to happen when I switch from an ortho view to persp, turn off grid, then switch back to ortho (with grid off). Pulling up the grid settings dialog at this point shows (greyed out) 0.1, no rulers. And sure enough, if I turn grid back on, it's reset itself.
I can confirm that the prefs file gets written with Save Defaults, and that the grid setting is in there & correct.
This is H15 15.0.326 on Windows 7. And it's irritating as all heck.
Technical Discussion » point clouds and vex
- meeotch
- 33 posts
- Offline
I've got a thread going on over at odforce with some questions about how point clouds work under-the-hood. Was hoping someone from SESI would chime in and give us some info regarding a weird case where they don't work as one (well, I) might expect:
odforce thread [forums.odforce.net]
Original post:
odforce thread [forums.odforce.net]
Original post:
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.
Technical Discussion » broken right-click menu
- meeotch
- 33 posts
- Offline
I can ask the systems people here. (But it appears that we currently only have 14.0.361 & 15.0.244.16 installed.)
Technical Discussion » broken right-click menu
- meeotch
- 33 posts
- Offline
When right-clicking on some nodes, I get two error dialogs that pop up, one right after the other:
“Error while evaluating menu item filter expression. IndentationError: ('unexpected indent', ('<stdin>', 26, 10, ‘ \t\t ’))”
I'm assuming this has to do with the code that generates the context menus. Clicking on the little icon to the left of the node type name in the Parameters pane gives the same results.
I haven't done an exhaustive search, but this seems to happen on Attribute VOPs, and any nodes inside them. I don't have any menu customizations in my $HOME/houdini directory, and I don't believe the studio I'm at does, either.
Any thoughts regarding how to work around this? Houdini 15.0.244.16
“Error while evaluating menu item filter expression. IndentationError: ('unexpected indent', ('<stdin>', 26, 10, ‘ \t\t ’))”
I'm assuming this has to do with the code that generates the context menus. Clicking on the little icon to the left of the node type name in the Parameters pane gives the same results.
I haven't done an exhaustive search, but this seems to happen on Attribute VOPs, and any nodes inside them. I don't have any menu customizations in my $HOME/houdini directory, and I don't believe the studio I'm at does, either.
Any thoughts regarding how to work around this? Houdini 15.0.244.16
Technical Discussion » Adding ocean spectra
- meeotch
- 33 posts
- Offline
Unfortunately, I did tweak the grid size & gravity in order to get the really low frequency, huge rolling waves we're looking for.
Though I'm beginning to suspect that we may end up having to sculpt a big wave to layer in, rather than try to get it out of ocean spectrum, and just use the higher freq ocean spectrum for detail. (They're shooting a green screen boat in a gimbal, and we've got no idea what the plates will look like when we get them.)
Does the list in my post above seem accurate, as far as what needs to be changed, in order to deform a splash tank based ocean arbitrarily?
Though I'm beginning to suspect that we may end up having to sculpt a big wave to layer in, rather than try to get it out of ocean spectrum, and just use the higher freq ocean spectrum for detail. (They're shooting a green screen boat in a gimbal, and we've got no idea what the plates will look like when we get them.)
Does the list in my post above seem accurate, as far as what needs to be changed, in order to deform a splash tank based ocean arbitrarily?
Technical Discussion » Adding ocean spectra
- meeotch
- 33 posts
- Offline
Thanks for the reply. Will that give the correct result? Aren't the frequency & phase spectra necessary to evaluate the whole thing?
And related: I went ahead and started trying to modify the outputs of the ocean evaluate node as a backup solution. I'm currently using the “splash tank” setup, so it appeared that my changes needed to go inside the wavetank node that drives the splashtank sim. If I'm understanding correctly:
1) the particles from the ocean evaluate need to be moved, for instance using the restdisplacement from the secondary ocean evaluate. Their velocities should be summed as well.
2) the vel fields probably need to be composited. So I guess VEX/VOP to move the values of one, then add that to the values from the other. I'm not clear where this field is even being used, though, since the particles already have velocity on them.
3) the SDF can probably just be replaced with an SDF generated from the composite (twice displaced) surface, rather than putting it back together from fields as it was original computed in the wavetank node.
Does that about cover it?
And related: I went ahead and started trying to modify the outputs of the ocean evaluate node as a backup solution. I'm currently using the “splash tank” setup, so it appeared that my changes needed to go inside the wavetank node that drives the splashtank sim. If I'm understanding correctly:
1) the particles from the ocean evaluate need to be moved, for instance using the restdisplacement from the secondary ocean evaluate. Their velocities should be summed as well.
2) the vel fields probably need to be composited. So I guess VEX/VOP to move the values of one, then add that to the values from the other. I'm not clear where this field is even being used, though, since the particles already have velocity on them.
3) the SDF can probably just be replaced with an SDF generated from the composite (twice displaced) surface, rather than putting it back together from fields as it was original computed in the wavetank node.
Does that about cover it?
Technical Discussion » Adding ocean spectra
- meeotch
- 33 posts
- Offline
Apologies for the cross-post - but I figured there are probably folks who don't monitor both here & odforce…
I'm interested in “layering” large, low-frequency waves with higher-frequency ones. The surface is no problem - just pipe the output of one ocean evaluate into the other. But the ocean evaluate has other products (vel volume, sdf, particles) that are used elsewhere in the pipeline - and in fact some of those parts have their own embedded ocean eval nodes for generating those products.
I could hunt down and deform all the volumes, particles, etc. But it occurred to me that a better solution would be to composite the two ocean spectra at the head of the chain. Unfortunately, my math is too rusty for it to be immediately obvious to me how to do this. (Adding them isn't the answer.)
Does anyone know how I could go about this? I'm assuming the amp/freq/phase volumes that are output by the ocean spectrum node are spectra giving… power? in each band of frequencies across a given range. But it's not really documented anywhere.
I'm interested in “layering” large, low-frequency waves with higher-frequency ones. The surface is no problem - just pipe the output of one ocean evaluate into the other. But the ocean evaluate has other products (vel volume, sdf, particles) that are used elsewhere in the pipeline - and in fact some of those parts have their own embedded ocean eval nodes for generating those products.
I could hunt down and deform all the volumes, particles, etc. But it occurred to me that a better solution would be to composite the two ocean spectra at the head of the chain. Unfortunately, my math is too rusty for it to be immediately obvious to me how to do this. (Adding them isn't the answer.)
Does anyone know how I could go about this? I'm assuming the amp/freq/phase volumes that are output by the ocean spectrum node are spectra giving… power? in each band of frequencies across a given range. But it's not really documented anywhere.
Technical Discussion » packed geo and alembic
- meeotch
- 33 posts
- Offline
So here's the context: I've got an RBD sim of a bunch of packed pieces. These are hand-animated at first, then become active at various times. I'm using a SOP Solver / AttribVOP to stick the transforms (transform & pivot intrinsics) from the animation onto the packed DOP object prims. All of this is working.
o.k. so now I'm handed an alembic file from maya containing some more pieces. Setting the alembic node to Alembic Delayed Load Primitives brings the geo in as “packed alembics”, which have the same one-point-one-prim structure as regular packed objects. I feed this into my existing DOP/SOP/AttribVOP setup and it doesn't work. Inspecting the alembic node, the “transform” intrinsic is just an identity matrix. I guess this makes sense-ish: the transforms are presumably on disk. Setting the “abcusetransform” intrinsic to 0 results in a reasonable rest position for the packed objects, which seems to confirm my conclusion that everything is properly packed, it's just the transforms that are missing.
So what I need to do is re-constitute a “proper” packed object by extracting the transforms from the alembic and applying them to the rest geometry, so that my AttribVOP scheme will work. I can see the packedfulltransform intrinsic matrix, which is animated. “P” is also animated, as is the pivot intrinsic. Using a Matrix4toMatrix3 VOP will give me the scale & rot as a 3x3. But I'm a bit unclear on the relationship between P, pivot, and transform, and how to put them together into something that can be applied to the rest geo to rebuild the original animation.
Any insight on how to go about this?
TL/DR: How can I turn an alembic into “proper” packed geo, with the transforms stored in P, pivot, and transform as they should be?
o.k. so now I'm handed an alembic file from maya containing some more pieces. Setting the alembic node to Alembic Delayed Load Primitives brings the geo in as “packed alembics”, which have the same one-point-one-prim structure as regular packed objects. I feed this into my existing DOP/SOP/AttribVOP setup and it doesn't work. Inspecting the alembic node, the “transform” intrinsic is just an identity matrix. I guess this makes sense-ish: the transforms are presumably on disk. Setting the “abcusetransform” intrinsic to 0 results in a reasonable rest position for the packed objects, which seems to confirm my conclusion that everything is properly packed, it's just the transforms that are missing.
So what I need to do is re-constitute a “proper” packed object by extracting the transforms from the alembic and applying them to the rest geometry, so that my AttribVOP scheme will work. I can see the packedfulltransform intrinsic matrix, which is animated. “P” is also animated, as is the pivot intrinsic. Using a Matrix4toMatrix3 VOP will give me the scale & rot as a 3x3. But I'm a bit unclear on the relationship between P, pivot, and transform, and how to put them together into something that can be applied to the rest geo to rebuild the original animation.
Any insight on how to go about this?
TL/DR: How can I turn an alembic into “proper” packed geo, with the transforms stored in P, pivot, and transform as they should be?
Technical Discussion » Is EC2 cloud rendering working with Houdini 13?
- meeotch
- 33 posts
- Offline
I checked H13.0.237, and in python2.7libs/cloudsubmit.py I see the line:
processor_type = (“i386” if instance_type in (“m1.small”, “c1.medium”)
else “x86_64”)
I'm not sure how the menu items map to instances - presumably “1 EC2 unit” is small, and “5 EC2 units” is medium?
processor_type = (“i386” if instance_type in (“m1.small”, “c1.medium”)
else “x86_64”)
I'm not sure how the menu items map to instances - presumably “1 EC2 unit” is small, and “5 EC2 units” is medium?
Technical Discussion » Is EC2 cloud rendering working with Houdini 13?
- meeotch
- 33 posts
- Offline
I discovered that the 32-bit image sesi has on EC2 doesn't seem to include H13. (Or didn't at the time I checked.) Forcing the instance to the 64-bit image worked. Amazon's had 64-bit small/micro machines for over a year now, iirc - so there's really no reason to have a 32-bit image at all.
Also discovered that EC2 rendering is crazy slow. I was getting 15min+ times for frames that were taking 3-4min on my local workstation. Even with a large instance. And that's not counting the spin-up time & the time to upload the files.
Also discovered that EC2 rendering is crazy slow. I was getting 15min+ times for frames that were taking 3-4min on my local workstation. Even with a large instance. And that's not counting the spin-up time & the time to upload the files.
Technical Discussion » alembic ROP broken in 12.5.533?
- meeotch
- 33 posts
- Offline
It's not just the animation aspect that appears to be broken. The output is just points, not geo. Try the file attached to the original post in 427 and 533.
-
- Quick Links