Atom Posted March 23, 2016 Share Posted March 23, 2016 (edited) HI All,I am trying to export a VDB sequence from a pyro simulation. No matter what I do I can not get the sequence to export at a reasonable quality. Sure if raise division size I can get a low quality crappy sequence that covers my frame range. As I lower division size to focus on the quality I need for rendering Houdini just chokes or hangs and won't complete the export. At first I thought it must be my hardware but after careful testing I can verify that my simulation does fit within my physical memory and the system is not overheating. Consider the attached image. This shows Houdini reliably exporting my VDB, with a division size of 0.25, to the disk every couple of minutes per-frame. But at frame #127 and it is not specific to that frame, other attempts Houdini will crap out on other frame #s, Houdini just hangs and won't export anymore even though the CPU monitor still shows some activity. The CPU activity is no longer near 100% either. I have waited over an hour or more and the frame never completes. What can I do to fix this problem? I have tried using a File node and playing the simulation frame-by-frame and I have also tried using the ROP Output Driver. They both fail with the same symptoms. Continuing the export does not seem to work either. If I setup the ROP Output Driver to start on frame 127 Houdini will chop through the sim till it gets to that frame and then hang as usual. I have also tried this same scene on OSX and Windows and Houdini fails the same way on both operating systems. I am attaching the file but it references a geo sequence on disk that I can't upload. But at least you can review the setup. Thanks in advance for any tips! ap_construct_VDB_for_building_01.hipnc Edited March 24, 2016 by Atom Quote Link to comment Share on other sites More sharing options...
Skybar Posted March 23, 2016 Share Posted March 23, 2016 No idea. But another thing out of curiosity, why are you caching out the visualization and not the actual sim? Quote Link to comment Share on other sites More sharing options...
lukeiamyourfather Posted March 23, 2016 Share Posted March 23, 2016 No idea. But another thing out of curiosity, why are you caching out the visualization and not the actual sim? Likely because they're using a non-commercial version of Houdini so DOP level files are not possible. Are you sure it's the output file causing a problem and not the simulation itself? If you're caching out a simulation as it runs then the simulation is likely the problem, not the file export. Quote Link to comment Share on other sites More sharing options...
Skybar Posted March 23, 2016 Share Posted March 23, 2016 Likely because they're using a non-commercial version of Houdini so DOP level files are not possible. Well thats not what I meant. If you look at his file he is caching the visualization, and not the other SOP in there which fetches all the fields. Quote Link to comment Share on other sites More sharing options...
Atom Posted March 23, 2016 Author Share Posted March 23, 2016 (edited) I am exploring using Clarisse for rendering. The fields are setup correctly for Clarisse. When I load the VDB files into Clarisse I see Density, Heat and Temperature which I can use to drive materials. I can play the simulation. I have done so using a lower division size. I just want to get a higher quality VDB into Clarisse. The problem is that Houdini lockups up after a while during export. So no one ever exports VDB files...? . . . Here is the result of another attempt. This time I used the ROP Output Driver which crashed on a sooner frame than the last attempt which makes me think it is not in the simulation. But it is a memory allocation that is failing. Edited March 23, 2016 by Atom Quote Link to comment Share on other sites More sharing options...
lukeiamyourfather Posted March 24, 2016 Share Posted March 24, 2016 It might be a software bug. I've exported VDB files from Houdini in the tens of gigabytes range. Quote Link to comment Share on other sites More sharing options...
Skybar Posted March 24, 2016 Share Posted March 24, 2016 I don't know if .vdb supports geometry. Since you are exporting the visualization you are exporting the bounding box geometry as well. But I guess that would make it fail a lot sooner than it does now. Does it work if you write to .bgeo? IF that works, you could maybe do that first and then write .vdb from those. Quote Link to comment Share on other sites More sharing options...
Atom Posted March 24, 2016 Author Share Posted March 24, 2016 (edited) I conducted another test. I put a python 1 second sleep command in each of the ROP Output Driver scripts. This timing experiment got me farther down the line. I was able to get 218 frames out of my 480 frame sequence. If you examine the time each file was created you can see that Houdini was merrily cranking out frames until 2:21am. Then it got suck in the Gas Solver at 100% load for 6 more hours. Each previous frame was only taking a few minutes. I have not exceeded physical memory. So I'm thinking it must be some kind bug. Maybe the problem is in the Convert TO VDB Node? @Skybar: I'm trying your suggestion of exporting to bgeo.sc first... @Luke: How do you export your VDB files? Do you use the ROP Output Driver as well? Also, how much memory does your machine have to export a 10Gb VDB? Could I , in theory, export such a file size on a 32Gb machine? This image was taken at 8:23am....Update: @Skybar: I just conducted a bgeo.sc export with the pyro sim division size of 0.5, which is a fairly coarse light weight setting for volumes. Once again I get a Houdini crash in the memory allocation module. I did take the VDB Convert out of the loop on this test so I don't think that node is the problems. I guess I should conduct some actual RAM test to see if my memory chips are still good? Edited March 24, 2016 by Atom Quote Link to comment Share on other sites More sharing options...
Atom Posted March 24, 2016 Author Share Posted March 24, 2016 (edited) Ok, I think I figured it out. It was mis-matched RAM chip timings. I purchased two new EVGA 8Gb DDR3 chips to max out my motherboard with 32Gb of ram. This ram is so mis-labeled that it is borderline false advertising. Where are the import police when you need them? EVGA has went so far as to embed false XMP meta data so when you put the RAM into the motherboard it reports as specified on the label 1600Mhz. However, it can only run @1333Mhz, not 16000Mhz. When I viewed the actual speed of the ram using CPUID it was reported as 667Mhz (DDR up to 13333) not 800Mhz (DDR 1600). Houdini was accessing memory at the speed of 1600Mhz some of the time and 13333Mhz other times. I can see that being a problem, especially if data is being shared across memory chips that are running at different speeds. So I say shame on you EVGA, you are a large enough company that you should actually test your ram before you label it and ship it. The false XMP meta data is kind of like a smoking gun that leads to a foul play conclusion. I don't think this is an honest labeling mistake. It feels more like an attempt at trying to trick consumers into buying a product that is purposely mis-labeled with a higher spec. I had a similar run in with a company called AddOn who has the same shady business practice of mis-labeling RAM and lying to customers about specs. In the end I took the EVGA ram back and traded it in for Crucial Ballistic Sport to match my previous set of Crucial 16Gb chips and now Houdini is running fine and kicking out my VDB files. Edited March 24, 2016 by Atom Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.