mtucker

I just wanted to post an update here that several edge selection bugs have been squashed in recent builds. 14.0.235 and later should preserve the ordering when converting an edge selection to a point selection. Also, when selecting edge loops, the edge order should now be correct, with the edge directions going the same direction as the loop. Mark

There isn't much you can do about most of these issues except wait for a new daily build with some of these errors fixed. I believe I have things working better in our development branch, I just want to do some more testing and cleanup before porting it back to the daily builds. Even with these fixes there will still be some problems relative to H13. There will still be no one-click way to select the edges all the way around the hole. The loop selection algorithms were completely rewritten as I'm sure you can tell. If we do add back more keyboard-oriented loop selection commands, a way to "select boundary" would be a good addition. There will also still be no way to specify an edge direction when selecting a single edge. If you select a partial loop we will always orient the edge directions to go from the start of the loop to the end, but with a single edge we have no way to differentiate without further changes to the UI. These issues are unlikely to be addressed until at least the next major release. Sorry to have hobbled the workflow for this tool. Using the HDK you could add functionality to make up for some of these limitations. For example you could add a toggle to "Find Boundary" given a single point or edge in the Group field? I don't know about the case of selecting individual edges though... Mark

Thanks for the video. There are a few things going on here. First, you are making an edge selection in the viewport, but the SOP wants a point selection. When Houdini is doing that conversion from edge to point selection, we are doing it rather badly. It looks like we are not preserving the ordering at all. I'll submit a bug for that. The inability to specify the direction of an edge selection is a byproduct of the massive overhaul to loop selections. As always, we knew there would be some users/situations where the old approach would be preferred, so there is already an RFE to bring back the "f/R" keys for explicit building of selections using the keyboard. As a workaround, could I suggest using a point selector rather than an edge selector to make your selections? Because you are selecting points rather than edges the "direction" is always explicit, and because there is no conversion from edge to point selection, Houdini won't mess up the ordering. You'll get the selection in exactly the order you specify. Further, you can still use the "Shift-A" volatile key to (reasonably) quickly select that interior border by clicking a few points. It will take a few more clicks than it used to, but it should at least make that SOP functional again... Mark

