sidandmj

http://www.sidefx.com/forum/topic/44970/ here is another one asking the same question , blackpixel replies with a much better method than vdb heavy work flow and provided a couple of example files on how to achieve the look purely in a shader! much much better...unless you need geometry for some reason

i think that is possible if you add a properties vop to the shading network connected to outputs and add the light samples as a parameter...then you can override that parameter with an attribute on the geometry....

Using a GI light and modifying samples, maybe some crazy numbers that could use adjustments: 80 samples on the light, 8000 on stochastic samples, 16 min on my machine as a comparison the original render from the scene as rendered above toook 0:58 seconds on my machine ap_geometry_dome_spot_light.hipnc

Here is a recreation of the vr camera from Arnold...it is a CVEX lens shader and does over/under or side by side 360 renders apply it to a camera that is set to Lens shader and render! best to use square aspect ratio, and over/under for a setup like what you have shown et_vr_cam.hda

I have used pyro on a number of shots recently and am more than impressed. I have acheived upres sims at 866x256x905, sim times are around 3min per frame Even turned around a full frame dust hit in one day, in 3d! The pyro tools are more than production worthy Proper data preparation is essential to getting fast sims I have seen others try similar shots at my studio, in both maya and fume, and they keep being asked to make it look and feel more like the pyro renders im sticking with houdini, its only going to get better from here

actually I am doing this very thing for a shot now and having great success at running the sim realtime then using the sequence blend sop to blend the voxel data so far it seems to work like a charm you can also readvect density thru the blended vel fields with the time scale of the advect dop set to the new rate i recommend not using the time scale as there are a few fields that dont respect the scale and you cant animate the scale these issues are not present in the blending method

this is because the solver creates all geos in a fracture object with a center of 0,0,0 not the actual centroid of each fractured chunk so to fix the problem, you must first center all your chunks in sops but store their original position as an attribute, then use a position dop to retrieve the attribute and reposition the pieces. this will then transform the centroids as well and result in a happy sim. or we need to find a way to rewrite the plugin such that it computes the centers the way an rbd fracture dop does.

you can try a point sop, put the point number in the group field, in this case 8 then change the "keep weight" to "new weight" and set the weight of the point to a very high value 100+ not sure if this is the best way but it is one way cheers

it all depends on how you are moving the source geos if you are using the "use animated geo" toggle, the sdf for the object(s) is getting rebuilt every frame. if you dont need the geometry to deform you should use the object level transforms as the sim will only build the sdf on the first frame of the sim you can also cache the sdf to disk as this will help dramatically if you need deforming geometry. they can be saved as .simdata from the Collision/Volume tab on any rbd or static object

h10 is good to go for vc8 i was able to compile the maxwell plugin for 10 today, however................... first setup according to the docs mentioned above and ensure that cl.exe runs from a houdini shell from that shell, navigate to %HFS%/toolkit/samples/SOP you will need to run hcustom -e SOP_star.C >> output.bat then edit the output.bat file to remove the lines up to the last long one that starts: C:\Program Files\....\cl ....................... edit the C:Program files\.........cl to just read cl or cl.exe then remove the UT_DSO_VERSION = longhexnumbers line as it will keep the plugin from compiling this is a bug in hcustom for windows 64bit and currently this is the only workaround i have found to work, not sure if there is the same issue with the 32bit version. i sent the bug into support but have not heard a response for a fix yet good luck

Great work! anticipating the animation!

i understand just what you mean about the support side of NL terrible at best . . . Mark you are correct i do have a working, minus texutres version of a Maxwell Exporter not sure if its a bug on maxwell side or my side, things worked prior to beta 1.1.2a there are some minor things that are unsupported, and need to doc it a little bit for use further i need to implement apprentice code so as not to screw sideFx by releasing a plugin that allows apprentice to be used commercially for renders will be talking with nl about getting them the plugin once i have the textures and apprentice code working but i am beginning to wonder if i should proceed with nl or find another next gen type renderer like maxwell . . . . .but im not writing one!

i dont think one would want many cache files, especially refined ones, as they can be quite large. i expect rather that one cache file with the "scene" lighting baked into it is sufficient for the read only portion. rendering from different points of view into the same cache file with a zero error will fill in missing areas from the cache. once the scene has been rendered from every key view, i can think of no reason to continue writing to the cache. if a character walks into the room, only that characters irradiance would need be different from the calculated cache therefore requiring calculation, but again i dont think it is appropriate to write that information into the cache. since read only cache files can be used during multi-proc rendering i think that once the scene cache is complete, throw as many procs as you can at each frame. With enough procs, rendertimes could drop to minutes per frame instead of hours . . . . which is what it would take if you had to write 100 cache files to render a 100 frame animation . . . i am rendering a camera move on this sequence to test the single cache theory . . . so far results have been promissing. . . but i have not added a char or other objects to the scene

i found that the cache works very well, easy to use. i first started the cache before i had any textures on, and added one light at a time. i found that rendering it small and uprezing was no problem, as long as the default error on the ROP was set to 0. if i then use read/write option i can continue to write into the cache. i re-rendered this with the read only option and .1 error and shaved about an hour off the render times. with that in mind i would assume that the cache is written to until the SCENE lighting is established, then it is used as a read only from then out as characters, objects, lights, change in the scene. when using read only it is possible to multi-proc the render, and thats how a render can benefit from the cache. i could probably optimize it a little more as i am using raytraced shadows on the area lights. if i were to generate a global photon pass with the area lights i could use the global map instead of using the area lights, and calculating rt shadows, which should significantly speed up the enitre render . . . . thats the hope anyway, will post results as they are available . . . i can attatch the textures i used if anyone wants them, just reply . . . thanks for the comments, ideas, questions, and suggestions, keepem comin . . .

Full irradiance must be used in order to write a cache for it. check out my new rendering post, i have included a hip file that has a GI OTL embedded in it, maybe this will help . . .