PRT Loader not showing Saved Colors with Material

Deprecated Krakatoa 1.5 Beta Discussion
1

1.4.9.36818

Trying to render out some old scenes for SIGGraph material, but getting no love. So much broken in new beta (not broken broken, just not backward compatible broken). But something seems broken broken…

Loaded in a PRT with a valid color channel. Set mode to Saved Particle Colors. Shows up fine. Set mode to Material Color, it turns to wire color. Assign default material, it stays wire color. Minor gripe, no big deal. But if I change it back to Saved Particle Colors or Wireframe Color, it stays Material Color. Makes working with KCM’s really hard, since I can’t see the results in the viewport now.

  • Chad
2

Thanks for the bug report and sorry for the inconvenience! (We are not getting enough reports, good to see one for a change…)

The Standard Material support was rewritten from scratch in 1.4.8 and it looks like it does not behave as expected in many respects.
Darcy is away on a mission right now, I hope we will be able to take a look at this later tonight.

The original plan was to use the render dropdown list to decide what will be seen by the KCM, not what will be seen by the renderer. So a material would always override the color channel after the modifiers, but the KCM could see either the loader’s color or the material’s color to do other things with the data, like modifying or populating other channels. As far as I can see, this does not work right now.

The logic behind this decision was that materials would be simple overrides of data channels, with KCMs employed by advanced users IN PLACE of materials. We had the choice to evaluate the material either before the modifier stack or after it. In Max, the material is at the node level, and we wanted to allow the KCM to see the loaded channel before it gets overwritten by the material. At a certain point in time, we had a Krakatoa Material Modifier planned - one would place it on the stack to define the time the material would be evaluated, but that idea was dropped. Combining the new shading features (incl. KCMs) with the old way of doing things (materials and maps) was not easy and we had to make a decision.

In short, if you want to use a KCM to work with Colors, you will have to remove the material from the object.

Please use this thread to discuss how you would prefer PRT Loaders, Materials and KCMs to work together. (Assuming that the Viewport would still be able to show either source based on its drop-down list once the bug is fixed)

3

Ouch. That explains a lot. I was moving a lot of maps around in the KCMs. Gradient to Density, Density plus Gradient to Color, Color plus Cellular to Density, etc. Had 7 KCM’s on there. None of that is working now.

Is it an issue with materials or maps? I can live without material support, but not without map support… I’m constantly tweaking the colors with gradients, color corrects, noise, etc. Is that working?

Right now I’m confused as well because I’ve deleted all my KCM’s and se the render mode to wireframe, and I’m getting NOTHING in the render. Fast and empty. So I might be having other issues.

:frowning:

I’m going home. Will try fresh tomorrow.

  • Chad
4

KCMs should all work, as long as there is no Standard Material assigned to the PRT Loader. If there IS a Standard Material, its data will overwrite the Color channel. But this has been like that since we introduced the KCMs, so nothing new here.
What is really broken aside from the viewport display of the PRT Loader is that if you put a Vertex Color map in the Standard Material’s Diffuse Map slot, it does not render the Color channel but comes out black. If you do the same with a Krakatoa Material, it works. So it appears the Standard Material is broken in that regard. So if you are tweaking the Color Channel using a shader tree in the Standard Material, it won’t work in the current build (I logged it as bug). If you have the map tree inside a KCM, it should work.

Maps inside KCMs work ok. Just don’t assign a Material to the PRT Loader if you expect to change the Color Channel with a KCM.

5

Ok, here is the current plan:

*Both Color Source lists will be removed from the PRT Loader.
*New “Ignore Material” checkbox will be added to the Viewport section.

When rendering, the following hierarchy will be used for the Color Channel:

Global Color Override (overwrites the Color channel coming from below)
Global KCMs (can get, modify and set the Color channel)
Object Material (overwrites the Color channel coming from below, unless a Vertex Color Map is used to pass it through)
Object KCMs (can get, modify and set the Color channel)
Saved Color from PRT

The above works already, except for the Vertex Color Map support that’s broken.

When showing in the viewport, the bottom 3 sources of the rendering pipeline are supported. The color calculated in them will be displayed, if there are global KCMs or Overrides, they will not be shown (those are render-time-only).

When the Ignore Material checkbox is checked, the color from the bottom 2 sources will be shown - if there is no KCM modifying the color, the Saved Color will be displayed. If there is a KCM, its result will be displayed.

This way, one can use a KCM set to Color and Disabled In Render to visualize other channels in the viewport, for example Normals, Positions, UVs etc. Switching the Ignore Material checkbox would show the channel in the viewport, but the Material color would still render.

We wanted to support the global 3ds Max Display tab “Shaded: Object Color / Material Color” switch for this, but could not find out how to access it via the SDK (it is a Max 1.0 thing and obviously hard to find). So a pre-PRT Loader checkbox must do, and it might be more flexible that way.

Last but not least, with the amount of workflow changes and things that feel “broken” due to differences to Krakatoa 1.1, we are contemplating to release this as Krakatoa 2.0 to avoid any confusion. :wink:

6

Sounds good. So a PRT Loader with no material, and no Color channel will show wirecolor? Will there be a way to show wirecolor otherwise? The Object/Material Color would be ideal, yes.

We said that about 1.0, right? That it should have been released as 1.5 considering how much it had changed during the beta? Frankly the current beta is so different from 1.1, anyone who’s skipped out on the beta will only recognize the “OPEN KRAKATOA GUI…” button.

Regarding my fresh start in the morning, I invalidated the material assignment and the PRT loaders started rendering again. Not sure why a default Standard Mat would mess up a PRT Loader with no modifiers, but at least I’m getting everything back to “normal”.

  • Chad

(Extra wishlist item: In Debug mode, have KMfE check validity of IN:Map. When I have 7 map trees being loaded in, I can’t tell which is the bum one that is causing the downstream “FAILED”.)