"Shadeless" material is lit when vertex-colours are present


#1

I’m trying to create a very simple sky-dome: just a blue sky, shading from a relatively-saturated turquoise at the apex to a desaturated dusty-blue at the “horizon”.

To that end, in Blender I have the appropriate colours assigned via vertex colours, and a simple material applied that has both “Shadeless” and “Vertex Color Paint” checked. However, when I export the model, I find that it’s still lit in PView. (When lights are applied, of course.)

The “Shadeless” check-box does seem to work if “Vertex Color Paint” is left un-checked.

Checking the egg-file, it looks as though YABEE is simply not exporting any material values when those two check-boxes are both selected–there’s a “material” entry, but it’s empty. Copy-pasting the values from a file exported without “Vertex Color Paint” into one exported with it results in the dome being shadeless.

Having looked around the forum quickly, I’m honestly not sure of where the problem lies. I thought for a while that there were two issues here: YABEE exporting a blank “material” entry, and models that are both “shadeless” and “vertex-coloured” taking light. But my search suggests that this may not be the case. Should YABEE be exporting a blank “material” entry? In the presence of a material, should vertex-colours be ignored? Is there a check-box that I’m missing somewhere? :/

I do realise that I could call “setLightOff” in code to produce the effect that I intend–but I’m trying to make an environment model that “just works”.


#2

As far as I know, there is no material without shadow or lighting. And setLightOff must always be set individually. In fact, these are old technologies, now usually need to use shaders for the sky.


#3

I do have the auto-shader set, so shaders are being used–they’re just the Panda-generated ones instead of custom ones. (I should perhaps have mentioned that–my apologies! ^^; )

As to materials, that’s fine–it’s not really the material settings that I want, just the vertex-colours. I’m only applying a material so that I have access to the “Shadeless” and “Vertex color paint” check-boxes.

However, if the settings being applied are causing the material to be ignored, then that may be a problem, indeed.

(I believe that objects can be made shadeless without calling “setLightOff” in code, by the way: I have a set of background “mountains” in front of the sky that use a “shadeless” material, and they don’t seem to take any lighting.

Specifically, it looks as though YABEE exports such materials with zero-values for diffuse and specular (I think that it was), and non-zero values for emissivity, producing the effect of the object being unshaded.)


#4

With material, the colors of the vertices overlap, as well as with textures. If you set the material to zero, then this is just a masking of the lighting effect. But when rendering Panda3d, still calculates the lighting for the object.


#5

There is no way to truly represent a material with both the Vertex Color Paint and Shadeless options in an .egg file. YABEE implements Vertex Color Paint by emitting a material with no diffuse (which tells Panda to take the diffuse colour from the vertex colours), and it emulates the Shadeless option by writing the colour to the emission slot. But, there is no way to tell Panda to take the emission colour from the vertex colours.

Also see:

This would have to be remedied with an addition to the .egg syntax. In the meantime, the best way to avoid applying lighting to objects is to call setLightOff(override), though this has no equivalent egg syntax.


#6

That’s perfectly acceptable to me: I just want the model to appear unshaded. I don’t mind that it’s not technically so.

Ah, that’s a pity! :/

Hum… It’s not a major problem for my tutorial, which has a top-down view and thus never sees the sky. But I would like to provide the model for others to potentially use, and to that end I would like it to work “out of the box”. Vertex-colours seemed like such an elegant solution–but given the above, perhaps I should use a simple texture, instead…

Well, thank you both for your advice and help–it’s appreciated! :slight_smile:


#7

I think that, ideally, the material parameters should be separated from the egg. And to have additional property fields for rendering the object. Also links to shaders, and more. Plus it would allow to create a user library + shaders. This is not exactly the topic of the post, but a thought for the future.


#8

I do like the idea of links to shaders. As to materials, perhaps they could be treated a little like animations: separate files, referenced by the model using them. This might open up the possibility of material reuse–presuming that Panda doesn’t already do something like that.


#9

To solve this issue, perhaps we could add something like a “material model” scalar to the .egg <Material> syntax, which could have an option for flat-only shading. Or, we could add a scalar to the containing <Group> indicating that this object should not receive lighting.

Allowing a material to be defined in a separate file is an interesting idea. Though, I’m personally of the opinion that materials shouldn’t be linked to shaders, as I think it should be possible to mix-and-match materials and shaders, but I’m willing to be convinced otherwise.


#10

I like the idea of the “material model” scalar: that way shadeless rendering–whether vertex-coloured or not–could be represented. Indeed, In addition I wonder whether representing “shadelessness” via emissivity might not interfere with custom shaders that make additional use of emissivity data (such as by increasing bloom around such areas, or some such).

Intuitively, I think that it makes sense to declare that a material is “shadless”, rather than an object–especially as this is the way that Blender handles the matter, thus making for a more direct connection between the representation in Blender and that in Panda.

