Hello I have question about colorization of particles.I have some ramps in cop and need transfer colour to particles. Problem is that If I choose colour node with cop file $BBX $BBZ, particles still changes colour with time when moving. I could do it vit initial state, but I prefer, take colour from surface from place where you born and dont change it. It is useful for me becouse I than deform geometry and still need new born particles with “deformed” colour. Is there some posibility how I could do this? Thanks a lot…

There are two methods you can go about this. You can either colour the geometry from which the particles are birthed from or create a group for when the particles are birthed and set the colour for the group.

For the second method, in your Source POP, set the Birth Group parameter to “born” and the group will contain particles that are birthed for one frame only.

Next, in the Colour POP, set the Source Group parameter to “born” and the particles will have the colour set correctly.

Hope the above helps!

Cheers!
steven

Thanks a lot stevenong, but I have still problem. Firt metode is, like you write, that If i have colored surface, First input for pop is saturn disc with good UVs and applied material, but I still don't know how to color particles. I add color node inside pop but which folder I must choose? Param with some color expression?Idont know how to tell houdini take colour from place where you born. In the next example with bird group, I add colour pop but stil same problem, How I could tell hopudini take it directly from surface? thanks a lot for your help. If it will be little example, should be perfect.

Hi,

Here's a video tutorial [sidefx.com] that might help you.

Please search through the forum with these keywords: “particle AND color” or “particle AND texture” and also, check “Search for all terms”. You should get quite a number of posts regarding this topic.

Cheers!
steven

Particles automatically inherit all attributes from the source geometry. This includes Cd (color) and the uv's if they are point uv's that is. The uv's should be nicely interpolated as they would be at render time so the latter method will give you more accurate results.

This gives you two methods:
1. Birth your particles inheriting color already mapped on to your geometry.
2. Color your paritcles on the birth frame (following Steven's advice) using the inherited static uv attributes.

1. Color your source geometry.
The two most common methods to color source geometry is to use a Point SOP or a VOP Network SOP.
use the pic() function in the Point SOP and $MAPU and $MAPV to reference each point's u and v coordinate in that function.
So for the three color parameters you would have an expression similar to this:

pic(“/img/img1/color1”, $MAPU, $MAPV, D_CR)
pic(“/img/img1/color1”, $MAPU, $MAPV, D_CG)
pic(“/img/img1/color1”, $MAPU, $MAPV, D_CB)

Resample your source emitter until you get the accuracy you want.

If that isn't accurate enough, you can always scatter a bunch of points on your emitter geometry and feed those points in to the Point SOP to color them. Then change your Source POP to birth from points.

2. Color particles at birth frame using inherited uv's (See Steven's post on how to set this up).
This requires the Color POP. Just use the same expressions above for r, g, and b.
Now you could omit the birth frame condition since the uv's won't be changing by default. You would use the birth frame since it is much more efficient since the particles really only need to have this calculated once.

Note:
Using VOP networks to color particles is wwwaaaayyyyyyyy faster! See the attached example file.

Note:
I apologize for the inconsistency of attribute indexing via $MAPU, $MAPV and $MAPW to index in to uv0, uv1 and uv2 (using $UV1, $UV2, $UV3 and even that is inconsistent…). It's a very old legacy inheritance issue from the stone age. Once you know, you know.
A good reason to use VOPs/VEX.

thanks a lot guys

stevenong: I search a lot of forums, odforce, there, but All use $BBX $BBZ what is bad, easu but bad,texture blowing threw. So $MAPU - V looks good. Videotutorial is great but still $BBX .. Image dont blow becouse of initial state. If I need emit particle some frames, it is problem.

jeff: Thanks a lot for detailed explanation. $MAPU - V is propably what I need, but vops/vex sounds great.(I buy yesterday some videotutorials CMIvfx for vops/vex, at festival Ill teach it) But I cant see attached file. Please could you resend it?

I can see the file, excelent vops/vexwork briliant and speed is perfect. Thanks a lot :roll:

I tried Georges' “Blowing an image away using particles” tutorial. In H9, the pic() function was slow but acceptable. However, in H10 it is much much slower. Is it a bug in H10?

Quite possibly.

It could be the Point SOP or it could be the drawing performance in the viewport. I believe we did some work to the viewport…

I usually use the Performance Monitor (from the Window Menu) to verify the performance of specific nodes versus the view port draw time.

Please try this out and let us know if possible.

Please be sure to turn the Performance Monitor off after using. Simply closing the window does not turn the feature off. It will certainly compromise performance if accidentally left on.

Jeff,

I reduced the test, to start from a 10x10 GRID, a POINT with one pic(), and a default.pic FILE COP. I also attached the test file.

Here are the results on H9.5.379:

0.31 ms 4 cook /obj/geo1/grid1 (Sop/grid)
4.28 ms 4 cook /obj/geo1/point1 (Sop/point)
0.10 ms 10 port background (persp1)
0.25 ms draw /obj/geo1/point1
0.01 ms drawlist
0.05 ms 10 port transp (persp1)
0.05 ms 10 port inter-object (persp1)
0.00 ms 10 port handles (persp1)
0.00 ms 10 port foreground (persp1)
0.03 ms 10 port name (persp1)
0.11 ms 10 port statename (persp1)
0.19 ms 10 port other (persp1)



