Well, getting a slight grasp to it, strictly on the simple side but wow this is cool!
Absorbtion: (interesting ping with alpha knocks out on the forums)
Color by velocity (thanks for the example Bobo) I tried something similar using temperature but I couldn’t seem to get an data from the fume sim (I exported temp. from fume and added the channel to the prt before saving the particles) all I would get were black particles even though my color was set to red? Any ideas?
The additional FumeFX channels might not be implemented yet internally (have not looked or asked, will find out tomorrow).
I just put them on the list because they are likely coming (read below).
Self-Illumination maps/color are not used YET. Our Beta 6 internal build has the Emission channel already exposed and you will be able to define Emission (self-illumination) per particle via KCMs next week. Later we intend to populate all three channels (Color/Scatter, Emission and Absorption) based on the values of the current material.
In addition, the Additive/Volumetric/Constant Alpha modes will be likely removed and you will be able to mix Additive and Volumetric rendering by simply modifying the three channels (additive rendering is self-illuminated and has no absorption). This will also let you define self-illuminated fire particles/voxels where the fire channel is defined in the FumeFX and transition into volumetric smoke where there is no fire the same way FumeFX renders them natively.
Also the Use Scene Lighting button will be modified to just control whether the scene lights will be used or not. If particles have data in the emission channel, they will render as self-illuminated. If they don’t, they will render black unless you enable the lights. Right now, the Use Lighting button switches the whole renderer into a mode where the Scatter data (Color channel) is used as Emission color. We want to unify things so there is one render mode and the content of the channels will define how each particle will render. Since the Lighting channel is also available and savable, you will be able to pre-light particles and then tweak the Lighting in a KCM or completely change the render results by manipulating the Lighting Channel and the three shading channels with scene lights turned off.
Great, sometimes it’s hard for me to tell, so much is evolving so quickly.
That is off the top! so you are saying you will be able to define, bake, and manipulate particle lighting and render both voxels and points at the same time?
You can already save and manipulate Lighting. Just add the Lighting channel to the Save Channels when saving PRTs.
Then in KCM you can load the Lighting channel and use to Multiply with the Color (Channel, Vector, whatever) and dump into the Color channel - this will also show the lighting in the viewport! With Use Scene Lighting turned off, you will be able to render particles that look illuminated. Of course you can scale or manipulate the value of the Lighting channel any way you want.
At this point, you will be able to render either points or voxels. (There might be some form of a hybrid render mode in the future, but for 1.5 most probably not). What I said was that you will be able to mix Volumetric and Additve shading in the same rendered image (something that is Either/Or right now). Obviously this will be implemented for Voxel rendering first, then the Point renderer should also be modified to support the Emission and Absorption channels to do the same.
LOL, Sorry, I misunderstood the sentence. “This will also let you define self-illuminated fire particles/voxels where the fire channel is defined in the FumeFX and transition into volumetric smoke where there is no fire the same way FumeFX renders them natively.”
That will be nice, one less pass to render and mix.
Thank you for the clarification. as you can see I get excited easily, poor Oleg has to deal with this too
We tested the Temperature and Fuel channels and they are correctly written out, provided you exported them from Fume and checked them in the Krakatoa FumeFX Modifier. Unfortunately, we don’t support the Fire data yet which is not really a voxel channel but some derived data which we will attempt to get to later.
As of today, we also support Fire, and it Burns, Burns, Burns, the Ring of Fi…uh you know. (insert Adam Lambert performance here).
We intend to change the way the FumeFX is loaded, so the Modifier will be used as an override to DISABLE the loading of channels you don’t want as opposed to the current enabling of their loading. So it would be harder to have a user error since it will try to load them all.
I updated the list of new features again so you can get an idea of the progress on Beta 6. For example environment reflections are now nearly 4 times faster on an 8 core machine (exactly as fast as a regular light pass when voxel rendering). We got proper support of BlackOps including full editing. Just before the end of the day Darcy got the modifier stack to evaluate in order so deformation modifiers can affect the results in following KCMs… And more to come.
Yep, user error, no fumefx modifier, but why I am getting velocity data?(EDIT: PFlow) Also I did notice I cannot use fumefx birth or follow with the fumefx modifer, the data doesn’t seem to pass through the KRK FumeFX Modifier. If I of course remove the modifer my particle stream comes back (if I add it back again and scrub I get a crash)
I should still be able to get temp/fuel/vel data as it is still being written by fume. Shouldn’t I?
That is a good idea as a disable instead of enable.
Fire really! excellent! (I feel I am beginning to say this often, it stills holds as much weight )
So it seems velocity is written without it or it is gathering velocity from pflow, that is my guess, anyway, I have no idea what is happening internally. I tried adding the fumefx modifier and scrubbing a few more times crashes consistently. Not sure if it was designed to do this or not. Is it just for simple/object sources? I guess I am a little confused. I thought the FFX mod was only for direct Krk FumeFX rendering or writing to PRT.
The proscess I have been following.
Setup pflow
Add FumeFX grid, set params, ect. + particle source
Simulate
Turn off PF source 01
Add PF Source 02
Add FFX Birth and Follow
Set Krakatoa as renderer
Select channels, set folder
Save Particles
Create PRT & Load
Tweak renderer
Any ideas? or was I silly to think that it would work the way I thought it would work. ie Fume driven particles with a Krakatoa FumeFX Modifier to trap temp/fuel data.
As it is, it was the only way to get fire without using simple/object sources into Krakatoa.
I must be missing something. The build you have does not support Fire yet. It works internally in our yesterday’s build. Darcy is sick today, so you will have to wait until the end of the week or so before you can access the Fire channel which does not exist as such in the sim, it is a derived value we had to read through the SDK.
What we did here was:
*Create a FumeFX grid.
*Put a teapot in it, make it a source.
*Simulate
*Save FumeFX to PRT with the Fire etc. channels saved
*Load PRT
*Drop KCM on top
*Read the channels and set Emission (Beta 6 feature) where the Fire is.
*Render after some tweaking.
What we want to do is:
*Add a KCM on top of the FumeFX and read straight from it and render without intermediate PRTs. But this is just a wishlist item, we will see.
You can read the Temperature and Fuel channels right now, but the Fuel is usually set so it does not output anything since all the Fuel burns out immediately, and Temperature is not much hotter where the Fire is than in the rest of the smoke so it is not easy to use to get fire.
It is. It does absolutely nothing. All it does it tell Krakatoa the Renderer to grab certain data from the Fume and render it.
Scrubbing the viewport does not do anything inside that modifier, so if it crashes, it is possibly something else going wrong, like the usual FumeFx + PFlow problems. Perhaps the Fume PFlow Operators don’t like the fact the Fume Grid has a modifier on top? We will have a hard time fixing this if it is not in our code.
Try adding some other modifier like an empty Attribute Holder and see if it crashes with it.
Your not missing anything, my typo, “without” should not be in that sentence. I should clarify fire as in particle driven fire motion, not the actual fire channel. Sorry to confuse.
As for the FumeFX stack, anything on top of the FumeFX grid object seems to visually stop the data flow, so yes, it appears to be a Fume issue. It is too bad that it doesn’t work, it would be nice to grab that additional data when driving with particles. Out of curiosity, do you think it could be done with a custom pflow operator?
As for temp, I was thinking/hoping that their would be enough variation in temp to more accurately color a pflow based fire driven PRT. Since you have included the fire channel this may now be a moot point.
I certainly don’t mind waiting, better Darcy is better being sick is no fun. well wishes.
as you can see I get excited easily, poor Oleg has to deal with this too 
)
