eddgarpv

Oh, I see, Let's do some tests! Thanks for the input

So I'm doing some tests (wire solver) and I've found a bit difficult to get the stiffness under control. I agree that wire objects are waaaay faster than vellum tho Can you share a bit of your workflow, Thomas?

Thanks Matt, it is even more clear (I'm right now at the orient, matrices, quaternions and stuff ) Fuat: works good too, I'll see how much it changes within the dop network and constraints

Hello, I'm trying to do the same (get rotation) following Matt's suggestion but for some reason, there is a weird flip at some point in my orient attribute. I know I'm missing something, it's just I'm not really familiar with vex. Already tried a couple alternatives but this one looks more clear to me. I just wanted to create constraints and one thing leads to another I guess . test_constraint.zip

I know this is an old post, but just recently had the same problem with a fresh centos 7 install (debian was working perfectly, but had to switch). Anyway, the problem was I had a firewall running in centos. Disabling this solved that 'Unicode: need string' error. I can't restart nodes using the web interface but I can ssh to the nodes. There may be another security option that may be causing this but I still have to find out. Hope this helps somebody in the future.

Cool example! adding a trail for velocity makes it look super sexy.

Ah, that was the problem. Adding that option solves the issue... thanks John!

from support: The issue that was causing the incorrect shading was related to ray continuation. Some of the tracking of ray distances was off, resulting in ray continuation beyond the far clipping plane. This issue has been resolved for our Houdini 15 release.

Submitted to support. I tried using deep comp but for this particular shot, it was too much (of disk space and nuke script setup). I've found that this problem happens when there is no density field in the volume. If I create a primitive called density and copy heat to it, it will clip the volume just fine. http://i.imgur.com/zrODQKX.png I ended up using matte objects for the front, but now I know how to solve it.

That is amazing. You guys have been busy. Congrats.

Hello, I'm trying to use near/far clipping planes on a camera to render a volume and comp something in the middle.. the problem is, when the far clipping plane is in the middle of the volume (i.e. the front part of the fire), the far clipping plane is ignored. If the volume is hidden, I can get the front part clipped. Right section of the image is using the same far clipping plane as the left part, just with a hidden volume. I'm not really sure if I should add something else to the ROP, so any hint is appreciated Here is the indie file and bgeo. thanks!

cool videos, thank you!

https://www.youtube.com/watch?v=x-_-uNhnXQU

I have the same problem: a crashing mantra render at random frames when reading bgeo files but without compression. Already reported (using 13.0.582). An alternative could be caching sim files instead (probably this is the correct way to do it?)

Thanks for the scene, Ian. I thought I could get a continuous motion using the ocean spectrum's Loop Over Time checkbox