hi, is there anywhere we can post suggestions for this wonderful renderer?
or only possible in betaforum?
i ask because i have a few,
and was just wondering, if it would be possible for future versions to render particles trajectory,
so it would look similar like the Lines Display in partice flow viewport,
it would be great to choose amounts of frames to draw backwards (or forwards)
i know this is essentially motion blur, but it could would be rendered in oneframe (Faster) and wouldnt have a fading opacity)
would be nice feature to show particle motion & trails without adding thousands of extra particles
Regarding the line drawing - before the current motion blur was implemented, our original head of RnD Mark Wiebe experimented with line drawing, but it showed to be difficult to combine with the density functions being used to render attenuation maps and the final rendering, so he opted for the multipass approach.
What you are asking for is not so much a faster motion blur but a longer particle “shape”. The wish for drawing particles as something else than points is on the list, and the ability to draw a single particle as a long strand or bezier spline based on a couple of additional channels (for hair rendering for example) has also been proposed before.
Whether or when that might happen is indeed a matter for Beta forum discussions though.
It is possible, of course, to produce such an effect now, but it’s not a one-click operation. If you really need this, let us know, and we can describe some options.
Hi Chad,
i would appreciate if you can give me an insight on your workflow, is it a spawn by travel to leave particles on the trail or how do you mean?
if you got the time id be glad to see how u do it
Something else to consider is that you could multiply the density by the reciprocal of the motion blur sample count to counteract the opacity change with the existing motion blur.
Another option is to use multiple PRT Loaders, each with an temporal offset (subframe). The PRT Loader will extrapolate the positions from the position and velocity channels.
“Another option is to use multiple PRT Loaders, each with an temporal offset (subframe).”
great idea didnt think of that, that would also be a great modifier addition for prt loader (or volume) that automatically lets you add the frame offset and not have to manually have to add 10-100 prt loaders each with differen offset