David Gary

HDK !!

The answer is: ALL :) Houdini Escape lets you use otls made with HoudiniFX, it just doesn't let you create any ( unless sthg has changed), and"sopsolving" can be even "emulated" in sops, using fileIn/fileOut approach ( i know some people even use tools like ramdisk to write to ram as if they were writing to disk, so it's super fast). Apart from ragdoll, the core of my tool is not a solver, it's a sop, that you can put, and that is put in a sopsolver! If you're not using bullet, it works on 12 too, which i developed it with ( cos i wanted for better compatibilty to refrain from using novelty workflows) -d

Yep, i put a lot of thought into the "infrastructural" side of things before even starting to "code", looking at Massive, boids, etc.. Locomotion is separated from skeleton reconstruction so it and can be "decoupled" and so as far as packed primitives go, yep, in my workflow, you just replace skeleton reconstruction by baked out the geo and it works:) my video card is a bit and so i haven't demoed it yet . And this is often sufficient for manyt cases ( ex. stadiums ). One subtle thing that you might lose to an extent if you cache out your meshes is the live blending between actions , which produce new interpolated rotation values and consequently new skinned geo, but again, if you cut into a long action, that's all just fine he he) The good thing is that skeleton reconstruction can be re-coupled,which is needed sometimes, especially in the case of Bullet where the position of a bone influences back the simulation if the character is for example hit on an arm.. About IK solver in vops, i'm glad you mention it: it's on my list. Well, i was going to go the C++ route ( there's a great example in the HDK about it... the documentation is just awesome!!). i don't have joints anymore in my character representation, not physical ones that is, just points. as far as AI and flocking, there's a few nodes that replicate boids ( essentially target based locomotion, but then you convert the target into agent space and you can also call the corresponding angle/distance as new attributes in the brains - which is more "Massive-like" and it's often a nicer space to describe things into.

Hi Clear! I haven't tested Miarmy, the only thing which i'm a bit skeptical about is that they claim that getting rid of nodes and replacing them by interfaces was a progress, while virtually everyone everywhere have finally come to agree that nodes makes life so much easier and clearer. It seems to me that it would also greatly limit the complexity of the logic you can define and become soon intractable. If it's a matter of "refining conditions", as i seem to have vaguely understood from them, meaning conditions-subconditions-subsubconditions, it's actually implemented in Crowdigy in VOPs and 'And' vops. A subcondition is a child of a condition AND a new condition, that's how you make "trees "of cases,subcases etc left to right, by "parenting them" horizontally and you possibly merge back with an 'or'... In any case, with my tool, since it's done in Houdini, nothing stops you from turning your "brains"/logic into one big otl with a simplified set of controls, and that's actually what you would pass to an artist on a shot This means also that ready-to-run agents , as they exist in Massive, are something that everyone can build and even sell. There's many ways to integrate this in Maya , at its simplest, you turn everything into a big subnet and bam! but there's actually finer control that exploits node similarity between Houdini and Maya, which i haven't had the time to explore yet. I'm really hoping that SideFx is putting all its efforts into speed, speed, speed now for Houdini Engine... and for Houdini itself. GPU acceleration pleeeeaaaase!!!!

"CROWDS ARE HERE... CROWDS ARE HERE..." Hi all, After a couple of projects involving crowds and flocks, it was clear to me that Houdini had everything to become the new crowd software, but besides just brains as sopsolvers, the whole pipeline/framework had to be built to be able to deal with characters in a fast way! ( SOP-speed that is), along with proper rendering tools (custom instancer). That's what i did over the last couple of months Fast, fully customizable crowds are available in Houdini with the upcoming release of the CROWDIGY 1.0 ( codename) plug-in/Framework No CHOPs, no copy SOP... only current VEX/C++ speed ! Built upon more than 30+ otls. Demo: http://vimeo.com/112054883 ( WATCH IN HD!!! or download - working on a better/richer version). Currently Includes/Features: - Crowd DSO (Mantra): character deformation happens DYNAMICALLY AT RENDERTIME (currently porting the code to Renderman and Arnold ) - - Ragdoll module (made with Bullet) happening in sync with crowd solving -Action editing module, action graph ( fully editable as geometry to handle action choosing, transitions, blends etc. processed at VEX speed of course), -Works with arbitrary skeletons, actions are saved in a custom format ( no CHOPs i said:) ). Skeletons can be imported as .bvh and are converted into our own format -Full Artficial Intelligence Module ( aka "brains"): Comes with a lot of predefined agent "inputs" ( Vision, Terrain adaptation, Flocking etc ...). A cool one is the Path Finding SOP (Djikstra/A*-like pathfinding), built upon the uber-awesome-and-remarkably-fast Shortest Path SOP), Of course you can define your own brains using all the array of of VEX and SOPs tools -Entirely integrated with the rest of Houdini : cloth, particle, any DOPs are accessible at each timestep...( see the coupling with particle sims at the beginning of the video) ( and much much more to come but hush!) And of course: DEPLOY YOUR CROWDS IN MAYA,3DSMAX, CINEMA4D, UNITY, etc.. through the Houdini Engine (populate, invade, spread or colonize ..) The official commercial release is expected end of 2014, on Orbolt. The plan is to have it under closed beta at first. Compatible with Houdini 11 to 13 ( only 13 for ragdoll module) So much more i have to say, but i will keep it short to start with... ( currently putting together a 1hr overview video ) Any questions: shoot a mail at houdinicrowdsolutions@gmail.com Not sure if SideFx has something cooking for Houdini 14, but i wanted to do it anyway, and couldn't wait ha ha . i had thought the infrastructure through in great lengths before i went ahead and actually implemented it - to make it the most versatile, algorithmically fast, conceptually simple, the most "houdini-esque". I hope it is Will be looking for nice mocap and rich rigs to make even more pictures... (did i tell you i even made my own mocap with a Kinect sensor.. it's not entirely there but it's really really promising) P.S You asked about speed: It includes a live speed test on a rather poor machine! 6GB Ram/Core Duo/512Mb Vram cough cough! Comparing it to Fabric Engine for instance is meaningless, Houdini hasn't got GPU acceleration yet. And i wonder how much time it would take for them to code everything.. Let's only compare what can be compared. 1/3 sec per frame for 1000 characters ( 50+ actions) for pure solving and display 2 sec/frame for 100 characters with Bullet solving -d

Hey, As i was typing the reply Mario and Madjestic kinda answered already It's funny you raise this question and propose to solve it that way because i had similar thoughts lately. How it happened is a while ago i asked myself the question: "what is this CVEX thing, why not another vex context", and i came across the definition in the documentation : CVEX = "vex that executes outside of contexts!" Bingo! I think we're getting a rich idea here: I think we should rethink the contexts and VEX/VOP could be defined out of contexts and the bindings would determine where it is executed ( by binding i mean global parameters and outputs: that's how it's more or less working with the volume VOPSOP). The compilation would tell you if you could use this code in SOPs or in rendering or in COPs, depending on some of the functions you use that only make sense in some contexts and not in others and you would have "vex callers" in different contexts There's a lot of cool things we could do with this: ranging from using the same code for surface shaders and displacement shaders ( skipping variables exports) to baking a shader to geometry (surface/volumes, either GLSL or on vertices) or baking to COPs !! (i'm not a hardware specialist at all but shouldn't this unification be reflected in a unified SIMD hardware- it was more or less the idea at nVidia, no, to render with graphic cards?), or even bake volume to i3d, whatever you want really, the things you mentioned would be a subset of this! Instead of having several VEX/VOP contexts for 90% of the functions that are similar, why not have one UNIQUE VEX context with bindings. I mean, after all, Vex contexts are a redundancy, no!, and with this we're getting THE VEX UNIFICATION ! So CVEX ( from what the definition says at least) corresponds to your FOP! I think that's the underlying idea of it, and it would be cool to have this pushed further ( i haven't thought of the limitations of this approach yet, there may be some big ones. Question is: are contexts similar enough for this to work). hope i was clear -d

