Many qwestions

[lorduk]

First of all how can I get shader to use "Cd" point primitive (Coloring the particle sprites)

Secondly, when I use sprites inside the ray-marcher (the example how to use i3d, came with houdini) then it will add the colors of the sprites to the color of the smoke (not a good thing , so if I have grey smoke and yellow fire inside then it will become super-white)

Third how can I use motion blur on particle system (tried all thre types but transformation shoud do the trick, right?) anyhow set the oversampleing up to 10 but still nuthing, use a single spehere avrything works just fine ). What I do is use a pop network and a circle as inputs for copy .... but I do not get any BLURRR

Aprichate all the help .....

Kaspar

[TheUsualAlex]

hey there.

1) Can you try the Attribute SOP to rename your "Cd" to "diff"?

2) the default implementation of those i3d shaders, I am not sure if they can pick up colors from particle itself.... I could be wrong, tho. I haven't have any success in getting the i3D shader to pick up color attributes from particles. Please let me know if you indeed done it.

3) Particles should work with Velocity Attribute Blur. There are quite a few ways to do this in Houdini. One way is by rename any vector attributes to v (velocity). Another way that you can calculate the velocity blur -- if you output your particles to sequence of geometry -- by calculating the future frame minus current frame in your Point SOP's Velocity or Normal field. (If you use the Normal field, just rename N to v with Attribute SOP)

EDIT: All right.... looks like I have a bit of correction to make... Concerning the "future frame minus current frame" --- this may or may not work with particles due to the possible difference in the number of particles from frame to frame. However, it will work great with geometry -- presuming that the geometry itself won't change its point count from frame to frame, that is. Either way, you could also play with the Normal or any vector attribute and turn it into a velocity attribute to calculate motion blur.

Hope that helped.

Cheers.

Alex

[pockets]

I'm going to assume you're trying to get the default shaders that ship with Houdini to be aware of your point/prim color attribute. For some reason SESI didn't compile up default shaders that could read these settings. Don't know why.

The shader needs to use the isbound() call to check for incoming attributes. It's kinda annoying but they do provide the source so that you can add the hooks yourself. Something like:

...

if (isbound("Cd"))

diff=Cd;

...

Assuming "diff" is the parameter used for diffuse surface color in this shader. For further syntax examples look at any shader that lets you pass in UV coords, or the " Runtime Miscellaneous Functions" page in the html VEX documentation.

For fire inside smoke I'd suggest you place a light(s) inside the i3d volume. That way you cook out your volume and you can more quickly dial up and down your fire's intensity and play with flicker, etc.

For particles use velocity based blur. Oversampling will have less to do with your results than making sure your camera has a proper .5 shutter (I think default is 1 which will produce incorrect motion blur for 99.999999% of all needs).

I haven't checked lately but for some reason, way back, I got into the habit of needing to multiply up my velocity vectors on particles by $FPS in order to get appropriate blur lengths...this goes back to Houdini 2 or so. I never found out if it was a bug or a feature but whenever I've not gotten blur when I know I should I usually try this after making sure my particles or particle instanced geometry do, in fact, have velocity attributes by looking at the geometry spreadsheet.

Also, make sure your copy SOP is set to stamp point attributes from the template geometry. For (most likely) speed issues it doesn't do this by default. And if you only want velocity but not all the other particle attributes (for speed) set the scope to just "v" on the stamp page.

[lorduk]

"...with the volumetric shader the problem is when I use objects behind (and or inside) the volume that the color values get added Cvolume+Cspriteo_bject - so when I have dark yellow sprite and grey volume then it will apear white in final render." just when writing this down I figured out what it was doing wrong, in case of volumetric shader the P is first SOLID object or a cliping plane. Now I do not know how mantra handels transparency (is opacity of differnt objects added untill it == 1 and this is P, or it ignores all the geometry with opacity value set what would result a wrong P). Because when the render would set the P to the cliping plane instead of sprite then extra volume density would be calculated and therefore density would be higher on the spots where the sprites are.

Is this making any sense?

As a current workaround, I just render in layers and composite it aftewards.

thnx for all the ideas....

evrything else I have worked out by now .....

-Kaspar

[lorduk]

I was wondering can I do curved motionblur for particles, beacause the velocity attribute cannot be curved (no vector can be ) so is it bossible and how?

-Kaspar

[pockets]

Ahhh...object IN the volume. To get around this you're going to need to clip out the volume for the area your other object and it coincide. Otherwise I'm sure you'll run into problems such as this, or worse.

I'm just now playing with i3d stuff, so I don't have a tested, working solution for doing the boolean. I'd start with Jason's tutorial on voxelizing objects and see what I could work out from that. Rendering in multiple passes might get you something that looks okay but your results will be more dense than they should in areas your volume and the other object coincide.

There might not be a totally feasable model based approach for doing it, without popping or some other form of aliasing, but possibly an i3d shader which allows you to flag certain particles/blobbies/points as "negative space" so that you can sorta sculpt the volume while you generate your i3d.

Just a thought...I haven't finished my second dose of caffeine for the day so maybe there's an easier solution.

Also, adding up to white...I'd look at the shader you're using to shade the volume and work out how it's using alpha and opacity. These can be tricky when dealing with semi-opaque objects.