Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Posts posted by Fireandsmoke

  1. On 12/7/2018 at 9:16 AM, Daryl Dunlap said:

    Redshift 2.6.28 added support for rendering Packed Primitives and instancing them.

    The next Redshift release will take this a step further, and add support for Automatically Instancing SubNets as well.

    So does that make the above instruction now irrelevant?

  2. 6 hours ago, Jesper Rahlff said:

    Thats awesome. Yeah it makes retiming mostly pain free for sure.

    so I am not sure this is the reasons why, but if you go to advanced < bindings on the up res node, at the bottom you can specify extra fields that it needs to take into consideration from the low res volumes. Try to input the name of your color volume there.

    Thanks Jesper. Nice try but no cigar unfortunately!

  3. 14 hours ago, Jesper Rahlff said:

    can you share the file when you get home?


    Well Ive worked out where the problem was coming from, but damned if I know why.. maybe its a bug.  For Redshift to render coloured smoke, you have to convert the volume to a VDB (among other things).  And basically I'm getting the error if I cache out to VDB and then load the VDB back in and render.  If I cache to Bgeo, and then do a the conversion to VDB at render time, no problems.   

    Iv'e been playing all even with the GasUpRes...  I LOVE it!   It's the first tool I've used in Houdini that makes timescaling a sim do what I want, I wish I'd looked into it ages ago.    One question I have, which maybe by chance you can answer...  I'm trying to use Gas UpRes with the Colored Smoke shelf tool. but the color is not transferring to the upressed volume.  The volumes are created but the Cd values are black.  I found a hacky way to use Volume Mix to mix back in a frame with colour from the low res smoke, but I'm wondering if there's a better fix...?  

  4. 8 minutes ago, Jesper Rahlff said:

    can you share the file when you get home?


    Will do!  It currently imports a reasonably heavy vdb and requires redshift, but the sim is still in there so you can see the settings I used.   Thanks Jesper, much appreciated.  Ill start looking into Gas Upres and substeps tonight.    

  5. 26 minutes ago, Jesper Rahlff said:

     the way you can retime volumes is to use a Gas Up Res node to basically create subframes from your original simulation and then do a velocity advect on your source volume to gain the exact desired speed. The theory goes that if you know you want to slow down your simulation to 10% you need 10 subframes. meaning frame numbers like 1.0, 1.1, 1.2, 1.3 etc..

    By default the retime node will try to create the interpolation on its own, but if you cache out subframes from your original sim, you can feed the retime node those frames and it can do the retime correctly. This way you avoid going through another simulation step. 

    The help file if you search Gas Up Res will at the bottom of the page give you an example file of how to retime the volume.



    Ah ok, excellent.  I will have a look at that, thanks.  When you say cache out subframes, does this have to be done as a .sim, or can you cache subframes into .bgeo or .vdb?

    My understanding was that a large purpose of the Retime was to avoid having to do all this, relying instead on the method of interpolation (aided by advection), so I'm still curious as to why I'm getting such severe errors (basically its jumping back to some kind of rest state at 5 frame intervals (retiming at a 0.2 speed)).  

    Not to hijack my own thread, but whilst a Retime approach may work, I'm still also curious as to why my original problem is occuring with the flickering color, if anybody has a theory about that...? 

  6. 23 minutes ago, Jesper Rahlff said:

    what happens if you cache out your sim at full speed with substeps and retime it after the simulation?

    You should be able to use the new Retime node from Houdini 17 to do this quite easily.

    Well I would have thought so, but I've been having plenty of issues with the new Retime node..  I posted about it on sidefx forum but nobody has replied, I keep getting very jittery results such as this:  https://giphy.com/gifs/69EhNTJHxxpfE6vHU8
    My post is here:  https://www.sidefx.com/forum/topic/59932/

    One thing I have not been doing though is adding extra substeps to my initial sim.  Is that a requirement for a velocity advected retime?  And is so is there a relationship between the number of substeps required and the desired retimed speed?  

    Any advice would be helpful, I haven't been getting very good results so far!

  7. Hi,

    I have a simple smoke sim using the Colored Smoke shelf tool which I have run at timescale 0.1, cached out to VDB, and am using Redshift to render.  Not problems if I render a sim at full speed, but I'm noticing at this slower timescale I'm getting random flickering of my colours, the saturation dropping away to a varying degree every few frames. 


    Any ideas??

    Thanks for the advice

  8. 15 hours ago, Noobini said:

    in your pyro_import, render tab, if I blank out the Procedural Shader (/shop/vm_geo_vexvolume1), it works...well I 'think' it works coz as said, I don't know what the usage of these are in the first place.

    Not sure what you mean to say... if you blank that out, then its just rendering the volume without the procedural.. so naturally it will render the smoke.  
    This issue I'm having is with the volume procedural applied, how do I import that density of the existing smoke into the cvex shader, so I can use the volume procedural to augment my existing smoke. 


  9. 1 hour ago, Noobini said:

    sure, just switch between volumevop1/2 and you'll see immediate difference


    Thanks.  Yes can see a difference in the viewport but have you tried rendering it?  I just get black from the second version (which was also happening when I tried to build the vop according to your picture)
    An issue seems to be that the "density" inside the cvexvop is not referencing the density of my preexisting volume.  Because even the following in the cvexvop will render black.  

  10. Hi,
    This is probably a simple bit of VOPs, but I can't seem to get it.  I'm wanting to use a Volume Procedural to add some detail and noise to a low res smoke sim.  When I add the noise to the cvexvop, driven by the P and output as density, it is creating noise but filling my whole bounding box, because obviously its adding density driven by noise at every position.  How would I restrict it to apply only to the existing smoke, or use the smoke density as a mask? 

    I thought that by first multiplying P by the density would work (such that where smoke density equals 0, no noise would be added) but does not seem to.  

    Thanks for the advice


  11. More VR tools, particularly a HMD preview mode, if not from the viewport, then from a flipbook (which would require a top/bottom latlong veiwport display from the spherical camera), or even the render window as a last resort.  This would make Houdini infinitely more usable for VR.  

    • Like 2

  12. For my own understanding, I'd really like to know why changing the timescale parameter changes the look of the sim so much?  I thought its function was to scale the time base of everything inside the solver, so why does it then cause such huge change - a basic smoke sim at timescale 0.1, 1 and 5 are all going to look completely different... which makes it kind of useless.    

  13. Thanks for that.  
    Sounds like from some other sources that RS does not have a similar feature.  However I need to stick with RS for fast render times.
    So is brute force voxels the only way for me achieve a dense looking volume with no visible voxels?  Are there any tricks or tips you can suggest for keeping my voxel count high and volume smooth, without crushing my pc?  

  14. Hi, I'm fairly new to volumes so please bare with me..  
    I'm enjoying creating some cool effects with Houdini volumes and Redshift by simply assigning a Redshift volume material and cranking up both the Scatter and Absorption coefficients of the density to get some cool sci-fi-ey gaseous effects where the volume has an appearance of being quite thick bodied yet translucent.  The problem is that dialling up the density like this in the material means the voxels become very defined.  So I'm wondering if I'm going about this the wrong way? Or is there a way to smooth my volume out?  Im aiming for a 4K output for a big screen so it will need to be very smooth. 
    Ive tried cranking the voxel count to 600 (Max Axis), as you can see below still quite visible.  Also tried a Volume blur (and converting to VDB and using VDB Smooth), which helps a bit, but it loses the overall effect and still leaves a moire-ish pattern from the voxels.
    Thanks for any suggestions

  15. I've got a simple particle setup, a large number of particles being advected by a smoke sim and then cached out to a bgeo.  Then loading that into a File sop and using a delete SOP with a Delete by Range (29 of 30) to dramatically thin it out for some close ups.  This process has been working well for me across a variety of different particle setups, but for some reason on this shot, my particles hit a certain frame and go bonkers.  There is nothing wrong with the actual sim, so I can only put it down to being something to do with the delete SOP.  


    Any ideas what this might be causing this?  

    And any way to fix it without changing my existing geo, as I had already rendered hundreds of frames before I noticed this problem and would love to not have to redo the earlier frames, if possible. 

    Thanks for any advice

  16. On 01/11/2018 at 12:17 AM, Atom said:

    Check out the volume retime HIP file at this location.


    To leverage this technique you must have a vel field in your output.

    Basically simulate at a normal speed then use that setup to slow it down.

    Thanks Atom, this looks good. 

    Have you used this setup before?  

    Ive tried copying this retime setup into my own pyro sim but its not working as in the original .hip, just plays back both at the same speed.  

    EDIT:  Just noticed that this actually involves the installation of a custom asset library.. then it will work..

  17. I've been playing for days and days trying to slow smoke sims for some nice particle advections.  They need to be very slow, so the process I've been trying to use is either reducing the timescale, or cranking up the FPS of my timeline.  At these slow speeds, it is not practical to find the "look" of my sim, I need to look dev at 25fps, and then slow that version down.  But by then slowing down the sim via timescale or FPS, only rarely do I get a result I want.  Is there settings with the solver or DOPnet that I need to be adjusting to compensate for the slower speed?  Most of the time, a beautifully turbulent and dynamic sim at 25fps often just turns into a hopeless blob at 200+fps or 0.1 timescale.  Would love some input on this..  (PS.  Im still on 16.5 for now, so the retime node is not an option).  



  18. I've seen a few responses to this question, but still am having no luck, wondering if someone can hold my hand and give me some specific instructions.
    I simply want to retime a VDB of smoke to make it slower, interpolating between frames.
    I've got a VDB which I've cached out and loaded back in via File SOP.  Now I've added a Time Blend, and then a Time Shift.  In the TimeShift I've changed the Frame expression to $F*0.5 and unchecked Integers.  I'm still not seeing any interpolation between frames.  What settings do I need in my TimeBlend for this to work?
    Thanks a lot


  19. I'm trying to make billowing smoke follow a spiraling curve, kind of as if a tornado did a corkscrew.  I know with POPs this is quite easy using Curve Force, the particles really adhere to the tube.   But using Gas Curve Force with my smoke is just causing little wisps to get sucked in the direction of the curve rather than causing suction to the mass of the volume.  Is there a better way I should be approaching this?  
    Thanks for the advice

  20. 5 minutes ago, kiryha said:

    Vector is just a direction and length and it does not matter where the vector is located in Cartesian space (there is a special type of vector called "position vectors" which lock to space and always starts at the origin, though).
    So, vector B is the same vector as green A+B. Placing B on the tip of A helps to visualize that A + B = blue line.

    But how would you define the direction of the green vector, because without the point of A as a reference, how are we to know by reading the green vectors coordinates that the origin is the tip of A?