If you are wondering where the next build is, here some info on what is going on:
We felt that the current material and color source handling was rather convoluted, and with the addition of PRT Loaders became inconsistent. So we decided to fix these things before 1.0 to make our life easier in the future, and your life even easier in the near future.
For example, the color controls in the Main Controls rollout applied to the scene particles except for PRT Loaders which had their own sources, but two of the modes (Blended Camera Distance and Z-Depth) were again an exception and affected both groups of particle sources.
The Script Vector Channel applied only to specific PFlows that had it enabled, but to nothing else.
The Custom Material in the GUI was cumbersome to use because MAXScript material buttons do not support drag and drop outside of the Material Editor and so on.
Exceptions are bad and confusing.
So we removed them.
In the future, every particle source will render according to its material. If there is no material, its wireframe color will be used. This means that a default PFlow will render in the same color it would render in Scanline or mental ray. A geometry object would also render in the color shown in the viewport - if it has a material, the DIFFUSE color will be used - we now set the ambient light to 100% in the render context automatically, so you don’t have to bump up the Self-Illumination to 100% before you can see any particles!
The Particle Color in the Main Controls rollout is now an OPTIONAL OVERRIDE for the whole scene, including PRT Loaders. So if you want all your particles in a certain color, turn on the override and pick the color. Instead of Custom Material, we now allow you to select the First Material Editor Slot to apply to the whole scene. And the 3rd and 4th options are still Blended Z Depth and Camera Distance.
Similarly, the Density controls now only support scaling by Material Opacity, which is a simple checkbox. All other options were removed.
Instead, we now provide automatic mapping between particle channels. Krakatoa checks the particle source for channels it needs, for example Position, Velocity and so on. If it cannot find the data, it fills it with defaults, for example a geometry vertex has a velocity of [0,0,0]. If the Material requires a certain UV channel, Krakatoa supports all 100 of them. Even better - if the PFlow has a Script Vector channel enabled, it is automatically copied to a UV channel and can be easily enabled with a Vertex Color Map pointing at that Channel. Same with Script Float Channel which can be put into either the Diffuse map slot (as grayscale) or the Opacity slot (to scale Density). You can, of course, visualize any UV channel available in the particle system using the Vertex Color Map. Thus, the Density Scaling by Vertex Color or Script Float Channel options are gone from the Main Controls rollout and are a special case of UV channel mapping via Vertex Color Map in your material.
This is, of course, not all - ALL these channels can now be saved to PRT, so the PRT is a full mirror of the Particle Source, including any supported particle channels and UVW channels! So loading a PRT file would now allow you to access all the data that was originally available in the initial particle source, including any UVW channels! Of course, we will provide a channel selector rollout where you can specify which channels you want saved to PRT, so if you want only positions and nothing else, now it will be possible! (even velocities with no positions would be possible, for example for driving particles with the Krakatoa File Position with Apply Position unchecked!) This will lead to much smaller PRT files if desired, and much richer PRT files when more channels are needed.
The ultimate goal is to pave to road for a future Krakatoa Shading system (post 1.0) where you would be able to create your custom shaders and reference channels like Velocity, Age, Orientation and so on regardless of whether you are shading PFlow particles, Geometry vertices or particles from a PRT File.
As you can imagine, this is once again a relatively big change to the system and we will release a Beta whenever we feel it is ready for testing.
Thanks for your patience, some exciting things are coming your way!
I’m confused, is there going to be a special map or material for this? How would I get the script vector channel into the diffuse color?
Last time I tried rendering with a map, using output map and vertex color map, it took longer to render. Will speed be signifigantly different?
- Chad
Standard Material. Drop a Vertex Color Map into Diffuse slot or Opacity slot. Select channel 42 for Script Vector or 43 for Script Float Channel (right now we hard-coded them there). Render. Done.
As for speed, I have no benchmarks yet, so I cannot comment on how fast or slow it is.
Right now, we are hijacking the Max shading context evaluation to do the coloring.
In the FUTURE though, we hope to provide custom Krakatoa shading, either through special materials or, if everything goes well, through some form of a Shading Language the way Renderman and Gelato do it.
As for speed, I have no
benchmarks yet, so I cannot
comment on how fast or slow it
is.
Here are some benchmarks from Beta 16.
10 million particles from PRT file, Max 9 64 bit.
Loading and shading with no lighting:
No Material, saved colors and density: 25 sec.
Standard Material, no maps: 33 sec.
Standard Material, one Vertex Color map: 34 sec.
Standard Material, one Noise map in Opacity: 38 sec.
Standard Material, two Noise maps in Opacity and Diffuse: 42 sec.
Standard Material, one Cellular map in Diffuse: 47 sec.
Thus, evaluating a standard material with no maps costs 8 seconds for 10M on my machine.
Between 1-14 seconds for an additional map, heavily dependent on type. Procedural 3D maps are generally slow.
So if you want to shade stuff, you have to use materials and maps. If you can live with standard colors, you can save PRTs with custom color and load those, much faster.
We are just adding more flexibility, at the SAME time price for regular shading in previous builds…
I will post benchmarks of 17 using the same scene when I can.
That’s similar to what I was seeing.
The penalty for adding the vertex color map to get the PRT colors vs loading them directly is 9 seconds, which is pretty severe.
If beta 17 will force us to use vertex color maps, that could slow things down.
When messing around with materials, I’ve been re-saving my PRTs out when I was happy with the new coloring from the maps. That way I could get faster speeds when I was doing my tweaks on the camera, lighting, motion blur, and DOF settings.
- chad
If beta 17 will force us to
use vertex color maps, that
could slow things down.
Uhmm, this is a misunderstanding.
If you saved a PRT with colors you are happy with, you can just keep on loading them and they will show up as before, no time penalty for that.
The addition is that the PRT can save a UV channel so you can RETEXTURE your PRT if you are so inclined, something you could not do before. If you don't want to do that, you can disable the saving of UVs in the PRT and it will be back to what it was in 16.
The main difference is that if you are running a PFlow (which is slow on itself) and want to use a Vector to Float Script Channel (which is even slower), you would have to add a Vertex Color Map to your material to make that script channel visible. Also, the data you produced in the Vector and Float channels will be saved in Map Channels 42 and 43 of the PRT if you enabled UV saving, so you could access the Float and Vector channels of a PFlow ANYTIME IN THE FUTURE in the PRT Loader.
In short, the PRT Loader will have the capability to contain ANY channel PFlow has (yes, even Age and stuff we don't currently use).
To avoid bloating the PRT, we provide filters to enable/disable EVERY possible channel, so you can produce PRTs with exactly the content you want.
Oh, ok, excellent. I didn’t want to HAVE to set up materials each time if I had the color already set in the PRT. No problem, then.
- Chad
Oh, ok, excellent. I didn’t
want to HAVE to set up
materials each time if I had
the color already set in the
PRT. No problem, then.
Dude, my biggest stress on this job is the fear of disappointing YOU. ;o)
Btw, we added 3 spinners to set the bbox of the OSM gizmos, independent from the Icon size. We also made them animatable so you can adjust the gizmo over time.
Awesome. That will help a lot.
- Chad
Ok, trying with beta 17, and I can’t get it to work. I have a pflow where UVW channel 42 and 43 are being set to some colors, but the colors aren’t showing up in the render. It’s using the display operator color (which is weird, since it still uses it even if I remove that operator from the flow). I tried outputting script vector, too, but that isn’t doing anything either.
- Chad
In this scene, have you assigned a material with a vertex colour map set to channel 42 or 42 in its diffuse slot? With no material assigned, the new behaviour is to always use the wire colour, which is the display operator colour in the case of particle flow.
-Mark
Yes, I have a Standard Mat with Vertex Color in the Diffuse Color set to Channel 43, Sub Channel All.
This material is directly assigned to the PF Source. I have also added a Material Static to the Source with this material.
It renders black. Alpha still shows up, but the RGB is all zero. If I disable the Data Operator that is setting the Mapping Channel 43, then I get not the wire color, but the Display operator color.
- Chad
You cannot assign materials directly to the PF Source. PFlow has never worked that way, ever.
Add a Material Dynamic and try again.
The Display Operator color IS the wire color of a PFlow. That’s the color all particles will be drawn in.
Material Dynamic didn’t help either. Still black.
- Chad
Changing to channel 1 for both the Vertex Color Map and the Mapping Vector Channel output from the Data Operator makes it work.
- Chad
Ok, I can’t check performance in Beta 17, so I tried it in Beta 16.
10 million particles, Data Op getting position vector and setting to script vector. Renders in 38 seconds.
Same setup, but Data Op setting to map channel 1, Added Material Static with Vertex Color set to channel 1 in Self Illumination Color channel. Renders in 45 seconds.
That’s a big difference. Would seem to me that the double operation of setting a map channel vector + applying that as a lookup to get the RGB value from a map is much more intensive than just setting the script vector channel and just passing that to the renderer.
I can’t tell if Beta 17 would be doing anything differently if it could.
- Chad
Ok, we are looking into providing direct access to the Krakatoa particle color channel from the Data operator, for example if you would dump the data into Channel 0 (Vertex Colors), Krakatoa would directly render those colors without any material. (Right now you cannot do that, but we will see if we can change it again to allow for channel 0 to override the wireframe color)
Stay tuned.
OK, that would be fine. Vertex color is perfectly interchangable with Script Vector.
But what about the rendering black? Should I persue this? I got channel 1 to work, but not channels 42 & 43.
- Chad
Channels 41 and 44 work fine, too.
- Chad
I think I know what you are doing wrong.
You are actually dumping your data to channels 42 and 43. You are NOT supposed to.
You are supposed to dump the data into Vector Script Channel and Float Script Channel like before (so one could write there with a script, too!), and Krakatoa copies this data into channels 42 and 43 internally when saving to PRT or rendering the Flow.
So you should set your Data Operator to write to Script Vector Channel, then set your Material’s Vertex Color map to read channel 42.
42 and 43 will show as black because the Script Channels contain no data by default ([0,0,0] and 0 respectively), unless you write something there yourself.
The Channels 42 and 43 are a replacement for people who want to use Script Operators to define colors and densities, since writing to the Map channels is not possible via Script Operators. In your case, since you are using Data Operators which are faster and more flexible, you can use any UV channel OTHER THAN 42 and 43, or write to the Script Channels and then use 42 and 43.