yourdaftpunk

Mason, mind if I fold this into the VEX Syntax package?

Houdini has to decide which function to call. It's looking at these two function signatures: float noise(float) vector noise(float) And it has to pick one. The parameter in both is a float, so that doesn't help distinguish between the two. Houdini next looks at the return values. Do any of those possible return values make sense with the next operation? Your expression is: (noise(seed) - 0.5) And Houdini sees that you subtract a float, thus you must want a float back. Houdini chooses: float noise(float) That value then gets multiplied by a float, your "speed" parameter, then the float is assigned to the vector distort. When a float is assigned to vector, the behaviour is to set each component to the same value. It's an implicit cast. That's what you noticed. The solution is to explicitly tell Houdini you want a vector back, even though you're about to subtract a float from the result. The full line becomes: distort = (vector(noise(seed)) - 0.5) * ch("scale"); This is function casting. It's not a full cast from one variable type to another, so it's fast. Cheers, Shawn

Sigh, fixed. Thanks!

Oy. Fixed now. Thanks!

Thought this was worth reposting here incase you didn't catch um @ sidefx.com. Shading and Shader Building (Kai Stavginski) https://vimeo.com/142534640 This masterclass provides an overview of new and existing shading features in Houdini 15. This includes an introduction to the new SHOP shaders as well as shading and layering in VOPs. We also take a deeper look at working with BSDFs to build custom shaders. Loops in Sops and Vops (Jeff Lait) https://vimeo.com/142534639 Houdini 15 has introduced a new way to do loops in VOPs and SOPs. This masterclass provides an overview of the new looping constructs. With the new constructs; effects that used to require significant technical knowledge to achieve with Foreach SOPs can now be readily built. Grain Solver (Jeff Lait) https://vimeo.com/142534638 Houdini's grain solver uses Position Based Dynamics to simulate sand. This masterclass describes what that means and re-builds the sand solver from microsolvers. It also provides some insight and advice in how to tweak the grain solver's parameters to get the effects you desire. And follow GoProcedural on vimeo if you're not already. Cheers, Shawn

Symek, you're right, I'm lucky to tackle this in sops. Have you seen whole buckets poisoned with NANs in mantra before? I remember mental ray doing that, but so far mantra has been kind to me. Arnold too.

Anim, I do intend too. I see it as three bugs to report: 1) Arnold's handling of NANs. 2) Arnold's handling of certain topologies without NANs which seem valid in Houdini (the point delete issue I mentioned). 3) Houdini's/VDB's issues with certain particle to vdb operations and/or sdf smoothing operations. For the third bug, if I can find the time I need to: 1) Remove custom otls and slim down the network to the problem area. 2) Transfer the 1.2GB particle cache frame going into the mesh nodes so they can diagnose the issue. 3) Write up some additional observations which I think will help. It's my last week on the job so I would put all this well bellow finishing I'm also curious what would happen if I wrote that mesh out as an alembic or obj. Would it be loadable in other apps? Would Houdini gracefully bring it back in? I hope this post helps some future TD banging her head against a monitor. NANs are part of the floating point specification along with INF values and software needs to properly take this into consideration. Much like non-manifold geometry, this stuff will crop up from time to time, or it will come into houdini through the external pipeline. I remember educating compositiors about the issue years ago when they first started moving to Nuke 6 / exr-half and they couldn't understand why some renders had black pixels which couldn't be easily fixed and grossly contaminated neighboring areas when blurred (protip- Houdini has a builtin cop node called illegalPixel with a cute icon for handling this). The solution then was a simple expression much like the vex code above.