Two replies: If you want to do that in the viewport, this is not possible. Volumes are monochromatic! As for rendering. 1) At the shading level: the workflow is no different from surface shaders where you import/call attributes with a parameter VOP with the name of the proper attribute. 2) At the "volume level"( in SOPs): thing is there is no such thing as volume attributes. What you have instead is you must merge several volumes together ( like coming from a fluidsim, typically). And for each volume which plays the role of an additional attribute you use the primitive attribute "name" and set it to the name of your attribute ( 1 volume= 1 primitive, this gives you the "name of the volume") This is EQUIVALENT to volume attributes ( instead of "attaching" attributes to a volume, you merge several volumes together which will play the role of the attributes. note that volumes are scalar fields ( floats), so if you want vector attributes you need 3 volumes). Example: Coming from a fluid sim, if you want to use the burn field as the color attribute for your volume ( whose shape is represented by the density field), what you have to do is typically to merge the "smoke object" ( the "density" field) and the "fire object" ( the "burn" field) together. Fluid simulation sets the "name" attribute properly for you already ( you can check that in the geometry spreadsheet, you'll find "burn" and "density"). Note that you can import any other field with the Dop Import SOP, as long as it is displayed at the DOP level. If you want to use the input field "burn" as the input for color in your shader you just use a parameter VOP with the same parameter name: "burn", and you pipe it to the piece of code in the shader which computes final color. Names are not relevant, as long as the name in the parameter VOP and the name of the "field" match. Now if you want to create other volumes attributes from scratch ( without fluidsim) you create other volumes with proper "name" attributes at the SOP level ( with an AttribCreate SOP) and you merge them with the volume which will play the role of density. You can do that at the DOP level, create your own field with (SOP)scalar/VectorFields DOPs and the name of your field becomes the name of your "name" attribute when re-imported in SOPs. The same idea applies to motion blur and "texture advection". The whole thing may seem unintuitive. I thought that at the beginning, but it's actually perfectly consistent with the rest of fluid implementation This may change with H9.5 though. Hth David

Hey. Mantra is getting close to be the best and most complete renderer in the industry ( with such a speed, volumetrics, PBR, and properties overrides, not to mention the procedurals) , so i think the more we know about Mantra specifics the more we can optimize our scenes and produce fantastic images. And tiling is a critical thing for large scenes. But, reading this interesting post, i'm still a little confused... The fact is, aplogies for throwing some fuel on the fire, it actually seems that point clouds ARE tiled : the wiki says so (here) , the Houdini help as well ( if you go under the Geometry File Format ), besides this looks completely consistent with the way the pc handle operates ( who should i trust, or am i missing something) So, my current opinion up to that point is that point clouds actually win on all fronts: -size: lighter files, sparse distributions -way to work in the shaders formulas to more or less replace raytracing (SSS or AOC classic approximations) -way to store/bake shaders - irradiance caching -more or less unified with photons paradigm Up to the point where i actually wonder if they shouldn't be also the way to go for volumetrics ( i mean to replace i3d, not for procedural textures, but to replace brickmaps). i mean i don't know the i3d specifcs, but tiling is a good thing, multi-scale ( kd-tree like) is another even better, and a sparse point distribution even a third. Does i3d have all that? If this is the case, then Point Clouds become the basis of almost all advanced rendering techniques, and this kind of unification is very satisfactory ( from photons to SSS) both theoretically and implementation-wise. anyway, Mantra rocks!

To i-d and ofer and other people who may have questions/pbs about the video streaming : don't hesitate to contact Chris at Cmivfx: chris@cmivfx.com or chris@cmistudios.com. And a MAJOR upgrade of the player is coming within the month, with chapter markers, bookmarks and more -d

Hi everybody! We're very happy to release the sequel and first application of our Fundamentals video, entitled "Introduction to Procedural Modeling" http://cmivfx.com/product_houdini_procedural_modeling.asp Aimed to work together with the Fundamentals video and to be a large and thorough deepening, this is also en entire project-based video, since Houdini is not just for theory but also for practice. It has procedural challenges like rigging caterpillars so that they adapt to any terrain, but also all kinds of modeling approachs, cause real-world scenarios are not 100% procedural or 100% art, they're always a blend. Plus The challenge at CmiVFX was to find which effect/scene could combine the maximum diversity of training content, while keeping the consistency and the realism/reality of a project-based approach. We ended up with the idea of the tank cos it had everything: 1) In terms of procedural modeling and applying the concepts of the Fundamentals, it has everything as i mentioned and procedural modeling here even fuses with rigging! Hearing the change and the ongoing demand, we wanted to show that Houdini is not just for big studios and/or for computer science PhDs and/or impossible-looking shots, but for EVERY artist who just want to do things FASTER, NICER on ANY project. People often used to say: " i've been told it's possible with Houdini, that can be done, it's possible in theory", if we can, let's not just say that we can, let's DO it. 2) Then, in terms of the base for possible future content: let's suppose we want to create a procedural camouflage pattern, rendered with global illumlintaion, motion blur, this allow us to show a lot of things about rendering, let's suppose we want some tanks to follow a parade, or to move in synchronicty with cannons animation, or interacting with their enemies, this allow us to teach CHOPs and/or particles and behavioural animation. Let's suppose we want planes to drop bombs/missiles onto a tank that will explode, this allow us to show all the dynamics, the rigid-bodies, the partice-based or fluid-based explosion, the particles for volume rendering etc. I'm not particularly into war stuff, quite the contrary but i got to say that creating a battlefield scene with tanks allow us to show an incredible number of things with the consistency of a project-based approach where you have to do EVERYTHING with Houdini. Don't do war, simulate it! lol Enjoy! David