All that said, and regarding shaders being linked to materials especially, I fear that I don’t use materials extensively enough to be confident in what would make the most sense. In most of my projects materials are little more than a means of associating textures with models, and occasionally indicating to YABEE that I want vertex-colours to be retained. The only reason that I’m encountering these issues here is because I want this particular model to work “out of the box”, and so am not using my usual approach of applying custom shaders.


#11

I sometimes use vertex color for something else then diffuse color (eg. glow) so when PBR finally hits I imagine one could use vertex color as roughness or metallic. A way to tell the shader generator how to use vertex color - like the envtype for textures - would be cool.


#12

You know, I’m going back and forth about whether we need a separate type of material for this or whether emissivity really is the way to go. A material really is something that defines how a surface reacts to light; if we model unshaded as a material, we are essentially saying “it doesn’t reflect any light, but instead it emits light straight at the camera”.

In an HDR/PBR pipeline, bloom is essentially what happens when the object emits so much light at the camera that the light starts bleeding into adjacent pixels on the camera’s imaginary sensor. This isn’t really a property of the object or its material so much as it is a property of the camera. In HDR, bloom really only happens when the emitted colour is really, really bright, ie. scaled beyond regular 0-1 values.

If we want to use vertex colours as unshaded colour, we either need to make it possible to tell Panda to take emissivity from the vertex colours, or we need a special material or flag telling Panda that this is an unshaded object that doesn’t react to light.

Hmm. Actually, I had imagined that we would simplify the vertex colour handling and always make it multiplied into the base color slot.

Maybe we should have a ColorAttrib flag to do something like this.


#13

Under the concept of a separate material, I relied on JME3. It is very convenient. Since there are several types of materials, lit material and unlit. For each was used its own technology. In panda, this is done by the SHADER GENERATOR.

https://wiki.jmonkeyengine.org/jme3/advanced/material_specification.html


#14

Hmm… I’ll confess that I’m not all that familiar with such techniques, so again I don’t speak with confidence. I’m just imagining that if an object is indicated to be “emissive”, then it’s conceptually “glowing”, and thus, if light-bloom is being emulated, I would expect such glowing objects to have some degree of bloom. That is, if only pixels with values greater than 1.0 produce bloom, I would expect emissive materials to start at 1.0, and increase from there.

However, that may well be quite unlike what’s commonly done in practice!

I suppose that one question worth raising here is this: Is this matter worth fixing? How often will it be a problem for users?

After all, simplistic colourings such as I was attempting seem likely to be uncommon–and there’s a workaround via use of a small texture. In cases in which I’ve used vertex-colours for shadeless rendering, I’ve done so with custom shaders that use those colours as I intend.

I don’t know how others use vertex-colours, however. It may well be that uses such as I stumbled upon here are more common than I think! ^^;


#15

“emissive” just means that the object produces light, rather than just reflect it. A black object with an emissive texture set will emit exactly the value of that texture, so it will appear to have the colour value of that texture without affected by lighting.

“glowing” is not quite the same thing. When we say an object “glows”, we are usually talking about one of various various effects: the diffuse reflection of the emitted light on other objects, atmospheric scattering, diffusion through a translucent object, or bloom (which, again, is due to light bleeding in our eyes / camera sensor). But glow can result from any light leaving the object, also from the diffuse reflection. For example, in this screenshot, note that the red wall is also glowing by casting reflected red light onto the surfaces of the adjacent walls; this is because there is light reflecting off the wall, and so it is “glowing” subtly. Similarly, all objects with bright reflections should receive glow effects, not just emissive ones.

Whether you want to go that far as to simulate all these things in your lighting application sounds to me like a function of how the lighting is set up in Panda3D, not really a function of how the material is defined; ie. if someone wants to do flat shading, they can simply choose not to set up any lights (or to use setLightOff). I am happy to be proven wrong, but it seems unlikely to me that someone would want to load unlit models into a lit scene and expect the lighting to be applied inconsistently.

That said, as far as .egg files are concerned, there may be value in defining such an “unlit material” after all, which we could just import as setLightOff in the .egg loader. Furthermore, if we push ahead with the planned new material models in 1.11, it will become possible to offer different Material subclasses for different types of shading models; we could then also offer an UnlitMaterial class that essentially contains only a single colour and texture, multiplied by the vertex colour. I’m not really sure that that makes sense, but it’s an option.


#16

Hmm… That’s a fair point.

But still, perhaps a better term than “glowing” in my post above, then, might have been “radiant”, or similar–that is, giving off, not just reflecting, light. That’s what I’m inclined to think of when I think of an “emissive” material.

But thinking about it further, a dimly-radiant surface in the dark is effectively the same as a non-radiant surface that’s well-lit. So an emissive material wouldn’t necessarily produce values above those produced by diffuse reflection, and so wouldn’t necessarily have pixel-values higher than 1.0.

The one major use-case that I see is “distant views” or sky-boxes/domes. However, in such uses, I would expect that a texture would generally be applied, rather than vertex-colours alone, and so the issue described in this thread would presumably not occur.

Those sound like promising options, presuming that there’s call for them, I do think. :slight_smile: