This does not change the attribute values. To change the value of the currently processed element, see the Bind Export VOP. To change other elements or other attribute classes, see Set Attribute VOP.
Bind Export VOP does work though. I'm not sure of the details of why add attrib doesn't do per-point authoring though.
Yeah, what Guillaume said about finding them via the help docs is the best. There is a page that has all of them by category; and if you open it from within Houdini (not from www.sidefx.com, but from http://127.0.0.1:48626/ [127.0.0.1] or something like that), you can click load and it'll toss those examples in your Houdini session.
Hopefully Apple will come to their senses and either let the experts handle it, or hire someone to fix it internally. Both Marks have been doing an incredible job trying to work around the moving blackholes of OpenGL in OS X, thanks guys!
Rob, if you can dual boot Windows or Linux, for cases where workarounds take a while to get patched, that's a good bet (that's what I've done, where possible). But as far as not fixable issues, the problems often only manifest themselves in specific hardware + software combinations.
For example, my 2011 MacBook Pro (6770M) had lots of problems that weren't present in the Desktop cards running OS X, or even other AMD MacBooks. I would just keep submitting them to SideFX as you encounter them, with system info and screengrabs/repro steps where possible. It's not ideal, but like Mark said, until Apple gets their butts in gear…
chrono1081 Thanks! Do you just want the log or the .hip file it creates too? I noticed in temp directory next to the log there's a .hip file but it appears empty anytime I open it. I can reproduce the crashes every time so if there's anything I can do to help just let me know.
I'll be sure to file a bug report when I get home.
Unless the steps are really easy to repro, or you know for a fact they don't need the hip file, it doesn't hurt to just zip up the log and hip files, and send them to SideFX together.
Like edward said, FBX is the way to go. If you start following the crowds docs, you'll get more info on getting a character into the crowds system. And the Street/Zombie example is really good too; I feel like having both that example and the docs, helps things make the most sense.
You can import each cycle as its own FBX file, or you can bake out all of the character cycles as one cycle, but you'll need to setup an Agent Bake for each cycle, and set it to the appropriate frame range.
Before submitting to SideFX, I wanted to check wtih others: if anyone using Gnome 3 seeing slight lag in the menus? I recorded a video (ignore the gnome menu stuff), which shows the menus lagging behind. Even when I disable all animations in Gnome shell; this affects the tab menu as well, and is just aggrivating.
Anyone else seeing the same thing? I don't know if there is something else to disable in Gnome shell, or if there is some way SESI can draw/code the menus, so they don't draw slowly in Gnome shell?
FWIW, I don't currently use Gnome shell, I'm just thinking of CentOS/RHEL 7users who might have it madated by their studios.
Jorge's advice is the way to go. I didn't hit problems until I tried to setup Hqueue on my crunchbang machine - a few packages conflict with the libc6 version from jessie.
I'm trying to modify the cloud rig's cvex shader, so I can taper off the cloud on the boundaries. I want to make it easier to blend between BG cloud rigs, and FG hero clouds.
Could someone share some insight as to why relbbox doesn't work when rendered in Mantra, but does in the viewport? There must be some un-documented gotcah here, right? Or is this a bug?
This is using the Cloud Rig shelf tool, so the viewport is displaying an Attrib VOP, set to SHOP, and pointing to the cvex network in the shopnet.
With the POP Solver, I noticed I could get a 27% speed up in large particle sims by using a Switch DOP to disable Collisions.
I thought that perhaps if I set Enable Collision Attributes to Set Initial, and initial was 0, I would get similar speedups; but it was the same (a hair slower).
Should the Enable Solver be that slow? I haven't done much low-level DOPs work, so it could be that I'm missing something. I was just surprised at how much faster Switch + Null was, compared to the Enable Solver, especially considering Enables are all over the POP Solver.
The attached file has a modified POP Solver, and here are some of the results I was seeing with a 300,000 particles being birthed + some noise and color (and gravity), for 72 frames (POP Solver time only):
- No Modifications: 4.59s - Set Inital (on Enable Collision Attrs) to 0: 4.52s - Disconn. Enable Collisions and Reaping: 3.41s - Disabled Coll. Attrs via Switches:3.60s - Disabled Coll. Attrs + Reaping via Switches: 2.34s
I know reaping and collision attributes aren't something you'd normally get rid of; I noticed in the Performance Monitor those two areas were a big chunk of sim time, and could imagine scenarios where you don't have any collisions, you'd want to avoid paying that cost for no reason.
Well, that would explain the time difference much better completely spaced that the Linux machine is much faster (3.4Ghz vs 2.4Ghz). I blame the 3-day weekend and too much food… Thanks Marty for running that on the same hardware.
And thanks for the clarifications Edward, it's helped these make more sense; particularly, how adding geometry affects performance.
Re: disappearing Packed Prim anim: inside of the RBD Packed Prim object, you need to toggle on Allow Caching on emptyobject1, then you can see the cached geometry.