Normals in Shading / Sounds needed / Fedora Extras Packaging

[KarenRei]

I have three questions here.

 

1. Looking at the graphics, it doesn't *look* like you're using normals in shading. Screenshots like this look quite flat:

 

http://www.el-development.com/screenshots/shipwreck.jpg

 

WIth normals being used, I can't picture thouse rocks in the background being so matte. Other examples: the light in this next picture seems to be coming from the southwest, but why is the cylops's face so dim? Why is the near soldier's right shoulder lit? Why, with all of the curvature of the near-right rock, do all of the facet seem to have roughly equal brightness?

 

http://www.el-development.com/screenshots/cyclopsfight.jpg

 

A (brief) look through the source code doesn't answer the question -- I see one file rendering objects with a normal array, but then I get to actor.c, and see it talking about how the objects don't have a normal array to load. So I don't have to search through the entire source to figure out what's going on, can someone enlighten me as to what is the current level of usage of normals in rendering in Eternal Lands?

 

I daresay that the use of normals is *the* single most important element in graphics realism -- more than even texture mapping or polygon count. Without them, objects (esp. moving objects) look flat. Examples:

 

A texture mapped cube with no normal shading:

 

http://www.zanir.szm.sk/dx/obrazky/002_Tex...Mapping_big.JPG

 

A non-texture mapped cube with normal shading:

 

http://www-static.cc.gatech.edu/~haro/cs64.../cube_green.jpg

 

The effect is more pronounced when objects are in motion. The shaded cube begins to feel especially real. The texture-mapped cube begins to feel especially fake.

 

If there is no normal shading, I'd be willing to look into implementing it for you. I've written 3d engines before; this is well within my range. If there is normal shading, can someone explain why things often look flat? Do the textures have very high ambient values or something?

 

2. Sounds:

 

In my copy of the game, I see only 9 sound effects. That's not very many. Do you want more? I've made hundreds before. Just let me know what you want SFX for, and I'll contribute them.

 

3. Fedora Extras Packaging

 

Is there interest in having me package this game up to be part of Fedora Extras? At first, I was concerned because of your license (QTPL), but I looked it up, and it is an acceptable one. I'm a Fedora packager already, and maintain the package for nethack-vultures. I think this would be a lot of free advertizing for EL.

 

If there is interest, I'll need to know what the release cycle is around here, and how to make sure I get the latest of everything. To get my own client working and able to connect to the server, I had to deal with a pretty roundabout process -- installing an ancient EL package that I found, then downloading the update and untarring that over it, then downloading the CVS source (I checked out "elc") and building it, then replacing the binary and a few of the directories with the fresh-from-source versions, then hand-tweaking the INI file. Everything else that I tried failed to work; this was the only thing that succeeded. I worry that I may end up missing something with such a convoluted process. Is there a cleaner way? Surely there is, and I just missed it.

[ttlanhil]

normals will come some day... there was someone working on that and other enhancements, but it wasn't finished or isn't used yet (there's a fair bit of code for it, but I don't know if we only need to hook in the textures or if it needs something else)

 

there was some work a while back on hooking sound files to actions, which was tested but not commited, it had a bunch more wavs, though they seemed more proof-of-concept quality. that patch is certainly out of date now, but like the above, if a coder comes along, patches are welcome

 

there are packages for several distros floating around, though they probably have fallen out of date

there is no real release cycle; when there's small changes to the data files the client can fetch updates (which mostly won't work on *nix, since it needs write access to data dir, but is usually enough till a larger update), client and larger data updates happen when there's sufficient new stuff or bug fixes... sometimes a bugfix release a fortnight after a major update, sometimes months

 

the install process you described is about accurate, though full installs shouldn't need an update... the ini can also be saved by the client, so hand-editing is only needed if something is broke (bad server settings, some graphics feature that must be disabled for it to work locally, etc)

 

the majority of EL users are using windows installers (created with NSIS), *nix users can usually get away with just the full release (though the client CVS will have been updated since)... anyone compiling either has to and gets help, or generally knows how to do that sort of thing, so while it could be improved, it's not really a priority

