any chances of getting a PRT Light object in the future? it would/could treat prt loaders or direct pflow/tp systems (pick like frost) and turn them into omni lights,
so krakatoa would treat these “points” as a lights,
there is a script to position omni lights in fplow as script operator, but what if i have 100 million particles and would like a thousand lights to light the partition, would it make sense to have a PRT Light object instance an omni light in the scene only to internally act as a light source for krakatoa?
if i had 1 percent of the particles of the partition act as a light source, this would already be 100,000 omni lights, and wouldnt really work in the scene, but if krakatoa interprets it as one mini-light source might work fast and allow new possibilities?
In the scope of possible future Global Illumination feature, any particle with Emission channel value could act as a light source, illuminating the other particles.
Now “all” we have to do is develop that feature
before it goes completely GI, wouldnt it be a good start then to have a new light channel that is not emissive but just creates light at each preferred point?
just making a particle (and then some more) an omni light with a master controller for intensity and decay
Nothing stopping you from doing this now, right? The main problem will be the speed. If each particle generates 6 shadow maps, then for say 10000 particles you’d have 60000 sorting steps and 60000 lighting pass renders. Me personally? I find the renders to get a bit slow when you have as few as 200 lights.
exactly! why id thought itd be nice to have a light object which generates its light from multiple points in space, but not have to regenerate its data for each of the 200 source points, all sharing the same instanced light data, acting as one light
Krakatoa’s lighting algorithm requires particles to be sorted relative to the light so that means that having 100 particles acting like omni lights is exactly the same cost as having 100 actual omni lights. This doesn’t mean your idea can’t be done, it just means its a completely different lighting algorithm.
I can think of lots of alternative means of doing lighting, but they all come with tradeoffs. Like you could build a voxel sampling that you raymarched though. Or you could render a subset of particles for lighting and diffuse the lighting information to the full particle set. Or you could render the lighting at larger timesteps and interpolate the values for the rasterizing timesteps. There’s weirder ideas too that I’m not sure would be practical.
Getting faster sorting would be a nicer solution for getting the predictable results we’re used to with Krakatoa.
But from what I understand, the actual sorting is very fast, you are just transforming the particles, binning them, and then comparing the Z against the already sorted particles in the bins, right? Meaning there probably isn’t a way to get that much faster. Like a binned pre-sort done before the transform or something like that would involve some sort of lookup and wouldn’t be any faster?
Could we sort the binned particles faster on a GPU? Or would there be a bandwidth limitation?
Would it be more practical to do lighting passes on Deadline and output PRT’s that were just ID and lighting and accumulate those together as a post-processing job? Hmmm… What about sorting jobs that just output the ID and sort index along with a global sort origin point? Would the I/O and assignment of the sort index be slower than doing a re-sort?
Since sorting indices was mentioned, a word of warning - in the early days of Krakatoa 1.0, we tried to sort just the indices of the particles. The result was SIGNIFICANTLY slower particle data access during the drawing phase because the particles were accessed out of order. For that reason, Krakatoa currently sorts the actual particle stream which allows for much faster memory access during the drawing phase.
