Look here:

https://github.com/sideeffects/HoudiniEngineForUnreal [github.com]

Be sure to change to Houdini 16, Unreal 4.15 branch

So one of the things I'm most excited about with H16 is the new HAPI 3.0 for the Houdini Engine. What kind of improvements / additions can we expect? I haven't been able to find any details about what's new.

New information. Looks like the Polyknit viewport tool is only letting me select points that are already part of a primitive polygon. Points by themselves are unselectable. Not too terribly useful.

Was playing with the PolyKnit tool in the viewport and quickly came to the realization…it doesn't work at all.

It asks me to left click a point and hit enter to begin. It won't let me select any points. If I hit enter, it says to shift+left click to continue. When I do that, it asks me to select a point and hit enter again. It won't even create the PolyKnit node.

Manually adding the node and specifying the point list works as expected.

Houdini: 15.0.392
OS: Windows 10
GPU: NVIDIA GTX 670 driver 361.91

You have the pricing backwards. Houdini Indie is $199 and the Houdini Engine Indie is $99.

Houdini Indie ($199) includes the Houdini application AND the Houdini Engine. The Houdini Indie Engine @ $99 is the engine only.

Houdini Indie Engine would only be appropriate for using Houdini assets already created by someone else. If you want to create your own assets you need the full Indie license.

As another mentioned, there's also the Free apprentice version for learning the application and creating assets. However, the UE4 plugin requires at least the Indie version.