Edited October 13, 2006 by ttlanhil

[KarenRei]

Thanks for the response.

 

As for normals: I'm not talking about normal maps, but just basic normals -- you know, gl_normal3f and whatnot. Basically (ignore this section if you're already familiar with the subject), you calculate a unit vector perpendicular to your polygonal facet (the normal) when the object is designed or loaded, and whenever the object rotates, you rotate the normal vector as well. The dotproduct of this vector and the light vector gives you the degree of illumination from the light source. You can get smoother shading by using (approximate) normals of the vertices and interpolating them across the polygon, and even better shading by incorporating normal maps (which show how the normal varies across a polygon or mesh), which are a high quality type of bump mapping.

 

The point I brought up was that EL doesn't have the appearence of using even the most basic form of normal calculations for shading. Yet, in the code, there's at least a framework for it. So, if you can't track down a person who's working on this for you, I volunteer to. If you can, my kudos to the person who's doing it.

 

As for sounds, the same applies. My sounds are not proof-of-concept quality; they're product quality. I've donated some to other games, such as UFO: Alien Invasion. In this case, however, I'd rather not touch programming. I'd rather just donate whatever sounds people need.

 

the install process you described is about accurate, though full installs shouldn't need an update... the ini can also be saved by the client, so hand-editing is only needed if something is broke (bad server settings,

 

Biiingo. It couldn't connect to the server. Probably ended up with an INI from an older version.

 

*nix users can usually get away with just the full release

 

Not on modern Fedora. The libraries that it links to are pretty old, so it won't run. When I first logged in, the first person I chatted with was another Fedora user who also had to build, with a lot of help

 

So is this a "Yes, we would like it packaged" or a "No thanks"? If it is a yes, is there a place to get the latest version of the files that aren't included with the source (checked out as elc), such as models, sounds, etc, apart from the full install?

[ttlanhil]

So, if you can't track down a person who's working on this for you, I volunteer to. If you can, my kudos to the person who's doing it.

I don't know much about it myself, which is okay, since my vid chip doesn't support much anyway

the person who was working on it was xaphier, the code in there is like a year old, I don't know how complete it is... if you want to look at it, submit any patches needed, etc, it'd be welcome (the berlios site has patch submission)

As for sounds

the person to give yay/nay on sounds is probably roja, she's in charge of the art side of EL, if you have some samples you could post it'd probably help.

the thread about that patch I mentioned is here for anyone playing at home

It couldn't connect to the server. Probably ended up with an INI from an older version.

ahh, yes, we changed server address pretty recently, though all installs should have been updated when that happened

The libraries that it links to are pretty old, so it won't run

hmm... I know there's the depreciated wav loader in OpenAL, any other libs that don't link/run properly?

So is this a "Yes, we would like it packaged" or a "No thanks"?

I'm only one of the client coders, for official answers you have to go a bit higher, but I expect it's a case of: go right ahead, users are welcome to do this as long as it's a clean and complete copy, but it's up to you to maintain/support the package, it's not what EL in general supports

is there a place to get the latest version ... etc, apart from the full install?

nope, latest stuff anyone except the devs working on it and managing it has is in the installs, updates, or in auto_update (which you could use a bit of trickery to get manually... wget the entire list of files from the update server, etc, to ensure you have the latest)

[KarenRei]

Great, thanks. I'll probably get to work on some of these this weekend. As for posting sound, I don't know what sort of sounds would be wanted. I guess I could just pick some examples?

 

any other libs that don't link/run properly?

 

libstdc++.so.5 was one that I remember

Edited October 13, 2006 by KarenRei

[Entropy]

Umm, we are using normals, and we have been using them from the beginning. That's more visible at night, or when the sun is high in the sky, and, just as in the real life, less visible during a rain, dawn or dask.

[Roja]

Hold off on the sounds a bit..I gotta get more organized with that again as we do have someone else who is providing some sounds. But we may need other sounds too so I'll let you know in the next few days or so.

 

btw, this link doesn't work: http://www.zanir.szm.sk/dx/obrazky/002_Tex...Mapping_big.JPG

