I dont know what seems to be the problem.

All is working as expected.

My tutorial is a little dated and the Fur module has received a lot of updates, though my method is still viable. There are some parameters that have changed so maybe an amendment is in order for H14, but H15 is fast on the horizon.

I'm crossing my fingers that the new fur tools which are difficult to work with have been improved.

I replaced your external curves with a locked nulls so it is all in one file. And your sphere is just a Houdini one.

edit/ oh i know what was wrong. Your file sop for the curves had a number suffix, and Houdini reads it as curves_$f.obj. You had Show sequences as one entry checked when importing the geometry and so the File parameter still has the path with the $F in it. Can't tell you how many times this has happened to me.

I think the frustration is really rooted in the balance between artist and technical uses of any particular tool.

I can be 100% sure that this tool could be re-written to work more like a feature in any other package ie opaque as mud.

The transparency of the tools that SESI provide is refreshing to say the least but that transparency can come at a cost.

And when the best workaround is to learn HDK, that isn't the most practical solution, especially for a more artistically driven task.

It is and probably will continue to be a constant struggle on SESI part but i think one that will benefit both parties (you need a technical userbase as much an artist one ).

In my humble opinion of course .

Ahh cheers

Maybe this video might help to show what i want. I would like the VOP COP ramp to drive a Ramp in SHOP's.

https://vimeo.com/120380455 [vimeo.com]

I tried out what you recommended. Still for me, the interactivity is still tough to deal with.

The old way combing simple normals for fur direction was blisteringly fast. And I hate using another app but blender for shaping complex styles is fast and precise.

Maybe the next iteration of this system will prove more usable for my needs, im sure they will prove me right and I'm sure others will find it perfectly fine to fit with their workflows.

Hey guys, hope you can help me out, i've been looking for a while on this subject but it is hard to search for.

Is it possible to have a ramp VOP say in the shader context reference or be reference by a ramp in another context, namely VOP COP Ramp or even SOPs.

I've been trying to make it work but it is a dead end for me.

Hope this makes sense.


-andrew

You don't suppose you could get your studio to release it secret tools to me, i won't share it, promise.

I while might not share the same tone i agree with the sentiment. I have spent a lot of time trying to make it work, with unsuccessful results sadly. :cry:

Also some very nice work with the hair shader. Very pleased with it. Just a very quick test.



Also very fast, this was raytraced.

Thanks Daniel, i tried this but it is not working. Perhaps i am doing it wrong?


The guides will turn blueish with pre-highlighting, but the tool wont respect the selection.

So i have been playing with the new Hair tools. Lots of fun and really clever implementation. But when it comes to making something precise i run into two problems.

Speed and control.

It was advised in the demo videos to use multiple fur objects for different portions of hair. But I am finding it difficult to make strands overlap or just control one strand independently without affecting the others.

In essence what i am looking to do is some sort of on-the-fly masking, where i can select a strand and the new stroke SOP will only be able to control that strand. Is this possible right now, maybe i am missing something in the new selections options?

The other is speed/interactivity. Maybe it is my system and card which is pretty old and not brilliant, (GTX 670 4gb vram ).

I have seen it been mentioned that i should turn off realtime stroke but then i lose interactivity which is pretty essential.

Btw the settings at asset level update very fast though and the dynamics soo nice, amazingly smooth/interactive.

-andrew

The interactivity is a massive improvement.

Using the blendshape sop it felt faster but using a attributeVOP to accomplish the same task, 30k poly object had no problems. And i suspect it will be faster still with a wrangle node.

I will always be looking for the Blendshape SOP & Sequence blend to evaluate faster.

(even if you convert the file sops into edits with the hscript function sopcreateedit, which is meant to make the blendshape evaluate faster since it only stores the deltas).

H14 is faster than any other version but still falls short to Maya in terms of responsiveness with meshes around 20-50k polys.

Also if there was something like Daniel Pook-Kolbs Blendshape Combination system (http://dpk.stargrav.com/pafiledb/pafiledb.php?action=file&id=31 [dpk.stargrav.com]) that would be amazing, it might be outside the scope of what Houdini usually focuses on.

It is very generous of you to share the scene. Cheers.

Very nice.

On the subject of your facial controls.

The problem i always have with these types of rigs is there are so many channels to keep track of.

They are super intuitive but in the end i always opt for controls Inner Brow Up/Down etc instead of curves that have separate XYZ channels. Problem is using Set Driven Key (ala Blendpose or Lookup chop isn't as intuitive as it needs to be and some scripting effort is required to make it more automated/streamlined).

Are you using any Set-Driven-Key-like setups in your rig?

I dont know if this had been added but i would love if scoped parameters (channel box) would allow a drag selection like in Maya.

LMB in one box and drag up and you have no selected a bunch of channels and then enter a value and it applies to all of them.

You can multiselect but it is not as easy as i have described. Also using the ladder slider is way to many clicks in the scoped parameters. To click in a channel and drag to increase/decrease a value is very useful but to click then select how much you want to increment and then drag adds a layer of complexity and removes speed from most situations.

Just my little two cents.

Thanks for the comments. Even though this is an old project i did some test renders with Dany Bittel's Skin Shader available in the orbolt store.




Full Rez [lh3.googleusercontent.com]



Full Rez [lh5.googleusercontent.com]

I bugged it about a month ago after the Fur tutorial. Bug #60736.

For now you can setup a custom display marker using the “furdirection” attribute if you are using it for fur.

The chf() is hscript if im not mistaken. The Lookup chop is the node version of the chf() function. It's functionality can also be replicated with the Blendpose chop.

I think andrej22 is talking about a shadow matte material.

stu
I used to LOVE the model SOP for it's ability to put things down quickly in a singular workspace- proceduralism went out the window, but it was a small price to pay for the fluidity that it afforded. My nostalgia for the model SOP was routinely met with eyerolls from the sidefx faithful.

I found that over time I was spending far too much effort trying to keep my models procedurally viable and that in a lot of ways the cost outweighed the benefits. In my experience it's often easier to make changes at the end of a chain rather than to search up the chain to make a change and then to make sure that the changes are non-destructive at the end of what might be dozens of SOPs. That said, I find that the working in non-procedural sub-assemblies and then combining the results live is a good way to keep the flexibility that a procedural workflow provides while not being a slave to it.

I have found a lot of success modelling in a modular fashion. But even then there are just decision that need to be destructive. I think the best style is a hybrid. No on bats an eye with procedural shaders being assisted by bitmap textures. I think of modelling in Houdini the same way. Have a procedural base, then destructive on top and then alternate where you needs fit. Of course i would love those destructive parts to be in one node.

Another problem with using locked nodes is it deletes history of the whole chain, it would be great to have a string of nodes, then some destructive modelling on top that then gets baked to one node after the procedural portion of the model. So i can still make changes.