Is it possible (currently) to bake lighting into the colors of a PRT? I’m thinking I would load the PRT, set up the lights, and save out a PRT. But that’s not doing it, so I’m thinking there’s no function for that.
- Chad
Is it possible (currently) to
bake lighting into the colors
of a PRT? I’m thinking I
would load the PRT, set up the
lights, and save out a PRT.
But that’s not doing it, so
I’m thinking there’s no
function for that.
Not currently, but it sounds straight-forward enough. Will log it as a request and let’s hope it will make it into 1.1.0
Talked to the developers, they plan to get this done soon.
Currently, the suggested workflow would be
*The Lighting (attenuation data) will be stored in a separate dedicated channel.
*When a PRT Loader is loading a sequence with a Lighting channel, and if USE LIGHTING is UNchecked in the GUI, the saved lighting will be used. If the USE LIGHTING option is checked, the PRT will be re-lit and the channel will not be used.
This way, you would be able to replace the color/material/mapping of a PRT sequence and still keep the baked lighting.
The alternative would be to bake the final resulting color (particle color * lighting) into the existing Color channel which would save you a channel, but you would not be able to replace the color and keep the lighting.
Any thoughts?
I originally wanted the lighting baked into the color for two reasons. One, so I could get a viewport display of the shading, and two, so I could bake the lighting in once and then play around with motion blur, camera angles, or DOF on an animation, not just a still.
What you are proposing with a presumably vector channel for the lighting would be really nice, especially if I could access it from the material editor, so I could multiply the lighting by the color to get the lit color and put THAT into my viewport. Or I could do artistic things, like put a LUT on the lighting. NPR Krakatoa?
Hmmm… More CPU and memory overhead in exchange for more flexibility? Tough call. Both seem appealing, but I don’t want to be too greedy.
- Chad
Hmmm… More CPU and memory
overhead in exchange for more
flexibility? Tough call.
Both seem appealing, but I
don’t want to be too greedy.
There will be no CPU or Memory overhead involved - the Lighting channel exists already in memory (it is what is being used when calculating lighting and when using the LCache), the main change would be in an additional (Float?) channel in the PRT which would dump its content into the existing Lighting channel in memory and skip the illumination by dynamic lights. In a way, it will work like the PCache+LCache now (PCache keeps all the data except the Lighting channel; LCache keeps the attenuation data separately so when it is off, you can still apply dynamic lighting), but using PRTs instead of RAM - you would be able to load any frame from a pre-saved sequence and render it without having to light it.
We have plans for a Krakatoa Shading Language somewhere in the future so one day you would be able to manipulate and combine any channels any way you like. So it is a good idea to implement things with this in mind…
I meant there would be CPU overhead to get the lighting to show up in the viewport, as you would have to combine the color and illumination into a new color channel.
I would expect the illumination to be 3 floats, at least 16 bit. That could take up a lot of space in the PRT’s themselves, as opposed to actually modifying the color channel which in our case is usually there anyway.
If we couldn’t get the illumination out of the PRT into something we could edit, like the vertex illum channel (that would be ideal, right?) then the flexibility of having it as a separate channel would be lost.
BTW, I still am hoping for getting the density into the vertex alpha channel. Along the same lines, having the ability to edit that is really important.
- Chad