[Entropy]

As for your offer to package it for Fedora, sure, we could use additional packages.

We usually update a few times a year (maybe 3-4 times, depending on many factors). Most of the updates involve adding new artwork/maps/animals, changing some previous maps/artwork, and, of course, the client change to make improvements, eliminate bugs, and that kind of stuff.

 

Thanks for the offer.

[KarenRei]

Umm, we are using normals, and we have been using them from the beginning. That's more visible at night, or when the sun is high in the sky, and, just as in the real life, less visible during a rain, dawn or dask.

 

Interesting. And, indeed, at least part of the code looked like they were being used. Strange, though. Do you know why do the screenshots that I reffed look so flat? It looks like textures with brightness pre-specified. It's easy to come up with more examples:

 

http://www.el-development.com/screenshots/cityentrance.jpg

 

The sides of the bridge are equal brightness to the top of the bridge. Opposing sides of the gate are lit, as though the flames were a light source, yet the wall that the flames are on is dark. There's no sign of brightness change on the ropes, which should show it off well, since they're (assumedly) rounded. Etc.

 

http://www.el-development.com/screenshots/pvtemple.jpg

 

The trees have absolutely no shading around the diameters of their trunks. Surely we're not *perfectly* aligned with the direction of the light source.

 

http://www.el-development.com/screenshots/pvhouses.jpg

 

The well seems to suggest light coming from the west. The fence in the lower right does not. The trees beside the house suggest light from the right, as does the fence by the house. The pole beside the house shows no lighting angle differences.

 

Why is this? Compare these screenshots to, say, these from WoW:

 

http://www.haslo.ch/wow/lvl_1-40/Quest_2.jpg

 

Note the consistant illumination from the point source flame, whether it's the tree, fence, or well.

 

http://www.haslo.ch/wow/orgrimmar_raid/raid_orgrimmar_14.jpg

 

Again, illumination is exactly what you'd expect. Shapes near light sources are bright, and the light falls off with distance. Angles are all appropriate. Lets do one more:

 

http://igrozone.com/pic/screen/world of warcraft/wow01.jpg

 

Here we have multiple light sources. The weaker fire lights up the hearth, while light from behind the camera consistently lights up the wood.

 

I must be missing something here. Some of the graphical elements in EL are great. You really nailed cast shadows, for example. But the shading on objects themselves just doesn't look right.

 

As for packaging: looks like that'll be what I'll be working on, then.

Edited October 13, 2006 by KarenRei

[crusadingknight]

http://www.el-development.com/screenshots/pvhouses.jpg

 

The well seems to suggest light coming from the west. The fence in the lower right does not. The trees beside the house suggest light from the right, as does the fence by the house. The pole beside the house shows no lighting angle differences.

 

The 'pole' is a light source, hence the lighting in the picture.

 

Quick note: Is it just me, or are the shadows in the WoW picture projected from above, even though the lightsource is beside them?

 

In any case, one of the main elements which makes the lighting look a little more spectral on EL is the fact that lightsources are scattered around maps, sometimes on posts (though, these unfortunately have no halos to make is obvious), while other time's it's over a house or such.

Edited October 13, 2006 by crusadingknight

[Roja]

http://www.el-development.com/screenshots/cityentrance.jpg

 

The sides of the bridge are equal brightness to the top of the bridge. Opposing sides of the gate are lit, as though the flames were a light source, yet the wall that the flames are on is dark. There's no sign of brightness change on the ropes, which should show it off well, since they're (assumedly) rounded. Etc.

 

 

 

This is a strange problem. At first I was attributing it to the 3d object...mostly all these objects are optimized quite a lot and have a limited amount of polys, however the normals were always just fine on the objects.

 

You can look at the objs in the map editor and move the lights around to really see it in action. Make it night time in the editor(press n)

 

I say if you can take a stab at correcting this problem and improving those normals & shading in the client then go for it. If you do improve them and also want to implement normal maps for us that'd be most appreciated too We can use any help in programming with the client that we can get.

[emajekral]

