I am facing a task where i need to camera project millions of particles. The particles inherit a camera projected material from an object that has it’s beauty render projected through a projection camera. The render camera is slightly different but close enough to not reveal the projection stretching where the camera is not directly facing. I that 4 years ago already:
BUT in my new case the camera AND the object are moving. The technique above doesn’t seam to account for that so i am looking for alternative ways to camera project an image sequence on a moving object/moving camera. Box#3 comes to mind first. A simple color reading from the position object works but is 4 times slower (!) then the technique Bobo shows above. Advantage: It just works with moving object, moving camera etc. just painfully slow…
The MappingObject operator (formally from Box#1) doesn’t hold the color when changing the event, even with the Box#2 feature to inherit shading through events.
The fastest way to do Camera Projection is using the PerPixel Camera Map in Max.
The problem with it is that it does not have an option to STICK the color to a moving particle - it will reproject on each frame so the particles would be floating through the image.
To solve this, we had a Frantic Films Camera Map in house that could use a given map channel containing the original world position of the particle on a static frame and would map according to that. The Script/Box#3 example in the help MIMICS that, but is many many times slower.
There is a WORKAROUND to do the same sticky color trick, and it was outlined in the Studio Daily tutorial with the Lambourghini disintegration. The trick was this:
*Distribute STATIC particles on a surface, say using PFlow or PRT Volume or whatever.
*Camera-Project the color on each frame with static particles. The projection and rendering cameras can be moving around as needed. Save the particles to PRT.
*Load these particles in a PRT Loader - the Color channel will contain the camera projection on each frame, positions will be same on each frame.
*Load this PRT Loader into PFlow using the Krakatoa Birth/Update operators. In the Update operator, UNCHECK the Position channel so only the COLOR channel is updated. This will force the particles to get the projected color from each frame saved to PRT, but the positions are now free to be modified.
*Use some Forces/Deflectors/Whatever operators in PFlow to move the particles around - they will float in space, but their color will be based off the color at their original static position from the first pass.
Thanks a lot again and again ! I will try this. I had a trick like that in mind already but prt birth can be slow as well with 10+ mio particles loaded. I will post my experiences here
the project itslef unfortunately never happened but I learned a ton on how to speed up the process, do it in at least 3 ways(e.g. moving objects and multiple cameras) possible and how to utilize the newer Krakatoa tool sets. (My old test was done in 2007 with the beta of Krakatoa i believe and before i joined Frantic…)