Lewul
My only wish :
http://www.smashmycode.com/wp-content/uploads/2011/12/lenna.bmp [smashmycode.com]
Add her to the default pic !

Ha ,That's cool and very USEFUL feature
But we always know Houdini with Mandril image :wink:

I know

The modeling tools in Houdini could be a lot better. They do not play very well to the strengths of procedural modeling, and they don't play to the strengths of more destructive modeling workflows that every other package on the market employs.

While I support the idea of continuing to improve and add to the number of modeling operators in Houdini, especially a procedural bridge tool I think it would be best for SideFX to move quickly in the direction of embracing more fully featured procedural modeling workflows and not worry so much about matching the more destructive non procedural modeling solutions out there.

For example Procedural extrude [peterwonka.net] (PDF)

Procedural terrain by drawing curves? uhm YES! [youtube.com] (YouTube)

Sexy brushes loaded with procedural goodness? [graphics.tudelft.nl] (PDF)

There's more of course. Procedural modeling has made many advances over the years, especially with eyes towards usability by non-programmers. There's a paper [graphics.tudelft.nl] being presented at Siggraph this year rounding up the advances of recent years in the field of procedural modeling. There are lots of things that could be done in Houdini to make procedural modeling more powerful and more accessible.

I would absolutely love it if Houdini 14 became the one stop package for procedural world building.

On other fronts Houdini has some amazing technology that isn't quite presented in a way that makes it obvious what it's for, like the blendpose CHOP. There should be a new blendpose shelf tool (or at least an example file) for transferring one models topology to another, this is the kind of thing RBF's excel at, with a little bit of extra work you can also transfer motion vectors and it becomes even more powerful (blendshape libraries transferable between characters regardless of shape or topology). This is the kind of stuff that has to be more easily accessible.

Being able to easily bake out simulations to bones would great for games and make Houdini FX a more obvious value in game development pipelines. A flow map shelf tool or example file would also be fantastic, too many people paint those in Photoshop.

Houdini has some amazing character setup tools, especially in the realm of deformations, however it's all for film pipelines. If SideFX were to implement an example based skinning system game pipelines could also take advantage of the advanced deformation technology.

hi lyr,

well that with the mountain there is saidly not a finished asset available but the good thing is houdini has got every component to do this. :-)

just a example not 100% of that what you want but it gives a overview(the end part you will like it 16:30):
http://www.sidefx.com/index.php?option=com_content&task=view&id=2252&Itemid=354 [sidefx.com]

Yes, obviously it's not production quality work. The people who designed that solution are scientists, not artists. Research papers are rarely aesthetically pleasing.

Yes, Freek's stuff is awesome! it's what helped me renew my interest in Houdini as a game art package. Freek solved a pretty big problem for game terrain systems, and with the Houdini engine initiative his solution becomes even more compelling, which begs the question why isn't there a HDA available that does exactly what Freek shows? What is the point of Orbolt if stuff like that never even makes it up there?

There have been many breakthroughs in procedural modeling and while they are technically feasible in Houdini they are not as easy as they should be. Here's an example of interesting research in procedural modeling, with no official Houdini support Inverse procedural modeling that results in a grammar! [arxiv.org] (pdf)

How awesome would that be? especially when coupled with complementary workflows [pixologic.com] (pixologic video) from other packages like Zbrush.

These are the directions I would love to see Houdini start to move in.

hey thank you for the paper about the buildings.

interesting how it's done i think that should be pretty simple to do.. when i have got time i will try that.

just a bit offtopic but these are some nice add-on for houdini sadly not at orbolt but there are some tutorial on cmivfx:
http://forums.odforce.net/topic/19260-craft-houdini-tools-it-is-animation-tools-for-vehicles/?hl=craft [forums.odforce.net]

houdini is a such mature tool and there are so many function's that they can integrate but the resources are limited.:-/

what i hope that they add some function like photogrammetry, camera tracking, painting, film editing(NLE), so when you start working you know just on tool for your daily work… houdini :-) *smile*
just imagine just like a nuke studio but with all the houdini functions you can do everything so when something is missing just edit or modify.

r+h has done a fantasty work: http://www.rhythm.com/labs/ [rhythm.com]

In order of importance (in my opinnion):

1. Physbam integration - http://physbam.stanford.edu/ [physbam.stanford.edu] (for simulation option 2 for fast simulation option)

2. Adaptive Tearing and Cracking of Thin Sheets - http://graphics.berkeley.edu/papers/Pfaff-ATC-2014-07/ [graphics.berkeley.edu]

3. Crowd simulation tool: http://golaem.com/ [golaem.com] . http://www.basefount.com/miarmy [basefount.com]

4. Vechile simulation tools: http://www.craftanimations.com/products/craft-director-studio/add-ons/vehicle-tools [craftanimations.com]

Sure these are already possible, but i think there could be faster options for simulation (and faster way to do these) when deadline is short and crowd simulation needs own tools (sure it is possible with current tools, but i think it needs more, i think same way from these other feature/tool requests).

jumaku
2. Adaptive Tearing and Cracking of Thin Sheets - http://graphics.berkeley.edu/papers/Pfaff-ATC-2014-07/ [graphics.berkeley.edu]

This!

If it doesn't spaz on anything other than spheres & cubes…

I'm hoping that viewport selection sees some attention in H14, particularly edge selection - I'll inadvertently select an edge on the hidden backside of geometry more often than should be the case.

It would be nice to have a more minimal UI design, with simpler icons. I am suggesting a vector format for the icons for optimal display in high-dpi screens.

