My Data Op is writing to Script Vector, and my Vertex Color map is set to Channel 42/43. Neither one renders anything but black.
My Data Op is writing to
Script Vector, and my Vertex
Color map is set to Channel
42/43. Neither one renders
anything but black.
Then it sounds like something it broken :o)
(Testing, appears to be the case)
Why don’t you use another channel in the mean time? When using Data Ops, it doesn’t really matter which one you will pick…
Yeah, using any other mapping channel was fine, so that’s what I’m doing now.
- Chad
Beta 18 now, just to clarify…
Script Vector and Script Float save out to Color and Density in a PRT, right? So I only need the MatEd if I’m changing stuff around?
- Chad
It seems to be saving out the Pflow Display color now. Even on events where the display was inactive, the color was set to black.
- Chad
Beta 18 now, just to
clarify…
Script Vector and Script Float
save out to Color and Density
in a PRT, right? So I only
need the MatEd if I’m changing
stuff around?
Nope.
Script Vector and Script Float do not save anywhere in 18. Our plan is to introduce a PFLow Operator that enables that. It will have checkboxes like “Copy Script Vector to Color Channel” and “Copy Script Float to Density Channel” so you will be in control.
In 18, you can add a Data Operator and dump the color to the Vertex Color channel (map 0), then in Krakatoa set Color Override>Ignore Materials and your colors will appear without a Map because Krakatoa considers a valid vertex color channel (on any object) a color source now.
Don’t think you can get density without a Map right now, but the above saves you a lot of time already.
EDIT: We plan to work on that PFlow operator today ;o)
So what’s the suggested method for adding the density channel to a PRT then?
Sorry, I’m re-doing old scenes for the contest and for Scott, and nothing works anymore. Perils of beta and such.
- Chad
We will try to finish the PFlow operator today or tomorrow and will post a beta.
In the mean time, just dump the density data into any map channel except for 42 and 43 (those were just broken in the process ;o) using a Data operator and use a Vertex Color map to get the data. The color will NOT use Vertex color map, so under the line it should be faster than using two vertex color maps like in Beta 17.
Then in Beta 19, you will be able to get the data from the Scripted Verctor and Float channels via the PFlow channel enabler operator - Krakatoa will make sure all the data is written to the color and density channels directly and it should shade as fast as it used to before we generalized the UV map channels.
Spooky, I answered my own post…
Actually, the Script Float (in 18) does seem to save out the density. I haven’t confirmed that it did so correctly, but it certainly saved SOMETHING other than 0’s.
Beta 19.
Hmmm… I can modify the color of a PRT with a vertex color map set to channel 0, but how do I modify the density of a PRT? Channels 42 and 43 are coming up all black.
Beta 19.
Hmmm… I can modify the
color of a PRT with a vertex
color map set to channel 0,
but how do I modify the
density of a PRT? Channels 42
and 43 are coming up all
black.
Please forget those 42 and 43 channels - we removed support for them two betas ago :o)
From the release notes:
#
RENDERING
…
Added a new PFlow Operator (Krakatoa Options) which allows Script Vector and Float channels to be copied to the Color and Density channels when saving and rendering directly without using a Vertex Color Map to shade.
Changed the way color sources are handled by Krakatoa to allow vertex colors to be shaded directly without a Vertex Color Map (which would still work but would be slower):
* If there is a Material, its color will be used
* If there is no material but there are vertex colors, they will be used
* If there are no vertex colors, the wireframe color will be used
So basically you do this:
* Stuff the color and density data into the Scripted Vector and Float channels like in early days of Krakatoa.
* Drop a Krakatoa Options operator into your flow (in the Emitter to affect all particles, for example).
* Check both checkboxes in the Krakatoa Options to tell it to copy the data into the correct channels.
* Do NOT assign any material to the PFlow
* Save to PRT
RESULT: The saved color channel will contain the values from the Scripted Vector channel, the density channel will contain the values from the Scripted Float channel, no maps involved!
If you render directly, you should see the same result, in the same shading time as around Beta 10-13... Since you complained about the speed of Vertex Color Map shading, we implemented this special PFlow Operator to let you access and copy data from the scripted channels directly. Of course, one can use Script Operators to get the same result, or Data Operators for speed...
Hope this helps!
Ah, the issue is how do I change density values already saved in the PRT?
In the case of the color channel, I can apply a vertex color map, and then mess with the output or put a color correct map on it or whatever.
I can put a map in the opacity slot to affect the density, but I don’t know how to get the existing density into the opacity slot.
- Chad
Ah, the issue is how do I
change density values already
saved in the PRT?
In the case of the color
channel, I can apply a vertex
color map, and then mess with
the output or put a color
correct map on it or whatever.
I can put a map in the opacity
slot to affect the density,
but I don’t know how to get
the existing density into the
opacity slot.
When you load particles using a PRT Loader, the checkbox “Load Particle Densities” controls whether the densities saved in the file will be used or not.
If the checkbutton “>Scale Density Using Material Opacity” in the Main Controls rollout is checked, the values from the PRT file will be multiplied by the Opacity channel if a material is assigned to the PRT Loader. On top of that, the density will be modulated by the Visibility track of the node, and once again adjusted by the Volumetric Density settings.
If the “Load Particle Densities” checkbox is not checked in the PRT Loader, the content of the PRT file’s density channel will be ignored and assumed to be 1.0, the rest will be applied as described above.
This is a departure from the old method where a drop-down list defined what to do with densities. We decided to simplify things, making opacity channel modulation a global switch and letting you either assume all densities to be default 1.0, or get whatever is in the file.
In short:
Read Particle Density (either channel value or 1.0) -> Multiply by Node Visibility -> (if valid material and global switch is on, multiply by material opacity) -> Scale by the value derived from the global Density per Particle value.
So there is no way to change the density value of a PRT based on itself? We can do Density*10 but not Density^2, the way we can with Color?
We can put function curves on color quite easily, or mix it with other maps, especially if we have UVW channels assigned to the PRT’s. I can’t figure out how to do that with density though, other than to overwrite it entirely. Like I can make the density become a cellular map, but I can’t fill the cells with ther existing density values. You know?
- Chad
>We can put function curves on
>color quite easily, or mix it
>with other maps, especially if
>we have UVW channels assigned
>to the PRT's. I can't figure
>out how to do that with
>density though, other than to
>overwrite it entirely. Like I
>can make the density become a
>cellular map, but I can't fill
>the cells with ther existing
>density values. You know?
>
We know :o)
The real solution would be a dedicated Krakatoa shading subsystem where you could design any behavior you want, using any channels and existing maps you want, hopefully in a manner similar to Data Operators creation...
Of course, this is already on the wishlist. I just cannot tell you how long would it take to get there...
(But we have a developer already adding light attenuation ranges support because you asked last week, so who knows... :o)
If we have any interim solutions or workarounds, you will be the first to know!
The obvious thing is to write Density to a UVW channel, but that’s wasting a vector on a scalar. Waste is bad when you have 890 million particles (our current largest single PRT file, and it still works!).
- Chad
Since color goes into vertex color, could you assign density to vertex opacity? I seem to recall that 3ds max’s standard vertex color map is “fixed” so that you can’t get to negative values anymore, but that would be a super easy “unfix” for us to write. I’m not in front of max now to check.
- Chad
Yes, it is “fixed” 
Still, it should be trivial for us to unfix it if PRT Loader were to use those mono channels.
- Chad