Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

4 Neutral

About tinyhawkus

  • Rank

Personal Information

  • Name
  • Location

Recent Profile Visitors

1,161 profile views
  1. Pyro renders taking way too long

    Jesus, please don't use deep shadow maps, unless you want to go retro 2001 style. Can we see a frame? Can you upload a single bgeo + your scene to have a look at? Volume limit of 1 means 1 bounce of indirect, which is already pretty expensive as Mantra kinda sucks in that regard (but guess what, almost all of them suck at volume bouncing, hello Arnold!), your volume light is doing a point cloud bake to simulate emissive illumination. So you don't want to be using it as well as doing a volume bounce too. I would steer clear of using volume limit (volume bouncing) completely in Mantra, it is just too slow to be usable unless the shot really calls for it. Use PBR mode, your env hdr, and a volume light.
  2. To much noise and rendertime

    Almost all the noise will be coming from indirect rays, so there's a few things we can do. Can you PM me a link to a zipped up scene with everything needed for the frame you've shown here?
  3. Pyro OpenCL vs CPU - Why do the sims differ?

    You need to set your openCL device to cpu. What I generally do, is test out quickly on the GPU, and when I submit my sim I set the following; HOUDINI_OCL_DEVICETYPE=CPU. This will give you the same results. Interesting to note also, that comparing a CPU sim, to a openCL CPU sim can be quite a bit quicker. Have a little search around the docs, to walk you through this.
  4. Bullet sim blows up with targetw/spinresist

    Also, I've moved to always doing bullet sims at 10 x real scale, seems to get rid of so many typical bullshit bullet oddities. Bullet really doesn't like small stuff.
  5. Light Wranglers

    Hey All, So I'm sniffing around this page: http://odforce.net/wiki/doku.php?id=sohowranglers and it's mentioning a sample code archive "Wrangling.tar.gz" that I cannot track down. Did this get lost with the re-vamp of odforce? Cheers Lewie
  6. Yes. Simply add the xform samples render parm to the geo container you don't want blurred, and set to 1.
  7. SOP level rotational motion blur

    Any time a point moves inside SOPs context it is classed as deformation, just like a character mesh. At OBJ level it's transforming. So Xform samples relates to OBJ motion, including camera motion. Geo samples are for deformation. So if you have SOPs level movement of points but your camera isn't animated, you can leave Xform samples at 1.
  8. DOP's doesn't process top down like SOP's. in SOP's each node is kinda a self contained function. Process the incoming data, spit it out. Whereas in DOP's it's from the bottom up, and is the ingredients to feed into the simulation engine.
  9. [SOLVED]Fire Emission Too Noisy

    Strange though. I don't any PC message at all. You can just save them out by setting up a dummy mantra ROP and running that. The PC write is strange, you'd think there'd be a PC write inside the shader that the Volume light is looking at, but nope. It's doing some sneaky stuff. You can reduce your noise by simply jacking up pixel samples a bit. The PC quality can be dropped to half of what it's currently set at. Maybe I'll make a PC write ROP to make life easier. Sometimes the PC temp from the volume light was crashing my renders on the farm. If you need any more help just sing out dude. Lewie
  10. [SOLVED]Fire Emission Too Noisy

    I've added a file cache to your sim. It's saving to bgeo.sc and loading it in another geo container, as a packed primitive This helps keep your IFD file size down. So it's now working fine loading a bgeo.sc sequence saved from your sim. Cheers Lewie geo_light_point_cloud_issue_with_bgeo_FIXED.hipnc
  11. [SOLVED]Fire Emission Too Noisy

    Use Volume light, not geo light. With point cloud turned on. I've fixed up your scene, and added some AOV's for you to play with. Your fire shader is now outputting a fire and smoke mask. Is this the result you are looking for? Lewie geo_light_point_cloud_issue_FIXED.hipnc
  12. Guys, So I'm getting to the pointy end of my ice cream setup, it's all doing pretty much what it should, but for one aspect. Even with particle separation enabled, it is still compressing when colliding with geometry. Clearly volume preservation is key here, I have a test scene, but thanks to MPAA I can't upload more than 100kb files. Basically the test scene is a FLIP object sitting in a cone, think egg and egg-cup, with a box pushing down directly on top. Now you'd expect the FLIP fluid to move out of the way, but it's not doing it at all. It ends up looking like a boolean of the FLIP, and I get it that the particles can get stuck too close together during the projection stage, but I thought that particle separation would fix that by enforcing an almost SPH force. I've done honey in Realflow before with SPH, and that required an insane amount of sub-stepping to prevent explosions as you'd expect, but that's not an option here. The fluid is very viscous (it is ice cream after all) Is it something stupid I'm missing? Cheers Lewie

    This helped me set up a compiling environment in Winblows. http://www.deborahrfowler.com/C++Resources/HDK-HcustomOnWindows.html Lewie
  14. Object picking up sticky FLIP fluid

    Yep, ran into that issue. Thank you so much for taking the time to test and build me a hip. I'll look at it straight away. If you're ever i Melbourne i'll buy you a beer! Cheers. Lewie
  15. Object picking up sticky FLIP fluid

    Definitely going to need that test scene. :-(