There's little to no directional lighting (sun) at night so objects will appear rather flat - but nights in EL are lit unnaturally anyhow (too bright). During the day or near light sources (there are up to eight lights enabled and some street lamps actually turn on at night) you can plainly see that the normals on objects are set appropriately. There may be a glitch or two but none come to mind. The ambient factor is set fairly high so dark areas are filled nicely, but you'll see the shading on your character change as it turns, etc.

 

I'll try to provide a moving example shortly.

Edited October 14, 2006 by emajekral

[emajekral]

Video with examples of Lambertian lit models under changing lighting conditions. Also note that there's a mixture of smooth shading and flat shading. I captured the video at too high a resolution so many fine details are lost, but I don't have time to redo it.

 

Also included are samples of Point Particle adjustments which may be applied to magic effects with a bit more work, my skybox work so far, and Learner's efforts to bring together LOD and Frustum optimizations (-DSIMPLE_LOD -DNEW_E3D_FORMAT).

 

 

*Babble mode engaged*

Something that would be really nice would be some way to turn on phong shading for some objects to make them look shinier. Even old OpenGL cards do phong shading per vertex, but that only works well for highly tesselated models. Given that EL is conservative with polygons the effect would be poor. Hence the need for normal maps before we go to Phong or even better BRDFs. Another lower tech material property to try would be environment maps rather than texture maps for some armor. Bring on the shiny! (They could be combined for cards that support multitexture or pixel shaders)

Edited October 14, 2006 by emajekral

[KarenRei]

There's little to no directional lighting (sun) at night so objects will appear rather flat - but nights in EL are lit unnaturally anyhow (too bright). During the day or near light sources (there are up to eight lights enabled and some street lamps actually turn on at night) you can plainly see that the normals on objects are set appropriately. There may be a glitch or two but none come to mind. The ambient factor is set fairly high so dark areas are filled nicely, but you'll see the shading on your character change as it turns, etc.

 

I'll try to provide a moving example shortly.

 

Here's a direct demonstration of the problem:

 

http://www.daughtersoftiresias.org/images/el/

 

The first three images are different angles rotating around a boat. It's evening, so the shading should be the most extreme that you can get. You'll notice that no matter what angle you look at on the boat, and no matter what facet you look at on the boat, they're always precisely the same shading level.

 

This is flat shading. If normals are being used, they're not true normals, but something like "1, 0, 0" on all polys (either that, or ambient and diffuse are set to the same value). Either way, the result is flat shading.

 

EDIT: Yet, in your video, we certainly seem to see the usage of normals (albeit with very high ambient levels). This is strange, and I'm not sure what to think of it. On one hand, I see, for myself, in the game, a boat that all facets have the exact same lighting level. On the other hand, you show shading varying at different times on different facets on a video. What is causing this?

Edited October 14, 2006 by KarenRei

[Entropy]

Actually, if you take a picture after the sunset in the real life you will notice that all the surfaces are the same.

If you don't believe me, go out before the sunrise or after the sunset, and you will notice the effect yourself.

 

As we were saying, we have normals in the game, and they act properly. Some objects have some fucked up normals, but that's the exception, not the rule.

In all the screenshots you posted, the objects behave similar to how they would in the real life, with the mention that the ambient and direct lights are different.

[emajekral]

Umm, we are using normals, and we have been using them from the beginning. That's more visible at night, or when the sun is high in the sky, and, just as in the real life, less visible during a rain, dawn or dask.

 

Interesting. And, indeed, at least part of the code looked like they were being used. Strange, though. Do you know why do the screenshots that I reffed look so flat? It looks like textures with brightness pre-specified. It's easy to come up with more examples:

 

http://www.el-development.com/screenshots/cityentrance.jpg

 

The sides of the bridge are equal brightness to the top of the bridge. Opposing sides of the gate are lit, as though the flames were a light source, yet the wall that the flames are on is dark.

 

First I recompiled with ambient turned down:

 

http://www.cs.uregina.ca/~jaclarke/ELpics/Gate.jpg

 

 

The problem here is the point light source is too close to the wall and the wall has a low polygon count. The light sources are attached to the flame particle systems. Wild stuff.

 

