ThomasPara

I would have removed the gpus atleast. The hdds doesnt have that mutch room to move around i guess and your case is solid enough to keep them in place. You could setup an rbd sim an check out how things fly around inside the case

Important to check if you have substep data, go to your timeline and uncheck "integer frame values". If you scrub through and there is no motion between frames you will get zero motion blur. To fix this you can try to use the "time blend" node.

Many ways to accomplish this, do you want to offset one position, or a "time-shifted" animation?

TreeSystem_rbd_updated.hiplc I removed some of the assets. Its alot to think of when you split a curve in this setup, hard to explain it in a simple manner. I can try later when i have the time

i would wait for september for the new nvidia cards

Tasteful!

We did a take on the diff growth for a shortfilm-festival. I dont have the complete video, but a cut down instagram version of it. (Not pleased with the mushroom animation, but it is what it is); And a instagram breakdown.

Took a similar mesh and applied some differential growth on top of it. Maybe a direction you could try. Heres a thread where you can get some directions on how to do it. https://forums.odforce.net/topic/25534-differential-curve-growth/

So based on petz file i could make a new version that was between 15 to 20 times faster than my old one. Combined with using the edge transport node for @curveu. And i was suprised on how mutch performance you gain from using "numbers" mode instead of "primitive" mode in the wrangle. Seems like multithreading doesnt kick in, even with 10.000 of them.

Werry neat solution petz, performance wise it atleast the double of mine. Havent been using Numbers mode that mutch, need to look more into that.

I guess you won the performace editor, you came up on the top

Because curveu doesnt give a precise value when created by a resample sop. It works best when all the points have an even distribution, but still then it would be "incorrect" in the ends because of the even last segment. You dont have to resample with the resample node, you can just generate curveu if you want. So if you try with a curve that have uneven length between the points, you would see that your carving is "jumping" up and down in speed. This would be solved by making a curveu value that has the correct length between the points. Even in Anims case that would fix the uneven carve. But that example doesnt include carving a curve from both ends, and i guess its just pushing the other end of the curve down into the clip plane. Here i compare it to the carve-sop that use parametric-uvs. The same problem will occure with the @curveu attribute created by the resample-sop. Top is carve-sop, the bottom is carveing with uvsample.

I guess most tds have created their own solutions and its a shame that the carve doesnt support per prim attributes for carving, and when i first started using houdini i remember that was frustrating. I guess thats also why it became one of my first otl/hda aswell. I first started using the primuv function, but as stated here, when curves have uneven segment-lengths the result doesnt look that great. So uvsample is the way to go in my opinion. Havent tried the clip approach, so its hard to compare speeds in a good way. So i put up a test with default clip, no other magic and compared. In my test i had two clip nodes, i guess you can get away with one and get some speed there. Clip wins if i delete points and transfer attributes. If i dont delete points or transfer attributes i get a good increase in speed. But i guess clip would be faster with only one clipnode instead of two. So if somebody have created a good clip carve, it would be nice to compare speed. Clip_vs_Carve_01.hiplc

qlib has a good camera rig, easy to use and gives a more realworld camera setup. https://qlab.github.io/qLib/

You could "object merge" inn a null and use that as a reference. Simplest i can think of now.