I just tried a toy test adding an ikchains sop after the full body ik solve and I do seem to be able to add additional twisting afterwards using that method. Just delete the tip point from the full body with a delete joints and use that as the goal and create your own twist point to feed into the ikchains sop.
Maybe there's an easier way….

Would it be possible to layer the twist on top after the full ik solve?

jsmack
Opacity and transparency are two unrelated concepts. Opacity makes an object allow rays to pass through it, and the degree of opacity determines the proportion being blended. Transparency is really transmission, it enables refraction which samples objects behind the surface with a ray bend according to the index of refraction. Transparency=raytracing, Opacity=compositing.

So if you want to composite something Transparent is there are “correct” way to set the alpha channel?
I guess want you need to know is if a ray hot something in the scene or not. Is that available as an export?

Historically Nvidia cards have always been more stable than AMD with Houdini. Did you ever take the plunge and try it?

2 interesting announcements at CES
1. Autodesk will have Arnold rendering accelerated by RTX cards
2. RTX laptops coming 29th Jan

https://www.nvidia.com/en-gb/geforce/gaming-laptops/20-series/?url=https://www.nvidia.com/en-gb/geforce/gaming-laptops/20-series/&ncid=pa-pai-70739#cid=Paid_GEFORCE_UK_20190107_Google_Search_2060_Laptop

Any plans for mantra to support Nvidias new raytracing gpu's?
I see that Arnold is going to be.


https://www.youtube.com/watch?v=57D0xJRkxrc [www.youtube.com]

https://nvidianews.nvidia.com/news/nvidia-reinvents-computer-graphics-with-turing-architecture [nvidianews.nvidia.com]

Do you have any tuts on baking normals in a format suitable for use in Unity. When I simply bake N into a separate plane, there is no default option in the baker node to do so, the result is entirely different to what I get when I bake N from a high res mesh using Substance designer. The Houdini one doesn't work in Unity for shading.
I guess you have to roll your own shader to do this, but that seems to negate the point of having the bake renderer?

As long as you use the vertexsplit sop first as directed above…

Of course this assumes you have vertex uv's in the first place, not point uvs. Though I would assume if you have seams then they would have to be vertex uv's to start with.

You can promote back to vertex uv's after the polyreduce and re-fuse the points if you need to.

Actually you can pull the same trick replacing the remesh with polyreduce. But you need to turn on prevent cracking.

Try this…

1. Add a vertexsplit sop and set it to uv, then turn on “Promote to Point Attribute”

2. Add a remesh sop and play with the values to get the mesh detail you want.

UV's should be maintained in this process without any seems. You might find they get a bit “wobbly” if you reduce the mesh too far.

The results will depend a lot on the type of geometry you are reducing and the type of map and existing uv's on it already.

Not to say that you can't do it now in Houdini but it does take some setting up that could be avoided.

Objectmerge all objects into one, edit there, objectmerge back into all the source objects.

Easy enough to setup as a shelf script but much cleaner if it were built in.

Korny Klown2

Simon
When you get more used to the joys of procedural workflows you will see the benefits too I hope.

Who said that I don't do so?

You did :wink:

Complexity and fine detail is not what procedual workflows are aimed at

Well that's precisely why I described in detail how we combine both worlds of destructive and non-destructive method. Both have strengths and weaknesses. And being able to run some procedural methods throughout a destructive process for complex modelling is where you get big gains.

When you get more used to the joys of procedural workflows you will see the benefits too I hope.

jeff

Simon__hayes wrote:

I was surprised that modelling in Houdini is also pretty destructive (i.e. the edit node has no history.) some sort of history in the node would be nice.

+1
It would be great if the edit node would have a stack of edits, like the attribCreate SOP can create multiple attributes. The edit node should automatically create a new editlayer everytime it recognises a different selection and when it recognises a modification on a group/selection that is already existing then it adjusts that editlayer instead of creating a new one.

Another great point. Trust me when I say this has been hashed over many times.

Once you use the Edit SOP, you are now set on a course where you can no longer re-sort the input geometry. This makes each individual step within the Edit SOP self-contained. Currently it just saves a list of deltas on the input points. If you shuffle the input points, it doesn't know how to re-marry those deltas. What happens if an input point is actually deleted? Edit is blind to this so it is no longer valid.

Is it faster to navigate a tree of say 100 edit tweak nodes or just grab the point and move it? After just 5 minutes of editing, you can easily get up there.

In practice, it is quite easy to tab-type add a new Edit SOP and continue editing in turn. It is common to carve your object in to parts, work on each part then merge everything together at the end. There aren't too many of these strategies either. It's either fan out then merge to keep some things procedural or layers on layers.