Here I move the light around in the editor:

 

http://www.cs.uregina.ca/~jaclarke/ELpics/FlameFix.jpg

 

Here's a diagram of what's going on:

 

http://www.cs.uregina.ca/~jaclarke/ELpics/badAngle.gif

 

There's no sign of brightness change on the ropes, which should show it off well, since they're (assumedly) rounded. Etc.

 

Nope. They're long rectangular prisms. Not many vertices to light. They are trying though.

 

http://www.el-development.com/screenshots/pvtemple.jpg

 

The trees have absolutely no shading around the diameters of their trunks. Surely we're not *perfectly* aligned with the direction of the light source.

 

No but the trunks are *completely in shadow* look at the ground around them.

 

 

http://www.el-development.com/screenshots/pvhouses.jpg

 

The well seems to suggest light coming from the west. The fence in the lower right does not. The trees beside the house suggest light from the right, as does the fence by the house. The pole beside the house shows no lighting angle differences.

 

Here's a no ambient light snap of the same scene with light sources marked and their effect pointed out. Two light sources.

 

http://www.cs.uregina.ca/~jaclarke/ELpics/TwoLights.jpg

 

 

 

Here's a direct demonstration of the problem:

 

http://www.daughtersoftiresias.org/images/el/

 

The first three images are different angles rotating around a boat. It's evening, so the shading should be the most extreme that you can get. You'll notice that no matter what angle you look at on the boat, and no matter what facet you look at on the boat, they're always precisely the same shading level.

 

This is flat shading. If normals are being used, they're not true normals, but something like "1, 0, 0" on all polys (either that, or ambient and diffuse are set to the same value). Either way, the result is flat shading.

 

 

I'm not sure if that's a bug, but I'm going to agree with you on this one. Some objects are not lit correctly. They have had their material properties or normals set so that they are bright even when there's no light on them. They are bright regardless of time of day.

 

No ambient version of rowboat scene:

 

http://www.cs.uregina.ca/~jaclarke/ELpics/Emit.jpg

 

 

At first I thought the object must be set to emit, but commenting out all GL_EMISSION settings and glDisable(GL_LIGHTING) calls for 3d objects didn't do the trick. Map editor says it's not set to emit. Is this a bug?

 

Ah! I see Entropy says that some objects have "issues" (being euphemistic).

 

How about boat1.e3d, tile_stucco3.e3d and tile_stonewall6.e3d for starters? (Glow in the dark objects I noticed while making pics and video... tile_stonewall6.e3d is shown glowing just before sunrise in my video)

Edited October 14, 2006 by emajekral

[Roja]

Some of the old objects didn't have their normals exported correctly when I used an old exporter. I have been reexporting those objs whenever I find them, thus correcting their problem.

 

I will correct those ones you listed, thanks!

[KarenRei]

Some of the old objects didn't have their normals exported correctly when I used an old exporter. I have been reexporting those objs whenever I find them, thus correcting their problem.

 

I will correct those ones you listed, thanks!

 

Interesting! That seems to explain it then. There are three problems, not one, as I initially assumed:

 

1) Objects with too low of a poly count to be responsive to point lights (I've actually run into this myself several times, so I didn't know why I didn't think of it before). If you can spare the polys, a few subdivisions would be nice. If you're worried about poly counts, perhaps an optional LOD?

 

2) Objects with improperly set normals.

 

3) Too high of an ambient value (emajekral -- when you lower the ambient on that scene, it looks wonderful).

 

Good to know! These are all fixable things.

Edited October 14, 2006 by KarenRei

[KarenRei]

Update:

 

I've finished making packages (both for the game and for the music) for Fedora Extras. They've been tested, and work just fine. Now I need to submit them for review with the Fedora Extras team. This usually takes a few days. When (assumedly) they accept them, I'll be able to submit them to the server, and after a few days, they'll show up. All future fedora extras releases will then contain eternallands, making it a nothing task for fedora users to install it.

[emajekral]

If you play around with ambient settings I've got some suggestions:

• Keep some ambient light at all times. None at all is scary dark.
  