stu
I'm hoping that viewport selection sees some attention in H14, particularly edge selection - I'll inadvertently select an edge on the hidden backside of geometry more often than should be the case.

Remembering selections would be nice too, i.e. trying to click Group Selection and you click something else… undo, and voila your selection is lost forever.

It would be very good to see some of the older SOPs that have to do a lot of heavy lifting get multithreading, particularly PolyReduce and Remesh - and an improvement to the ability to ESC cancel operations. More than a few times I've fallen foul of the 0.1 Remesh default on complex geometry, it rarely ends well at 3% CPU load.

alexpi
It would be nice to have a more minimal UI design, with simpler icons. I am suggesting a vector format for the icons for optimal display in high-dpi screens.

I'm pretty sure the icons are already vector images that get turned into raster images when a user starts up a build of Houdini for the first time.

Not sure if any of these have been mentioned yet, but here are solid production suggestions that would have a big impact on Houdini's adoption and usage :

Mantra/PBR : Complete library of real-world materials for use with Mantra PBR (like Modo and other software has)- everything from concrete to wax to car paint to gold to brushed aluminum to skin, etc. with Pre-sets that work out of the box with real world scale. This would greatly increase the capability of new artists to create photorealistic renders that rival competing software.

LightMaps: MUCH BETTER support for lightmap baking (used for games) to bake bounce lighting/AO/shadows/textures into one texture. Simplify the process, allow lightmaps to be rendered from all rendering types (PBR/RayTracing/etc. with spec/reflections/etc. taken out of pass), support rendered lightmap texture edge dilation (helps to avoid artifacts with mip mapping) so rendered lightmaps can be used directly in game without any post processing

Normal Maps : Support industry standard Tangent Space Normal Maps (and Object Space Normal maps) in ALL Mantra materials and SHOPs. Any artist should be able to bring in a ZBrush/Mudbox/Modo model with normal maps and render it immediately in Mantra without a ton of headaches. Introduce tools for creating these normal maps from Houdini geometry so complex procedural geometry from Houdini can be baked out as low res game geometry with high-resolution Tangent Space normal maps for detail.

FBX: Better pre-sets and documentation for getting FBX out of Houdini and into other software- especially game engines like Unreal and Unity. Perhaps options to move Point UVs to Vertex UVs, etc. and the other things that work better for FBX export. This will help reduce the frustration many game artists new to Houdini experience and help adoption.

Game Pipeline : Basically I want to be able to model, render and export from Houdini and use it right in a game engine. This means lo-res geometry, Tangent space normal maps (that preserves detail from high res geometry), high quality pre-rendered lightmaps, and solid FBX out of Houdini that works without a lot of post-processing in other packages or headaches.

DOPS: Simplify standard things like adding simple air/wind/turbulence (with improved visual feedback) to DOP simulations for new users (it can be a little confusing and difficult for new users when this should be easy). Make DOPs tools/presets/demos with consistent real world scale and settings and production ready (works well, looks great, renders great) with simple to use fast lo-res and slow hi-res options.

Windows support : Windows directory supporta little wonky- like backslash/forwardSlash and getting to network drives- can this be improved to work as well as most other packages do?

I'm trying to build a simple massive asset in houdini.
I want to use instance for each agent, but instance doesn't support different sop deform, and if i insurance multiple objects to points the viewport can't display.
So i instead it with copy, the only problem is slow, if it's multithreaded(maybe other deform sops and chops should multithread tighter) it would 10times faster.
So my wish is more powerful instance and faster copy.


And i found mantra writes many times to disk during rendering one image, i guess is it not good for disk ? Is there a choice how many times it write. Just my guess :wink:

alexpi
It would be nice to have a more minimal UI design, with simpler icons. I am suggesting a vector format for the icons for optimal display in high-dpi screens.

Already is the case…
After a find ${InstallDIR} –exec grep -i svg {}\; I saw


${InstallDIR}/houdini/config/Icons/SVGIcons.index

has obiously everything needed. Just had a peek with a HexEditor….

So…where are the siggraph sneak peeks at H14?

Yes, anxious to see what you guys have done 14!

Or do we have to wait for Unite?

Yes! also looking for the sneak peeks!
c'mon!

luoqiulin
I'm trying to build a simple massive asset in houdini.
I want to use instance for each agent, but instance doesn't support different sop deform, and if i insurance multiple objects to points the viewport can't display.
So i instead it with copy, the only problem is slow, if it's multithreaded(maybe other deform sops and chops should multithread tighter) it would 10times faster.
So my wish is more powerful instance and faster copy.

Instances have to have identical topology in Mantra (and other render engines). The moment one of those “copies” has a deformation, even a single point deform, you no longer have an instance.

These days in H13, if you can't keep your geometry as a packed primitive type (either as an alembic or packed delay load primitive) through the Copy SOP, you can't use instancing. Even applying a displacement shader at render time will force that geometry to render uniquely in most render engines.

The answer is in the above paragraph: Use packed primitives to feed the left input of the Copy SOP. If you can get by with 20 (or whatever number of) variations of pack primitives and switch between them to get enough variation, then you will see a big speed-up. Packed primitives = instancing.

luoqiulin
And i found mantra writes many times to disk during rendering one image, i guess is it not good for disk ? Is there a choice how many times it write. Just my guess :wink:

Not enough info to give you an answer here.

A very simple idea: Make Particles the default visualization type for liquids (instead of sprites).

If working with liquids, changing the visualization type is always the first thing I do and I know I'm not alone with that.