[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vr / w / wg] [i / ic] [r9k / s4s / vip / qa] [cm / hm / lgbt / y] [3 / aco / adv / an / asp / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / qst / sci / soc / sp / tg / toy / trv / tv / vp / wsg / wsr / x] [Settings] [Search] [Home]
Settings Home
/3/ - 3DCG

Thread archived.
You cannot reply anymore.

Houdini general
What are you working on?
Post questions here
here's my demo reel:
But I know, this all could be done better and easier in Blender LMAO!
Good job on that filename, OP. Thread ruined.
File: tenor.gif (170 KB, 360x346)
170 KB
170 KB GIF
Not really. I expect of Houdini users to be mature enough to not enter into pointless software frays.

each scene there took a lot time to finish. houdini id good software but blender is not famous for its simulations..
File: hands (2).webm (862 KB, 1012x1390)
862 KB
Studying ragdolls.
yeah mean soft bodies?
blender isn't really famous for anything to be fair
Maybe look into vellum soft constraints for the hands, it'd look a lot better if they weren't just intersecting
File: final_render.301.jpg (559 KB, 1280x720)
559 KB
559 KB JPG
non color graded version of a river i've been working on
No, it's crowds. Bullet/RBD.

I can give soft constraints or spring constraints a shot. Mixing multiple solvers sounds like overkill.

Color grading isn't going to differentiate wet rocks on land from dry rocks underwater unless you hand-paint a mask. The color is currently all the same looking like dry rock. I like the moss.
blenders fan-base is famous for being retarded rabid cultist that want to convert the whole industry into blender users.
A little bit similar to muslims desu
Yeah wet maps are on my to do list, but at this point I'd rather just make a new sim altogether
File: leonel-perez-comp.jpg (290 KB, 1920x1428)
290 KB
290 KB JPG
Hours since last crash: 0.
Hours since last paycheck: 0.
i translated a vop network from a tutorial into vex and i feel like less of a shitter than I actually am
//sine ripple deformer
//controllable sine wave base formula
//sin((distance*frequncy) + (-time*speed)) * amplitude

//store position of target point on second input
vector target = point(1, 'P', 0);

//initialise and normalise normals
@N = normalize(@N);

//time variable with speed control
float timeMult = -@Time * ch('speed');

//calculate distance from points to origin
//float dist = distance(@P, {0,0,0});

//calculate distance form points to input 2
float dist = distance(@P, target);

//frequency control
float freqDist = dist * ch('frequency');

//sin of distance + negative @Time driving phase creating animation
float distSin = sin(freqDist + timeMult);

//amplitude control
float amp = distSin * ch('amplitude');

//amplitude multiplier to fade wave to edge
float decay = fit(dist, 0, 10, 1, 0);

//displace along normals
@P = @P + (@N * amp * decay);
that last fit is shitty because of the hardcoded 10. that value is based on a 20x20 grid.
>@N = normalize(@N);
No need to. You can do @N = @N; to make them explicit, but they are computed on demand if they weren't assigned before (as if you applied smooth shading). Also, unless you are computing normals in an unorthodox way, they are already normalized.

>@P = @P + (@N * amp * decay);
You can simplify this to @P += @N * amp * decay;

i know about that second one but i left it explicit because i'm a brainlet and i come back to vex after months long breaks so i thought i'd forget the next time. futureproofing against my own stupidity.
can anyone have a look at this file and tell me why the two methods exhibit such different results?

The difference is caused by the trig functions. In VEX, they operate with radians, while the HScript expression functions work with degrees. If you rewrite your attribwrangle1 like this you'll get the same result from both graphs:

@P.x = sin(radians(ch('copies')));
@P.y = cos(radians(ch('copies')));
bless you. do you know why there's such a massive performance penalty doing it via the wrangle?

i'm not sure i'd notice on my desktop machine, but on my ultrabook i actually have to wait a few seconds for the copystamp to cook.
>do you know why there's such a massive performance penalty doing it via the wrangle?
Not sure. I did some profiling and isolated the cause to the copies parameter. The solution is to move it up to another node, such as the null in pic related. My guess is that the wrangle is possibly recompiling the code with each different stamp.
Is there pbr viewport support.

