Jump to content

Fireandsmoke

Members
  • Content count

    74
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Posts posted by Fireandsmoke


  1. 8 hours ago, zarti said:

    i opened your EXR in Blender and these were the Alpha values on your file .

    Capture_AlphaOnly.PNG.fe0907920be27999b5100314d937c425.PNG

    maybe you should tweak its values from the render

    .cheers

    Yeh Mplay displays a similar alpha, but with all channels on it creates an image like in my post above, whereas AE/ Prem do not, the image has far less detail.  Maybe this could also be a Redshift thing..  I dont know yet.   By changing my AE settings to the following I can get the image to look similar, but whatever I export still seems to have the same alpha issue once in Premiere.  Perhaps this is starting to be more of an issue for an Adobe forum, but I just thought there would be some people here who have a simple answer, given this must be a very common workflow.    AE.thumb.JPG.0b108ccc8d248ccc28e04de855fff21e.JPG


  2. I'm having trouble deciphering the correct workflow for importing Houdinis EXRs into AE and then out for edit in Prem Pro (EXRs are exported from Houdini/Redshift with default settings).
    It seems like the alpha channels are very weak, and leaving nearly my whole image transparent.  Does anyone have a tried and tested method which they could share for bringing Houdinis EXRs into and out of AE, for an export into a format like ProRes 444+alpha?
    I've had a look at a few posts online and played around for hours with countless colour management and alpha premult settings within AE but feel like I'm banging my head against a wall.  
    Ive attached the EXR and a Mplay vs Prem comparison.  
    Thanks for any advice


     

    Premiere.JPG

    Mplay.JPG

    ExampleEXR.exr


  3. Very useful attribute when doing anything that involves rendering particles or copied geo.  I use it endlessly.  For example, it can uniformly change the size of your particles, by creating a wrangle and adding @pscale = "insert float value here"
    And beyond that add noises etc to the pscale value in VOPs for interesting effects.  Remember as well that when copying geo to points the pscale attribute will also affect the size of copied geo if "Copy Point Attributes" is selected in your Copy to Points SOP. 

     

    • Like 1

  4. This is probably a fairly simple one..  
    I have a geo sequence which I want to convert and export into a different format.  I would like the filenames to remain the same as the original geo, (apart from the new filetype suffix). 
    How would I reference the name of each frame of the original geo sequence?

    Thanks for the help

     


  5. Hi.  I have an interesting problem I've been trying to solve for the last few days but still haven't managed to find a good solution.  I have a sequence of geo which has been captured with a depth sensor. One of the issues with the sequence is that the point numbers change positions every frame.    Whilst there is a rough order to the point numbering per frame, its not very consistent.  I'm wondering if there would be a way to homogenise the layout of the point numbers by reordering, or to somehow re-mesh the geometry sequence to create a new version with more of an ordered structure?   I've attached a short bgeo sequence as a sample if anybody would be interested in having a look.  Thanks for any advice
     

    VolumetricTest.rar


  6. Thanks for everybodys input.  Ive ended up going with the free version of Royal Render, and it has been relatively easy and effective to setup on a single machine, and I have very minimal networking skills.   For whatever reason, I was finding that the rrSerivce was not resuming my renders on a system restart, so I placed the win__rrClient.bat into the Windows startup directory to force it to start.  


  7. It's quite common that Ill set off a render at night only to find out in the morning that it has crashed at some point a short way through.  Generally, if I simply restart houdini and render from where it got up to, it will continue without problem.  Not sure why this happens, but it does mean over night renders are often a gamble.  What I'm wondering is, would it be possible to have some kind of script which detects a crash, reboots houdini with the working project and takes off from the last rendered frame?  Would such an idea even be possible?
     


  8. As a side note to this which may help someone in the future:  if youre wanting to render a wireframe quad look  (which is what I was after), using Redshift selecting Rendering an object as Strands will automatically render the wire frame as quads.  


  9. Hi,

    Im wanting to render a wireframe look of a scan captured asset, but Id prefer to lose all the diagonals and have it in quads..  is there a simple way to convert tris to quads in Houdini 17.5, I cant seem to find it? Thanks

     

    image.thumb.png.2f45915acbb46e5b894c2ba6f8c759b6.png

     


  10. 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?


  11. 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!


  12. 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...?  


  13. 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.    


  14. 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...? 


  15. 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!
     


  16. 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. 

    https://giphy.com/gifs/FfpdaTVBqu7CVlcAd8


    Any ideas??


    Thanks for the advice


  17. 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. 

     


  18. 1 hour ago, Noobini said:

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

    vu_volumeprocedural.hiplc

    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)
    Capture.thumb.JPG.46b1971ffca7ac677885dbad53d26cf7.JPG
    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.  

×