We can get color and UVW channels into a map for a PRT Loader currently, and soon we will be able to do it for density. But how about position? If I could get the position channel as a map or a mapping channel, I could assign new maps to the particles based on their positions. So I could recolor some particles with a simple procedural map, like a gradient, without having to store an extra UVW channel that is just XYZ->UVW.
So basically, I would like to be able to “patch” a mapping channel to use the PRT’s position channel.
We have done some work on the new PFlow operators that allows us to do such basic remapping of data, for example dump the position into a mapping channel, dump the velocity into the vertex color channel and so on. This is currently for PFlow loading only, but it could be potentially something we could do in the PRT Loader, too.
Unfortunately, our current roadmap says that any such remappings of channels should be part of the Particle Shading pipeline we intend to build, so I am not sure whether the developers would be crazy about hacking something together instead of doing it right once ;o)
Yup, a switchboard is pretty much what I need. Not unlike how Fusion does OpenEXR loading.
We can use the Pflow workflow for now, but the overhead and low particle counts might totally suck. But hey, won’t know til I try, so I’ll start downloading now.
>Yup, a switchboard is pretty much what I need. Not unlike >how Fusion does OpenEXR loading. > >We can use the Pflow workflow for now, but the overhead and >low particle counts might totally suck. But hey, won't know >til I try, so I'll start downloading now. >
Chad,
The new PFlow operators workflow is specifically for people who WANT to import PRT into PFlow, for example from RealFlow, Maya, Houdini etc. (As it reads both PRT and BIN files).
We are far from the idea to ask you to use PFlow as an intermediate converter of channels because we understand that pushing billions of particles through it would be a nightmare. It is just that we have long-term plans for channel management and adding a hack to the current incarnation of the PRT Loader would be a bad design decision. That being said, if your production depends on it, we will have to discuss a solution...
I’ll play around with the new beta first. Right now we’re doing OK with just the 1 UVW channel by just “packing” the mapping into offset regions. And if the new handling of Density works out, we shouldn’t need nearly as many PRT revisions, so we could be relieving a lot of the production grind with what we have right now.
I want to try the new Pflow operators anyway, because we have some more box#3 ideas to try. I like particles.
>We can get color and UVW channels into a map for a PRT >Loader currently, and soon we will be able to do it for >density. But how about position? If I could get the >position channel as a map or a mapping channel, I could >assign new maps to the particles based on their positions. >So I could recolor some particles with a simple procedural >map, like a gradient, without having to store an extra UVW >channel that is just XYZ->UVW. > >So basically, I would like to be able to "patch" a mapping >channel to use the PRT's position channel. >
Hi Chad,
Can you identify any other use cases or capabilities of such a feature (esp. after having seen the Channels Editor in the File Update PFlow operator) and tell us what the PRT Loader should be able to do in the minimal case?
For example, the PRT Loader would probably not feature blending modes and percentages, but could have a static (or animatable?) multiplier, for example to be able to scale down position data to map to a different color or UVW coordinates range.
The Krak-FU op looked good, though I didn’t play around with it too much (crashing thing).
Multiplier and Offset would be essential. I suppose any normalizing would be slow, since it can’t do it point-by-point, so unless you have some voodoo for that, it’s non-essential. Things like Gamma or Contrast or Clamping would be nice, but are not essential.
It would be pretty important to be able to change depth, though. If we want to convert color (float16[3]) into position (float32[3]) it should handle that conversion for us. Same thing if the input channel is int8[3}. I think these should be automatic. The multiplier and offset would be used to compensate for data that gets into funny ranges because of the conversion.
However, we might want some control when we change arity. If we are converting float16[3] to float16, does it use one of the triplet or does it average them together? Might be nice to allow us to decide that. Like an R,G,B,L kind of thing.
How is the memory handled for PRT Loaders? Is it only using color (RGB) for the points drawn in the viewport? Or are all the channels loaded into memory for the viewed points? I assume it just streams the data as needed per point, and outputs just the color, but I could be wrong.
Seems to me you could implement the switchboard into the “edit” window. You already list all the channels each PRT has. Could you not let us select some cells, and have a “convert” menu option that shows us our options? Then you could change the color of the cells to indicate A) that they are being used elsewhere or B) are getting their data from elsewhere? Doubleclick the cells to change the options? I dunno, just seems like it would be too complex of a UI to put in the regular modifier panel.
We intend to release the 1.1 version next week as planned (provided it is stable enough) and then continue with further Beta builds towards 1.2 where we will implement the channel retargeting and some more things that were not addressed this time around.
We intend to start implementing additions to the PRT Loader as modifiers your can drop on the stack. Attached is a screenshot of the UI of an early prototype of the Channels modifier.
>Yay modifiers! > >So when can we start making our own? We want to make a >PRTSkin among others. >
We discussed this yesterday. As soon as we start splitting the PRT Loader itself into a set of modifiers (for culling, shading control etc.), we will probably expose some sort of API for 3rd parties to make their own. Cannot tell you a date yet, let's see what the developers think.