thanks again.
Native, with 17.5, using the Principled Shader and High Quality Lighting in the viewport. See https://player.vimeo.com/video/322512939
anybody done any rigging or character animation in houdini?
I'm not into masochism, thanks
File: 1533576228396.png (322 KB, 500x489)
322 KB
322 KB PNG
i miss softimage
I did the Goldfarb tutorial series. My impression is it's slightly better than Blender, but far worse than Maya. It's like they tried to rip off how Maya does things but didn't get the ergonomics right. Rigs are also single-threaded so don't expect fast playback of anything complex.
File: AbWcskU.jpg (100 KB, 616x359)
100 KB
100 KB JPG
Me too, but it's not coming back.
File: 1545596346015.jpg (41 KB, 641x530)
41 KB
ok THAT'S masochism
Zip it kiddo, you probably never had the joy of working with XSI
File: vxc.jpg (300 KB, 1920x1055)
300 KB
300 KB JPG
Making some comfy houdini rocks
How easy is it to take the hair/fur made in Houdini and use it on a model in Maya?
I actually did for two years, and it was atrocious
is there a way to use vray in 17.5? the beta install script doesn't seem to work for it and i'm not sure how to change it.
some nice set ups here:

i guess this is what happens when gaben doesn't actually let you make videogames.
Add an ocean, a beach HDRI, and hand paint some seagulls and you've got yourself an Instagram daily
File: 1267471275930.jpg (18 KB, 500x332)
18 KB
Fuck Instagram dailies.
Non-Houdini user here.

How good does your hardware have to be for simulations like this and how long does it take to render?
every time i try to turn on advanced viewport shading it crashes what do?
Other anon here.
You can never have enough power and it always takes too long.
hq fluid sims are pretty compute intensive

render times depend on renderer. houdin's own mantra is slow as fuck.
Submit a bug report.
It's finally out, peeps.

Holy moly, Simon holmedal still shitting down the throats of everyone else who uses Houdini.
>some flow sim with colors

I was expecting something more interesting desu
it's a lot more than just a flow sim

Do i need all of this "patches" if i want to learn and work with pirated 3ds, maya, zbrush and Autodesk?
>tfw brainlet and don't grasp vector mathematics so just try different operations until i get the result that i need
he's using vops instead of vex!!!
It's almost the same, practically.
File: me_smug2.png (28 KB, 160x160)
28 KB
>look up something on google
>find the perfect solution posted by this guy every single time

matt is a treasure
should someone still learn vex or not?
Vex is far more important. Vops are best for certain cases when you want to wire up a few predefined functions and get a graphical controls. When you need any custom code, you're back to vex.
vops are basically a node base gui for vex and you can do most things you'd want to do in there. iirc almost all vex functions are available as vop nodes:


once you've wired up a vop it'll actually produce vex code (you can bring this up by right clicking the vop and viewing the generated code)

there are few downsides to vops, however:
the vex code they spit out is not particularly elegant or optimised so you suffer a small performance penalty. however, unless you're dealing with massive number of points/voxels etc you probably won't feel this.

i'm also not sure it's possible to write your own custom vop function (which you'd be doing in vex anyway).

plus sides to vops:
you don't have to deal with the vex documentation

vex functions can be barebones e.g. the noises. so adding curlnoise with a ui to @P in vex in vex would look something like:

@P += curlnoise(@P * chf('freq') + chv('offset'));

and that's just two parameters. in vops it's a couple of wires.

that said, vops can be clunky when doing logic operations and more complicated stuff. e.g. here's some code for a broken ass supershape creator in vex:

i don't even want to think about doing that in a vop even though you could if you really wanted.

now someone help me fix my broken ass supershape please.
this should read:
>@P += curlnoise(@P * chf('freq')) + chv('offset');
File: 2019-05-17_16-16-19.webm (272 KB, 596x930)
272 KB
this thing's still kinda neat desu.

anyhow, i'm just going to watch a tutorial about this.
made a container yard generator yesterday (it can take any geo, so really it's just a random stack generator), but ran into a problem when i wanted to delete random points + all the points directly above those points.

is there a point equivalent of the intersect function?


i'm assuming rays don't actually intersect points.

solved the problem by putting deleted points into an array and running position checks against that, but can't help but think there's a better way to do this / just useful to have a ray based point intersection checker.

excuse the placeholder assets
Redshift renderer supposedly saves 30% on average. Haven't tried it myself though as I am still getting used to Mantra

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.