emajekral

I should have used the word cells. Cells and Portals are a visibility technique to be used together with frustum culling (which we already have). Basically they involve defining regions of a map that are relatively enclosed and have only a few small "portals" through which you can see other parts of the map. When a portal is visible you use its edges (or a rectangle around its edges) to define a new frustum that lets you see into the space beyond. Maps like the Tarsengaard map are ideal candidates for this. As a first step, when we define a system for choosing what parts of a map get what sky we also create a rough kind of cell. All the geometry inside the cell becomes a mini-map and gets its own storage in memory separate from all the other little cells on the map. Some of the doors (and maybe archways) in that map can become portals. This will reduce what needs to be culled and reduce what is rendered that shouldn't be seen anyhow. The reduction in what is culled is important. I've noticed that the culling step can cut frame rates by over 5fps on busy maps. Comparing 1000's of objects against 8 planes at the cost of several math operations can be time consuming. Having smaller sets to compare against, or some predefined way of completely ignoring huge amounts of scenery with a minimum of fuss is a big advantage. See this link, starting on page 19. We don't actually need the portals to start, just the cells. We may never wish to use portals because lining up ceilings and walls may be problematic. Using boxes or polygons to section off independant parts of maps would eliminate some slowdowns that don't seem to make sense. Any further discussion belongs in LOD, even though it is tied to skyboxes. By sectioning maps into sky regions we define a perfect candidate for a scene complexity management strategy. PS At the end of that presentation is a quick case for the use of distance sorting of primitives/scene elements (not polygons) combined with occlusion culling to improve performance. That technique is used, with a hardware assist - GL_[ARB|NV]_occlusion_query, in games like Serious Sam 2. edit: trying to make sure it all makes sense.

In post 22 on this thread I suggested using a system like the one for sound to manage sky definitions for maps. I still think this would be the best plan. Going even further, I think that a basic portal system would be a good idea for interiors maps (It might make places like Tarsengaard Magic School more friendly to fpv play). I have noticed that several interiors show a noticeable reduction in framerate in certain directions in fpv, probably those with lots of out of sight interiors, most notably (to me) the storage in portland: the slow down happens when you face into the room from the door making fpv nearly useless. Sound, sky, and portal maps could all be handled similarly (except that portals may need polygons, not boxes) and should sooner or later be incorporated into the map editor if sound isn't already. There would be no need to include these polygons in the map files, they could be stored separately just as sound is now. For now I'll make it so that if no sky is defined for a region on a map, no sky is shown, or a default colour is shown. For the sake of those who use traditional views and to keep water looking good I propose blue.