A problem I've now had twice in production is NAN valued points in hi-res meshes generated from vdbs. Out of maybe 10 million point meshes per frame across 100 frames I'll get one or two meshes with 200ish bad primitives (prims with garbage points, so far NANs, but I bet infinite values wouldn't play nice either). These meshes look fine and render fine in Houdini and the bgeo's are the same size as the other frames. If you finish in Houdini, you'll never know there is a problem. The bad prims are tiny and just not drawn as they have no position. However, caching out .ass files results in silently truncated frames. There are no errors when writing out these .ass files from the in house tool. The corrupt frame gets rendered in Maya and no mesh shows up or it throws and error and I get an email about issues with my mesh which, again, look fine in the viewport. Files are about half the size they should be so truncation is clearly happening. If this sounds like something you're experiencing, consult the spreadsheet and sort your position values by any channel and if you have not-a-number values it'll look like this: If you're familiar with vex, you may know there is a NAN testing function called isnan() which will work on a float so we can test against each position channel and if any fail the test we have discovered our bad geo. A word of advice though- don't just delete the bad point, delete the bad primitive! For whatever reason, Arnold doesn't always find the geo well formed when culled by points in Houdini. You'll often get a vertex mismatch error during rendering and another email. So the safe solution is to walk over primitives in a wrangle and test the points of the current primitive. If any fail the NAN test, delete the entire prim: // PrimitiveWrangle code int cull_prim = 0; int pt; vector pos; for (int i=0; i<primvertexcount(0, @primnum); i++) { // convert the prim vertex -> linear vertex -> point number pt = vertexpoint(0, vertexindex(0, @primnum, i)); pos = point(0, "P", pt); if (isnan(pos.x) || isnan(pos.y) || isnan(pos.z)) { cull_prim = 1; break; } } if (cull_prim) removeprim(0, @primnum, 1); If anyone has a better solution, I'd love to hear it. I'm a bit disappointed by how brittle the Arnold/.ass combination is compared to Houdini's handling of floating point values. Vertex mismatches and NAN errors have wasted too much of my time. On the other-hand, Arnold renders look great! Cheers Shawn

Hi Diego, This has me a bit miffed. That's unbelievably bold to sell a pirated course. And to a small community no less! This ain't Maya, yo! > It is always frustrating to see my workshops being pirated, but its an occupational hazard unfortunately. Yup, and I almost saw it as a right of passage when my course was first pirated. Was gonna happen, nothing to be done. But these guys have serious chutzpah to resell others' work. Grrrr.

Just a quick heads up, VEX in Houdini is running for a third term and slots are still available. Week 1 starts on July 6th: http://www.cgsociety.org/training/course/vex-in-houdini I've been updating materials for Houdini 14 and started covering the useful changes. CVEX is taking over, dummy-nulls are resigned to the history books, and isn't that wrangle parameter script award worthy? Can that get VES statue? Cheers -shawn

Just a quick heads up- the course starts soon and there are still a few openings. This is probably the last time I will run the VEX course. Hopefully everyone gets in! -shawn PS: May the odds be ever in your favor.

Thanks for posting here, the message system is a bit... rough. I've heard word they are updating the entire platform though so look forward to improvements. Second, you sound like exactly like the audience I had in mind for this course! Sorry about using the visual effects lingo, I'm going to update the landing page at some point. In the broadest sense, TD, or technical director, is someone who doesn't mind programming or tool building to solve a problem. That could be a specialized lighting rig of some sort, a procedural building generator in Houdini or just someone with the scripting know-how to troubleshoot a pipeline. Lots of TDs are self-taught programmers- artists that are highly motivated to learn on their own and love to take a crack at a hard problem. Basically, if you've done any sort of programming and you're comfortable with houdini you'll probably do fine. It also helps to have a bit of linear algebra knowledge- understand what a vector is, what it means to normalize a vector, how to add vectors, dot-product and cross product, etc. I'm not currently providing a math cheat sheet but I may in the future if there is a demand. There are already lots of great free videos and resources on the subject. Additionally, if you're up to date on the free sidefx videos, peter quints videos, you're in a really good place! And you'll be able to ask me specific questions when the class starts which is a huge help if you avail yourself of the forums. And yup, Cinder is the bomb.com and my good friend Justin is over at the Barbarian Group working with Andrew, Robert and all the crazy brilliant Cinder devs. Went to a cinderdome once, they are a fun crew! -shawn

I believe we are already over half full so I expect it to sell out. If you register in the next week I think you'll get in no problemo.

- is it necessary to have some knowledge on houdini interface etc prior in order to follow correctly your workshop? I'd say so as this is not a beginners course. If you really want to take it, you have 5 weeks left to get comfortable with the program, but it's challenging because Houdini is deeper than any other 3D package so you need to commit several hours to watching the sidefx videos (which are great btw!) and going through example scenes that come with Houdini as well as tearing apart the networks which the shelf tools build. You have the programming background which is great and that will get you far in Houdini's procedural world. - if you decide to repeat the course next year do you know when would it be most probably? summer as well? (that would be great for me!) No firm plans, but I'd like to repeat and summers are preferred for me too. This depends on my day job - how much workload would this workshop take? I may have an update on this later as I'm currently just starting to record and design assignments. I'm trying to cover my material with a similar commitment to video length/assignments as the courses by Spencer Lueders (Fluids) and Robby Thomas (Python in Houdini) which I've been auditing as good examples. So if you've taken similar courses that's the reference point. More specifically though, if you have little Houdini experience or little programming experience I expect it to be far more challenging and time consuming- you might be up all night reading docs and hammering away at code. - i dont know if out there in the world there are jobs that allow you to do this mixture of tasks: art related & code. Are there any? Sounds like you've got the bit nailed that most artists stumble with- programming. Marc and Netvudu's answers are right on point. You'll be desirable to VFX studios if you're straddling both worlds confidently. As for games, I imagine it's the same, but you'd have more mentors as far as coding goes. Hell, you're on your way to being a one man indie game studio if you can program and handle the art assets yourself. Good luck if you decide to join us and do study that Houdini interface hard! Find an excuse to do something in each context and work on moving data from one network to another.

@paxsonsa Awesome! See you there