Hi all! Actually i have all these PDFs on my computer. :) There were sooo good i kept them ( mine came along with Houdini 5.x, i guess it's even better but from what i see, they look identical) and i still use them once in a while to check things. ( That's the doc i used intensively to learn Houdini at that time, it was well written, well organized, and some relevant info may only be here). I've never felt very comfortable with the html help actually. The expression cookbook and the l-systems were very nice actually. Nice tutorials as well. I'm gonna ask if i can upload them somewhere. -d

Tamis: Well, actually i don't know Python well for now. Thing is, I've never seen the whole point of it so far but I'm certainly wrong. From the look i took at these links... Man! Makes me want to dive into that right away. Biut i've got loads to do right now. I've always seen Python as a slow language , good for automating interface tasks, but that's all, but now with the OpenGL bindings,yum yum! I've always seen it as a high-level wrapper of things that i would implement in VEX for instance, so python code *on top* of the nodes. But having Python code now *inside* of nodes like that changes everything! I knew Python OPs but never saw their point ( i mean speed-wise), now i do. This being said, if Python now lies "inside" the nodes, will these C++/python bindings be able to ceoxist with what is inside the nodes already and which is linked to low-level c++ through HDK? I'm not quite sure, it would be killer if they did Mattd: Yes, rendering... Mantra is sooo good, soo fast, sooo customizable! But there's so much to say about it! Little by little i guess we'll have to. -d

