New client roadmap (1.5.0)

[KarenRei]

Daniel suggested (and I think it's a good idea) to store them in xml. We can base it on the existing xml-reading code. The basic process is that whenever the function is called to load a texture, it also loads the material data from xml. I'll also be replacing the GL material commands with a wrapper that sets the material, but also sets the material properties. It should be pretty painless.

 

Then we'll finally be able to get scenes that don't look flat but don't, say, cast shadows on snow that are too dark.

Edited July 17, 2007 by KarenRei

[Entropy]

I was thinking, wouldn't it be more flexible to store those parameters per object instead?

This way, we can use the same texture with different parameters to have two different looking objects.

 

For example, a roof texture can have an different specular on two different houses.

The only dissadvantage would be that we'd need to modify the 3d format yet again (and the importer/exporter/map editor).

[KarenRei]

It didn't come up with Daniel, but I had considered that. As a whole, I figure, you're much more likely to want multiple properties per object than multiple properties per texture. You have, say, an armor made of leather and bronze, you don't want metallic leather or organic bronze. But if you have a leather texture, you're rarely going to want to make it look metallic. You have a tree and leaves; the leaves are shinier than the bark. Again, you're not going to want the bark to have to be shiny or the leaves to have to be dull. And so on.

 

Also, when you look at the worst case, one set of material properties per object means you have to split your object into multiple objects and place them individually in order to get multiple sets of properties -- a real pain. One set of material properties per texture means that, if you really want the same texture to have different material properties, all you have to do is copy the texture file to a different name and give it its own material properties xml file.

 

So, I think per-texture is the way to go.

[Entropy]

I had a talk with Daniel and we came to the conclusion that the best thing is to have a material, rather than a texture.

So basically the object would use materials, which are xml files that contain a texture (or maybe even more, blended?), and various other things such as even shaders.

[KarenRei]

That'll take redoing the object format, won't it?

 

Since I'm almost done with it in the current incarnation, should I just finish, or should I throw away all my work?

[KarenRei]

Just to update: I haven't checked anything in in a while not because I'm busy (which I am), but because I'm having the darndest time with the glMaterial commands. Even if I turn off GL_COLOR_MATERIAL immediately before every draw statement in the tile_map's code, I still get sudden lighting changes on the tile map as the camera rotates (it matches everything else in the scene for a while, then suddenly is too bright, then matches again, and so on). If I never set any glMaterials (to reasonable values), however, it's fine. This makes absolutely no sense to me -- if GL_COLOR_MATERIAL is off, it shouldn't care what glMaterial settings were set.

 

So, I'm trudging away at the problem.

[Entropy]

The way they need to be done is to just store the settings in a 'virtual' material, which will be used for shaders.

[KarenRei]

Just an update: I'm back from vacation, but A) my laptop's screen shattered when it fell off the RV's bed, and I took several dozen panoramas, which my PC is currently stitching together, thus using up all my CPU and RAM, and thus making EL run so slowly that it's unworkable.

 

So, my EL development will be minimal until either of these situations gets remedied. My apologies.