hkspowers

Houdini express its camera apx value in millimeters. Maya express it's apertures in inches. (Actually it expressing them in “decimal-inches”. ie Mayas horzFilmAp look like this “1.42”in) Do some conversions between the two and look into the USERSGUIDE for its short treatis on Houdini cameras. The other values you may need can be derived from the ones already supplied in houdini. James Peterson *Rangi Sutton answering a post on the SESI list: houdini Aperture * 0.03936981 = maya Horizontal Film Aperture Or backwards: houdini Aperture = 25.400173 * maya Horizontal Film Aperture Yep, maya focal and houdini focal are the same deal… I've checked the above by outputing rib's from each package and it's good…

That's exactly what I'm trying to eliminate. When I load an image in, it should auto load and cache the entire sequence like RV does. Having to manually tell it every time gets tedious when you have to check frames many times a day.

A check box or option to always cache all frames in mplay when flipping frames. We don't have enough RV licenses at the office, so I'm often left to use mplay which is surprisingly very good at flipping frames but I wish I didn't have to click "cache all frames" every time, a toggle or a preference setting would be nice.

There you go man! I have the LG 31MU97 true digital cinema 4k monitor. 4096x2160 http://www.lg.com/us/monitors/lg-31MU97-B-4k-ips-led-monitor

I've used that quite a bit and while it's great for home use, it does seem to increase the sim time considerably if you are doing a heavy sim. For smaller sims it's pretty transparent and hardly noticeable which makes it great for pops and quick pyro sims.

Can confirm Luke's assessment in conjunction with Symek's. I'm running dual 12 core E5-2680 v3 @ 2.50GHz and I get a similar problem to yours but I know exactly why. When it does the actual pyro calculation in the sim, procs get pegged at 100%, but when it goes to write out the huge geo file for that frame the cpu tanks to 2%, but that's only because it's waiting on the file write over the network. So you will see in my case a very predictable pattern of peaks and valleys in the task manager as the sim progresses. If I was writing locally to a pci based ssd, the whole thing would be sped up as it's not bottlenecked by my storage solution.

Thanks Djiki! I used the "UV Map" node in cops to generate the UV map. As it turns out, I was indeed writing out the UV data to the c plane, I didn't realize this would cause an issue. I tried writing it out to the B plane as you suggested and it works perfectly now. Thanks again!

Hey guys, Our tracker asked me to write him out a 2d UV map today from Houdini because he was running into a bug in Nuke where the resulting UV Map would have a missing .5 pixels on each side of the frame for a total of 1 missing pixel . However, when he generated the UV Map out of out of 3d Equalizer it was correct and it was not missing a pixel. So I took a crack at it and ran out said UV Map from Houdini, and sure enough it came out identical to Nuke's UV Map with the missing pixel. If I load in the generated UV Map into Nuke as an STMap input and add a checkerboard with the same res as the UV map into the STMap node and compare them, the difference in resolution is very clear. Has anyone run into this or is there a reason for this behavior? Any ideas would be appreciated. Houdini 15.0.347

The grid size as I understand it is just a refrence to the size of your original ocean "chunk" that will be tiled after the fact. So you have to decide on a base resolution of how many meters of ocean you want to create and based off that size decide how much tiling you can get away with on a shot by shot basis. All of the other attributes are relative to your original grid size.

Not sure if Arnold for Houdini works like Arnold for Maya off the shelf when it comes to converting existing shaders to render in Arnold, but you can get that same efffect with the ramp shader in Houdini. https://www.dropbox.com/s/3u5i8y4yic3c2rl/untitled.jpg?dl=0

The 970 has 664 more cuda cores which will help with your open cl processing. Also the memory bandwidth is double at 224GB/s which will also help. If you can afford it I would go with the 970.

The GTX 960 should preform fine, it may not be listed as ofically supported but it's a higher end nvidia gaming card so it should be fine. Many people are running the same card without any major issues. Open cl is natively supported on the AMD platform, where nvidia supports it but through their cuda framework. As far as real world comparisons between the two there is a thread somewhere around here where people compare the two, but in reality 4GB video memory is going to be your limiting factor. Unless you're doing tiny low res sims then you won't be using open cl much if at all. Hope that helps.

You certinly want to go with the Intel i7-4790k proc, it's quite a bit faster than the AMD Check out the passmark scores. http://www.cpubenchmark.net/high_end_cpus.html And for video cards: I would go with the MSI GTX 960, the arcitecture changed significantly between the 700 series and 900 series cards and the 900 preform quite a bit better compared to their 700 series counterparts. Also Nvidia just to avoid display issues as much as possible. Some will tell you the AMD is ok, and it very well may be, but overall from my past experience with 2 AMD cards they ALWAYS had some annoying display issues as in manipulator handles wouldn't show up, normals missing etc. And with the new houdini viewport it's already riddles with random bugs, so if you're on the same hardware as most houdini artists then you can at least narrow down your problem easier if you should run into one. Just some thoughts.

I've also struggled with this and found it to be extremely inconvenient. Do you have a link or a short reason as to why this was done? My main gripe is loss of var maping on new atrributes created within vops.

In Houdini 14 we also now enjoy background caching.