( as before, the dvd came out on our sever before i could prepare a little speech. lol.. thanks guys ) Hi everybody. We bridged the gap! A warm hello to all the new users of Houdini. This video is for them! The old users know us already, i know they always want more of advanced stuff... But with the H9 boom, everybody wants to learn Houdini! We couldn't leave the growing community of beginners on the side. We have to please everybody! Everybody has to discover this wonderful, marvellous, mind-blowing, brillant, killer, ahead-of-its-time-since-the-beginning... application And beginners won't always stay beginners anyway: so we had to bridge the gap left before our advanced dvd AND set the first stone of a comprehensive and unified Houdini training. That's finally done with the release of our new DVD called : Houdini Fundamentals ( AND the sequel will be released in the 1-2 weeks! http://cmivfx.com/product_houdini_fundamentals.asp That's it! Learn Houdini from the ground up, setting some solid foundations and leaving no holes usually left by manual discovery, with no questions unanswered. So that now ALL users will be able to follow our DVDs about Procedural Modeling of Cities, VEX and l-systems. A great learning experience in perspective. http://cmivfx.com/product_houdini_cities.asp http://cmivfx.com/product_houdini_lsystems1.asp http://cmivfx.com/product_houdini_lsystems2.asp http://cmivfx.com/product_houdini_vex1.asp http://cmivfx.com/product_houdini_vex2.asp Since the workflow between h8 and h9 hasn't changed on Cities and L-system topics ( with the only thing that now we can write shader overrides differently), do you think it's worth upgrading the video, just "cosmetically"? Do you, users, really want that? It would maybe take some unnecessary time that should be put on something else? It depends. We're all ears on that. ( phrenzy84: about 3dbuzz, i don't think it's called "Houdini Fundamentals" ( maybe old VTM's, i don't remember) i mean we checked and we were cautious to pick a name that didn't exist already) David

Hi, yes it has been hosted at Cmivfx a certain time ago. I think the link aracid sent still works. I'm gonna check and if not ask Chris from Cmivfx to put it back on cmi list of freebies. It has been done in houdini 8 but all the workflow still applies ( and it was my first video tut 3 years ago as an amateur with an awful lot of "alright", "ok", that should be removed... needless to say the dvds are nothing like that). warning: the param expression is deprecated in favour of the stamp expression. check the help on that -d

well, you're even closer to the result that you think you are, lol About the deep shadwos I don't use deep shadows ( i mean specifc shadow maps). Just use Ray-Traced Shadows under the shadow tab of your light. And it defaults to "transparent shadows" ( below). It's equivalent to deep shadows ( one is raytracing, one is more "scanline" - but i lose my old opinion that scanline is faster than raytracing, not anymore). The default volume shader handle shadows naturally, no need to write any more VEX or complex raymarching: It's aaaalll taken care of . That's the beauty of the new volume integration. You may have to use more ray samples in rendering than the default ( i get a grainy look with the defaults). -d