ttlanhil: I only have a sky that reflects time of day and has stars and clouds. Let me hack in a sun and moon, make a generic rock sky for caves, turn off sky for houses, and tweak the sky color a bit for sunset and sunrise and hook the weather to change cloud cover. Then I'll let you know. Once I'm there It'll be ok. The reflections aren't reflections yet (They're just the bottom of the sky spheres). Eventually I'll use a stencil to make them look right. I won't be doing any of that until I merge my changes with the new client. I'm going to set them up with defines and everything. ( I was too lazy when I started, and it became a difficult task before I knew it. I've hacked at over half the files so far. ) If it gets to be too long I'll just release a version to you that isn't too ugly (say 2 more weeks). Roja: Yea, that's me. Somehow an interest in MIDI music (I'm a singer who can't play piano. How sad.) morphed into an interest in computers, which, combined with a fascination with the demoscene (Yay Future Crew), led me the wrong way into computer programming. I found an outlet in Computer Graphics only to discover that people thought I was good at math. Hahahahahahaha! I wasted a full year of post-graduate studies making a recording with this group and going to competition with them.

Silly songs with Ezzat And, of course, a look at the latest iteration of the skybox.

UPDATE: Patch and Binary removed pending 1.3.1 update. Once the new source and client are released and I make my stuff work with them I may replace them. Windows version can compiled with Dev-C++5. See how to compile the client by clicking the link in the next paragraph for a tutorial. (Post to that thread if the tutorial is broken) I would have had it up sooner but I had a wrestling match with VC6, gave up and had another with Dev-C++5. I won the latter. Victory speech here After that I test compiled it and discovered I had nearly destroyed the shadows and lighting code (game clock was night at the time, see). That bug is fixed. Still haven't converted all floating messages to Orthographic yet. What's new: Extended Camera Camera has wider range of motion Camera is now centered just above player head (only tested on human - other races let me know how it works) *** use a perspective of around .45 for this option Follow Cam Camera follows the character as it turns When the option is first enabled the camera moved directly behind player Works great with Extended Camera Ortho Banners Because the game would be *ugly* without it I have folded the Orthographic patch into this one New Configuration Options Extended and Follow Camera options are now in Video tab at the top The Orthographic Banners option is not configurable. So there Other Stuff Follow cam is a bit herky jerky due to the limited directions the character can face. I'll see if I can smooth it out a bit The Video tab is now overflowing. Can anyone suggest where else to put these options? The camera height could be made adjustable so that players can make it work for their race. Check out how things look from Directly overhead - Classic Warcraft New configuration options are disabled by default The current client does not render everything you should be able to see right away if the camera changes too much (those who use the current high perspective camera know this) just move the character or your mouse and that will fix itself. Here's some screenies. To make overshoulder usable I think that clicking on your char should generate a movement somewhere in front of the character... either that or alpha-ing the character and allowing clicks to pass through him to the scene. Both are possible client side modifications. Source may come later... but I want feedback first. This modification changes only 7 digits in draw_scene.c so I may just post the modifications here. So far I've tested movement, passing though doors, combat, and subsequently I navigated out of the underworld... so its useable.

Fixed and fixed. Fixed. Previously the back clipping plane was hooked into the near plane. I have separated the two for the first person mode only. There will be a far plane spin box now. Objects nearer than the far plane will all be rejected leading to a fair speed boost. The near plane will not be adjustable in first person because you will see the ground clipped in front of you. Not good.

Using control and clicking files in Windows (and some other modern window systems) is a way to tell Windows to keep everything you've selected and toggle the state of what you clicked. What I'm telling you to do there is select everything *except* cal3dwrapper.c and cal3dwrapper.h and I show you how to do it really fast. (Takes me 2 seconds) It's just the kindergarten, hold your hand explain later, way of doing it. Sorry.

Please keep the -DUSE_FRAMEBUFFER define for now. The framebuffer code does things that interact with my camera code badly, even when the elconfig option is turned off. For one, it seems to change the far clip plane. It is also buggy. In a clean install (compiled from unmodified source in linux, and the official installer in windows) the elconfig option claims it is currently only used for Reflections and on my system (gForce 6800, new drivers) enabling framebuffer causes reflections to flicker in Linux, and disables them completely in Windows... The only noticeable effect on reflections is that the fake sky color no longer appears when reflections are on, just the clear color with a little alpha texture. Also framebuffer allows me to use higher resolution shadow maps, despite what the option claims. Are these things only a problem for me or have others had them as well?

Are these the compile options for the official client? I'm pretty sure that the last two official windows binaries had -DUSE_FRAMEBUFFER at the very least. Are there any others?

I found that the size didn't help things much and have just done a cull on distance squared in my version (with spin box to adjust it ingame). I'll have a look at yours and see how they play together. Mine is automatic for reflections, cause the cull is done on 3d objects only. 90% of rendering effort is expended there. Roja can confirm this using my client: turn off reflections and shadows and you'll find that the boxes labelled tiles, 3d objects, 2d objects, etc will turn on and off those layers. Using simplified models in a certain range may further improve performance. Billboards are my plan for now, but I'm not saying that using lower poly count 3d objects and no alpha testing in the mid-distance wouldn't help a lot too. I'm looking at using the bbox code for distance sorting and occulsion testing. If I'm right the bbox hierarchy uses some kind of space partitioning that can be used to get near O(n + ln(n)) sorting time on distance for objects, similar to bsp trees. If objects are rendered front to back we get an automatic savings on texture lookups, alpha tests and other stuff. If the hierarchy can't do all this then it's time to look at bsp or k-d trees as a preprocess step.

Yup. Right now there's a hotkey to flip back and forth. The mouse grab mode is available in all views, but is only really useful in first person mode right now. It can be used in over the shoulder with follow camera disabled if you like, or I could make the client lie to you about what direction your character is facing and force it to have its back to the camera at all times. (That would make the client disagree somewhat with the server, but only in an eye candy way. Shouldn't break anything on the server.) That would have to be disabled when your character begins fighting so that you don't look like you're kicking the air and getting bit in the... It's doable. Then again, most people will naturally look at what they fight so maybe its not a problem. As far as further refinement of over the shoulder, I think that the character needs to be made unclickable and an hotkey for a good default view needs to be made, but that's fine tuning that can be done later. What all gets integrated will be interesting to see. We need a sky and better LOD or visible surface culling before this stuff makes it into an official client, so... Anyhow, there's a lot of settings in the modified client right now. Not all of them work well with each other. In fact there's so many that the burden of state management gets a little too high for the player. The options need to be simplified and bad combinations need to be made hard or impossible to stumble into. Which ones we want will take play testing.

Perlin noise or whatever sounds okay, but a little animation in terms of one sliding over and blended into another for the Underworld would go a long way to making it look good. Caves can be pretty static. In terms of specifying what skies/fiery infernos to use where, I was thinking that something like the music config files could be used. When a map is loaded, sky textures in the sky file for that map are read and applied. That way the sky can fade ominously to dark in certain areas on maps, and we have a solution to the problem of what to do to represent the horizon, whether it be land or sea, when people get to the edge of maps: the horizon is specified by rectangles near the edges of the map. Another issue that needs to be dealt with is the fact that on interior maps other unrelated, or supposedly unseeable, interiors are visible. Roja mentioned this. There needs to be some way to specify what areas to show. Normally this would involve portals and such. I think that perhaps we need a plan to deal with this. But this is a LOD issue.

Those references should all exist provided all the .c files compiled successfully with the correct defines set. As the defines for the link stage look OK try: make -f Makefile.bsdg clean ; make -f Makefile.bsdg Your .o files may be old. Shouldn't happen, but you never know. If you changed your defines but not your source files that kind of thing can happen.

Yes. They try to teach programmers not to be like that in some of the soft-er content courses (like Software Engineering) but when your head is buried deep inside a project you tend to forget what others don't already know. Many programmers are familiar with the scroll box editing quirks from using weird widget sets in Unix-like environments. The whole EL widget set makes me think of the horrible old Athena widget set that was created at MIT as a sample for the X Window System in its early days. You had to keep the mouse inside any box you were typing in. Line art buttons, no colors. *Bleck* Here's a fun one to try. I think it's a bug (drag events interpreted as click events), but many bugs are features. Click in on an arrow on one of the scroll boxes. Wiggle your mouse ever so slightly from side to side. Watch the numbers fly past.

Glad to be of service (and thanks Placid for putting the devpaks in one place. I'll fix the rest of the guide to reflect that soon.)

Thank you all for your kind words. I hope that the compliments I got from you for the video translate into the real world when I start my new job as CS Lab Instructor next week. (And yes that means the patches from me will probably dry up for a while ) Nothing really, I just wanted to show off before everything was just so. Impatient I guess. I used a combination of SDL functions to grab the mouse and allow unlimited camera motion, ie. the mouse never leaves the frame. The side effect of that is the mouse is hidden. I was in a hurry and didn't feel like putting up textures, so I pasted a bunch of string copies in the cursor handling code and displayed the strings as the last step of scene rendering. There's no reason I couldn't just put the use quads with icon textures there, but I want to use a proper targeting reticle with the icons off to one side. I tried to use SDL_WarpMouse to move the mouse back to the center after reading mouse motion events, but warping in SDL generates a MouseMotion event and I had trouble finding and ignoring those. The end result was a mouse icon that jittered around in the center of the screen and an uncontrollable view (every move was undone by the warp). So I took the path of least resistance, used the tool provided and life was easier by far. Except I've got a kludge instead of pretty icons until I get up the energy to fix things up a bit and maybe get some artwork from Roja. (I just read your comments about that. I can wait.) I think EL themed crosshairs would be really neat.

Cheesy Video

If I get an affirmative from a mod/admin I'll submit it and post the link when it's approved. BTW the pictures went up just after you posted.

Work complete. There is now a first person camera. Use ctrl-f (for first person) to toggle first person camera. There are two interaction modes: action and HUD Action mode has an X in the middle of the screen for a targeting reticle, and a text banner to describe the interaction type (Walk, Use, Attack, etc.). It is implemented using the grab mouse feature of SDL. This feature should work in Linux and OSX as well as Windows, but it has not yet been tested on those platforms. HUD mode is just like regular Eternal Lands, except the camera can be first person. Use ctrl-g (for grab mouse) to toggle action/HUD mode. Action mode is available for all cameras, but it works best for first person. It is possible to use hotkeys to turn on chat, map, and other dialogues while in action mode, however I recommend hitting ctrl-g to release the mouse before using the map, cause you can't do it while you're there. I'll fix that if it bugs enough people (probably when I make/get a graphic for the reticle and replace the text interaction banner with the appropriate icons). (I have a video ready to upload to Google Video. Do we want that?) There are also some mode change fixes for the follow camera. It now keeps the camera at the angle positioned it when you switch in and out of follow mode (I hope).

dns_server: I am aware that the scene representation is inefficient or used inefficiently. There are reports of very slow frame rates and I am looking at strategies to deal with it. The objective is not, however, to make a first person shooter out of EL, but to provide some first person interaction on a trial basis. In terms of how to use BSP trees, they allow ordered rendering of a scene, generally back to front (good for alpha blending), but can also do front to back (duh). Using that information one can use occlusion culling to improve performance. There's an NV extension on gForce 3 and newer cards that allows that test to be done in hardware. I have an article from Croteam on how to do it properly. Outdoor maps could benefit a lot from this. Especially if there were an additional sort on object size ( a separate bsp tree for big stuff to be rendered first then small stuff is occlude tested against that). BTW, I'm having trouble categorizing the tree structure used in bbox.[ch] (see esp. sort_and_split). What is it? It looks a bit like a k-d tree. I've seen some discussion of the use of octree or k-d trees over bsp trees. Usually bsp trees seem to win, but... Perhaps the structure we already have could be used to better advantage? Until I know what kind of structure BBox uses I can't do much. Take your answers to the LOD thread. That thread was created to be a place to discuss framerate fixes. (Or make a new thread if you want to take on the responsibility.) For now I'm relying on my machine to just cruch the numbers. I get framerates over 8fps for all maps, and generally hover at 30. But I have a P-820D with 1G ram, and a gForce 6800. A little over the target machine for EL, i'm sure. kl4Uz, ttlanhil, Roja: Reserve judgement until you see it. It may be good, it may be bad. I may throw up my hands and quit. I may have an aneurism looking at some of the hacks in the code (mine and others'). Who knows? I've already changed plans 2 or 3 times as I make progress. I'll keep you posted.

Oh boy. I've got lots to say. Sorry. Auto Camera is kinda finished. There's some mode switching stuff I want to look at. Right now when you switch between follow mode and regular mode the camera jumps to a different angle. I'm going to eliminate that jump. Trying out a first person view is possible. In some games I've played there's such a view, and there are different ways to handle it. Spyro the Dragon, Knights of the Old Republic: the look around view does only that: you move the camera around to look at things, but you must switch back to regular camera to move. Action games: actually switch between full featured first person and third person. In EL this would make first person an action mode: mouse look then click on what you want to do, switch out to do anything else (with a different camera and everything) Star Wars Galaxies: mouse look mode and a HUD mouse mode same view for both except the cursor becomes a crosshair in look mode Things to consider: Just look, limited interaction, or full interaction with mode switching What to do with cursor: hide, center, make into some crosshair type shape that changes when an actionable item(Ooooh! Corporate speak!) is available? Is there something logical the middle mouse button should do? Could it toggle between HUD and look? Should it be left alone and the game be played as before? Just look is easiest, a little harder if we want the mouse hidden (but not much harder). What hotkey to use? Do we still want a hot key if the mouse toggles the interaction mode? If motion is permitted in first person mode there will need to be some kind of spring back cause the camera will move strangely if you're not pointing the right way. (I tried it, then needed to go lie down for a bit ) Some other things I've been considering: Should we provide hotkeys for useful camera positions? Should there be a lock camera feature, or is middle mouse safe enough? (I've ruined a good position through a desire to look sideways for a bit) Should we allow the player to store a few favorite camera positions? A big problem with follow camera: There's little I can do about the fact that the character often stops in a position that is different than the general direction of travel.I could try some crazy stuff that makes the in game character face a direction that is different than the one it faces on the server and is instead a smoothed out version of the travel direction, but that would be bad - we don't like the client representing information that is different than what's on the server. Doing the first person camera itself is really very easy. There's already code in the client to do special stuff when rendering your character. I could use the same code to turn off the character, then set a flag that tells the camera code not to move out, just to move to eye level then rotate to match the camera's direction. BUT I made a boo boo and started implementing some very broken sky and LOD code over top of fixes to the camera, so I have to fix that before trying anything else. Before releasing first person I'm pulling out the sky stuff cause it's really bad right now. I've got some stabler stuff in LOD. Does anyone want to be able to change the back clipping plane, remove layers of tiles and change whether to display objects smaller than some size? Hey experienced programmers: what's the [best|a good] way to manage development of multiple features? How are patches merged into the client? If I want to prep a change for merging what do I do? Are these related? Is there a thread for this? (I'm expecting answers like use your own CVS, Subversion is nice, blah blah blah. What I want is: How I work on different projects then merge the results nicely later. How I cope with changing CVS code. Maybe I need to be neducated in diff and patch. If that's it then tell me so.)

Yes, if resolution is a concern many 512 textures could be used, either one texture tiled, or many stitched together for greater variety. Texture memory becomes an issue if we try to do too much. As for changing weather... I'm sure something could be hooked into the existing weather lighting and fog system that could cue cloud cover changes. If we're okay with fading from one cloud type to another then it's a matter of tracking which clouds are being displayed, loading the new clouds into the inactive ones and then fading over. I think. I've been busy suffering from heat exaustion so I'm not too thinking too clearly.

You're getting dangerously close to volumetric shadows there. The technique I suggested is a simplification of a volumetric rendering process, but it is too simple and very hackish. I'm guessing that the major projects are now using volumetric shadows. I have some cg code snippets, paper references, and commentary in nVidia's Graphics Gems somewhere in my office. I have no idea how hard the system is to implement, or how much tuning is required for performance, but... hold on... they say As if the implementation itself wouldn't be bad enough. But if we get em, they sure are pretty, and can have very complex light interactions - they can be lit by multiple sources using BRDFs. For clouds the idea is this: store low detail shapes in a 3d tex map, and perturb them with a small procedurally generated and animated noise texture volume. Light using a custom fragment shader/light table. Lookit the pretty: This cloud technique would be icing on the cake. A basic cloud system is needed for those without shader capable GPUs.

There is no first person view, only over the shoulder. The new camera is flexible. It has a follow mode and a free mode. In follow mode the camera tries to follow the character at a user specified angle. You place the camera relative to your character and it does the rest. In its latest incarnation the camera works without any hiccups but does not do collision detection, and I will never implement code to do that (because I've seen it done badly too many times and I don't think I'm good enough to do any better). There are some parameters to tune camera follow speed and acceleration in a new configuration tab - because the character can only face in 8 discrete directions and following too tightly is nausea inducing. As in the official client (OC) camera repositioning is done with the mouse or the up,down,left,right, page up, and page down keys. In free mode the camera is exactly like the one in the OC except that you have the option of using the camera from parallel to perpendicular to the ground. If you've ever played Neverwinter Nights then you have a rough idea of what to expect.

If the sky can be composed by layering images with alpha channels, then that all I did with Gimp for display. I don't think it there is any actual need to simulate clouds on the client though, as I describe above. So some stock images which can be merged for variety should give the right illusion. C'est exact. Sphere + texture + inverted normals = sky sphere. A, B : Two spheres with clouds, with patterns generated in Gimp or Photoshop ... this is done in the old Quake games. C: One sphere with stars that fades in at dusk and out at dawn. D: One billboard that tracks the sun used in shadows. E: One Billboard that has the moon that follows some track I don't know yet. F: One Sphere that has Sky colour. G: One cylinder that has fog coloured haze that fades to Sky colour. (May be integrated with F as a Height vertex colour function. At some large distance, with huge spheres Centered on player Render in order: no_alpha( F+G ) + alpha( C ) + alpha( D )to allow a glow + no_alpha( E )so that moon covers sun + alpha( A) + alpha( B ) Spheres with clouds can fade in to allow clear skies, or they can have one blue hemisphere and clouds can rotate to travel beyond horizon. Continuous cover is achieved by having the spheres rotate at certain relative speeds. Care needs to be taken that the degenerate point at each pole of the spherew is not obvious. This is an artwork issue. I'm pretty sure this pattern will work in reflections and regular rendering. Using one cloud texture, some surfaces, alpha blending, and gl's glColor*() functions I'm pretty sure one can make clouds that look like this (3 layers: cloud, shifted red tinted cloud, blue) removing the red tint gives this: I'm hacking together a module to handle this. I seem to be having some troubles with openGL's states though, so I may take a while. If I get it done, expect sun tinted clouds, haze on the horizon (and maybe sunset colors), sun, moon, and stars. There will be no cloud shape evolution though. I'm not about to rise above cheap hack level on this one. Sorry. Maybe one of the other efforts will work and we can plug it in. (Sorry Roja, I didn't look at your pictures before posting, I'll leave it here, but...)