Houdini Windows 11
Arleen Jerdee
Hey guys!
I've had some serious issues these past days with insufficient RAM where Windows 10 force closes Houdini, so it's not even real crashes it just kills Houdin mid-simulation.
Since it's a very troublesome process to try and detect when the force quit has happened and restart it from the last simulated frame I'm turning to you guys for help.
1. Is there some way I can limit Houdini so that it sims slower but I won't have to worry about it crashing?
2. (Probably a bad idea) but is there some way to stop Windows from killing Houdini if the problem should arise again?
3. Am I simply in over my head and calculating something too heavy that won't be possible to write out? (Feels pretty weird though since I can simulate at least around 10-12 frames between every crash)
Any and all answers are greatly appreciated!
Cheers,
Jack
Have you tried limiting your cache limit to something "small" (depending on your machine), In my case I set it to 5GB (DOP Network --> Cache --> Cache Memory = 5000, I think this is the default anyways). Also, maybe you should make it really small like 1 GB and enable "Allow Caching to Disk". I see also "Save Checkpoints", the documentation says that it will save the entire state of the simulation so you won't start from scratch each time (I think in your case, if the simulation crashes at frame 100, then next time it starts it will start at frame 100, I have not test myself take this with a grain of salt ).
Hey Catchyid!
Thanks for the reply, I can see now that I should have been way more explicit in my previous post haha.
I am not simulating per se but writing it to disk through an ROP Output node and that's when the crashes happen, the DOP Network is switched off completely!
Aha yep, whatever I said has nothing with your problem I am not expert here, but have you tried looking at the console (i.e. run houdini from dos prompt and see it it has written any useful hint before it crashes?), also maybe you could try using File Cache or simply File node and switch to output (i.e. instead of ROP output)...Other than that, I really don't know! Hope you can figure it out
I just started using Houdini on Windows 10, on a low end 14GB system, and my experience is that Houdini is stable on that platform so I would not jump to the conclusion that it is the OS causing the problem. I would investigate the hardware first. How much memory do you have? Are all the memory chips running at the same speed? I know we rely on the motherboard to help keep mis-matched memory speeds in check but I find that Houdini is sensitive to this and will often crash if chips are not running at the same speed. Pull down CPU-Z and examine the RAM chip speeds. Also, are you overclocking your motherboard or GPU? Is your system stable with a 2 hour prime95 stress test?
I had this problem some months ago and after lots of try and error I found one of my eight memory modules was corrupted so I changed it. This is probably different to your situation but if you are facing a new machine so it's better to check each ram modules first.
EDIT: Due to my lacking tech wizardness I do not think I'm fully qualified to indentify an issue should I find it, but anyways to answer your earlier questions.
1. I just upgraded my computer to 64 GB of RAM, which (I hope) should be plenty for now.
2. According to CPU-Z they are all running at 1067 MHz in frequency (please let me know I am looking at the wrong thing here).
What are your power settings on Windows 10? Maybe it is something silly like the screen saver is kicking in and that messes things up? Or power save mode is turning off the disk when your are trying to write to it?
There is also the dreaded TDR which can cause things to time-out or error out. If you have OpenCL enabled on the FLIP solver it may be contributing to instability. Basically it is a mechanism to prevent blue screen crashes by safely crashing the video driver instead.
"OpenCL Exception: Failed to create compute grid. (-4)"
Might that be connected to the crashing?
I am running Houdini from an SSD but not writing to one, if you think that could be the problem I'll start simming to the SSD instantly.
I'll download HWMonitor and see if there might be any heat related issues, but the computer is equipped with liquid cooling so I doubt that'd be the issue - but I'll check it out!
P.S. Managed to sim a few more frames so I don't think the issue was with a specific frame in the simulation or so, this time it proper crashed my computer though!
EDIT: For some reason I can't upload the file, I'm only getting a notification about it failing.
_test.rar?dl=0
Try this link and let me know if it's working as intended.
I took a look at the file and I don't think I can re-create on my side due to the complexity and multiple caches that are needed as well as missing OBJ files. But you may want to try a larger division size on the smoke object itself just to sim quickly through more frames. Also try turning off Use OpenCL on the solver to see if that makes a difference.
Still has issues on ym side im afraid hardly could work when up to few millions of polygons, above 30millions... This is indeed really drives me seriously nuts and just kills my productivity flow right now...
I have a ASUS Strix OC RTX 3090, latest NVIDIA Studio driver, nothing else excepted Houdini running... Has even crash when you maximize and minimize windows like the geo spreadsheet, or netview view, back to regular layout...
Yeah the registered commands line is really suspect here, or what came before it. Most likely commands are being fetched from the server/config. Also I see they are being written to xml, which is how Houdini reads them. Check out tk-houdini/python/tk_houdini/ui_generation.py
Edit: from a cursory scan of the file, it seems not to change between context etc? This means the fix in the engine should be relatively simple - just do not regenerate the file every time if it exists.
Hello @maxmax003,
Thanks for reporting the error. I have an update regarding the issue.
Currently the connector assumes your Houdini user directories live under %USERPROFILE%\Documents\houdini19.x If the directories do not exist, that will fail the connector installation. Please note that it only fails when neither 19.0 nor 19.5 not exist (It is ok if you only have one versions of Houdini 19 installed.)
We have an upcoming release that will address this issue properly. In the meantime, you can manually create the directory before installing Houdini Connector.
For example, C:\Users\maxma\Documents\houdini19.5\ . Please also make sure that path is in the %HOUDINI_PATH% environment variable, which is the default Houdini settings.
Hi, I created a post, I wanted to upload images, but I just can upload one file so I uploaded the hipcl file, basically I want to read the attributes or primvars to the shader when I do the instances or packed geometry, here is the link to the new post
Environment file is a simple text file located in your Windows user directory, that lets you define a number of variables and settings that can change how Houdini behaves and where it is looking for resources. In this article I will explain how you can use it to setup some basic Houdini asset sharing across multiple workstations.
Typical task that can be accomplished by modifying the env file is user defining paths to scan for plugins, HDAs, gallery files, toolbars, presets, etc. Very convenient if you want to have a shared network folder that collects that kind of things which you want everybody on a team to have an instant access to.
Other than that there is a number of variables that can alter some low level funtions, like turning on/off various GPU and CPU functions, altering how houdini is hadling textures, log files, color spaces, there are debuging options, graphical output options, network features, caching, and tons of other things.
Other than auto loading stuff from custom user directories, you can setup all sorts of low level system stuff here that can make your life easier and user experience more enjoyable: HOUDINI_VIEWER_STATE_VERBOSE got rid us of some annoying viewport verbosity (that might otherwise be useful for debugging I imagine), HOUDINI_ACCESS_METHOD deals with network permissions which turned out to be a critical little tweak, HOUDINI_ENABLE_EXR_TEXTURE made it possible to work directly with exr textures without having to constantly converting them to rat in lookdev stage, before they were ready to be rendered in shots.
That immediately solves one issue caused by the fact that user directory on each workstation will have a different path. As you can see at the example of our env file, paths to user folder are simply substituted by the variable, which makes it work for everybody.
What is even better, houdini.env can take advantage of Windows environment variables as well. Windows system too offers many existing environment variables that you can use, or you can create your own. That helps not only mitigate an issue if users have a different drive mappings, but these system variables are globally accessible across applications.
Hello,
i have a strange issue(apperently with no solution) that suddenly appeared, all my installed versions of Sidefx houdini wont open anymore. all of them stuck on splash screen, 19.5 - 435/493/534/569, using arch linux and just 1 month ago everything was working perfectly. I think it could be some update from Arch, but i could'nd track. I Deleted houdini home folder, and noticed that the new home folder was not fully populated and the houdini-bin process is running but is stucked.
This is the default operation for me. Always run from terminal. This is the problem, not even a tip, not a single line with an error, no crashlogs either.
there is another person with the same problem with 19.5 with no solution on houdini forum a month ago.
He tells me that he restored old versions of system, so i think theres is some update that broke something for me too.