LaidlawFX Posted August 20, 2013 Author Share Posted August 20, 2013 How about something like Intels tbb flowgraph for parallel graph evaluation for houdini networks? Task-based parallelism in general seems to be very suitable for houdini. http://www.youtube.com/watch?v=p_MVkbaIeq8 Just watched that video, are you talking about under the hood with better multi-threading design? or at the network pane level? Quote Link to comment Share on other sites More sharing options...
yongbin Posted August 20, 2013 Share Posted August 20, 2013 I've tested it. But it didn't work. It only works at render time. Quote Link to comment Share on other sites More sharing options...
0rr Posted August 20, 2013 Share Posted August 20, 2013 (edited) Just watched that video, are you talking about under the hood with better multi-threading design? or at the network pane level? As I am neither an expert on parallel programming nor have I worked extensively with the hdk I am not sure what the best way to approach this would be. In case of under the hood changes implementing every node and every expression as a flowgraph node would give somekind of automatic parallelisation of houdini networks. Even if other nodes ( for example the particlefuildsurface-node ) were themself using parallelism ( spawning tasks ) this would not result in oversubscribtion as long as everything is based on tasks. That is the task-scheduler would handel the final assigment of the task to actual threads and a work-stealing algorithm would ensure that the load is balanced among all cores. My guess is that it would not scale well because of all the dependencies in a regular houdini network. But maybe we should be given the possibility to use common parallel patterns inside of houdini. The Fork-Join or Map pattern would be a star. Edited August 20, 2013 by 0rr Quote Link to comment Share on other sites More sharing options...
Macha Posted August 20, 2013 Share Posted August 20, 2013 (edited) Just fix the freaking OpenGL viewport for 13. I'm going nuts with it. Edited August 20, 2013 by Macha 3 Quote Link to comment Share on other sites More sharing options...
Guest tar Posted August 21, 2013 Share Posted August 21, 2013 (edited) Just fix the freaking OpenGL viewport for 13. I'm going nuts with it. Can you please elaborate about the bug/problems with the viewport? A bug has just been filed about sticking viewports and I'm interested in other problems with the viewport. Please see this thread. Thanks. Edited August 21, 2013 by tar Quote Link to comment Share on other sites More sharing options...
Macha Posted August 21, 2013 Share Posted August 21, 2013 (edited) Different people, different places, different bugs. It's very hard to nail down exactly what is wrong with the viewport, wrap it up and file a meaningful bug. I guess a lot of artists just shrug their shoulders, grumble and find a ridiculous workaround. At the moment I have a lot of performance problems where the viewport can't handle more than a few thousand polys. Everything grinds to a halt. Restarting Houdini helps but is not a good solution. Switching from opengl versions also helps but just for a short while. It's almost as if 'something' fills up the graphics card and then doesn't let go. In any case, viewport issues are the single most frustrating problem in H right now. Again and again I come across people cursing Houdini's viewport. Something isn't working, somewhere deep down burried in code and drivers. Whatever it is, I hope H13 will be better. Can you please elaborate about the bug/problems with the viewport? A bug has just been filed about sticking viewports and I'm interested in other problems with the viewport. Please see this thread. http://forums.odforc...ot-supposed-to/ Thanks. Edited August 21, 2013 by Macha 2 Quote Link to comment Share on other sites More sharing options...
Guest tar Posted August 21, 2013 Share Posted August 21, 2013 Different people, different places, different bugs. It's very hard to nail down exactly what is wrong with the viewport, wrap it up and file a meaningful bug. I guess a lot of artists just shrug their shoulders, grumble and find a ridiculous workaround. At the moment I have a lot of performance problems where the viewport can't handle more than a few thousand polys. Everything grinds to a halt. Restarting Houdini helps but is not a good solution. Switching from opengl versions also helps but just for a short while. It's almost as if 'something' fills up the graphics card and then doesn't let go. In any case, viewport issues are the single most frustrating problem in H right now. Again and again I come across people cursing Houdini's viewport. Something isn't working, somewhere deep down burried in code and drivers. Whatever it is, I hope H13 will be better. Cool, thanks. I'm quite keen to tease out these bugs - it went very well for the sticky viewport- in only 3 days we had reproducible steps and the bug was submitted. If you start a new thread we can run through the sceanories and I'm quite sure can reproduce it. Others can then also contribute. Cheers Quote Link to comment Share on other sites More sharing options...
sanostol Posted August 21, 2013 Share Posted August 21, 2013 motion blur enhancements rotational motion blur for instances control over the blend of the motion blur (falloffs) more accurate motion blur on particles, more like the deformation blur, but using the id flying sparks look default more like tangents (not that nice) Martin Quote Link to comment Share on other sites More sharing options...
LaidlawFX Posted August 22, 2013 Author Share Posted August 22, 2013 motion blur enhancements rotational motion blur for instances control over the blend of the motion blur (falloffs) more accurate motion blur on particles, more like the deformation blur, but using the id flying sparks look default more like tangents (not that nice) Martin For rotational motion blur with particles, do you have continuous motion on sub frames, like $FF? with geometry velocity blur checked on? timeblend with ids is good for this. Albeit it would be cool somehow if in the viewport for a new attribute display type somewhat like a vector with and additional time control to show curves from sub-samples of a frame as opposed to just a vector from the current frame to visualize this better. This would have to require some additional option in the viewport display options, and some type of warning because it would require additional cooking for those subframes. Doing it by hand with a trail sop would be the nearest equivalent. The helicopter blade test would be a good example of this, if you could visualize with curved vectors in the viewport as opposed to straight lines of that frame instance. Quote Link to comment Share on other sites More sharing options...
sanostol Posted August 22, 2013 Share Posted August 22, 2013 (edited) I have instances on particles, particle count is changing and geometry motion blur just uses v to blur, so there is no curved motionblur rotational motionblur on particles also does not work, or do You know an attribute for rotational velocity? For rotational motion blur with particles, do you have continuous motion on sub frames, like $FF? with geometry velocity blur checked on? timeblend with ids is good for this. Albeit it would be cool somehow if in the viewport for a new attribute display type somewhat like a vector with and additional time control to show curves from sub-samples of a frame as opposed to just a vector from the current frame to visualize this better. This would have to require some additional option in the viewport display options, and some type of warning because it would require additional cooking for those subframes. Doing it by hand with a trail sop would be the nearest equivalent. The helicopter blade test would be a good example of this, if you could visualize with curved vectors in the viewport as opposed to straight lines of that frame instance. EDIT: Fast Instancing broke it, with full pointinstancing everything works as expected Edited August 23, 2013 by sanostol Quote Link to comment Share on other sites More sharing options...
LaidlawFX Posted August 22, 2013 Author Share Posted August 22, 2013 I have instances on particles, particle count is changing and geometry motion blur just uses v to blur, so there is no curved motionblur rotational motionblur on particles also does not work, or do You know an attribute for rotational velocity? If you do a separate thread with an example. I believe there's an answer for that, but depends on the test case what is throwing you the curve.... Unfortunately it should be more straight forward. The motion blur settings for mantra should def get a secondary outside look at simplifying them. Esp in the rop. The geometry velocity blur check boxes on the geometry should be done away with in favor of rop control it's more user friendly. Maybe more demo example files like the helicopter rotor blade example with the st elmo's fire like effect int he help docs. http://www.npr.org/blogs/krulwich/2013/07/30/206946740/mysterious-dancing-lights-in-afghanistan Quote Link to comment Share on other sites More sharing options...
LaidlawFX Posted August 22, 2013 Author Share Posted August 22, 2013 (edited) Write directly to vrmesh and ass files(plus reading realflow .bins, they're plugins SUCK!!!). We can write to ribs and other formats, it be cool if these render engines got native handling, too. Exporting abc are nice, but since they don't use velocity motion blur a lot of sub samples become an issue, plus .abc are not multiple files but one file that can have write and load issues normally associated with massive files. Not asking for full vray and arnold support in rops yet, but writing out to the equivalent delayed load so we don't have to use maya, xsi, etc. as an intermediate platform, and the lighter on staff can use what ever package they specialize in. Edited August 22, 2013 by LaidlawFX Quote Link to comment Share on other sites More sharing options...
loudsubs Posted August 29, 2013 Share Posted August 29, 2013 Multi-thread the point replicate procedural please Quote Link to comment Share on other sites More sharing options...
goldleaf Posted August 29, 2013 Share Posted August 29, 2013 Some multi-threading good notes (including from Jeff Lait re: Houdini) from SIGGRAPH: http://forums.odforce.net/index.php?/topic/12632-random-link-of-interest/#entry110748 As I am neither an expert on parallel programming nor have I worked extensively with the hdk I am not sure what the best way to approach this would be. In case of under the hood changes implementing every node and every expression as a flowgraph node would give somekind of automatic parallelisation of houdini networks. Even if other nodes ( for example the particlefuildsurface-node ) were themself using parallelism ( spawning tasks ) this would not result in oversubscribtion as long as everything is based on tasks. That is the task-scheduler would handel the final assigment of the task to actual threads and a work-stealing algorithm would ensure that the load is balanced among all cores. My guess is that it would not scale well because of all the dependencies in a regular houdini network. But maybe we should be given the possibility to use common parallel patterns inside of houdini. The Fork-Join or Map pattern would be a star. Quote Link to comment Share on other sites More sharing options...
holycause Posted August 31, 2013 Share Posted August 31, 2013 If rewrite a foreach node for maximum performance it will be amazing! Because it's really important node. And why not to do a spline or bezier interpolation in ramps?! +1 Quote Link to comment Share on other sites More sharing options...
jkunz07 Posted August 31, 2013 Share Posted August 31, 2013 (edited) Speed up VDB rendering in mantra. Edited August 31, 2013 by jkunz07 Quote Link to comment Share on other sites More sharing options...
magneto Posted September 1, 2013 Share Posted September 1, 2013 Someone needs to make a consolidated version of this along with the one on the SESI forum. So many good ones are buried within the pages 1 Quote Link to comment Share on other sites More sharing options...
mawi Posted September 1, 2013 Share Posted September 1, 2013 Speed up VDB rendering in mantra. Are they slower then houdini volumes or is it just that we tend to use lower div size with vdbs? Quote Link to comment Share on other sites More sharing options...
jkunz07 Posted September 1, 2013 Share Posted September 1, 2013 (edited) Are they slower then houdini volumes or is it just that we tend to use lower div size with vdbs? Definitely much slower, I'm not sure if it applies to all scenarios but I'll post some tests soon. I noticed this recently I was rendering a pyro sim which a cached to disk as vdb's - when I tried to render this some buckets that were completely black were still taking forever to render. Converting back to houdini volumes sped up the render 5-10 times. EDIT: Attached a file where the issue is prominent VDB_vs_Houdini_Volume_Render_Speed.hip Edited September 1, 2013 by jkunz07 Quote Link to comment Share on other sites More sharing options...
Sankar Kumar Posted September 4, 2013 Share Posted September 4, 2013 Weather Houdini engine will be available with Houdini Apprentice licence...? 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.