Jump to content


  • Posts

  • Joined

  • Last visited

About anakin78z

  • Birthday 05/25/1978

Contact Methods

  • Website URL

Personal Information

  • Location
    Los Angeles
  • Interests
    umm... Houdini!!!! That, and Yosemite National Park.

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

anakin78z's Achievements


Newbie (1/14)



  1. Hey, So I didn't quite understand from your posts... did you end up converting the spheres to cloth objects, or did you get it to work as rbds? Thanks, -z
  2. Sure thing. I don't remember the exact workflow I used then, but this is the gist of it: You can compute curvature using the measure sop. In the ray sop, turn off Transform Points and turn on Point Intersection Distance. Then, in a vop sop, if you multiply the distance value by the normal, you'll get the displacement. Remap the curvature value to something useful, then use that to scale your displacement, so that areas that have more curvature don't get displaced as much. The result is that flat areas should get a lot of displacement (or as much as they need anyway), while curved areas, such as the edges, don't get displaced as much. Also, you'll probably want to give it a limit of how much it gets displaced, to avoid any weird behavior. Good luck, -z
  3. But... that also doesn't work? Unless I'm missing something, even when using instancing, you don't get rotational blur... in fact, I'm not convinced that multiple time samples work with velocity motion blur at all. Now, if you don't have changing point counts, you can set Point Motion Blur to Compute sub-frame geometry (deformation), which WILL work, but we've already established that we have changing point counts.... -z
  4. exactly... Now if someone were to implement angular velocity blur... o:-)
  5. Hey Mike, I worked on this commercial a little while ago, and we had to tackle some of the same problems: http://adsoftheworld.com/media/tv/lg_vase Most of the fluids were created in realflow, but some of them in houdini using particle fluids. The techniques were fairly similar though. The fluids tend to blob up, so to get thin sheets we usually ran an emitter against a bowl or similar surface to get a flat fluid splashing out of it. The edges then tended to get really stringy too, which actually often became a bit of an issue, especially with houdini's fluids. We tried various things to 'direct' the fluid... in houdini I tried setting up pop solvers to get the fluid to follow along paths, to use attractors, etc, but that would only work for a short time before things get really blobby. It works for short shots though . One thing that ended up helping to get thin sheets of fluid is post processing the surface in houdini. I think I rayed the surface backwards against itself, then filtered that based on curvature, so flat areas got flattened more than bumpy areas, or the edges of the sheets, which created some really nice looking surfaces, and gave us better sheets than we were able to get by directing the fluids alone. Anyhoo, hope this helps . -z
  6. Keep in mind that velocity blur will never give you 'proper' blur anyhow, since it's always the velocity from the previous frame to the current, while all other blur in houdini (by default anyway, now you can change it) blurs from the current frame towards the next. Most of the time you won't notice, but since you asked.... Someone at some facility wrote a node that calculated velocity based on the ID attribute, rather than point number, so changing point counts didn't matter. Also, it looked at the next frame, rather than the previous to compute proper velocities. Maybe this is something Sesi could implement at some point. Another caveat is rotations however, which don't get blurred. If you have a fast spinning object on a particle and use velocity motion blur, you're only going to get blur from the translation, not the rotation. Just keep that in mind.
  7. Well, in my head it looks like this: You have an RBD object which falls and collides with a fluid. Check the rbd object for impact info. As soon as you detect an impact, The RBD becomes a source for your oil fluid, then gets deleted. This should fill the space where the rbd object was with fluid, which would then fall into the water/do it's thing. Sounds right in my head... might work in houdini? You could probably take a look at some of the example hipfiles where the slug turns into gas to see how that's set up.
  8. You can get the current path from the viewport using the toolutils module: import toolutils view = toolutils.sceneViewer() curpath = view.pwd() curpath is now a node object for whatever's displaying in the viewport. You can then check to see if it's a geometry node: if curpath.childTypeCategory() == hou.sopNodeTypeCategory(): print 'yay' At least I'm pretty sure that'll work. -z
  9. One thing that's always bugged me about takes is that you can't easily copy them from one hip file to another. I'll often be using takes on objects, then copy those to another hipfile and 20 minutes later I realize that all of my takes are missing. If there were some sort of relationship between objects and takes that would stick with the object, I'd be a happy camper. Actually, this is true for copy pasting within the same file as well. -z P.S. Actually, I haven't used takes in quite a while, so feel free to correct me if this actually works now.
  10. If you're only doing lists, have you checked out hou.ui.selectFromList? It fills most of my list needs. If not: I found gtk to be a lot easier to implement than qt. Here's an example scrpt. A lot of the comments are stripped from an example on pygtk I found online... I don't remember who the author was, but credit goes out to him... he might've just been the python docs though. The script pops up a text input window, then creates an object and font sop displaying the entered text. (This was implemented as a shelf tool). # example helloworld.py import hou #import pygtk_helper import threading global text text = 'poop' def RunHelloWorld(): import pygtk pygtk.require('2.0') import gtk class HelloWorld(threading.Thread): # This is a callback function. The data arguments are ignored # in this example. More on callbacks below. def hello(self, widget, data=None): self.text = self.entry.get_text() #This is where I currently run the houdini code. It's triggered when #the button is pressed and run before the gtk window closes. geo = hou.node('/obj').createNode('geo','Input_Font',run_init_scripts=False) font = geo.createNode('font','resulting_text') font.parm('text').set(self.text) font.setDisplayFlag(True) def delete_event(self, widget, event, data=None): # If you return FALSE in the "delete_event" signal handler, # GTK will emit the "destroy" signal. Returning TRUE means # you don't want the window to be destroyed. # This is useful for popping up 'are you sure you want to quit?' # type dialogs. print "delete event occurred" # Change FALSE to TRUE and the main window will not be destroyed # with a "delete_event". return False def destroy(self, widget, data=None): #print "destroy signal occurred" gtk.main_quit() def __init__(self): super(HelloWorld,self).__init__() #self.init_app() # create a new window self.window = gtk.Window(gtk.WINDOW_TOPLEVEL) # When the window is given the "delete_event" signal (this is given # by the window manager, usually by the "close" option, or on the # titlebar), we ask it to call the delete_event () function # as defined above. The data passed to the callback # function is NULL and is ignored in the callback function. self.window.connect("delete_event", self.delete_event) # Here we connect the "destroy" event to a signal handler. # This event occurs when we call gtk_widget_destroy() on the window, # or if we return FALSE in the "delete_event" callback. self.window.connect("destroy", self.destroy) # Sets the border width of the window. self.window.set_border_width(10) self.vbox = gtk.VBox(False,0) self.window.add(self.vbox) self.vbox.show() self.entry = gtk.Entry() self.entry.set_max_length(0) self.entry.set_text("Enter Text Here") self.vbox.pack_start(self.entry,True,True,0) self.entry.show() # Creates a new button with the label "Hello World". self.button = gtk.Button("Print Text") # When the button receives the "clicked" signal, it will call the # function hello() passing it None as its argument. The hello() # function is defined above. self.button.connect("clicked", self.hello, None) # This will cause the window to be destroyed by calling # gtk_widget_destroy(window) when "clicked". Again, the destroy # signal could come from here, or the window manager. self.button.connect_object("clicked", gtk.Widget.destroy, self.window) # This packs the button into the window (a GTK container). self.vbox.pack_start(self.button,True,True,0) # The final step is to display this newly created widget. self.button.show() # and the window self.window.show() def run(self): # All PyGTK applications must have a gtk.main(). Control ends here # and waits for an event to occur (like a key press or mouse event). gtk.main() hello = HelloWorld() hello.start() # RunHelloWorld()
  11. Hey there, I'm having an issue with fire simulations where I regularly get flame fronts (the blue stuff) which inflate, grow, end up taking over everything. This usually happens more when I decrease the Goal Flame Speed parameter in the Gas DSD Solver. In one case I managed to get that to go away by setting Curvature Forcing to 0, but that doesn't seem to have any effect in another scene, so for all I know that was a fluke. Anybody know how to avoid this? Thanks -z
  12. Not sure if this is the best way to do it, but what I would do is write your scrips as a function which you then import into houdini, or add to the session module. For example, if I add this to the session module: def poke(): hou.ui.displayMessage(hou.node(".").name()) I can then put this into the Pre-Render Script: hou.session.poke() and it will show the name of the render node before starting the render. The way we do it over here is to have all our common functions like that in a separate file which we then import in the 456.cmd (or py), using simply import ourmodule (or in the case of 456.cmd: python -c "import ourmodule" ) Then, in houdini, you can access any of your functions using ourmodule.functionname(). Cheers, -z
  13. hehe... hehe... heh... Anyhoo, turning up the Vortex Confinement to like 10 will give you a lot more nice swirling, and will get you close to what you want. However, the gas will continue to expand outwards and will eventually hit the edges. If you never want them to go that way, or if you want them to collect back towards the source, you'll probably have to add some additional forces.
  14. One thing I've gotten into the habit of doing is to move all the fractured objects to 0 and creating points in their original position. Then, in dops, move them back in the rbd fracture dop by setting their position based on the point position of the reference points. I set it up using the foreach sop which moves each group based on it's centroid and adds a point based on the original center.
  15. Yup, I think I know exactly what this is (after having run into it myself on many occasions). In the Pop solver, turn off Handle Collisions under the Collisions tab. That should do the trick.
  • Create New...