Actually I don't get the difference but I'm not a rigger anyways. Isn't a bone more or less just a joint that visually represents the rotation axis / ik goal it's aiming at? But if I'm wrong, how does an ik chain work if you don't have a axis which points at the next element in the ik hierarchy?

Sygnum
Actually I don't get the difference but I'm not a rigger anyways. Isn't a bone more or less just a joint that visually represents the rotation axis / ik goal it's aiming at? But if I'm wrong, how does an ik chain work if you don't have a axis which points at the next element in the ik hierarchy?

It depends on application. This seems to be the case with Houdini, but bones sometimes get additional “convenience” features, like head and tip instead of ordinary rotation, or the ability to be bent. Bones are always specific to the software, “a joint” is just another way to say “point in space with geometry bound to it”.

I think the other point that bears mentioning here is that typically in joint vs bone-based systems you'll have an ‘end’ joint that simply delineates the end of the chain – so an IK solver (for example) can just look at an internal representation of the points and generate the matrices that would be needed for the IK solve (this is likely quite similar to the null-based hierarchy suggested by the docs. I do agree though, that you'd want to ensure a proper output of the joints to i.e. a game engine. If you're using something like unity you'd still want that end joint if you were doing any dynamic IK in-engine.

I should preface all of this though with saying I'm just now starting down the road of using houdini for all of my asset work, we'll see how the next few weeks pan out for appropriate workflow

anyone here heard about “NanoVDB” in houdini 18.5?

from nvidia blog you can read that they mention it:

https://blogs.nvidia.com/blog/2020/08/25/nvidia-siggraph/ [blogs.nvidia.com]

“With NanoVDB being added to the upcoming Houdini 18.5 release, we’ve moved the static collisions of our Vellum Solver and the sourcing of our Pyro Solver over to the GPU, giving artists the performance and more fluid experience they crave,” said Jeff Lait, senior mathematician at SideFX.

“ILM has been an early adopter of GPU technology in simulating and rendering dense volumes,” said Dan Bailey, senior software engineer at ILM. “We are excited that the ASWF is going to be the custodian of NanoVDB and now that it offers an efficient sparse volume implementation on the GPU. We can’t wait to try this out in production.”

“After spending just a few days integrating NanoVDB into an unoptimized ray marching prototype of our next generation renderer, it still delivered an order of magnitude improvement on the GPU versus our current CPU-based RenderMan/RIS OpenVDB reference,” said Julian Fong, principal software engineer at Pixar. “We anticipate that NanoVDB will be part of the GPU-acceleration pipeline in our next generation multi-device renderer, RenderMan XPU.”



so if anyone can expand on “nanoVDB” it would be great

This is a good overview of what NanoVDB provides. nanoVDB starts at 9min
https://www.youtube.com/watch?v=VJBv9lh5kqg [www.youtube.com]

I got word that Sidefx decided that H18 is perfect now and needs no updates anymore :-D

Actually, looks like it is 18.6.2 already (https://github.com/sideeffects/HoudiniUsdBridge)

matozembery
Actually, looks like it is 18.6.2 already (https://github.com/sideeffects/HoudiniUsdBridge)

so houdini 18 should have three versions - 18.0 18.5 18.6?

Can't wait for H18.5

animation solve for topotransfer would be very good.

n2e
Universality.

I was having in mind something that's related to the 3d program itself, not compatibility. So to rephrase the question, is one system inherently better than the other, ignoring the compatibility issue?

The latest 3Delight update, released today, says it's compatible with the 18.5 beta branch. Something's happening!

Redshift3D has H18.5 support as well, for about 3 weeks now.

So, my guess is, some H18.5 Beta users wanna test 3Delight, so they added H18.5 support.

Finally coming soon…

This waiting is getting more nerve wracking than the first moon landing!!

It feels like we might get a more mature version of Houdini this time around, I‘m really curious!

citizen

n2e
Universality.

I was having in mind something that's related to the 3d program itself, not compatibility. So to rephrase the question, is one system inherently better than the other, ignoring the compatibility issue?

There's no such thing as “better” or “worse” in terms of engineering. There is only “does it fulfill it's assumed role?”. Which is, of course, strongly dependent on the assumption. To me bones/joints are a simplistic method of deforming models for animation, you could probably throw them away long ago if they weren't useful for compatibility reasons. So yes, assuming that compatibility is the main purpose of bones/joints, the more compatible is inherently better.

“Multiple small bug fixes for upcoming releases.”

It's around the corner , that what I thought also , but it says releaseS that S might be tricky.
It's been 3 days of no bugfixes, silence before storm ? I don't think so. I think it will continue till 600-650 version, maybe I'm wrong. but on the other hand stability is important , mostly even more important than features themself.

And what about presentation for 18.X ? No dates when Live event is planned ? If it's planned at all. which is obviously planned.

OMG…I'm so geeked right now!

Hopefully it's announced this week! I hope KineFX has to do with character animation so I can ditch some other programs!