KarenRei

Yes, please commit. Another bug bites the dust!

Aha! That's what's different about Harm from all of the others -- it uses the motion blur! I didn't think any effects were currently using that. And while the particle position history used for motion blur will quickly fill with entries, by default it doesn't have any in it. It sets the alpha of all of the ParticleHistory entries to zero so that they won't draw, but doesn't mess with their size, which causes problems in the draw routine. Oh, duh... Nice catch, there, Schmurk Seems the simplest answer is, as you suggested, to create a default constructor. So, in eye_candy.h, we'll just initialize everything to default values. Something like: ParticleHistory() { size = 0.00001; texture = 0; color[0] = 0.0; color[1] = 0.0; color[2] = 0.0; alpha = 0.0; pos = Vec3(0.0, 0.0, 0.0); }; Anyone want to try this out?

I'm thinking not 1.5.0, but way, way back -- what version did eye candy first go into, 1.3.3 or so? I.e., far enough to ensure that it's no insidious buffer overflow that's snuck in since then. Because it looks like a buffer overflow, and that could be anywhere.

Well, that definitely appears to be a problem. You should never get NANs or extreme values (positive or negative) for size, color, velocity, or position. It's strange to see size messed up, though. I don't see anywhere that size gets changed in TargetMagicEffect::HARM. It's just set to its intiial defaults (either 12 or 2 + randcoord(6), and it stays that way. Perhaps what you're seeing is a side effect of a buffer overflow elsewhere? Unfortunately, buffer overflows can be anywhere in the program I'd start commenting out code, hacking out one bit of functionality after another. Also, might not be a bad idea to see how far back you can reproduce this -- try way earlier versions and see if you can reproduce it in the same way. That'd at least rule out a buffer overflow introduced by recent code changes.

Sorry for the delay -- Christmas vacation and all. Plus, I went and got my eyes lasered Yes, the order is R, G, B, A. This patch doesn't change the shadowing system -- only material properties. If shadows looked bad before, they're still going to look bad. What lack of smoothing are you referring to? Is it something that you see with shadows off or not? If you only see it with shadows on, it's a shadow mapping problem. If it shows up when shadows are off, then it would seem that the facets of the objects in question have disjoint vertices, and I'll need to investigate further.

Sounds good to me, as long as it's after New Years . I'll be too busy with the holidays until then.

Bugfix in: Shadows when NEW_LIGHTING compiled in but not in use now work.

Indeed, the fact that the water becomes white all at once is because the water modelled perfectly flat, and a perfectly flat surface that has specular reflection, as you would guess, acts like a mirror. Unfortunately, OpenGL draws exactly what you tell it to The solution is normal maps, which Xaphier is implementing. In water, you would want animated normal maps. Sure, you can change the lighting for yourself First off, open up material_metadata.xml. There's a comment at the top that explains what you're looking at. For the characters, I made it so that their heads are made of either the material "Matte skin" (search for Matte skin to see that material) or "Shiny skin" (likewise, just search for that to find it). I arbitrarily decided to make orchan and draegoni heads shiny, and human, elf, dwarf, and gnome heads matte. Of course, you're the graphics gal, so you decide how you want everything I assigned the rest of all of the bodies to be the material "Matte cloth". To lighten up the shadowy parts of the clothing, raise the ambient level until it looks how you want. You can also lower the diffuse. To recap terms: Emission: Illumination on the material that shows even when there's no ambient light in the scene Ambient: Illumination on the material that shows when the object is in shadow, but requires scene ambient to be visible. Diffuse: Illumination on the material that shows when the object is in direct light, but isn't "shining" Specular: The reflective shine of the material. A little specular goes a long way. Shininess: How "tight" the shine is. A low shininess makes a broad, weak shine, while a high shininess makes a tight, bright shine. Now, for adjusting shadows in general: not only can materials have properties, but scenes can as well. Let's assume that you're in contmap1.elm. If you search for contmap1.elm, you'll find that it's in a scene properties section called "Grass and trees". Since grass and trees aren't very reflective, the ambient lighting in these scenes is lower than, say, in a snowy scene. The ambient is also a touch greener than it would be otherwise to simulate radiosity (http://en.wikipedia.org/wiki/Radiosity). All scenes have a bit of extra blue in the ambient because of the sky. So, if you want to make the shadows in this type of scene look less dark, you simply need to turn up the scene ambient. As you'll see, there are three types of ambients, three diffuses, and three speculars: one of each for day, one of each for dawn, and one of each for night. I.e., you can set how it's going to look at night, and as the sun rises, it'll blend into your dawn colors, and then as the sun keeps going up, it'll blend into your day colors, then back down to your dawn colors in the evening, and then back to your night colors. Any problems or questions that you have, by all means, let me know. Ed: Oh, and feel free to play around. For example, take the skin textures and, say, make them bright green with a strong specular shine, or whatnot. Have fun, play around, and get a hang on what different types of material properties look like.

Yeah, that's the big difference between the new version of NEW_LIGHTING and the old version -- every last detail can be tweaked now. You can tweak scenes (ambient, diffuse, specular) and materials (ambient, diffuse, specular, shininess and emission), with materials able to be set on a per-object, per-mesh, or per-texture basis. Can't get much more flexible than that

Ah, that'd be a bug, then I'll look into that this evening. Thanks!

1) Player darkness: Changing that merely takes adjusting the material properties of the player model in material_metadata.xml. I'll do that this evening. As stated earlier, the values in there should be tweaked as desired. 2) Water shadows in general: Yep, I ought to adjust the material properties on the water a bit, too. 3) Bridge shadow: It's black in NEW and OLD, so I don't see the difference. 4) Wavy line on house: That's a model problem. I can't do anything about model problems, as I can't edit the models. There are a number model problems that simply didn't show up before because EL was so flat, usually involving objects that have been placed against one another that don't meet with the same slope. When you have a "flat" lighting model, you can't tell that they're different slopes. In this case, you're probably seeing two polygons with different normals occupying the same place, and so the graphics card is switching from one to the other.** 5) The shadow of the plant is accurate. Light is coming from almost overhead, just a touch to the right (as you can see from the clock, it's almost midday). The flowers overhang the edge, so they cast straight shadows down at a slight angle moving to the left. The only element that doesn't match with the real world is that the shadows aren't "soft". Unfortunately, "soft shadows" are both difficult to implement and perform slowly. Let me know of any other materials that need to be adjusted, and I'll do so ** One fundamental error that was made with model design in EL is that all vertices within an object are shared. What having them all use shared vertices tells the graphics card is, "I want this object to look smooth and rounded". So, you make a perfect cube with flat sides, and the graphics card will try and make it look smoothly rounded; it thinks you're trying to make a very poor approximation of a sphere. Facets that you don't want to blend into their neighbors should not share vertices with them.

Cute avatar update If you want, I could grab you some screenies. Not sure if you specifically want Florian to get them for you. Feel free to suggest some things you'd like screenshots of.

Let me know if you have any other problems. As mentioned at the beginning of the thread, there are certain things that are map and model bugs that didn't show up when EL was as flat as it was, but show up now, and there's nothing I can really do about that. But anything that you suspect might be a bug on my part, just let me know.

Reproduced and fixed. Thanks for reporting!

If I get a chance (kind of tight, as we're getting ready for xmas), I'll try to reproduce it tonight.