At the bottom of the RMB menu on the component selection button there should be several entries, including "Select 3D Connected Geometry". Those same entries show up in the "Select" menu above the viewport. And they have (somewhat unpleasant) hotkeys assigned, Ctrl-Shift-1, Ctrl-Shift-2, etc. Those menu entries actually just run python scripts from the file $HH/SelectCustomMenu so you can create your own set of favorite selection setups (if the defaults don't do it for you). Things were rearranged this way because connected geometry selection is now just a subset of what the new group list gadget does. So to select connected geometry you have to turn on that gadget, and configure it to show connected geometry. We wanted to keep that accessible through a single hotkey/menu, thus the scripted menu items. Hope that helps, Mark

I must say I was pretty excited about the idea of reporting bugs to Jason instead of the other way around. So I had to download it and give it a try 1. I'd suggest making the renderer exec path a parameter on the ROP (or a parameter passed to the python script). It would be nice to be able to render without having to edit the .py file or set an env var. 2. The Temp file calculation (tempdir + "temp.igs") doesn't work if $TEMP doesn't end with a slash. And the hardcoded temp.igs prevents multiple simultaneous renders. Maybe you should just use "os.tempnam()" or "os.tmpfile()" to create the temporary file? 3. Does the os.system() call block? If so, you can delete the temp file when you're done... 4. This is no doubt a problem specific to my setup, but I kept getting errors from python about being unable to "import os". I eventually changed the render command to use hython instead of python. Maybe you should change this to be the default because you know without a doubt that all Houdini users have hython, but plain python may or may not be there... 5. I tried rendering before reading the README, so my geometry had quads. Nothing rendered, but I didn't get any error messages (from indigo or the ROP). I would think SOHO could detect and complain if your polygons aren't triangles? And last (but perhaps most important) I would love to have one of the hip files for the sample images you posted to this thread included in the download. It would provide a great jump start. I'm particularly confused about the material stuff right now - I can't find the shader/parameter that simply says "make my teapot blue"... But then I'm happy when I can make mantra render my teapots blue so I'm probably not your target audience for this Mark P.S. I assume you know this, but there is a link to your stuff on the exchange from the Indigo web site.

Open up the Operator Type Manager (from the Windows menu). Find and select each HDA you want to remove from the OTL, and hit Delete (or choose Delete from the RMB menu). Or if you want to take a scripting approach, you can use otdelete. Hope this helps, Mark

Well, a pre-defined number of potential iterations is completely different from a pre-defined number of objects. To make an object that could split into 1000 pieces you'd only need 10 copies of that subnet. And that's if each split always creates only two pieces. You could make as many pieces as you want (based on the impact strength for example). And in that hip file the splitting is procedural, not pre-defined. It doesn't use the impact strength, but it does use the impact position to decide where to do the split. Using a more complex SOP network other factors could be taken into account. So as I said this setup has the potential to do everything you talk about, just not very elegantly (you have to create a subnet for each potential iteration - but each subnet allows for exponentially more objects, so you can pretty easily create whatever level of detail you want in the fracturing). There are actually advantages to this iterative setup in that you can have different fracturing behavior based on which "generation" of fracturing is happening. But I won't pretend that this was by design That all being said, as soon as I got back from that trip to LA I submitted an RFE to make a few modifications to the Copy Objects DOP that would allow this sort of setup without having to create a subnet for each fracture iteration. There just hasn't been time... But that's what this H10 wish list is all about! Mark

This has always been possible, though not necessarily as elegantly as I might hope: http://www.sidefx.com/index.php?option=com...opic&t=8037 Mark

Jeff Lait solved this one. The Rotational Stiffness parameter on the RBD Objects was set to zero. The help for this parameter says that a lower value makes the object easier to spin. But what the help doesn't say is that a value of zero breaks the system completely. Setting this value to zero is like giving an object a zero mass - it makes the value physically meaningless. Generally when a simulation suddenly breaks, the best thing to do is hit Undo a few times until it starts working again. Then figure out what parameter is was that you changed to make it break. Fixing a simulation as soon as it breaks is always the best time to do it. Another good way to debug these problems is to rebuild the simulation from scratch, and more often than not it will work. Then you just need to start comparing parameters (opscript output can be useful here) until you find what is different. Mark

The ability to select one or several nodes inside a locked asset and mark them as "editable" has been on the RFE list since before OTLs were released. And it's certainly not impossible. I honestly don't know why it has never percolated high enough up the priority list to get it done, but somehow it hasn't. And no, I don't have any other suggestions on how to do this kind of thing within the current architecture. There's a lot you can do with Object Merges and opinput expressions, but eventually you're always going to hit a wall... Mark

To figure out how to fix this hip file, you have to look at the RBD Glue Object DOP. Inside there is an RBD State DOP which tells the object to which all other objects are glued that it should calculate its mass, center of mass, and inertial tensor on every timestep. The reason this is necessary is that having glued objects break off will change these values for the combined objects. In the attached hip file, the handle object is the object to which the others are glued, so it has to be set up to recalculate its mass, center of mass, and inertial tensor at each timestep. Failing to do this results in this object having a mass of 4000, and a center of mass way above its actual center of mass once the threee cubes have broken off, which explains the erratic motion in the original file. Mark cubes2.hipnc

The problem is that when doing multi-host rendering (even if the hosts are all local), the "remote" mantra processes are run by the hserver service. Services on Windows are, by default, run as a special "LOCAL" user, that basically has no rights to access anything on the network. So the mantra processes started by hserver are also run as this LOCAL user, and therefore they can't access remote drives (even if you use UNC paths). The solution is to have hserver run as a different user, one that has sufficient rights to access the remote network drives. To set this up, open the control panel -> administrative tools -> services. Then RMB on the Houdini License Client service, and choose "Properties". On the Log On page, change it to log on as "This Account", and specify the account name and password for some user with sufficient priveleges. You may want to set up a dedicated "RenderFarm" user which only has access to certain shared drives or whatever. Then restart the Houdini License Client service, and your mantra renders should be able to access texture maps specified with UNC paths. Mapped drive letter still may not work in this situation, because I believe drive mappings are local to a particular session. So unless you set up hserver to log on as the same user account as is currently logged in to the machine (with the drive mappings set up), the drive mappings will be meaningless. I don't know enough about Linux, but I'm sure there would be ways to set up your Linux environment to result in these same permission issues. But I guess the default method for running "services" on Linux like hserver result in sufficient permissions to access network drives. I hope this helps clear things up. Mark

I may be misunderstanding, but you could use an expression in the Delete DOP that looks at the geometry of each object, and deletes the ones with primitives in certain groups? In general you have complete access to the geometry of each DOP object from within DOP nodes. Any expression you can use on a SOP you can also use on DOP geometry. Mark

Using .sim files is probably the way to go. There is a Copy Object DOP that will let you make copies of existing objects. There is the Delete DOP which can be used to delete objects from the simulation. And just because a DOP object comes from a File DOP doesn't mean it can't be controlled by the DOP Network. You can add or modify data on obejcts read in from a File DOP using all the regular DOP nodes. I don't know what more to tell you without more specific questions... Mark

No, changing the collision options for RBD objects does not cause those other fields to be filled out (as you've already discovered). Those other fields are used by different solvers. The POP Solver, for example, fills in the prim[uv] attributes. No solver fills out all the fields. Mark