Isn't it time for some Houdini 18.5 action soon?
40992 72 12- Sygnum
- Member
- 119 posts
- Joined: 8月 2015
- Offline
- n2e
- Member
- 31 posts
- Joined: 1月 2018
- Offline
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”.
Edited by n2e - 2020年9月2日 01:37:38
- weidenba
- Member
- 6 posts
- Joined: 6月 2017
- Offline
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
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
- habernir
- Member
- 94 posts
- Joined:
- Offline
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
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
Edited by habernir - 2020年9月1日 05:56:27
- AslakKS
- Member
- 185 posts
- Joined: 2月 2016
- Offline
This is a good overview of what NanoVDB provides. nanoVDB starts at 9min
https://www.youtube.com/watch?v=VJBv9lh5kqg [www.youtube.com]
https://www.youtube.com/watch?v=VJBv9lh5kqg [www.youtube.com]
- Sygnum
- Member
- 119 posts
- Joined: 8月 2015
- Offline
- matozembery
- Member
- 4 posts
- Joined: 3月 2014
- Offline
- zengchen
- Member
- 77 posts
- Joined: 2月 2017
- Offline
matozemberyso houdini 18 should have three versions - 18.0 18.5 18.6?
Actually, looks like it is 18.6.2 already (https://github.com/sideeffects/HoudiniUsdBridge)
Edited by zengchen - 2020年9月4日 22:41:34
- EricSheng
- Member
- 159 posts
- Joined: 2月 2018
- Offline
- Erik Ws
- Member
- 39 posts
- Joined: 7月 2020
- Offline
- citizen
- Member
- 100 posts
- Joined: 8月 2020
- Offline
- BrianHanke
- Member
- 447 posts
- Joined: 4月 2018
- Offline
The latest 3Delight update, released today, says it's compatible with the 18.5 beta branch. Something's happening!
Subscribe to my Patreon for the best CG tips, tricks and tutorials! https://patreon.com/bhgc [patreon.com]
Twitter: https://twitter.com/brianhanke [twitter.com]
Behance: https://www.behance.net/brianhanke/projects [www.behance.net]
Twitter: https://twitter.com/brianhanke [twitter.com]
Behance: https://www.behance.net/brianhanke/projects [www.behance.net]
- TwinSnakes007
- Member
- 632 posts
- Joined: 7月 2013
- Offline
- ifree
- Member
- 54 posts
- Joined: 9月 2008
- Offline
- Sygnum
- Member
- 119 posts
- Joined: 8月 2015
- Offline
- CV
- Member
- 46 posts
- Joined: 1月 2016
- Offline
- n2e
- Member
- 31 posts
- Joined: 1月 2018
- Offline
citizenn2eI 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?
Universality.
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.
- Erik Ws
- Member
- 39 posts
- Joined: 7月 2020
- Offline
“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.
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.
- TwinSnakes007
- Member
- 632 posts
- Joined: 7月 2013
- Offline
- JalexM
- Member
- 29 posts
- Joined: 7月 2017
- Offline
-
- Quick Links