What is Krakatoa evaluating as the normal? Is it the Z axis of the particle? Or something else?
Also, allow me to re-iterate a wish for a specular color and/or a diffuse level. I’d ideally like to be able to make a specular pass and a diffuse pass for compositing.
Looks like X with the tests I’m doing.
I have a little red, green, and blue axis tripod mesh now that I am instancing to the shape. Definately helps clear things up. Now I just need to get my TM math right.
Looks like X with the tests
I’m doing.
This is correct. We went with it because it turned out that the X axis of a particle is the direction the force/speed is applied along in PFlow.
If you cover a mesh with particles using Position Object, then apply Speed By Surface along normals to turn your particles and then kill the speed, all particles will render as you would expect them in Krakatoa. If you would add a random Spin, it creates fantastic sparkling effects.
I hear you about the diffuse color / passes, not sure if it will happen for 1.0 though as there are still some major bugs open (shadows from Omni lights, Non-Square Pixels support etc.)
Word from development is that we want to add general support for Render Elements to Krakatoa first, then pass separation would happen naturally. We have also plans for advancements in the shading system, channel management etc. Add to that normal calculation from density gradients. All these are post 1.0. So at this point it looks like what you have is what will ship in the initial release.
Oh, I don’t need the render passes “built in”.
I would just manually set the diffuse to 0 to render the specular pass, and the specular to 0 to render the diffuse pass.
Or us RPManager. I don’t need to use anything fancy like “render elements” or some such.
If I could color the specular independantly, then I would just make that non-black and make the particle colors black and that would make a specular pass. If I couldn’t color the specular, I would need a “diffuse level” or somesuch that I could set to 0.
Hmmm… I COULD do a render now with specular level set to 0 and subtract that from the full render to get the specular, but that’s sketchy. Off to test…
Ok, so I made some metallic kidneys… Now I need to know what the heck “use normals” is doing.
It’s faster. And looks very different. But it isn’t the “scatter plus gradients” I was expecting. It’s not volumetric + phong, but something altogether different.
Is a completely different render system? Is it possible to have some particles “use normals” but others not?
Ok, so I made some metallic
kidneys… Now I need to know
what the heck “use normals” is
doing.
It’s faster. And looks very
different. But it isn’t the
“scatter plus gradients” I was
expecting. It’s not
volumetric + phong, but
something altogether
different.
Here is what I know about it.
When rendering without Normals, each particle is illuminated fully by the light except for the attenuation maps shadowing. So if you have particles on a SURFACE (as opposed to volume), for example the vertices of a 64 segments teapot, each particle is illuminated identically. Some particles might get in a shadow, but the backside of such an object would be illuminated the same as the front side.
When you turn on the Use Normals switch, each particle is illuminated like a point on the surface would get illuminated in any renderer based on its orientation to the light sources, so it gets more or less light based on the angle to the source. If its normal is parallel to the light source, it would not get any light. If its normal is facing the light source, it would get all the light. And the Blinn shading model in between…
Is a completely different
render system? Is it possible
to have some particles “use
normals” but others not?
Nope, it is just an option inside the current lighting system to shade each particle based on Blinn specular highlight calculation. If it looks strange, it might be a bug or just a strangeness of having a volumetric cloud being illuminated according to the Blinn model - we are used to seeing surfaces lit that way, volumetric clouds might look different…
We have huge plans for future Krakatoa versions with regards to shading, but at this point the “use normals” is a global switch. In order to allow different particles to use different shading methods, each particle would have to at least “know” which object it originated from in order to be able to access local shader data associated with that object (like the specular settings of the standard material assigned to a PFlow or a geometry object). This would be possible by storing such data in a custom channel (now that we can support arbitrary data channels), but it just not gonna happen for 1.0.
Right now, all particles are loaded into a huge buffer and have a color channel and a normal channel derived from the material of the object they came from or from the GUI settings in Krakatoa, but then they are all handled as a single point cloud.
Yeah, volumetric + specular is not something the eye is expecting. Shiny surfaces don’t also scatter.
But hey, that’s what compositing is for.
I am not using meshes to define the particles, but using Box3 to set the normal for each particle based on density gradient and texture gradient. The reason I ask about rendering both modes together is that only particles on the gradient make valid normals. Interior ones end up with a normal vector of 0,0,0 and thus shade incorrectly.
I can’t currently say “these particles have normals, but these don’t”, and shade accordingly. No problem really, just checking.
I guess the only way to have some particles render with normals and some without would be to use two PRT loaders - one for the surface particles , one with “Load Particle Normals” turned off loading the inside particles. (If you can split them somehow into two PRT sequences, you could try that out).
Ok, I’ll try that.
Ok, so here’s some tests with normals. 8 million particles based on the standard 3D map Waves. Don’t have Darktree for max 9, so I don’t have much map selection to work with.
With and without normals, and a test with speculars and DOF.
Something that bugged me… The Specular Level and Glossiness are both integer, and the Level clamps at 1000.
The values are integers and clamped because they mimic the Standard Material controls (which are, surprise! both integers and Level is clamped to 999) :o)
We could change that of you really need higher levels…
I was trying to get JUST the speculars by setting the color to 1,1,1 and letting really bright lights pull out the speculars. Couldn’t get the effect I wanted, which was basically similar to what I had on those tests back in the early beta where I was baking the specular into the script vector channel.
I’ve been using Brazil so long, I’ve forgotten how the standard material works.
Both values are now floats and the Level is virtually uncapped. Should it have any cap?
They have always been floats in Krakatoa, I just exposed them in the GUI with capped integer spinners to match Max. So the change was trivial and only in the scripted GUI.
I guess the only way to have
some particles render with
normals and some without would
be to use two PRT loaders -
one for the surface particles
, one with “Load Particle
Normals” turned off loading
the inside particles. (If you
can split them somehow into
two PRT sequences, you could
try that out).
Doesn’t work.
The checkbox for “Load Particle Normals” doesn’t seem to do anything when dealing with a PRT that has been saved with normals, and when rendering with normals. The render looks identical with or without it checked.
If I don’t save the normals to the PRT file, then it also doesn’t do anything, but I expect that.
What’s odd is what happens if you don’t save the normals to the PRT but render with normals. It’s… different. Can’t really tell what is happening.