mikeman

Hey KarenRei, as far as the lighting goes maybe I can give you some hints that will help you when you implement it. Most of the things you mention can be attributed to: 1) Ambient lighting. As others have said, at night there is no sun, only local lights that have a certain (spherical) area of influence. Beyond that, everything gets a constant amount of lighting. If you lowered the ambient and maybe add an additional directional light that represents the moon? 2) Vertex lighting. All the models have normals, but the lighting is calculated only at the vertices, not on the whole surface of each polygon. You'll see this in static geometry, because character models have a higher tesselation and they don't suffer from the problem this much. A large polygon with a small light in its centre will look all dark, because its corners are dark. A large polygon with small lights close to its corners will look all light, because its corners are lit, and so on. You can implement plain per-pixel lighting(which does not require normal maps) or normal mapping to fix that. 3)One other thing I noticed, at least when I was working on the code, is that EL takes into account only the lights that are visible from the camera's POV. This is not entirely correct, because a light maybe invisible but you can see its effect on visible geometry(for example, a torch out of view lighting a box inside the view). I noticed some incorrect lighting/popping due to this. -EDIT: Ooops, I see you adressed those issues in page 1, sorry Anyway...

You need to set the value of the samplers(and all the uniforms you use) from within the program. Assuming you have bind the rock texture into TEXTURE0 and the normal into TEXTURE1: int uniform_rock_loc=glGetUniformLocationARB(program_object_handle,"rock"); glUniform1iARB(uniform_rock_loc,0);//Set rock=0(TEXTURE0) int uniform_rockNormal_loc=glGetUniformLocationARB(program_object_handle,"rockNormal"); glUniform1iARB(uniform_rockNormal_loc,1);//Set rockNormal=1(TEXTURE1)

http://www.delphi3d.net/hardware/extsuppor...x_buffer_object It's supported all the way down to GeForce2(I'm not familiar with ATI hardware). How much lower can you get these days? Even Intel supports it!

BSP-based PVS has pretty much stopped being used by modern games for rendering. BSPs are maintained for other things(like collision detection), but Doom3 for example uses portals for hidden surface removal. I always found a little weird the framerate I got with EL. It just doesn't fit what I see in my screen. The polycount is pretty low compared to what graphics cards today are capable of. Are you using the VBO extension?

The thing is, fog and skybox doesn't really match correctly. You see in the pictures of EL and other games that do that that objects in the back look like gray blobs against blue sky. It looks unnatural. You can do a "hack" and make the sky "fade" into the single color of fog as it approaches the ground, but still that works only for object until a certain height, but it should look good enough. One thing I've thought but never really implemented is how an emulation of a round planet would look. You could just use a vertex shader to offset the vertices down the y-axis according to its distance from the viewer. Far-away objects would end up being below the feet of the viewer, thus taking care of the visibility/invisibility. Kinda like sailors see faraway objects smoothly appear due to the fact that Earth is round: even without fog at all, they still have limited vision because of that fact.

When I wrote the initial Cal3D implementation, the cal3d_wrapper just didn't expose some necessary functions as CalModel_GetMesh. As for CalModel_ExecuteAction there *was* such a function, but it didn't expose the autoLock parameter at all. Internally, the wrapper was always setting it to false. Since I couldn't done any overloading in C, I had to write a function with a different name(CalModel_ExecuteAction_Stop) which was always setting autoLock to true. So, I had to edit the .h and .cpp files so we could access those functions correctly from C. I don't know in what state the wrapper of Cal3D is now since I'm done using C, but if it at lasts wraps all functions and classes, yeah replace my modified versions with the official ones(and of course make some changes to the code).

Hm. CalMixer_ExecuteAction_Stop() is supposed to run an action animation, and then when it reaches the end it "freezes" in the last frame instead of being removed, which would cause the model to return into the default pose. It's not something I wrote, Cal3D in C++ supported it through a "lock" parameter or something like that, but not on the C wrapper, that's why I had to expose it this way. I had to use it to avoid the model going to default pose when switching animations(the timing in EL is not exact). CalMixer_RemoveAction() does not do the same thing at all. Also, I'm sure CalModel_GetAttachedMesh is needed. I don't remember exactly what for because I wrote the code a while ago, but I tried to found other ways to do things before deciding to expose those few functions that existed on C++ and not on the C wrapper. -EDIT: I just saw what GetAttachedMesh is used. It's used to identify the current rendered mesh and find out if it's a weapon or shield. The reason is that weapons and shields are "special", because they can be holded by tall or short model, but you mustn's scale them as well. You need to scale their position so they will be "attached" to the correct bone, but not change their size. If you can't use that anymore, I guess you will have to build your own list with MeshIDs that you can access and see what kind of mesh is it(body part or weapon)