• A fair amount of ambient light is needed to make convincing daylight.
  
• Daytime outdoor ambient light tends to be blueish (cause the blue sky is the biggest source of ambient illumination)
  
• If you turn night/dungeon ambient light very low you may wish to place a light at the camera or player position so that players can read signs as they get close. Quadratic attenuation and dim light will do fine, I'm sure.
  

Navigating with the modified client was difficult because things not directly illuminated were totally black. Daytime with no ambient light just looks bizarre. (cf pic of boat with broken normals)

[KarenRei]

If you play around with ambient settings I've got some suggestions:

• Keep some ambient light at all times. None at all is scary dark.
  
• A fair amount of ambient light is needed to make convincing daylight.
  
• Daytime outdoor ambient light tends to be blueish (cause the blue sky is the biggest source of ambient illumination)
  
• If you turn night/dungeon ambient light very low you may wish to place a light at the camera or player position so that players can read signs as they get close. Quadratic attenuation and dim light will do fine, I'm sure.
  

Navigating with the modified client was difficult because things not directly illuminated were totally black. Daytime with no ambient light just looks bizarre. (cf pic of boat with broken normals)

 

I agree with all of those points.

 

Unrelated issue: Some of the fedora packagers have an issue with the element in the license that "You may not use modified versions to connect to Eternal Lands server, without our approval." Their concern is that if a security issue is discovered, Fedora will want to patch it immediately. Their concern is that their patching it would constitute a "modified client", and thus they'd have to make it not connect to the server by default any more.

 

How should this be resolved?

[Entropy]

If they discover a security issue, they should submit a patch and a description to us, and we will include it right away in the CVS.

Alternatively, they can just ask for our approval to distribute their own changes in the Fedora package, and if it's only a security issue that doesn't create any cheating, we will grant them the permission.

[KarenRei]

If they discover a security issue, they should submit a patch and a description to us, and we will include it right away in the CVS.

Alternatively, they can just ask for our approval to distribute their own changes in the Fedora package, and if it's only a security issue that doesn't create any cheating, we will grant them the permission.

 

Thanks. New issue: eternal_lands_license.txt contradicts license.txt. Namely:

 

"4. If you want to [re]distribute this game, you are NOT allowed to modify anything. You can, however, distribute some txt/doc/etc file, with information about you, etc."

 

Versus:

 

"3. You may make modifications to the Software and distribute your modifications,

in a form that is separate from the Software, such as patches. The following re

strictions apply to modifications:

 

a. Modifications must not alter or remove any copyright notices in the Software.

 

b. When modifications to the Software are released under this license, a non-exclusive royalty-free right is granted to the initial developer of the Software to distribute your modification in future versions of the Software provided such versions remain available under these terms in addition to any other license(s) of the initial developer."

 

c. You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change."

 

I think the key issue is that you don't want illicitly modified software connecting to the server, as is specified in eternal_lands_license.txt restriction #4. Should the wording in license.txt be modified to reflect this? As it stands, the two don't reconcile.

[Entropy]

There are two licenses.

The game license, including the art, maps, sounds, etc.

The source code for the client license.

 

The game license does not permit modifying stuff such as the artwork, maps and so on, partially to avoid cheating and partially to avoid bug reports due to someone packaging bad stuff.

 

However, since the client source code license allows some modifications, those modifications are allowed in the game, if someone is to repackage the client.

[KarenRei]

There are two licenses.

The game license, including the art, maps, sounds, etc.

The source code for the client license.

 

The game license does not permit modifying stuff such as the artwork, maps and so on, partially to avoid cheating and partially to avoid bug reports due to someone packaging bad stuff.

 

However, since the client source code license allows some modifications, those modifications are allowed in the game, if someone is to repackage the client.

 

So, the artwork is under a different license than the source?

 

Lets back up a bit. Is the intent to stop people from using modded clients from connecting to the server without permission, or is the intent to prevent parts of clients from being used in other projects (and if the latter case, is to prevent parts of the client from being used "ever", or being used "without crediting the original"?)

Edited October 15, 2006 by KarenRei