eetu's lab

[kumpa]

good boy eetu tnx for sharing

Edited February 4, 2009 by kumpa

[curveU]

These are really nice examples. Thanks eetu !!

[dan_cgi]

I am now an official fan of Eetu's lab. That ubershader is awesome, loving the i3d work also.

nice one

[mrice]

veeerrry verrry nice

[wolf_cub_one]

Hello, all

While learning this beast of a software, I bet everyone has accumulated a bunch of more or less interesting tests and stupid tricks on their hard drives.

Here's some of what has been accumulating on mine, before bit rot takes them, hopefully some might inspire others on this same road..

First, one from the mailing list a couple of days ago

eetu.

Eetu,

Now I have not only my stupid stuff but yours too.

thanks

[michael]

Hello, all

While learning this beast of a software, I bet everyone has accumulated a bunch of more or less interesting tests and stupid tricks on their hard drives.

Here's some of what has been accumulating on mine, before bit rot takes them, hopefully some might inspire others on this same road..

First, one from the mailing list a couple of days ago

eetu.

a while back we were thinking of going through the entire forum and grabbing out ALL of the hip files and organizing them so people could search/download them...

it would be a pretty big job - plus the need to update them to ~9.x (if possible)

but given a hip file's unique ability to demonstrate itself it would be damn cool to have as a resource...

[calix]

Playing with SDF's.

A font object is converted to sdf, and some particles spawned inside.

After that, the inverse of the sdf gradient at the point location is copied to the velocity of the point, every frame.

animation

Hi eetu!

The "font sdf anim" looks very cool, can you share a hip file?

Many thanks!

c

[eetu]

All right. Particles!

This tale starts last summer, when I, like many, thought I'd like to render a lot of particles.

Like many, my first idea was to instance a bunch of particles to each simulated particle.

This, not surprisingly. led to something resembling a lot of fuzzy cotton balls.

Thinking of how to break up the cottonballsiness, I ended up creating a looping 1000-frame

bgeo sequence of twenty or so particles gyrating around the origin. (cos is your friend..

This sequence was then instanced to each particle, with pseudorandom rotation. Also, the

particles had 30 different time offsets for the loop.

Still the cotton balls were there. (couldn't find frames from this phase)

In retrospect I probably should have spent more time tweaking this instancing approach,

as it seems to have worked for many in actual production.

I started thinking about ways to create new particles between the existing ones, and do it

procedurally without simulation, so that a random frame can be calculated. Every scheme I came

up with was lacking, usually it wouldn't have been temporally coherent. So I dropped the

requirement of not needing to know the previous frame.

Simulation it will be, then. Also by this time I thought I'd up the ante. I would learn cuda, write

the simulation bit myself, and render a BILLION particles. Good luck.

It wasn't too bad. The method I ended up with was simple; the new particles get their velocity

from nearby particles and move according to that. Think of it as the old particles being some

sort of attractors, or just as v attribute transfer. Just transferring P would've been "safer", but

the result would be more boring. With v there would be some new emergent behaviour.

Transferring force/acceleration would be even more exciting, but more risky too.

This is one of the first successful outputs, looking promising.

The red balls are the input seed particles. And then the first renders - now I knew the approach

really worked.

different alphas

To be able to go as high as possible I kept the data per particle as small as possible, and

at this point I also converted the cuda code to work in buckets and also to 64 bits. Getting

the buckets to work resulted in some wild results on the way..

Now, armed with a more linear algorithm, I started cranking up the point count.

With this version I made my way up to 115 million, and this render is probably the best I've come up

with, yet.

I love how it has some nice new detail that does not exist in the seed sim.

So, at this point my executable read a .geo sequence with 1 million points in it, did it's resim magic

and spit out a .geo with 115 million particles, which I would then render out in Mantra. The resim here

took perhaps 15-20 mins per frame on a G260, and writing the resulting 4.5gig ascii geo (uggh!) took

20 minutes

Mantra mem usage here was getting close to 10 gigs (the machine has 12) so I knew I had to

change the angle to get higher. Still one order of magnitude to go after all!

I was hoping that mantra would throw stuff out of memory when no longer needed. (no raytrace)

If I wrote the pointcloud out in buckets, it might be a lot easier for Mantra, memwise.

That I did, and also finally rewrote the load/save to use the binary format. Save times dropped 10x

After having a discussion with Hoknamahn on the subject (thanks dude), I understood that

converting stuff to i3d for rendering might be an option too.

Enter the current beast. Now it reads a 10 million particle seed sim .bgeo sequence and spits out:

a) ~ 7k .bgeo buckets with 400 million particles total, an ifd fragment that loads in the above

buckets as dla's, c) a script that converts all the pointcloud buckets into i3d's via i3dgen.exe,

d) the resulting 7k i3d's, and e) a similar ifd fragment for the volumes. Phew. Ugly.

Currently my code needs all the particles to be in cpu memory, so 400mil is about the highest

I can get to with 12 gigs.

When loaded into Mantra, the ifd fragment then assembles these volumes into a ~30^3 cube

(empty buckets are not saved) with correct bounding boxes. The combined resolution of the i3d's

is ~1800^3. So far so good, but now I hit a bit of a wall. My assumption about mantra throwing

out no-longer-needed dla's seems to be wrong, or at least I haven't been able to coax it into

doing that. So I haven't been able to really render this 400 million dataset yet, only without

shadows it reaches the end. *sniffle*

Ideas, anyone?

I haven't tested with the particle buckets yet, here's to hoping..

My idea-bag isn't completely empty yet, though

Doing this in passes/layers would of course be easier but I want to do it all at once..