Reading over the release notes for the new nvidia 361.75 drivers (http://us.download.nvidia.com/Windows/361.75/361.75-win10-win8-win7-winvista-desktop-release-notes.pdf [us.download.nvidia.com]), I saw this line under Windows 10 fixes:

"Adobe Illustrator CC 2015 has TDR and subsequent crash with NVIDIA drivers higher than Release 353. “

I know Illustrator is an OpenGL based program, and it sounded similar to the issue I was having with Houdini…

I'm happy to report that 361.75 seems to be the first proper Windows 10 driver that hasn't had TDR crashes working on complex Houdini scenes!! I even tried increasing the multiplier on my ”grid_ultra" sop from 4 to 5 which added another 10-15 million polygons and could still render to the viewport just fine.

Excellent, that's all I was hoping for. I'm sure you guys would have a lot more influence contacting nvidia to get this resolved than I ever could.

I was able to render it fine, even on my older, much slower 120gb ssd hosting the page file. Using driver 347.88.

Now I have a Samsung 512gb m.2 NVMe SSD with an insane 2.5 GB/s read speed and 1.5 GB/s write speed at ultra low-latencies (<2 ms). It's random IOPS are equally impressive. It's about as close as you'd be able to get to having everything in DRAM memory. It still doesn't work with the newer drivers, only 347.88.

Like I said, I've gone up to over 200GB of pagefile use on other projects on driver 347.88 no problem.

mtucker
That's a pretty heavy file… Good thing I got a new machine today because my 16GB laptop runs out of memory trying to cook the scene. On my new machine it maxes out around 45GB. Is it always big scenes that lead to crashes or is there a smaller setup that can show the issue?

Are you getting the full machine crash (blue screen of death)? Or is it just Houdini crashing? Are you aware of the driver “hang detection” on Windows, where if the driver takes more than ~2 seconds to complete an operation, the system assumes the driver is deadlocked and crashes the process responsible? There is a registry setting that lets you extend that timeout, if you think that might be part of the problem. If you're getting full system/kernel crashes this is not the problem…

Also if you have any crash logs generated by Houdini you could post here, that may help too.

Thanks,
Mark

Could you clarify whether you were able to reproduce the crash on your new system?

Indeed, it's fairly heavy but I have 350GB of page file on a super fast m.2 SSD so it's no problem for me . With the 347.88 drivers I've rendered landscapes with hundreds of millions of polygons and 200GB+ of memory used no problem.


What seems to trigger it is the amount of time it takes between the end of computing the node chain and displaying it to the viewport. So, typically that would mean a lot of polygons but I'm sure there are other ways the viewport rendering could be slowed down. It was the same story in Substance Painter. If you made a complex layer change at high resolution, it takes a while for it to get updated in the viewport and would cause a driver crash-and-recover.

It's not a blue-screen-of-death, it's an nvidia kernel level driver exception that it's able to recover from, but causes houdini to crash. I am aware of the hang detection, it's the TDR timeout I mentioned before. That was discussed on the substance thread, and it's really only a band-aid, not a solution. I've tried messing with the TDR registry settings extensively and they didn't seem to help much. I think the way TDRs are handled was changed fairly significantly with the new WDDM 2.0 driver architecture introduced with Windows 10.

Ok, here's a zip with a Houdini project that reliably causes the kernel exception crash on my nvidia driver. Running Houdini Indie 15.0.360 with the latest nvidia drivers (361.43) on a GTX 670. The crash happens after the node chain finishes computing, but before the output is displayed in the viewport. Note that the Update mode was set to manual.

You may recognize it, it's from the Side Effects Terrain Generation tutorial

Mark,

Yea the nvidia drivers that the Windows Updater installs have had problems. I was aware of that, and have been using the tool that Microsoft provided (https://support.microsoft.com/en-us/kb/3073930) [support.microsoft.com] to “hide” those updates and prevent the Windows Update from overwriting my currently installed drivers.

I've tried 355.60 and many other drivers, doing a clean install each time. They all crash in the same way. I've even gone back and done a fresh installation of Windows 10, but to no effect. 347.88 seems to be the latest that doesn't crash. Again, this exact situation happened with Substance Painter (which is also OpenGL based) as I linked above. 347.88 worked fine, newer drivers would crash with TDR timeouts. Allegorithmic got in contact with nvidia and new drivers were released within a month that fixed the issue. Maybe some programming changes needed to be done in the software as well but they seemed to indicate it was entirely an nvidia driver issue.

I'll see about getting a file to reproduce the issue on here within the next few days.

I'd be willing to provide SES with a hip file that reliably causes the driver crashes for me. I'm an Indie user so I can't file it on the RFE server. Just let me know where I can send it…would love to be able to go back to using the latest drivers!!

EDIT: Appears to be fixed with the latest 361.75 drivers!

So after upgrading to Windows 10 I have been getting regular driver crashes on complex processing, unless I revert to fairly old drivers. It is a kernel level driver crash from the OpenGL driver.

I don't even think this is a Side Effects issue so much as a Windows 10 / nvidia issue, but I hope that by bringing this to your attention you might be able to work with nividia to get the issue resolved. The same thing happened with substance designer as seen here, and Allegorithmic was able to get nvidia to release drivers that fixed the issue with their software: https://forum.allegorithmic.com/index.php?topic=6160.0 [forum.allegorithmic.com]

The only driver version I can get to not crash is 347.88, which isn't even a proper Windows 10 driver, it's for Windows 8.1.

I believe it has something to do with the new WDDM 2.0 driver platform that was introduced with Windows 10, that nvidia started using with the 35x driver series.

Are you building from source?

I had to modify the two *.Build.cs files so that the bIsRelease variable was true instead of false. Otherwise the include path for the HAPI directory does not get set and my compiles were getting errors.

ttvdsfx
Unreal static mesh generation does not work in Game mode - only in Editor, that code lives in the engine itself, not the plugin. But I believe this is solvable.

I'm not sure how robust or complete it is, but I believe Epic added support for procedural mesh creation in 4.8 and probably will continue to improve it with 4.9 and future releases. Maybe you guys could collaborate on ways to improve compatibility between Houdini and their procedural mesh systems?

https://docs.unrealengine.com/latest/INT/BlueprintAPI/Components/ProceduralMesh/index.html [docs.unrealengine.com]

This was brought up in another thread. The answer is that H15 builds are coming fairly soon.

Good to see that modeling tools and interfaces are getting some updates in H15. I like the attitude about covering more of the pipeline. Gives me confidence that SideFX is taking game development workflow seriously. As much as I want to go solely with Houdini, at this point the interactive modeling tools just aren't nearly as good as they are in pretty much any other 3d modeling package. But it looks like H15 is starting to address that, very excited!!

So now the question is, when can we get Houdini 15??

That's great news. I've seen on the github that a lot of work has been put in over the last week or so. Being able to work more directly with the HDAs should definitely speed up workflow. Great work!!

I typically jump from version to version early on because I like to experiment with the new features. I don't work on big projects so I have no reason not to upgrade my engine version. I don't bother much with the preview versions though, I like to stick to the full releases.

4.8 is a big release, and it deprecates a lot of old code at the same time. So I doubt it and a lot of other plugins will compile without a fair number of changes. But hopefully things, at least API wise, start stabilizing after 4.8.

I think you guys should strive to support each major revision like 4.8, 4.9 etc, but not worry so much about the minor releases in between. Most of the time the source code should still compile on newer minor versions.