0.55 ms 5 cook /obj/geo1/grid1 (Sop/grid)
8.27 ms 5 cook /obj/geo1/point1 (Sop/point)
0.10 ms 11 port background (persp1)
0.46 ms draw /obj/geo1/point1
0.01 ms drawlist
0.05 ms 11 port transp (persp1)
0.06 ms 11 port inter-object (persp1)
0.00 ms 11 port handles (persp1)
0.00 ms 11 port foreground (persp1)
74.75 ms 11 port name (persp1)
0.15 ms 11 port statename (persp1)
0.21 ms 11 port other (persp1)

Here are the results on H10.0.341:

0.44 ms 2 cook /obj/geo1/grid1 (Sop/grid)
8.90 sec 4 cook /obj/geo1/point1 (Sop/point)
0.01 ms 9 port background (persp1)
0.00 ms 9 port pre-render (persp1)
0.26 ms draw /obj/geo1/point1
0.01 ms drawlist
0.06 ms 9 port transp (persp1)
0.02 ms 9 port inter-object (persp1)
0.00 ms 9 port handles (persp1)
0.01 ms 9 port post-render (persp1)
0.00 ms 9 port foreground (persp1)
102.25 ms 9 port name (persp1)
0.17 ms 9 port statename (persp1)
0.37 ms 9 port other (persp1)



0.67 ms 3 cook /obj/geo1/grid1 (Sop/grid)
18.22 sec 5 cook /obj/geo1/point1 (Sop/point)
0.01 ms 10 port background (persp1)
0.00 ms 10 port pre-render (persp1)
0.52 ms draw /obj/geo1/point1
0.01 ms drawlist
0.06 ms 10 port transp (persp1)
0.02 ms 10 port inter-object (persp1)
0.00 ms 10 port handles (persp1)
0.00 ms 10 port post-render (persp1)
0.00 ms 10 port foreground (persp1)
71.51 ms 10 port name (persp1)
0.17 ms 10 port statename (persp1)
0.37 ms 10 port other (persp1)

(WindowXP SP3, VC8 version, GeForce 8800 GTS)

Hope that helps. This is the first time I used the Performance Monitor

ops:

Kam

Just found that the same issue happen on MacOSX version, but on Linux version the problem doesn't appear.

Thank-you for the output.
The Point SOP looks real suspicious. The point1 SOP is taking an order of magnitude more time to evaluate itself. Your initial assumption seems to be holding up in the Performance Monitor trail.

Please submit this case in to Support along with the file and have it dealt with there. Point them to this thread as well.


-jeff

Hi Kam,
Please attach a test file so that we can test this at Side Effects.

Thanks, Jenny.

Jenny,
I will do so after I go back to my office tomorrow. Thanks!
Kam

where are we with this? is it a bug or a result of the new viewport code?

other than that, i'm curious if the following is valid ( or moot ) as a speed up to birthing particles based on the color of an image:

instead of using the pic() expression in the birth probability param, use Jeff's VOPs speedup to color points made with a Scatter SOP, delete points based on color, then birth particles from points.

other solutions appreciated, but my main focus is the apparent “speed-up” which may be erased or diminished with fixes made to the pic() expression etc.

thanks.

Last week I downloaded the version 10.0.355, and the pic() expression in POINT SOP seems to be run in an “acceptable” speed again (on Win32 version). I haven't tested it on my Mac yet.

It still seems to be insanely slow in the latest production build.

Yes, when I try recently (using the same build), the speed is slow again. I forgot under what situation that I had the speed “acceptable” last time. I believe the problem still exist. May be the graphics driver also affect, as Jeff said? I submitted the bug to SESI but they couldn't reproduce the same problem.

Currently I am using the VOP SOP solution.

Kam

WOW! The VOPSOP solution should be on the front page of SESI and odForce! SO much faster! Jeez, I'm ashamed to say I sat there for hours one day when I needed a high resolution, LARGE amount of particles inheriting color, then waited for the pic function to sloooooooooooowly chugg chugg chugg along. Anyways, I have a question, about the example file you posted…

I noticed, when adding the color before the popnet, the image looks fuzzy but when doing the coloring inside the popnet, the coloring looks exact!

Could you explain why.

Thanks,
Jonathan

hmmm so i noticed WHERE the difference comes into play but i'd just like to clarify if my understanding is correct here.

1. *the blurry result* that I saw was due to the resolution of the grid in the network example of grid –> uvtexture –> vopsop –> popnet. So that example is GEOMETRY RESOLUTION DEPENDENT.

2. whereas, the network example of grid –> uvtexture –> popnet with voppop inside is GEOMETRY RESOLUTION INDEPENDENT…

I thought at first I understood why, but the more i thought about it, the more curious it became to me… If we have a 10 x 10 grid, uv texture, and then do a vopsop to apply the color… the image on the grid is super fuzzy… up the resolution to 100 x 100 on the grid and the texture becomes crystal clear. So, it's obvious to me that the resolution of the grid results in the quality of the final image. However, when using the second method, coloring the particles using a voppop, the resolution of the geometry doesn't matter… i don't get why it's different here though… because, it's seems to be doing almost the exact same thing, pulling in the uv's, and applying color. why does the resolution NOT matter in this example? Just trying to understand it a bit better. REGUARDLESS, this new method ROCKS, and i'll probably never use the pic function ever again well at least until it's a bit more speedy

Jonathan