Chasing after big numbers and "rendering a billion particles" might sound like a childish goal,

especially as I have no production need for it, but I've learned a LOT during this - and will likely

learn still more until there

Particle diary will continue.. higher peaks are still waiting

eetu.

[pclaes]

mindblowing! Amazing work!

Very inspiring and I don't think a billion particles is a childish goal at all. You might not have a production use for it right now, but many others do and they'll come to you for it .

[pclaes]

a while back we were thinking of going through the entire forum and grabbing out ALL of the hip files and organizing them so people could search/download them...

it would be a pretty big job - plus the need to update them to ~9.x (if possible)

but given a hip file's unique ability to demonstrate itself it would be damn cool to have as a resource...

That would be a great resource indeed, I'm sure we all have little archives of files with cool stuff, either from ourselves or from others as we go about learning and experimenting with Houdini. A more structured hip/otl repository would be great. I would be willing to help with the process of gathering and documenting some of them, a few a week perhaps as a start. Perhaps start this up in a different thread as not to bypass eetu's great thread.

[michael]

That would be a great resource indeed, I'm sure we all have little archives of files with cool stuff, either from ourselves or from others as we go about learning and experimenting with Houdini. A more structured hip/otl repository would be great. I would be willing to help with the process of gathering and documenting some of them, a few a week perhaps as a start. Perhaps start this up in a different thread as not to bypass eetu's great thread.

stand by for some news in the very near future...

ok...back to eetu's crazy awesome work

[Jason]

Hey eetu,

I wonder if you've tried storing your points in a point-cloud file (.pc)?

i3dconvert should be able to convert to this format.

I do doubt that the regular DLA procedural in Mantra will manage loading/flushing of this file type optimally, but I thought I'd point it out. Perhaps you'd have to write your own procedural to split the point cloud up into a series of DLAs -which might be easier once in Point Cloud format?

[DaJuice]

Wow, some really cool work in this thread eetu, and the particle stuff is amazing. Love the last two renders in particular, reminds me of dust bunnies.

[sanostol]

You got a bunch of particle there!

Brilliant stuff. Keep it on.

[diula]

Great stuff!

On the topic of point clouds - is there an API to read these files? It seems one can only convert them via i3dconvert...

[eetu]

I wonder if you've tried storing your points in a point-cloud file (.pc)?

I do doubt that the regular DLA procedural in Mantra will manage loading/flushing of this file type optimally,

but I thought I'd point it out. Perhaps you'd have to write your own procedural to split the point cloud up

into a series of DLAs -which might be easier once in Point Cloud format?

No I haven't tried .pc format yet, but now I will..

I already do have the point cloud split into several thousand dla'd .bgeos, but until now I have only tried

to render the i3d's I converted out of these.

Any general advice on how to coax Mantra into loading and flushing things on demand? Raytracing is of

course a no-no.. I've tried playing with ray_texcache in case it applied to i3d's, but to no avail thus far.

Probably it won't matter one bit if my bucketed points are loaded in as .bgeo or .pc, as all the points will

never fit in memory. The key is getting them flushed after they are no longer needed..

eetu.

[Jason]

Any general advice on how to coax Mantra into loading and flushing things on demand?

I'm afraid not - I'm wracking my brain trying to remember if there was some limit you can supply.. but nothing.

Probably it won't matter one bit if my bucketed points are loaded in as .bgeo or .pc, as all the points will

never fit in memory. The key is getting them flushed after they are no longer needed..

eetu.

True, yeah. Assuming you can eventually get Mantra to flush, the only potential convenience is that the .pc format could make coding a procedural easier due to its spatial storage... maybe.

I hope a SESI person will throw in a hint:)

[ranxerox]

hey Eetu, is there any way you could explain what you did here in a little more detail. I was interested in trying something like this so I used a foreach sop with a scatter sop and a copy sop within it. Tried a bunch of different things which look close but I'm still not getting it quite right. Any hints you might be able to provide to a houdini noob would be greatly appreciated.

thanks

-ranxx

Aggregation.

A friend of mine made a fast dla in xsi's ice, so I naturally had to give it a try.

anim1

anim2

dla in wikipedia and in pictures.

From the start I decided to fake it. I started thinking about the probability of any point in any timestep receiving a randomly walking new aggregate particle.

I thought it would be close to occlusion at that point, so I made an occlusion scatter component.

Each frame I occlusion-scatter a couple of points on last frame's geometry, and then copy new geometry to those. Iterate to taste.

A nice thing about this approach is that one can have invisible geometry constraining the aggregation process.

(The first anim is constrained inside a sphere, the second a torus.)

The particle counts here are really quite low, perhaps I'll leave it running the next time I go for a vacation

eetu.

[eetu]

hey Eetu, is there any way you could explain what you did here in a little more detail. I was interested in trying something like this so I used a foreach sop with a scatter sop and a copy sop within it. Tried a bunch of different things which look close but I'm still not getting it quite right. Any hints you might be able to provide to a houdini noob would be greatly appreciated.

Hi,

I don't have that scene here, but things you might look for;

checking for occlusion (Ray SOP) so that scattered points do not lead to interpenetration,

scatter only on the latest generation of geometry, and

there are many ways to skin a cat in Houdini, but I don't think I used foreach here. Roughly: file read, scatter, copy, file write.

eetu.

[eetu]

Volume blurring. From Sidefx forum.

A quick implementation of gaussian volume blurring with a Volume VOP network. It's a bit dirty as it takes random samples, and the distribution is neither right nor optimal.

I like volumes.

eetu.

ee_volumeblur_vops.hip