Ok, I was talking about the biggest map in the game(including interiors and whatever), and I think I overestimated it. Do you really have 90 maps with 500K triangles each? Can anyone say with certainty, about how many triangles all the maps have, so we can be sure? Well, performance will surely increase(because the lighting isn't calculating in real-time), you can use as many lights as you want with no impact, you can use radiosity instead of direct lighting if you want, you'll have static shadows in night-time(static objects casting shadows onto static geometry, and possibly onto actors as well), and normal mapping as well is an option requiring only 1 pass using a fairly simple shader for an infinite amount of lights. Also: The lightmapper does 2 distinct things: 1)It applies UV coords to the vertices so they sample the correct lightmap texels. 2)It calculates the lighting for each texel. The second is what takes so long. (1) is much much faster. We can distribute the result of stage 2(lightmaps as .jpg), and have the players run only (1), so they can utilize the already given lightmaps correctly.

I think you overestimate it too much. The maps are not that big anyway, and the models are pretty lo-res. For 1 map, you would need: 1)A 512x512 lightmap. In .jpg, that's like 50KB. 2)What is the polycount in the biggest map(static objects only)? 500K triangles? So we would have 500000*3=1500000 vertices. We need to store the UV lightmap coords[0..512,0..512], and using bitfields we need only 3 bytes for each pair, so that's about 4 MB uncompressed, probably 2MB compressed with WinZip. Or, as an alternative, we don't give data files at all. We just supply a small program that builds the lightmaps, and let the players "upgrade" the maps themselves. It may take some time, but they only have to do it once.

1. I'm talking only about the night, where all those points lights are enabled. Day has only 1 directional light(the sun) that changes from minute to minute, so you can't use lightmaps here. It will continue to use vertex lighting. In the case of radiosity normal mapping, accumulating the lighting per-vertex and not using lightmaps also works well, so there will be no discontinuity here(if the user chooses normal mapping, it will be present both at day and night). 2. Well, you would need to store the lightmaps(a bunch of textures really), and of course the lightmap coordinates for every object. Even using .jpg for the lightmaps would be ok, and for the coords you don't need to store them in float format, 1 or 2 bytes for each coord would suffice. Not that much bigger.

The vast majority of lighting in the game is static(static lights against static geometry), yet it is handled as standard,dynamic,8-light per-vertex lighting. You could precalculate the total lighting in each vertex of the models, store that info in the map and get exactly the same result for an infinite amount of static lights with a single glColor3f() call for each vertex. Or use radiosity maps(or even radiosity normal mapping) and get even much better results.

Hey Roja, sorry for not being aroung, but I've been so busy I just have zero time for programming, and I won't have for atleast another month. As for the random idles, most of the functionality needed is there, I don't think it would be difficult for any of the other guys to finish it.

Hm, why not just do both? Have the option to set the camera distance from the player, and also the zoom. For example PgUp/PgDn(IIRC that's the keys) will zoom in/out, SHIFT+PgUp/PgDn will set the camera distance. Also, a nice effect on rain drops is to not make them have a solid alpha all over. If you give low alpha to the vertex that "points" up and higher alpha to the vertex that points to the ground, it looks much better.

The issue with close objects being fogged shouldn't happen with perspective projection. Fog distance is calculated from the origin(0,0,0), where the camera is supposed to be, unless you have put the code where you set the camera position inside the projection matrix. Also, to avoid handling problems differently between ortho and perspective, you can ditch ortho altogether and "fake" it by using perspective projection with really low FOV. It appears almost the same as orthographic.

Are you talking abou this? _mesh=CalModel_GetAttachedMesh(act->calmodel,meshId);//Get current rendered mesh   _coremesh=CalMesh_GetCoreMesh(_mesh);//Get the coremesh   _weaponmesh=CalCoreModel_GetCoreMesh(actors_defs[act->actor_type].coremodel,actors_defs[act->actor_type].weapon[act->cur_weapon].mesh_index);   _shieldmesh=CalCoreModel_GetCoreMesh(actors_defs[act->actor_type].coremodel,act->body_parts->shield_meshindex);   if (_coremesh==_weaponmesh) boneid=26;//If it's a weapon snap to WeaponR bone   if (_coremesh==_shieldmesh) boneid=21;//If it's a shield snap to WeaponL bone That's the only place I don't check whether mesh index==-1, because I don't operate on the returned mesh. I just check if it's equal to _coremesh, which is guaranteed to be valid. If meshindex==-1, then it will return NULL. About those other bugs(falling into holes, starting fighting anims, being at the wrong place)... I just trigger anims when the respective command is processed, and I haven't touched the command queue code. Is it possible that this happened with MD2 too and just didn't show up then? How can I cause invasions in the test server so I can check out the problems myself?