so… I’ve finally had some time to make a couple of tests.
I have to say that I’m amazed by the speed of rendering.
I’ve imported 300000 RealFlow particles with a Krakatoa PRT-Loader and I followed the tutorial
“Saving Particles to Disk” and have a couple of questions:
Render “Loader’s material color” doesn’t seem to change anything on the render (I’ve saved my particles as prt files, they are no longer bin files). Is this expected behavior?
When I try to render the sequence I get this “channel_map::append_channel()” error.
>Is it possible to keep .bin UV information to texture these >particles with a bitmap? Or to assign UV information to a >PRT Loader? >I saw the sample with the car and wanted to try something >similar. >
The car does not really use any UV coordinates. In the original case, we used an internal per-pixel projection map, in the online tutorial I faked the projection using PFlow Tools Box #3.
PRT Files can contain up to 100 UV channels (all the Max supports). The UV coordinates from the BIN file are being copied to the TextureCoord (Map Channel 1) inside of Krakatoa, so using textures that project on channel 1 should be possible.
You can also use object space coordinates instead of UV mapping when applying procedural textures like Cellular, Noise etc.
In general, you should be able to use BIN files directly for rendering instead of resaving to PRT, although PRT have their advantages. If there is no color info in the BIN (or PRT), a default color of white is used. As you have discovered, you can override it via the Global Overrides and use a solid color or the Material Editor Slot #1 instead.
For the next update (1.1.0), we just added a channel map viewer to the Editor that is supposed to open when you press the Edit… button in the PRT Loader. (This is broken in 1.0.1, see thread in this forum for a fix).
So in the next update, you will be able to SEE for each sequence what channels were actually saved in each file you are loading - I looked at a typical BIN file and it does not have a Color channel, but does have UVs and everything else according to the BIN file specs.
We only map some of these channels to Krakatoa channels as Krakatoa does not support things like Mass etc. When saving BINs, it populates such channels with defaults values like 1.0 or 0.0.
>One more question :) > >I followed the tutorial about aladdin's lamp with RF >particles and the casted shadows appear to be the same frame >through all the frames. >Is there anything I might be doing wrong? >
I don't see a reason for that, but you could dig deeper and figure out what happened yourself:
*Firt look at the folder containing the shadow maps saved by Krakatoa. There must be also an IFL animation file. Load it into RAM Player and see if it plays back as expected.
*If it played back correctly, look at the Map assigned to your light's Projector slot and see if it contains that same IFL file. Also check out the Timing of the map.
One thing to keep in mind - RF has the bad habit of adding 5 digits to the name of the emitter without any delimiters. So if you had an emitter called "Circle01", you end up with BIN files called "Circle0100001.bin" etc. Of course, Krakatoa sees this as frame 100001 and you would have to offset the animation a lot to get the BINs playing. I don't expect this to have an influence on the shadow casting (the real particle rendering would be wrong, too), but it is worth mentioning.
To avoid the above problem, add an _ to the end of the emitter's name (and if you ever meet the programmers who made that design decision, kick them from me ;o)
Thanks for testing out the RF integration - I am sure you will find lots of things we are not aware of because we don't really use RF that much. So please keep on posting your findings and we will try to improve the integration...
Since the BIN file does not contain a dedicated Density channel, we assume the density of each particle loaded from BIN to be 1.0.
When loading in a PRT Loader and rendering, the density should be affected by the global Density Per Particle spinners - try setting them to 5.0 and -4 (which means 0.0005) or even lower and see if that changes anything.
Also, if you are assigning a material and the “Scale Density Using Material Opacity” option is on, the Opacity channel of the material incl. any maps will also control the density.
On top of that, the Visibility channel of the PRT Loader could also be set to less than 1.0 (or animated for reveals and disappearances) and will additionally modulate the density.
Partitioning only works with PFlow and similar systems that have random seeds. Loading a BIN file via a PRT Loader has no way of changing the random distribution of particles, thus it cannot be used to create Partitions.
I have to say that it work like a charm, the only problem I’m encountering from time to time is at the time of rendering a sequence; I have to disable “Scale Density Using Material Opacity”, perhaps you want to give it a try in case it’s something problematic.
By “texture” do you mean “add UV coordinates” or “apply a texture map”?
You can do the former only if you would load the PRT file into PFlow (using the upcoming Krakatoa 1.1 toolset, cannot do that effectively in 1.0.1 unless your particles count does not change over time) and apply mapping there using using some of the PFlow Toolbox extensions.
Tha latter can be done using object/world space coordinates, but otherwise you have to have generated UVs in the PRT/BIN in order to use them, and I am not sure what mapping coordinates the BIN file might bring over from RealFlow, if any.
In the PRT Loader, there is an drop-down list specifying the color source - you can use the color saved in the particle files (if any), use the Wireframe color of the PRT Loader (the object color used for wireframe display in Max) or the Material assigned to the PRT Loader (including texture maps).
So you could switch your loaders to use either the wireframe or the material option (there is a mass-switching section in the PRT Loaders rollout of the Krakatoa GUI to affect any number of selected Loaders at once) and then set the wirecolor or the material for each PRT Loader to make them look different.
