Jump to content

mrWolf

Members
  • Content count

    95
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by mrWolf

  1. Smoke Solver | Tips and Tricks

    Thank you man , I'm glad somebody actually reads that gibberish !! The more I play with your setup , the more I like it. I tried to duplicate the sphere source and move it like 1000 units away...and yes, the sim gets a bit slower, but being used to see how slow non-sparse volume grid based sims can get, it's quite an amazing feeling. Plus one thing I love about this setup is that it's incredibly simple. I've to create a dust trail setup, mmm I think I'm going to give this technique a try. *OpenVDB creators, please please please make a OpenCL version of VDB advect and VDB project non divergent nodes*
  2. Smoke Solver | Tips and Tricks

    Thank you for sharing this setup ! Yeah it feels like the DOP's smoke is faster when it comes to single emitter like in your example, but if you have multiple emitters distributed in space, I bet this setup wins in terms of speed and memory footprint. I really hope they'll make VDB project non divergent faster , possibly GPU based ... see Eddy for Nuke for instance ( sparse grid + GPU = love )
  3. hey Horizon, no, I didn't use any sss. I worked in comp to achieve a satisfactory result. Something that really helps with smoke is finding the right density value. High density can give you great details, reduces render times (cause the ray tracer has to travel less samples before accumulating the full opacity), shadows really dark, smoke very thick and dirty and not a lot of transparency (like in your render). I would recommend playing with density values in the volume procedural shader and in the material shader too. On top of that, play with the ramp associated with the material shader, that changes a lot the look of the smoke too. I hope this helps.
  4. hi Horizon ! The hip files included are supposed to present a technique more than matching a specific look and they are a simplified version of the setup I created to achieve those effects in production. The purpose of the presentation was to inspire and trigger the desire to learn more. It's up to you to tweak parameters , use bits and pieces in your setup or maybe re-create the setup from scratch to understand the details and maybe come up with your own flavor. If you've a specific question about technical details in the setup please let me know and I'll definitely try to help.
  5. hey Ben ! the presentation was recorded by Framestore. It is being edited in these days and hopefully it'll be ready soon. I'll get you in touch with who's dealing with this so you'll be the first person to know.
  6. Hey Peter, it was just a bash script containing one mplay command reading more than one sequence, and with -V option to create specific row / column layout so I could visualize more than one file sequence per time. Example: mplay -V 2 2 -g flipbooks/03_tenPoints/* flipbooks/04_thousandPoints/* flipbooks/05_millionPoints/* .. this line will open mplay with a 2x2 row-column layout (in total 4, but since I'm specifying only 3 image sequences, the 4th spot in the lower right corner will be ignored) and 3 file sequences. The -g option " ... groups the command line images into separate sequences, based on base name and extension". An option that I use a lot is the option -C. This will pre-cache all the files before opening the actual player view, so that when the viewer finally shows up, the play is in real time. I didn't use this one during the presentation cause I thought it's less boring to watch the frames pre-caching opposed to a progress bar slowly reaching 100% The reason cause I was using the syntax "bash ... script.sh" was because I was storing the presentation on an FAT formatted HD, which doesn't allow to chmod +x to flag the script as executable, so I had to run a bash shell and the script as a parameter. p.s. mplay is awesome , pity it doesn't play videos
  7. Thank you ! Here it is the zip file including PDF and all the hip files with the ink setup and tornado setup. The scene files have been created with Houdini 15.5.632. Enjoy ! Hug_Nov2016-AlessandroPepe.zip
  8. Peter thank you for posting this ! I really enjoyed talking with you all yesterday , the vibe was really good and despite the length of the presentation (2.5 hrs ! luckily we had beer :D) I got really good feedback. I was totally not expecting such a response and I'm happy there is such an alive, vibrant and apparently growing Houdini community in L.A. Thank you all for attending ! @Eetu : totally ! I'll get the pdf and hip files ready in a nice zip file and post it tonight in this thread.
  9. hey j00ey, is it possible that you defined $mp as a float ? If so, that might be the issue. Try to define $mp as an int. p.s. did I just reply a 2 yo post ? lol
  10. Is there any sop node to convert an open polyline into *one* NURBS curve ? This is the poly object I am starting from : Each segment, forming the polyline, is an open polyline that connects two points. There are no overlapping points. The topology is very clean and it contains all the info required to rebuild a NURBS but I cannot find any SOP node that achieves this. I tried "Convert" sop , forcing the conversion to NURBS curve, but of course it creates a ton of tiny NURBS curves , each one matching the original segment. I am sure I am missing something very obvious
  11. convert connected segments into a nurbs

    Works flawlessly. Thank you Tomas !
  12. I have a RBD sim, with 1 packed object which contains 9 elements. I am trying to disable the gravity only on certain elements, within the packed object. In order to achieve this, I would like to control the gravity node with a dop group. I created a point attribute "falling" which I control in a sop solver, within the dop network. Then I created a DOP Group that creates a group based on the following expression: point($DOPNET+":"+$OBJID+"/Geometry",$OBJ,"falling",0) Now, this seems to work but ...not quite. I see elements that start fluctuating at a certain moment, but this moment doesn't match the moment when the "falling" attribute is triggered to 0. To start, I'd like to understand if I am using the above expression correctly. I am quite confused with the global variables $OBJID , $OBJ used with Packed Objects. Could anyone shed some light on this? I am on H13.0.547
  13. DOP groups for rbd Packed Objects

    hi Pradeep, thank you for the example hip file, very much appreciated. Your explanation makes sense and it works great ! I was trying to stay in the rbd land and use the old style way to drive rbd objects. But I guess with rbd packed primitives , since we deal with points and transformation matrices opposed to real geometry, we are suddenly in a pop world instead ! I've read often here and there that it's possible to access the real geometry of a rbd packed primitive in a sop solver (meaning, unpack ... use and re-pack), but I wasn't able to accomplish this. Meaning that when I re-pack the element it's not the same as the one I unpacked (primintrinsic are lost when unpacking), so the sim breaks. Is there a proper way to actually extract the packed data , within DOP, use it, and repack it seamlessly ?
  14. I'm using a small python script to open a hip file, "do something" , save, and press the button "render" on the proprietary node that sends the job on the farm. Of course this all happens without ui, so my script errors out cause somewhere there is some python code that uses hou.ui.setStatusMessage, and I guess hbatch doesn't load the ui module. This is the error I get: hou.ui.setStatusMessage( "Creating the render data", hou.severityType.Message) AttributeError: 'module' object has no attribute 'ui' This the script: import hou hou.hipFile.load("myfile.hip",True) <change parameters and do interesting stuff> print ("submitting job on the farm\n") farmrender=hou.node("/out/farm_render") farmrender.parm("FarmRender").pressButton() print ("done\n") hou.exit() and this is the error message ... hou.ui.setStatusMessage( "Creating the render data", hou.severityType.Message) AttributeError: 'module' object has no attribute 'ui' I already tried to execute the actual code contained in the button, but I get the same exact error. Is there any way to suppress any call to hou.ui when a script is executed via hbatch ?
  15. hbatch executing python script and ui error

    Graham, it works great. Thank you a lot man
  16. hbatch executing python script and ui error

    ehi Graham ! this seems very interesting ! I am not the most expert python coder out there at all, I am trying to figure out the syntax for this to work but I am struggling a bit with the syntax I tried this code: import hou def setStatusMessage(message, severity=hou.severityType.Message): print (message) hou.ui.setStatusMessage=setStatusMessage But I get this message: hbatch Version 13.0.447 (Compiled on 06/17/14) Traceback (most recent call last): File "actor001.py", line 18, in <module> hou.ui.setStatusMessage=setStatusMessage AttributeError: 'module' object has no attribute 'ui' Can you give me a hint on what I am doing wrong ?
  17. hbatch executing python script and ui error

    thank you for your reply Graham, unfortunately I cannot access the content of whatever script executes the call to hou.ui cause it's a pipeline script. I was wondering if there is any way to catch any call to ui, and ignore it. I tried with a try: except: structure but it doesn't work.
  18. hi all volume procedural lovers, I have a volume procedural shader that generates clouds from points. I was thinking to use this to create a large cloud distribution at render time (I've a 'twin' variant of the same shader that creates the same volume in sop using bounding boxes to inspect specific areas of the distribution, so I can preview the result quickly). I realized that when the point distribution I use as an input becomes very large, in my renders I loose all the details. I tried to crank up the parameter "octree division" up to values that make the pre-processing stage immensely long, and still I am very far from the details I have if I use a way way smaller point distribution. My question is: since the volume procedural shader is able to render "gridless" volumes, this should allow rendering pretty much infinite volume distribution. Or ... to be more precise, this is what I (naively) thought ! Is there something crucial I am missing in my setup, or the only solution is split my data to countless small partitions, and pretty much nullify the advantage of the gridless volume render ?
  19. I made a quick test at home and it seems to work ! If I couple this with Octree Dubdivision ~128 it renders relatively fast too. I'll try it tomorrow at the office. Thank you a lot for this suggestion Kunz !
  20. I am using a vex volume procedural shader, connected to a new cvex operator to generate a volume starting from points at render time. In the cvex op, I use pcopen to open a point cloud, then I process those points and export "density" and "Cd". Everything works great (even if the render time is insane ..). Now I'd like to export additional image planes. For instance I added an "export float nage ..." (normalized age of the points) and added a new float image plane to the Mantra rop, but the render of that image plane always comes out black. I tried to set nage = 1 by default to make sure it really doesn't work. My questions are: 1 - I noticed that I can successfully export "density" and "Cd" from the cvex operator to the vex volume procedural. Are there additional Mantra parameters vex volume procedural accepts from the cvex op ? 2 - what is the proper way to render new image planes using the previous setup ? For instance exporting Ce connected to a remapped density to simulate heat. Please let me know if the question is not clear enough and I'll setup a small hip file to illustrate the issue.
  21. Thank you for your reply Fathom, I'd like to stay away from the low res proxy object since all the geometry (volume) is generated at render time by the volume procedural. The new h13 point cloud light shader solution that you mention is very interesting ! I've never written a light shader. Can you point me to the h13 new point cloud shader function or any light shader example ? I've searched a bit in the help and I couldn't find any example.
  22. Amazing ! It works great, thank you for the clarification Fathom ! Now I understand why exporting Ce was not just lighting my smoke ! I didn't have any surface shader assigned to the geometry. I only had a geometry shader. I created a Mantra shader builder, dropped a Volume Model and connected density to density, Cd to Smoke Clr and Emit Clr. In the cvex shader I calculated and exported nage using the particle age. I created a nage parameter in the surface shader as well (set it to export) and used it to modulate the density and fed the result into Emit Int, plus I exported it as a separate image plane. I rendered a simple test to show you the result. In you opinion what is the most effective way to use the bright core of the smoke to illuminate the surrounding environment ? In this example i'm using the following parameters: - pbr render - one directional light - clay shader assigned to the ground - volume geometry procedural + surface shader to generate the smoke starting from a point cloud.
  23. pop emission issue

    I created a very simple pop sim, where I emit particles from a previously cached particle sim. I notice that the amount of particles emitted gets less and less in time. I couldn't find any possible explanation for this. The only workaround I found is to key the Impulse Count so that it increases a lot with time, but I'd love to understand the reason why this is happening. Has anyone experienced anything like this or maybe there is a known bug in this version of Houdini ? I am using H13.0.476. hip file attached. pop_emission_issue.hip
  24. pop emission issue

    Hi Loopyllama ! it makes perfect sense, every ~1 month I tend to forget how particles are emitted in Houdini ! Thank you a lot for the explanation, it works great now!
  25. Is there any way to hack to forEach sop in order NOT to collect (or reuse) the resulting geometry after each loop, and just iterating through all the primitives instead? As far as I understood the two modes for the forEach node are: - use the output of the previous iteration ("merge results" unchecked) - process each piece and merge them all together in the end ("merge results" checked) What is missing is .. - process each piece, without merging pieces together Scenario: I have a big Volume that I am building procedurally. This volume is too big to fit in memory at once, and since I know it's dimensions and occupancy, I splitted it's bouding box in smaller bounding boxes so I can generate each piece of the volume separately, store it on disk (with indices and a corrensponding point cloud per frame) and then reload it with an Instance at render time. The whole thing works great so far. I'm generating each piece using a forLoop. In the foor loop I write out each piece on disk , per frame, and it works great. So in the end on disk i have something like "pieceX.Y.bgeo" (where X is the bbox number, and Y is the frame). The problem is that in the end o the for loop, Houdini retains all the volumes and merge them together anyways (bringing me back to the initial problem of having it all in memory) ! So my purpose of keeping in memory only the piece I am creating per time, storing it to disk, and then move to the next, is defeated. I am probably missing a very simple solution. All I've to do is iterate through each primitive, process it, store the result, throw it away and move to the next , and all of this per frame. Any idea ?
×