This means you are now plowing ahead straight-up modelling adding successive operations as you go.

There is of course a way around the issue of changing geometry upstream of an edit sop and still have it work even if the input numbers change but it would need a very fundamental change to the houdini sop networks. I think I wrote a thread about it many, many years ago. Basically you need the nodes to create a permanent attribute that isn't the point, vertex or poly number for the modelling sops to work on. That way even if the point or polygon is deleted or re-ordered the edit sops can continue to use the unchanged attribute value to apply the edits by. Of course this carries a large over head and I don't know if there is enough benefit to it to make it worth while implementing. But I put it out there for your concideration again.

My personal/team approach to modelling in houdini these days especially with poly modelling is to work in stages. Each stage contains procedural and non-procedural elements and when you reach a “significant” point in the model you write out a new stage to disk and read it back in again. You are then free to do more destructive/non-destructive modelling at the next stage and move on. So something like versioning of code.

This leaves the possibility of going way back in the history open, say if you need to add an attribute very early on in the process but that also doesn't hamper you by forcing you into either destructive or non-destructive modelling exclusively.

Maybe there are some helpful work flows that could be added around this approach that make this hybrid method even more useful.

The one thing we find tricky is maintaining groups and attributes when adding new geometry into early stages. For example by stage 2 you might have 10 useful groups or attributes that will be needed by stage 10. However at stage 5 you need to delete a small chunk of the model and rebuild it for some reason. You then have to reconstruct groups that were part of the removed piece and that can be somewhat time consuming and fiddly. Of course building small custom otls can help here but maybe more can be done…. visualising existing groups in the viewport… not sure, just spit balling.

Long time request, maybe with some pressure from you guys and the desire to update the modelling set this will finally come into the land of the possible

edward

MartybNz
The main disadvantage is Subnets nests the nodes away- it's just one small step up from hiding nodes with shift-D. A goal is to go way beyond that to add efficiency and bring much nodal delight.

The only real differences between the concept of netboxes and subnets are that netboxes do not modify the path to the nodes. For the cases that the “delete history” feature is desired, I cannot see why that matters. Don't get me wrong though, I'm all for better implemented netboxes. However, I don't see how we do not satisfy the “delete history” people 100% today.

Perhaps this has only been implied thus far, so let me make it clear (mostly for McNistor). The workflow problems that “delete history” purports to solve are:

• Performance, and
  
• Complexity (Out of sight, out of mind)Collapsing nodes into subnets solves (2) and locking the subnet solves (1). Furthermore, collapsing subnets improves upon “delete history” in the sense that it is undoable because history was never actually deleted. And it is ok to have these nodes exist in your scene because they're lightweight behind the locked subnet since they do not cook.

• 
  When you dump stuff into a subnet on the one hand it's very useful because it allows you to work on one small part of your network. The big downside is you lose the ability to easily look at that part of the model in relation to all the parts outside of the subnet or even over in other subnets.
  There needs to be a way to template stuff outside the current subnet so you can still “see” it for reference.
  
  The downside to network boxes is when you collapse them to hide nodes you end up with huge empty spaces in your node layout that have to be left in case you want to re-expose the network contents. Making it hard to navigate between the nodes you actually want to work on.
  
  You really need some sort of “layers” system where you can arrange nodes in different configurations. I.e one with everything exposed and one with mostly everything hidden. Then you can toggle between node layouts.

Ok it's getting late and there is no way I'm going to read all 19 pages now so forgive me if there is any repetition here. As a long time Houdini user and modeller these are my top picks that I would like to see addressed on top of all the stuff about selections and loops that I have read so far.

Sculpting
1. A sculpt mode that allows points to be pushed along edges.
2. A relax sculpting mode than doesn't hit smoothing limits like smoothing currently does.
3. A sculpt mode that lets you push points in x,y,z or parallel to the viewport.

NURBS
Sort out the join and reverse sops so that when you join to 2 NURBS surfaces that aren't correctly aligned in terms of UV parametisation that it does what you would expect all the time and you get good clean joins between surfaces with no folding or things connecting to the wrong edges.

Polgons
A decent tool for manually building lots of polygons from scratch. Not the curve sop, and not the poly stitch sop. Something a bit more intuitive and powerful.

That's it for now, I'm sure there is more….

Not much to add here yet, coming to the party late and having 19 pages to catch up on, but just wanted to chime in and say how great it is to hear there is new motivation to improve the modelling operations. Been waiting for a long time to see this area get some love

Yes I hope it gets some more love soon. They got so far with it, it's not missing much. But with VEX improving that does help, just not in this instance. I'll just have to roll my own function.

they only seem to be available for curves, i.e you can only specify “u”

Unless it's undocumented?