danielpferreira Posted January 31, 2008 Share Posted January 31, 2008 I like this! I would really like to have the ones in "bold", although the other ones would be great, too - good multithreading (for DOPs first, everything else later!) - fast volumetric engine - universal material for mantra (a la VRAY) - Collada export ( this is coming with FBX, right? ) - better DOPs<>SOPs integration (able to read SOP point data directly from DOPs, be able to visualize the attribute spreadsheet for DOPs easily,...) - faster viewport display - Persistent SOP Attributes > Will accumulate data. Won't be procedural, and will need to run from first frame to process properly, but could be incredibly useful in certain cases. Right now, you need to set up a particle system and accumulate into particles if you want that functionality. - Good collisions. POP collisions are not that great. What about adding levelset (implicit surface) based particle collisions? - Faster Mantra - Rewrite some tools so they are faster. (Grouping, Smoothing, etc...) Now I will go and read the thread to see what people think. Quote Link to comment Share on other sites More sharing options...
grasshopper Posted January 31, 2008 Share Posted January 31, 2008 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 Hi Mark, thanks for the link. That's the method I remember you demonstrating in Santa Monica last year and I think it perfectly hightlights the issue I was trying to address. This method only works to a pre-defined number of iterations and each step requires you to copy a set of DOP nodes already built earlier which gets pretty hard to implement if you need many levels of the same repeated behaviour. It works okay for three or four levels of splits but what if I want an object to procedurally shatter into thousands of pieces? What if I want the shatter to be different depending on where the object lands and the localized physical forces that may be acting on it at that time? I'd ideally like to be able to express the splitting in a single block of DOP nodes and have the splitting handled recursively (so it will work to any level of splits needed) with new DOP objects being 'spawned' when needed based on triggers. Is that something supported by DOPs now and, if not, how hard would it be to support it? John Quote Link to comment Share on other sites More sharing options...
sergo Posted January 31, 2008 Share Posted January 31, 2008 1.Better python integration 2.Better python documentation Sergo. Quote Link to comment Share on other sites More sharing options...
danielpferreira Posted January 31, 2008 Share Posted January 31, 2008 Some additional things that would be cool: -- snap to surface (POP and SOP) -- SOP to modify an attribute based on ID matching with another geometry. For example, you have two particle systems, with a different number of points, like a frame after / frame before if the system is creating new particles every frame. I would like to be able to compute an attribute based on both velocities, only when the point ID exists in both systems. Like a point SOP but instead of using $PT, using $ID or the attribute of choice (It would be great that houdini had that out of the box) Hey guys what about offscreen flipbooks? that would be freaking awesome. Quote Link to comment Share on other sites More sharing options...
hoknamahn Posted February 1, 2008 Share Posted February 1, 2008 (edited) With my little experience these are the things i really would like to see.2 - Integrate the fuzzy logic engine from Massive Software, this would bring so much power to Houdini... why reinvent the wheel? is it possible? Also, better integration so we can import/export to Massive. 6 - Full support for Mental Ray 10 - Bundle PFTrack tracking engine inside Houdini as a node would be a great time-saver on many many things. [fighting_mode = on] 2. Several people here have asked about fuzzy logic... How it could fit into current Houdini pipeline? How AIOPs should work? Any ideas? How _Massive_ engine can be embed into Houdini? What about licensing? What about integration of code, libraries whatever? I believe in this case integrity of Houdini could be broken. 6. My favorite topic. Why do you care about third party renderers instead of Mantra? Why SESI should care about Mental Ray instead of improving their renderer? Should SESI write all necessary DSOs to provide support of all features of Houdini / Mantra in Mental Ray (like metaballs, point clouds etc.)? Or NVidia / Mental Images could do that? 10. Same as for 2. [fighting_mode=off] Edited February 1, 2008 by hoknamahn Quote Link to comment Share on other sites More sharing options...
MADjestic Posted February 1, 2008 Share Posted February 1, 2008 [fighting_mode = on]2. Several people here have asked about fuzzy logic... How it could fit into current Houdini pipeline? How AIOPs should work? Any ideas? How _Massive_ engine can be embed into Houdini? What about licensing? What about integration of code, libraries whatever? I believe in this case integrity of Houdini could be broken. 6. My favorite topic. Why do you care about third party renderers instead of Mantra? Why SESI should care about Mental Ray instead of improving their renderer? Should SESI write all necessary DSOs to provide support of all features of Houdini / Mantra in Mental Ray (like metaballs, point clouds etc.)? Or NVidia / Mental Images could do that? 10. Same as for 2. [fighting_mode=off] Agreed. SESI has done several significant steps developing Mantra already - rather than supporting all possible cool renders out there, it is Mantra that should be pushed even further. MRay is a good and respected renderer, no doubt. As well as many others. Should SESI spend resources on something that, say, 3DMax can do easily (support for dozens of 3d party renderers), or push up it own unique features? Why are you asking for turning Houdini into another Max or Maya? Those are great apps - why not sticking to them and stop this abomination? Fuzzy logics? Heh - python\Vex\HDK - it's all there already. Dig! P.S. sorry for all those emotions, that are so 'not odforce style'. It is the overall level of unadequate requests from some new users that makes me worried that SESI might actually follow the path that will move the power users away from H. Houdini has it's own unique features that we love this application for, the features that can and should be pushed further (take CHOPs alone - Maya\XSI and others are only starting to develope something close to that - and H had it for ages!) Read the H9 Wish List - the most crazy ideas were 'multi bounce' support and 'fluid solver' integration. Now we see all colorful circus with clowns jumping around! Please SESI - don't listen to our wishes. Don't spoil what you already have done! Keep the great work! Quote Link to comment Share on other sites More sharing options...
Marc Posted February 1, 2008 Share Posted February 1, 2008 Except that SESI has always been proud of their integration with MentalRay and Renderman. It's one of those things that if you're going to do it then you should do it properly. Most of the time SESI is pretty good with that, but if the consensus is that the MentalRay support is lacking then either fix it or remove the bullet point on your sales brochure. IMHO anyway. As for the other points, well Jason did ask for way out ideas... so you guys can hardly complain about them. And I like the massive-like idea, Houdini is well suited to that kind of workflow and I've always thought it would be fun to build a massive-like system in it. Obviously don't copy Massive exactly, but some sort of fuzzy logic system would be cool... M P.S. But not before the enhanced levelset collisions... Quote Link to comment Share on other sites More sharing options...
Vormav Posted February 1, 2008 Share Posted February 1, 2008 (edited) I might have gotten a little carried away with my list, but here goes... 1. Mental Ray Phenomenon VOP editor. Mental Ray is just short of completely useless in Houdini without this. 2. Python CHOP ops. I don't think it's really practical to use Python to write many types of nodes for performance reasons (especially pops, sops and cops; vex is just fine), but it seems to me that CHOPs are where Houdini would benefit the most from Python-based operators. 3. Upgrade to VS 2005 already! Please? 4. Allow custom GLSL shaders for all objects in the viewport. 4.5 To go with that, add the option to viewport cameras to do multipass renders, wherein one could use GLSL shaders to post-process the viewport. 5. Even better than #4: Dynamic FX shaders, akin to what Maya has through its Ashli Shader plugin. If you have to do gpu shader testing, that plugin is amazing. I mention 4-5 largely for the sake of pre-viz. A VOP context for creating gpu shaders (I've gotten the impression a couple of times that that has been in the works...) would be nice, too. 6. Ship with better materials, and more of them. 6.5 Even better, keep adding on to the HDAs available for shader creation in Vex Builder. Do-it-all SHOPs are nice, but they're completely locked down, and if you need to do something special (say, add a little bit of noise into one parameter), you're SOL. But when those shaders are instead packed up as HDAs that can be used inside of VOP surface networks, you have complete control over everything. Ideally, I'd like to see a variant of every single shader available at SHOPs level also be accessible in VOPs. Otherwise, honestly, I can't use most of those SHOPs for anything but previz (unless I'm doing a very simple, sterile scene). I like to, and often need to, customize the hell out of the input on most parameters. It seems like we've gotten a lot more nodes in VOPs in Houdini 9. More, please! I couldn't care less about SHOPs. 7. Integrated SVN tools for HDAs. 8a. LINE NUMBERS in the code viewer. 8b. SELECT ALL in the code viewer. 8c. Working drag-select in the code viewer. Basically, fix the code viewer! I don't need it for coding, but it is the most convenient tool for tracking down bugs when working in a VOP network. But right now, it's terribly insufficient for even that. 9. Tracking COP. 10. As danielpferreira suggested, persistent SOP data. Right now, in those few cases where I do need persistent data in SOPs, I use particles as a means of storing the data. It works, but it's by no means an efficient way of doing things: Particles come with a lot of extra baggage. 11. Some way of launching hbrowser separate from Houdini. I don't care if the .cmd links don't work; I just don't want to always have to have Houdini open to get at the docs. (I'm sure somebody will come in and show me that you can do this already, and I won't mind being shown how.) And a couple extras... 12. I don't know how feasible (if at all) this is, but as a potential workaround of #1, offer Generic VOP networks. This would be an addition to the HDK, wherein the behavior of a VOP context would be entirely configurable. I.E., let the developer decide what kind of data types are available in the context, what kind of interface is needed in a node, what happens when the node network cooks, and have the developer himself define what exactly the node network means. In that sense, maybe it isn't right of me to call it a VOP network. Instead, I just mean to expose custom operator contexts to the developer. Let Houdini manage events, the basic GUI, HDA management, and so forth, but leave the rest up to the HDK developer. That way, a capable and patient independent developer could create his own MR Phenomenon OP context, maybe an AI Context, or...? Houdini's node editing and HDA tools are excellent; it'd be amazing to be able to take advantage of that for other contexts that might not be a part of Houdini already. Just an idea. A bit out there, and I suppose one that not many people would jump on. But I'd sure like it... 13. Merge From Take (an answer to some poeples' calls for Animation Layers, which I've brought up in the past): Like the Object Merge SOP, except allow the user to be able to specifiy which take to merge the object from. In the past, I've found a lot of cases where this would be particularly useful: Say you're doing a crowd sim by copy-stamping a rig. In one take, you animate the rig walking, jogging in another take, and you animate a run cycle in yet another take. Then, when you copy stamp the rig, you stamp the take that the rig is being merged from. It might not be the most efficient setup, but it's pretty convenient. Yeah, of course you could create the duplicates of the rig for each cycle (going to suck if the rig needs to be changed), cache out geometry sequences (lots of diskspace, not to mention you have to re-bake every time there's a chang to the animation), or even cache out channel sequences to files...but none of that is really as quick and simple, imo. Just in general, there're a lot of cases where it would be very convenient to be able to merge from takes. Ideally, I'd want such a 'merge from take' node in SOPs, but an equivalent feature for CHOPs holds higher priority in my eyes. Edited February 1, 2008 by Vormav Quote Link to comment Share on other sites More sharing options...
graham Posted February 1, 2008 Share Posted February 1, 2008 I didn't want to reply, but Jason made me do it! In no particular order: Asset Difference tool Improved view port performance. Scriptable UI Better SDFs SDFs for Pops More multi-threading in all areas More HOM support, especially for assets and parameters Network tile connecting improvements: the DOT!!!! Ramps A Tangent sop Quote Link to comment Share on other sites More sharing options...
malexander Posted February 1, 2008 Share Posted February 1, 2008 3. Upgrade to VS 2005 already! Please? Houdini 9.1 has a build for VS 2005 (Win32 VC8), which was just recently added. Quote Link to comment Share on other sites More sharing options...
andrewlowell Posted February 1, 2008 Share Posted February 1, 2008 13. Merge From Take (an answer to some poeples' calls for Animation Layers, which I've brought up in the past): Like the Object Merge SOP, except allow the user to be able to specifiy which take to merge the object from. In the past, I've found a lot of cases where this would be particularly useful: Say you're doing a crowd sim by copy-stamping a rig. In one take, you animate the rig walking, jogging in another take, and you animate a run cycle in yet another take. Then, when you copy stamp the rig, you stamp the take that the rig is being merged from. It might not be the most efficient setup, but it's pretty convenient.Yeah, of course you could create the duplicates of the rig for each cycle (going to suck if the rig needs to be changed), cache out geometry sequences (lots of diskspace, not to mention you have to re-bake every time there's a chang to the animation), or even cache out channel sequences to files...but none of that is really as quick and simple, imo. Just in general, there're a lot of cases where it would be very convenient to be able to merge from takes. Ideally, I'd want such a 'merge from take' node in SOPs, but an equivalent feature for CHOPs holds higher priority in my eyes. Interesting Idea, yeah I've been doing the multiple rig thing, or the many animations on the same rig followed by the trim CHOP thing. Maybe instead of a completly new system the fetch CHOP could just have a list of takes to choose from. Like Takes [ animwalk, animrun, animjump ] then the channels would look like ... L_leg_tx_animwalk Quote Link to comment Share on other sites More sharing options...
Jason Posted February 1, 2008 Author Share Posted February 1, 2008 Another small one: I ask for this every year and every meeting I've had with SESI but please add the capability to the Trail SOP to using id's instead of point numbers. This allows the artist trail polygons off particles without the dying and birthing of new particles causing a dread mess of pick-up-sticks . I know it's possible to build one using the Foreach SOP probably but I'm talking about being effective on 30,000 particles here. Quote Link to comment Share on other sites More sharing options...
Vormav Posted February 1, 2008 Share Posted February 1, 2008 Houdini 9.1 has a build for VS 2005 (Win32 VC8), which was just recently added. Whoa. Hadn't even noticed that the new one was on VC8! Thanks. Quote Link to comment Share on other sites More sharing options...
edward Posted February 1, 2008 Share Posted February 1, 2008 - Persistent SOP Attributes > Will accumulate data. Won't be procedural, and will need to run from first frame to process properly, but could be incredibly useful in certain cases. Right now, you need to set up a particle system and accumulate into particles if you want that functionality. Just to clarify, this is because want to accumulate for each frame, as opposed to just doing a loop at the current frame (eg. ForEach SOP) ? Quote Link to comment Share on other sites More sharing options...
mtucker Posted February 1, 2008 Share Posted February 1, 2008 Hi Mark, thanks for the link. That's the method I remember you demonstrating in Santa Monica last yearand I think it perfectly hightlights the issue I was trying to address. This method only works to a pre-defined number of iterations and each step requires you to copy a set of DOP nodes already built earlier which gets pretty hard to implement if you need many levels of the same repeated behaviour. It works okay for three or four levels of splits but what if I want an object to procedurally shatter into thousands of pieces? What if I want the shatter to be different depending on where the object lands and the localized physical forces that may be acting on it at that time? I'd ideally like to be able to express the splitting in a single block of DOP nodes and have the splitting handled recursively (so it will work to any level of splits needed) with new DOP objects being 'spawned' when needed based on triggers. Is that something supported by DOPs now and, if not, how hard would it be to support it? John 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 Quote Link to comment Share on other sites More sharing options...
edward Posted February 1, 2008 Share Posted February 1, 2008 2 - Integrate the fuzzy logic engine from Massive Software, this would bring so much power to Houdini... why reinvent the wheel? is it possible? Also, better integration so we can import/export to Massive. Regardless of which "engine", how do you (and others mentioning this here) see fuzzy logic integrating into Houdini? By "fuzzy logic", do you mean full "fuzzy state machines" as in: http://www.fuzzysys.com/WebHelp/Fuzzy_State_Machines.htm where an "agent" can be an arbitrary number of states at any given moment in time? Just trying to wrap my head around what this means in Houdini. I suppose one way to do it is in POPs where we have float attribute of size 1 for each state. The value in each state attribute is the membership weight that the "agent" (ie. particle) belongs to. For example, say we have the attribute "happy" and "hungry". It's conceivable that the agent/particle is 0.5 happy and 0.5 hungry (and 1.0 happy when 0.0 hungry ). Then an "Agent" POP contains a list of transition rules where each rule specifies: Source State (string - name of state attribute), Target State (string - same deal), and Transition Weight (expression that evaluates to a float). So this POP takes each particle with the values of its state attributes, and applies to each one, the appropriate evaluated transition rule that gives it a new set of weights for each state attribute. The Transition Weight is just a float parameter that gets evaluated for each particle so we can have $ID, $PT, etc. be available to specifying transition weights. Just thinking along these lines then, the issues surrounding this approach: - Specifying transition rules -- Although a simple 3 tuple of parameters can describe a transition, it's awfully unwieldy. You would pretty much need to draw out your state machine on paper and keep referring to it. Of course one might argue for a new VOP-like context where one places down nodes as states, connects them, and allows one to add expressions to each line connecting the nodes. On the other hand, it's much easier to just implement a multi-parm POP as just described possibly just using existing functionality (or have a way of reading in a script file like the LSystem SOP). - Expressions for transition weights -- Even though this is fairly general, I'm not sure what ways would be useful for driving these expressions. Likely, CHOPs can be involved here, as well as Python/Hscript expressions. The Proximity POP could help to generate information to drive these expressions. I guess additional systems could be built in POPs/SOPs to generate information as well. - Debugging -- It might suck to debug fuzzy state machines. To figure out why a particle is misbehaving, I imagine you would need to scroll through the entire list of attributes of the misbehaving particle at the bad frame(s) to figure out the bad states. Then step through each frame to figure out how the particle arrived at the bad states. Now look at all the applicable transition rules to figure out which rules caused the particle to arrive at the bad states. Ok, so you fix the transition rules. Oh wait, but this affects like a million particles. Ok, re-run the whole simulation again <insert favourite addiction break here>. I think that regular finite state machine here would be much easier to debug. - Output -- Here, we're not too bad. You can do POP things to these particles based on the attribute values (like kill, color, etc), or take out into SOP land to do more. We can use these attributes to blend animation, instance different characters, etc. - Multiple fuzzy state machines (or "brains") -- Naturally, this POP will also have Group and Activation parameters, so that you can have different particles use different transition rules and state attributes. The drawback to this is that since an attribute must have a value for all particles, it will necessarily waste memory (lots of states will have 0 values). There are ways around this sparse structure though such as packing each "state machine" into a single index pair attribute like capture weights. However, this makes it rather unwieldy manipulate this data for doing other things. - Speed -- It seems that for each particle, all transition rules that have a state attribute of value > 0 will need to evaluated. This can be slow. Certainly slower that if we took a regular finite state machine approach. Or am I way overthinking this? Quote Link to comment Share on other sites More sharing options...
andrewlowell Posted February 1, 2008 Share Posted February 1, 2008 (edited) Then an "Agent" POP contains a list of transition rules where each rule specifies: Source State (string - name of state attribute), Target State (string - same deal), and Transition Weight (expression that evaluates to a float). So this POP takes each particle with the values of its state attributes, and applies to each one, the appropriate evaluated transition rule that gives it a new set of weights for each state attribute. The Transition Weight is just a float parameter that gets evaluated for each particle so we can have $ID, $PT, etc. be available to specifying transition weights. Just thinking along these lines then, the issues surrounding this approach: - Specifying transition rules -- Although a simple 3 tuple of parameters can describe a transition, it's awfully unwieldy. You would pretty much need to draw out your state machine on paper and keep referring to it. Of course one might argue for a new VOP-like context where one places down nodes as states, connects them, and allows one to add expressions to each line connecting the nodes. On the other hand, it's much easier to just implement a multi-parm POP as just described possibly just using existing functionality (or have a way of reading in a script file like the LSystem SOP). - Expressions for transition weights -- Even though this is fairly general, I'm not sure what ways would be useful for driving these expressions. Likely, CHOPs can be involved here, as well as Python/Hscript expressions. The Proximity POP could help to generate information to drive these expressions. I guess additional systems could be built in POPs/SOPs to generate information as well. Yeah I think a few clever new pops like that would be awesome! Something like "sample-attributes" or sample layers similar to deep-raster images on CHOPs samples might also help with the logic stuff but that would radically change the way CHOPs would work, if so I'd want it to be done very efficiently, correctly. Edited February 1, 2008 by andrewlowell Quote Link to comment Share on other sites More sharing options...
Marc Posted February 1, 2008 Share Posted February 1, 2008 Something which would go a long way toward doing decent crowds in Houdini (prior to any fuzziness need be added) is some decent 'vision' style controls for the particles. The interact pop is a sledgehammer where a lot of times a scalpel is needed. Building decent avoidance systems is probably the most elementary problem of any crowd system, and right now it's extremely difficult to do that with out of the box pops. So for starters (I guess), I would throw my vote into a minor overhaul of pops and make it far more efficient at large #'s of particles and add in some vision pops that are more refined than what we have now. Quote Link to comment Share on other sites More sharing options...
fox541 Posted February 1, 2008 Share Posted February 1, 2008 add one indispensible: better help file,pdf is more convenient for print Quote Link to comment Share on other sites More sharing options...
symek Posted February 1, 2008 Share Posted February 1, 2008 (edited) 10. As danielpferreira suggested, persistent SOP data. Right now, in those few cases where I do need persistent data in SOPs, I use particles as a means of storing the data. It works, but it's by no means an efficient way of doing things: Particles come with a lot of extra baggage. Can't you use just CHOPs for that guys? query, process, save or export any data from SOPs per frame... I heardy see any limitation of that. I was using Python for a time to cache in session module some SOP's state but in most cases CHOPs are enough and already there! Edited February 1, 2008 by SYmek Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.