Strange Export Error

[GPNMilano]

I've thought about doing additions to the plugin, but everytime I do i get discouraged cause I have way to many projects in the fire right now that juggling additions to the plugin would be way to many.

What I want to do is take some time and sit down with PyPRP and rework the matclasses so that they're more intuitive in blender. This would cause the wiki to need updates, which isn't a huge deal. But I want to do so when I have the time to.

[Lontahv]

After this RAD is over...
I WILL try to get to 2.0 export framework.

Oh, that's all after I've gotten to the moon!
NM that ^ line... RAD-madness.

[GPNMilano]

Regarding how materials are currently handled in PyPRP, one of the things I wanted to experiment with, is the possibility of extending the colors of a layer to no longer be in the materials section of Blender, but in the map to section. There's currently a color feature there, that is handled differently by blender, but what I wanted to experiment with after the RAD is modifying pyprp so that it uses the texture colors in blender for its layer color rather than the material colors in blender.

THe reason for this is that upon export, pyprp takes the blender's material color settings and applies this to all layers covered under that material. This causes some problems with Plasma, and is why sometimes you don't get the right effect when you blend layers together. Some layers require a different color setting, like an alpha layer should not have a blue color, but if your material has say, a lamp flare and an alpha blend, if you color it blue in the material settings it will color both the alpha layer and the flare layer blue. When only the flare layer should be blue while the alpha layer should be a greyish color.

[Paradox]

Regarding how materials are currently handled in PyPRP, one of the things I wanted to experiment with, is the possibility of extending the colors of a layer to no longer be in the materials section of Blender, but in the map to section. There's currently a color feature there, that is handled differently by blender, but what I wanted to experiment with after the RAD is modifying pyprp so that it uses the texture colors in blender for its layer color rather than the material colors in blender.

You would be my hero if you hooked this up

I've thought about doing it a few times, but the material code is just a huge chunk to work through, and I never worked up the interest to change it. With PRC, I've also never really needed to change much of anything...

[GPNMilano]

Regarding how materials are currently handled in PyPRP, one of the things I wanted to experiment with, is the possibility of extending the colors of a layer to no longer be in the materials section of Blender, but in the map to section. There's currently a color feature there, that is handled differently by blender, but what I wanted to experiment with after the RAD is modifying pyprp so that it uses the texture colors in blender for its layer color rather than the material colors in blender.

You would be my hero if you hooked this up

I've thought about doing it a few times, but the material code is just a huge chunk to work through, and I never worked up the interest to change it. With PRC, I've also never really needed to change much of anything...

The only problem I've really seen in doing it this way is the specular color will still remain the same throughout the layers This isn't a huge issue as this setting doesn't really change all that much between layers.

[Paradox]

What about multiplying the colours? Take the texture colour, multiplied by the Material colour... As long as you kept the material colour white, it would use the full texture colour.

[Nadnerb]

Would this break render consistency? A lot of the motivation in Trylon's original material rework was to make it so that materials would render pretty much the same in blender as they did in plasma, to reduce the amount of 'guesswork' involved in building... As far as I know, the color selector in the layer panel doesn't affect the render unless the texture doesn't have any color information.

[GPNMilano]

Yes, but most colors are stored in vertex coloring anyway. A materials color is less important than the actual vertex color of the mesh. which you don't see in a render unless you set it to do so in blender. (which requires changing the textures and layers, thus the settings for Plasma) I'd choose this way over that. You can see in the 3DView how the objects look, textured and vertexed colored. Blender's renderer will never give a completely accurate look either way.

[Christian Walther]

I think dox is the only person to actually change pyprp in the last few months

I have made some uncommitted tweaks to the export-with-modifiers-applied in my experimental branch that bring it a bit closer to production readiness. I don't know if people are interested in that. I'll try to commit it shortly.

[Justintime9]

I just had the exact same error as posted in the first post, but can't seem to figure out what the solution was by reading this thread. (other than that it's the plugin). If it was the plugin, hasn't PyPRP been updated since this topic was created?

My EnvMap was created by rendering for the waveset plane, and then, after it gave the error about there being no texture applied to the faces, I created an Empty object and loaded my rendered EnvMap image to that (and gave it the original waveset's material. After making them single users, I deleted the Texture > EnvMap property on the waveset object.

When I tried to export, it gave me an error at "@ Saving page textures -1" And the same exact "IndexError: list index out of range" error this topic was started about. Was there a fix to this problem after this post?