Since the latest 1.0 SDK any material with a lightmap for "glowy" parts has been bleeding the light out to the entire image like shown.

Why is this and how can I fix it.

Please read the version history notes, marked as "IMPORTANT" which are related to light maps.
You should zero material ambient value, and use glow maps instead of light maps

I've followed the instructions in the february version notes and light maps still aren't working the way they should be for me. The notes clearly state to zero the ambient values but if you do that even fully-lit sections of your light map are getting darkened. I noticed also however that i can throw any image i want into the "light map" section of the material manager now and it doesn't make any different though.

1) You model has an uv map for light map?
2) That texture looks wrong for me. If that lightmap were working you only will be able to see the 3 little marks and rest of model black.
3) Why you want apply lightmaps to a "dynamic" model like an axe?

Thanks for the reply but I'm not sure you are familiar with how they function friend.

I spent a lot of time texturing this model. Diffuse, Heightmap/Normal, Specular and Emissive.

An (emissive map sometimes called an illumination map) allows you to specify certain parts of the models surface that are always lit despite being in a shadow. This is what you use for any surface that is supposed to be emitting light, such as a light bulb or a "glowing section".

Greg calls these "lightmaps" instead. All the ones we had for the game worked until the february SDK and now they don't anymore.

I read all the info about "glow maps" and so on and how they work, and i can get glow maps to work fine, but that only creates glow around the part as it's supposed to, not controlling the actual brightness of the section itself.

I haven't seen this working in anyone elses games since (although there aren't many images of projects with Esenthel to choose from) so we might have to consider this a bug until I see it working for anyone else.

For the record, I tried it with my different kinds of input, single color, RGB, RGBA, and as i mentioned, you can throw any image you want to in there and the the model will have no change in lighting input so i'm guessing it's a material bug.

Do you have a 2nd set of UV coordinates?

It doesn't work on any models, created by me or others. There is nothing wrong with the asset so unless anyone here has an example of it working on one of theirs as well it must be a bug.

I think you are confused. They are working for me:

http://www.esenthel.com/community/showth...p?tid=5886

Lightmaps (precalculated lights) are usually for static meshes like buildings. You need a second set of UV coordinates in your model as tottel says.

In the past "light maps" worked as "ambient maps", but that was changed, now they work as multiplication of the "Color" texture.
"final color" = "color texture" * "light map texture" * ( "dynamic lights" + "ambient lights" )

http://www.esenthel.com/community/showth...p?tid=5922

Quote:-IMPORTANT: changed the way lightmaps work for materials, previously they worked as ambient map, now they always multiply texture color by lightmap color (lightmap texture coordinates is now always taken from VTX_TEX1), lightmaps no longer make use of ambient color parameter (you can clear it to zero now)

Also please don't make new threads for the same issue, I've merged this thread with the previous one.

(04-10-2013 09:21 PM)Esenthel Wrote:  In the past "light maps" worked as "ambient maps", but that was changed, now they work as multiplication of the "Color" texture.
"final color" = "color texture" * "light map texture" * ( "dynamic lights" + "ambient lights" )

http://www.esenthel.com/community/showth...p?tid=5922

Quote:-IMPORTANT: changed the way lightmaps work for materials, previously they worked as ambient map, now they always multiply texture color by lightmap color (lightmap texture coordinates is now always taken from VTX_TEX1), lightmaps no longer make use of ambient color parameter (you can clear it to zero now)

Also please don't make new threads for the same issue, I've merged this thread with the previous one.

I made a new thread because this one was with regards with the glow method, and what I'm talking about with this issue is the emissive method, so they're separate issues.

Cutting and pasting the patch notes that I already mentioned I've read also really doesn't do much.

To the individual who mentioned they thought they were working for themselves, you're talking about something totally different.

If Greg has changed the function of "light maps" to do something different now from what they used to, that's perfectly fine but you need to explain how to do what they previously did now - Which is use a texture as an illumination map (aka emissive) to make certain parts of a UV mapped model always fully-lit. It's a very common modern practice in games and you used to be able to do it with Esenthel until just recently.

Is this the effect you are looking for?
   
   

Yup that's it. The glow maps compliment the effect, but if you step back more than a few feet you'll begin to notice that there's no emissive element backing it so it just looks strange. Yours are kinda close up so it's hard for me to tell how you're accomplish it but it looks damn good. What's your method?

No method, just a glow map. The emissive element IS the glow map. What you have in mind is self-illumination, which is not quite the same.

You were able to achieve self-illumination (full bright rendered pixels) via lightmaps previously functioning as ambient maps (not because Greg named them wrong). I don't quite understand why this got changed/removed, because it's a nice feature (one example being your usage). Sometimes self-illumination is also named unlit, fullbright, even solid mode, basically you just skip any shading for the affected fragment and display it's texel color unchanged.

So one way around the problem would be a custom shader.
I'd first try and play with glow maps some more, since they seems to work ok in my case (yes, even from further away), but I haven't used them extensively (only on this one model, still fresh to EE), so maybe there are some implementation limitations that make them look strange the way you are describing.

Thanks for the input.

Unfortunately that's kinda what I suspected.

However i'll ask if you've tried using your object and it's shader in anything other than a fully-lit environment? This is what having a glow map but no "fully-lit" sections looks like at night. It's... pretty awful.

So I need to figure out a way around this.

Since you know exactly what i was talking about and you're just another developer like I am, I can reasonably assume that Greg knew what I was asking but didn't want to come out and say, "I changed it so you can't do that anymore".

It's unfortunate, because 75% of our character and clothing/armor models have an emissive element to them since it's commonplace among game engines today, so I don't know a way around it.

Is there a way I can just chuck the new shader system and go back to the one that worked, or is that something that can't be changed? I don't really feel like making a custom shader for every model that worked before and now doesn't work.

Thanks,

-Ethan

Bumping for a response.