I know it's frustrating. Modeling tools are still not 100% where we would all like them to be. You can file RFE's and wait for the fixes to get in or you can just buy DM and get on with your work.

Threadripper. AM4 socket is going to be supported for a long time, and if prices on future threadrippers drop as drastically as they did for the 19xx series you are going to have some great, easy upgrade options for the future.

mandrake0
There is no prodution ready Ai denoiser made with opencl. So it makes sense to implement this one. To develop you own takes a lpt of time or when you want to use tensorflow you will end up the same it has only cuda support.

You are correct that there is no OpenCL denoiser for production yet, however Tensorflow is now available free of Cuda https://rocm.github.io/index.html [rocm.github.io]

Given the current state of things I guess it's better to have a Cuda denoiser than no denoiser.

Olaf Finkbeiner
Vellum is looking just amazing. And i am realy looking forward to easier setups of the constrains. One solver for cloth grains and wire is great to say the least. I just hope my GPU (1070) is good enough.

For Vellum your GPU probably won't be, Nvidia GPU's are notoriously bad at OpenCL. You will however be fine denoising, since that uses proprietary Nvidia tech.

I am more than a little perplexed why SideFX chose to suddenly go down the CUDA route for denoise, especially given how much OpenCL is already a part of Houdini. I always had the impression that SideFX preferred open standards to proprietary technology.

I just moved to the frontrange. There are some indie game developer meetups I have been do, and Boulder Digital artists does stuff on a weekly basis. We could use one of those meetups as a pain free way to gauge interest and then start our own if it's warranted.

fuos
OpenCL on Mac is very good on AMD cards but on Nvidia and CPU it is very bad. The Vellum OpenCL solver could be totally unusable if it has the same characteristics as the other DOP solvers for non-AMD Macs.

Hopefully Radeon Instinct comes soon and is a viable option for the Mac users in the Houdini community.

OpenCL accelerated solvers is awesome, GPU accelerated denoiser is awesome. Proprietary API's forcing vendor lock in are not awesome.

Windows shits the bed with high thread processors. You should really consider switching to Linux as your processor is being wasted in Windows.

Better NURBS would be awesome, I also agree that modeling from curves does have more strengths for procedural modeling than Subd's.

Depending on where you are at, you would be better off going with a workstation card. All the gaming cards are massively inflated in price right now.

Check your library Gilly262 the text of what you purchased will be there.

CHOPS

The mech you posted should be doable in Houdini, depending on user experience level Especially if you lean on decals.

You don't need substance designer if you are getting Houdini. If you are on a tight budget and can not afford additional software for organic modeling I encourage you to look into the volumes tool set Houdini has and consider a different approach to organic modeling that isn't trying to make several hundred watts of electricity behave like wet dirt.

For an AI based animation system like I think you are talking about, stock UE4 isn't going to cut it. You will be writing a completely new solution for AI from the ground up. The only AI tech that unreal ships with are behavior trees, which are ancient by today's standards. What you want is something called Utility Theory AI, which to my knowledge does not exist in any form for UE4, but Unity has a few implementations available through the asset store.

Character deformation in a game engine uses linear skin weights. They are efficient and easy to get good enough results with. Muscle systems are not resource efficient from the point of view of games development, and likely never will be.
There will always be better things to dedicate resources too than muscle simulation in games. However there are a few methods of converting complex simulations to linear blend weights: http://lesterbanks.com/2015/06/check-out-webber-huangs-deformation-learning-solver-in-maya/ [lesterbanks.com] Maya has this solver natively now. Hopefully SideFx with their superior deformation and simulation technology will follow suit and implement it in Houdini as well(I've RFE'd various forms of this technology for years now).

No, you do not create an AI based animation system in Houdini for a game engine, you do that in the game engine itself. Out of the box muscles are not useful for games either. You could make a plugin/asset for decomposing the point deformation to linear skin weights, but that functionality is not part of the base Houdini package.

Game art must serve gameplay. Given that, Houdini is an ideal tool for game art. Good digital assets working inside your engine will allow you to iterate on game design in a way that is simply not possible with any other tool. For a game that takes Super Mario 3d world as it's inspiration this kind of capability will be extremely important.

Houdini is a very different tool from Lightwave and will initially be very frustrating, but as others have said just ask the community.

Once you have a handle on the basics of Houdini I highly recommend these videos: https://cmivfx.com/products/108-houdini-procedural-road-creation [cmivfx.com] https://cmivfx.com/products/110-houdini-procedural-road-creation-2 [cmivfx.com] While those two videos focus on roads, the techniques show can be used for a wider variety of structures. Most of what you see in super mario 3d world (not the characters) can be done with the techniques shown in those videos.

Making a procedural sword model that targets extremely low, 300-400, triangle counts. Geometry is fully procedural, so are the UV's. Each of these weapons took minutes to make, all the time was spent on design decisions only. UV layout needed a few minor tweaks with a transform node, no clicking on individual points or UV's though.

The texture was done in substance, but I am investigating how to move forward with procedural texturing in Houdini.

This kind of thing takes a little more work to set up in Houdini, but once set up it's set up and doesn't break.

Here are some orbolt assets that simplify this task https://www.orbolt.com/asset/AlexeyVanzhula::rebound [orbolt.com] https://www.orbolt.com/asset/AlexeyVanzhula::alignBB [orbolt.com]

I also attached a hip file showing some basic pivot editing and translation. The bbox() expression and local variables can be substituted with point() instead.

Yes, you can proceduraly bevel the result of a boolean. Make sure to output groups from the cookie sop, use those groups in the bevel sop. The high resolution your polygon objects the smaller your bevel has to be.

ndickson
I hear ya. The biggest difficulty with adding support for exporting Houdini's blend shapes to FBX is that Houdini's blend shapes support is *much* more general than FBX's blend shapes support. We'd need to have code to identify when a network happens to have exactly the right setup where it can be exported, and it'd fail in the vast majority of possible setups, so we'd need some way of trying to determine and then indicate to people what they need to change in order for it not to fail. Alternatively, we could slap together a bunch of heuristics to guess what might be closest, (which would also be a lot of work), but then it'd get into a mess of “Why doesn't this look like it did in Houdini?” Either way, there would still undoubtedly end up being some remaining differences.

If you really want it, though, please contact support to get added to RFE #70989 for FBX export of blendshapes, (unless you're already on it), and discuss recommendations there.

A general skinning decomposition toolset would let people convert blendshapes to skinned joints for export to game engines. It would let people convert any mesh animation such as cloth/FEM to joints actually.