emajekral

Learner got it. I needed to do the same for my Fedora Core 4 when I started looking at the source, but I've been through dependency hell before and knew what I was seeing...

It looks like Intel has decided NOT to provide adequate hardware acceleration to OpenGL, even on platforms that don't have DirectX: http://everythingapple.blogspot.com/2006/0...ble-opengl.html Also from Wikipedia: http://en.wikipedia.org/wiki/Intel_GMA Maybe you should write Intel a dirty note. OpenGL is a mature standard and should not be ignored, especially when one of the major platforms Intel is now supporting relies so heavily on it.

I've been pirate daying since 2001. This video introduction just got slashdotted. Dirty James Kidd You're the pirate everyone else wants to throw in the ocean -- not to get rid of you, you understand; just to get rid of the smell. Even though you're not always the traditional swaggering gallant, your steadiness and planning make you a fine, reliable pirate. Arr! Just 'cause I admitted I've skipped a shower now and then. Grumble.

Nice. It's the little details that make all the difference. I like: - the visible mortar - doorframes - specular 3D look for doorknobs - better inset look for window panes This will help. Good work given the constraints.

Video made me wish I was there. I'm with sisteMa`, a little more camera freedom would have been nice, but I'm biased The music was appropriate and made me wish I had something other than cheesy MIDI and a $5 mic when I made my last video. Good job!

Got it.

Can't wait!

I'm pretty sure clean CVS builds are allowed on the main server if the binary doesn't work for some reason. If the rain fix was needed you would have had to ask for permission to use it.

Bloodsucker, here's the quick fix: Go to gamewin.c hit CTRL-HOME hit CTRL-F paste render_rain into the search box hit ENTER Go to the beginning of that line and add this // now that line should look like //if (is_raining) render_rain (); compile. No more rain. (Unless you compile with -DNEW_WEATHER) If that doesn't work then do the same in timers.c with the search term update_rain Do you usually play in another OS, or did rain work for you in the last client under Windows? Experts: Possibilities: Array bounds checking error? New CPUs can use hardware to do fine grained access enforcement. I ran into that about a month ago with some old software an office mate wanted to use. Is it possible to have too many vertices in a vertex array? Has MAX_RAIN_DROPS been increased? Edited to remove stupidity and cause I'm thinking slowly today.

Nope. That hasn't worked for me yet. No console window. You'll note my Dev-C++ guide recommended that as the project type. I double checked that that was what the project type I'm using now and it is.

If you follow my Dev-C++ guide then you will be able to debug from the directory you are coding in with just a couple extra steps... I do it. All you have to do is copy the contents of your EL app. directory to wherever your project directory is. Then specify that you execute and develop from the same directory. Does that make sense? (Am I doing something wrong, or have I left out too many details?) From there using the debugger is a relatively discoverable process, assuming you have previous debugger experience. This makes creating patches a little harder, but not too bad if you just copy source files around a bit. Now... how does one view console output in Dev-C++?

Glad to see that 1.3.2 has gone live. This is my opportunity to merge my changes with all the other ones and try to release a patch for testing and stuff. Problem: binary works fine (I can log on), but a clean CVS build displays version string "1.3.1p2 Beta" and is rejected by the server.

I'll let you know in 5 minutes. Works now. Great stuff. Thanks Learner and crusadingknight.

Can I just change that string or do the differences go deeper than that?

Mapmaking issue, I'm sure. This isn't the only place like this. Many doors are doubled, though this is one of the few where the one in front is smaller than the one in back. (For a while my FPV test client showed me the door partially clipped every time I went in to a room.)

not to put more work on you, but what would you think of a ray-trace type draw? if you can't directly see the square( or tile, coord, etc), don't show it... or maybe allow some bends... with the current EL landscape 2D would be enough... depending on the 3D storage/mapping (no, I don't know the details), it may be more efficient inside. small rooms especially, but to a lesser degree caves and castles Ray tracing is teh slow. I know how, but for good visibility in real time I have to ray cast for every pixel. Maybe this can be done in hardware, but I have to process the whole scene for every pixel separately. I know the guys at the ATi and nVidia do hardware ray tracing with shaders... maybe there are tricks they use that make it easier. I don't know. I'd have to look into it... The frustum is doing a terrific job mostly, there's just some times where there's a really obvious clip that it's just too dumb to know about. Cells are relatively easy: make xml for describing boxes on the map. In the client load the xml with the map. Use cell numbers and an inside/outside/intersecting test to either sort cell contents into multiple render lists or add a cell_number tag to objects in the main render lists. I just don't have time for them. are there ways to avoid it? disable mouse tracking, run event, reenable... warp the mouse to the position manually before grabbing it, etc? Yes. Move to a grabmouse only interaction model. The client takes full control over tracking the mouse's current position and decides when to ignore that information itself. So far that's been more tweaking than I wanted to do, but it looks necessary. BONUS: that will enable full color cursors for all interactions. That was the original plan. I don't know XML (except in a vague XHTML, related to LaTeX, its a data tagging language kind of way. I imagine it would be simple enough to get into if I needed to... but I'm trying to relearn x86 assembly so I can teach it). I was going to make a generic sky that could be reconfigured with a set of related function calls. I was hoping eventually to make it so that it would switch its type based on bounding boxes like the music in the game. That way maps with multiple sky types could have appropriate skies for each location. Those were to be stored in some text based format like XML. I also figured sky cells could be used to do rudimentary quick visibility stuff. Light_level could be hacked such that it can be adjusted for different day lengths. That could then be exposed in the XML interface for skies. No prob. One would have to do something like that for generic programmable skies anyhow. maybe based on the map number, or even a format chage for mapinfo.lst so you can set the sky-type (far easier than changing the elm format) Duh. I forgot about that. I got too focused on doing sky switching inside maps. I forgot that I could switch on filename - if needed. I'll work on that. It'll be a hack though: underworld is the only exception. There's a perfectly good sky/dungeon flag to use for everything else. I'll look into mapinfo.lst and see about that.

Ooooh. Pretty. I can see normal mapping, bump maps and other fragment shaders are going to be high on the development priority list. I sure hope I didn't scare Josh off...

I'm still here! I'm doing my best to hack at all the projects I've taken on, but between two jobs and kids I can't go very fast. I'm going to post here because I have pretty pictures , but there's stuff relating to fpv and lod. Pretty Pictures First: LOD: I've finally decoupled near and far planes. In third person the clipping planes have their old behaviour. In FPV there's an adjustable far plane and a fixed near plane. I get the best boost by far from playing with clipping. That frustum does good work. Bad news: The frustum doesn't seem to cull reflections properly. I'm going to look into that soon. Cells will have to wait. The complexity of the project is beyond me for now. I don't have enough cycles to spare. FPV: The middle mouse button toggles between mouse look and GUI mouse modes now. Switching to chat or map views also gives you GUI mouse and switching out puts you back in whatever mode you were in before. Bug: I'm chasing down a bug where switching between mouse look and GUI mouse causes jumping. SDL_WM_GrabInput triggers a mouse motion event the size of the distance from your cursor to the middle of the screen. I can't consistently catch it, and some developpers claim whether its generated is implementation dependant. On my machine the bug only present in full screen mode. Sky: New Stuff Clouds have time of day colors and reflect lightning. The sky has sunsets.Colors are a compromise between classic EL and some selected photographs. There's a horizon fog faker to reduce popping and bad far plane culling effects. (Real skies have foggy horizons anyhow. I've consulted photos and maybe burned a few too many lawns while at my second job.) There's a moon. I still haven't decided how it'll move, or if there'll be two. I need a better texture for it. It's implemented as a sphere, so we can probably do lunar phases. I'm using a stencil buffer hack to do sky reflections. If you pay close attention in Silly Songs with Ezzat you'll see that the clouds move in different directions in the water and sky. If you are only looking down or up it isn't a problem. That's fixed but only if there's a stencil buffer available, otherwise you get the old behaviour. Someone with more time can work on that someday, I'm sure. The underworld has a flaming sky. It's animated. It sits above a yellow lake of fire. Perhaps yellow isn't the best choice (the magma in the underworld is reddish). Stars have 3 brightness levels. (For the astronomers out there the stars have 3 magnitudes of brightness ) They also fade smoothly with time of day. Under construction: Sun Make moon opaque to stars AND still have it take on sky hue during day (stencil buffer) Moon halo and cloud effect (more stencil buffer magic) Moon motion - suggestions please: Always opposite sun, slightly faster than sun or slightly slower; always shows same face or rotates slowly, etc. Variable cloud levels. This will need to be coordinated with NEW_WEATHER. For now I'll hook the two cloud layers into foggy and rainy weather somehow. Haven't looked there yet. Compromises: In the absence of cells the sky will come in three flavours: Outdoors - reflected cloudy sky Indoors - black above, blue below... for water Underworld - flaming sky, lake of fire [*]It will be hooked into the dungeon flag. I plan to intercept the word Underworld in a certain message to trigger the Underworld sky. It will turn off when a new map is loaded. That is unless there's a better way...

I know. I disabled it halfway through, demonstrated what kind of difference it made (impacts fps even when fps is below refresh - but only to a small degree) then finished with it off.

Working on LOD slowly along with sky. On some maps, like White Stone, cells just won't provide a performance boost. On that map one can probably section off the magic school and a certain secret area, but those don't lie in the directions that exhibit the lowest framerates. So I poked at the code again. I checked a few assumptions. I made some observations. I have drawn some conclusions. I have some questions. Alpha testing is NOT a problem on high(er) end video cards in this engine. Even if alpha testing is a problem on low(er) end video cards either there's an efficiency issue in the pipeline OR the polygon counts are too high. (We get over 6million polys per second on a 2.8Ghz Pentium 4. That's comparable to what Game Cube games get, iirc) Textures slow things down a little, but not much (on my system. Other's mileage will vary) Reducing polygon count is the surest way to improve performance without seriously overhauling code. Lower polycount 3D models for LOD would be great. Why do the ground tiles cause almost as much of a speed hit as 3d objects? I expected 2d objects to have more impact. (actual figures for 2d objects not recorded below) Investigative stream of conciousness follows. It contains hard figures relating to one problematic camera angle in White Stone. ____ I've been wondering if part of the performance hit some maps take is due to texture misses. I looked in the bbox code and saw that new items are 'qsort'ed by render type (state batching, good plan) and then texture (textured batching, good, good). The only problem is that the sort is done on the first texture id only resulting in render orderings like this(dumped from 3d_object.c just before drawing): ./3dobjects/structures/house10.e3d 95 156 146 98 94 ./3dobjects/structures/woodwall1.e3d 95 ./3dobjects/structures/house10.e3d 95 156 146 98 94 ./3dobjects/structures/house10.e3d 95 156 146 98 94 ./3dobjects/structures/house5.e3d 95 96 97 94 98 ./3dobjects/structures/house5.e3d 95 96 97 94 98 ./3dobjects/structures/house10.e3d 95 156 146 98 94 ./3dobjects/structures/house12.e3d 95 156 146 ./3dobjects/structures/woodwall1.e3d 95 ./3dobjects/structures/woodwall1.e3d 95 ./3dobjects/structures/woodwall1.e3d 95 ./3dobjects/structures/woodwall1.e3d 95 ./3dobjects/structures/house10.e3d 95 156 146 98 94 ./3dobjects/structures/house12.e3d 95 156 146 ./3dobjects/structures/house10.e3d 95 156 146 98 94 ./3dobjects/structures/woodwall1.e3d 95 ./3dobjects/structures/house11.e3d 95 156 146 98 94 ./3dobjects/structures/house12.e3d 95 156 146 ./3dobjects/structures/house11.e3d 95 156 146 98 94 ./3dobjects/structures/house5.e3d 95 96 97 94 98 ./3dobjects/structures/house9.e3d 98 96 94 108 ./3dobjects/structures/house9.e3d 98 96 94 108 ./3dobjects/structures/house14.e3d 98 156 146 94 ./3dobjects/structures/house14.e3d 98 156 146 94 ./3dobjects/structures/house9.e3d 98 96 94 108 ./3dobjects/structures/house9.e3d 98 96 94 108 ./3dobjects/structures/house9.e3d 98 96 94 108 ./3dobjects/structures/house14.e3d 98 156 146 94 ./3dobjects/structures/house9.e3d 98 96 94 108 ./3dobjects/structures/house14.e3d 98 156 146 94 The integers at the end of the filenames are the textures. Notice the flipping. I wonder if we can do better. I'm going to give it a try. (It'll take me a bit to get up the nerve, so stop me if this seems to be madness) First I'll try not sorting by texture. I've got a pile of vid card memory and PCIe so that should prove interesting. If theres a measurable performance hit I'll try tweaking the sort a bit. Wheee! No sort: works. Dumps are out of order. What is the speed impact? Disable dump. On fixed view: Sort crippled: 14fps Sort enabled: 14fps. Bleh. I've heard GL_ALPHA_TEST is killing frame rates. I can see alpha tested objects in my test view. Let's comment out the if(is_transparant){} branch. Difference is visible. I see filled in bushes and trees. No alpha test: 13fps. Hmmm. Why's that I wonder? Moved the camera a bit and then set it back to same view. 14-15fps. Bleh. Disable reflections: 21fps Disable 3dobjects: 47fps... hmmm Disable tiles: 61fps Disable vsync:117fps. Reenable tiles:44fps Switch tiles for 3Dobjects:27fps Reenable 3Dobjects... 22fps. How about all 3d objects get the same texture? 3d textures all same: 24fps. disable 3dobjects: 69fps. reenable 3dobjects: 24fps. disable tiles: 27fps. Hmmm. Disable texture compression: no changes. My LOD code commented out: 7fps (Yes I still plan to try learner's LOD. That's what got me off on this tangent in the first place.) In my FPV code near and far clipping planes are decoupled. near plane is controlled by a #define called np set to .1, far plane is defined as below. Variable near_plane has not yet been renamed. Change back clipping plane: 60*near_plane near_plane = 1.0: 67fps near_plane = 1.2: 60fps near_plane = 1.4: 52fps near_plane = 1.6: 48fps near_plane = 1.7: 45fps <- I usually test here: 1.7*60 = 102 where 1unit ~ 1m assuming humans are 2m tall. With fog enabled pop in is not too bad at that distance. Fog code not modified. On my PC the game is heavily CPU bound. Proof: Set near plane dist to 21.70. Set resolution to 1280x1024 AA disabled: 8fps AA 2x: 8fps (visual inspection confirms AA is working) AA 4x: 7-8fps AA 8x: 7fps AA 8x, Anisotropic Filtering 16x: 7fps Set all to 0, set resolution to 640x480: 8fps. Too many vertices! What's the polycount? Check in 3dobjects using face_no. Slap it in and display it on screen. ~842000polys per frame. ~6.7million polys per sec. And that's just the set dressing. But that's in vertex buffers. And my card can, theoretically, do 600million polys per second. What's up? Not textures lookups. Are we querying state info or otherwise stalling the pipeline? Maybe. Argh!

Etheran, May I suggest that you go for the simplest possible effect: shield. The client already knows it's there and puts up a shield icon. Find where that's done, and add an alpha version of the player and scale it up drawn over the player. This effect is used for shields in many games I've played including Star Wars: KotOR. If that sounds hard just draw an alpha'ed sphere. To answer your specific query: My understanding is that they want the particle system overhauled, or scrapped and replaced. Any major efforts to add new .part files will be lost when that change is made. If you are ok with that and want to go ahead anyhow, take a peek inside the particles.c file. The function that loads .part files is enlightening. If you don't happen to know the gl blending #defines, don't worry. It looks like the .part files were created by printing out plaintext contents of the particle structure. Have a look at particle_sys_def *load_particle_def(const char *filename) and its complement int save_particle_def(particle_sys_def *def). Combine those with the particle struct: /*! * the definition part (header) of a particle system. */ typedef struct { char file_name[80]; /*!< filename of the particle system */ int part_sys_type; /*!< type of the particle system. This is one of the values defined in particle system kinds. */ GLenum sblend,dblend; /*!< blending factors for the src and dst of the particle system */ int total_particle_no; /*!< current number of particles in the system */ int ttl; /*!< ttl should be negative for systems that don't use it */ //EMA: ttl is time to live int part_texture; //EMA: guess! I'm pretty sure particle texture numbers should correspond with the number on the file textures/particle#.bmp float part_size; //EMA: A kludgy number that is has a hard coded scale on it in the client. Bigger number = bigger particle. int random_func; /*! * \name Starting values */ /*! \{ */ float minx,miny,minz; //EMA: Particles spawn inside the box float maxx,maxy,maxz; //EMA: defined in these two lines float constrain_rad_sq; /*!< <=0 means not used */ float vel_minx,vel_miny,vel_minz; //EMA: constraints on initial particle speed float vel_maxx,vel_maxy,vel_maxz; //EMA: in these lines float minr,ming,minb,mina; //EMA: constraints on initial particle color float maxr,maxg,maxb,maxa; //EMA: in these lines /*! \} */ /*! * \name Update values */ /*! \{ */ float acc_minx,acc_miny,acc_minz; //EMA: Bounds on how much particle speed is changed in updates float acc_maxx,acc_maxy,acc_maxz; //EMA: in these lines float mindr,mindg,mindb,minda; //EMA: Bounds on how much particle color is changed in updates float maxdr,maxdg,maxdb,maxda; //EMA: in these lines int use_light; //EMA: Guess. Probably has values 1 or 0. float lightx,lighty,lightz; //EMA: If particles have a light put the light here, if GL has a light is available float lightr,lightg,lightb; //EMA: Oh, and make it this color. /*! \} */ /*! * \name Sounds for this system */ /*! \{ */ int sound_nr; //EMA: I assume there's an array of sounds we can index sensibly somewhere. #ifndef NEW_SOUND int positional; int loop; #endif //NEW_SOUND /*! \} */ }particle_sys_def; And you have all I can tell you about what might be in the .part files. I've added my best guesses to undocumented struct members with //EMA: ... They probably don't help much. Take an existing particle system, hook some spinboxes into it in elconfig.c and play away! Then save the def using the appropriate fxn. I hope. If the motion is the part that bugs you you'll need to write a custom updater and add it to this switch statement in particles.c:update_particles() : switch (particles_list[i]->def->part_sys_type) { case TELEPORTER_PARTICLE_SYS: update_teleporter_sys(particles_list[i]); break; case TELEPORT_PARTICLE_SYS: update_teleport_sys(particles_list[i]); break; case BAG_PARTICLE_SYS: update_bag_part_sys(particles_list[i]); break; case BURST_PARTICLE_SYS: update_burst_sys(particles_list[i]); break; case FIRE_PARTICLE_SYS: update_fire_sys(particles_list[i]); break; case FOUNTAIN_PARTICLE_SYS: update_fountain_sys(particles_list[i]); break; } Here's a fun idea for a code based particle system enhancement: attach particle size to individual particles instead of the particle definition. Make it so that some particles expand over time and make expansion rate and acceleration entries in the particle definition struct. This works well for smoke effects when combined with a slow alpha fade and the right puffy looking texture.

This patch fixes the tubes of smoke on distant chimneys and makes fires look a tad fuller close up when point particles are enabled. I'm not sure that those are problems for everyone. Some drivers may have different default settings for point particles. My video card is a gForce 6800. Others with nVidia cards should get results similar to mine. However point sprite size and its granularity is dependant on what data type is used to represent point size which could be card specific. This is a relatively simple change so I'm not doing a patch. If you want to provide one feel free. This is all part of my camera patch that will come out once I'm happy with the features (bugs) and maybe the new client code is stable. The changes rely on the relatively stable GL_ARB_point_parameter extensions. I have tuned the parameters so that they closely resemble the textured quad based particles on my system, but your results may vary. Play with particleAtten[2] and the multiplier on system_id->def->part_size to get that to your liking. Add these definitions to the definitions at the end of gl_init.h: #ifndef POINT_DISTANCE_ATTENUATION_ARB #define POINT_DISTANCE_ATTENUATION_ARB 0x8129 #endif #ifndef POINT_SIZE_MIN_ARB #define POINT_SIZE_MIN_ARB 0x8126 #endif #ifndef POINT_SIZE_MAX_ARB #define POINT_SIZE_MAX_ARB 0x8127 #endif #ifndef POINT_FADE_THRESHOLD_SIZE_ARB #define POINT_FADE_THRESHOLD_SIZE_ARB 0x8128 #endif Add these extension function pointers to gl_init.h just before #ifdef USE_FRAMEBUFFER: //Point Sprite Size/Brightness Adjusters extern void (APIENTRY * ELglPointParameterfARB) (GLenum pname, GLfloat param); extern void (APIENTRY * ELglPointParameterfvARB) (GLenum pname, GLfloat *params); Add these extension function pointers to gl_init.c just before #ifdef USE_FRAMEBUFFER: void (APIENTRY * ELglPointParameterfARB) (GLenum pname, GLfloat param); void (APIENTRY * ELglPointParameterfvARB) (GLenum pname, GLfloat *params); Initialize those pointers in void init_gl_extensions() in gl_init.c just before #ifdef USE_FRAMEBUFFER: ELglPointParameterfARB=SDL_GL_GetProcAddress("glPointParameterfARB"); ELglPointParameterfvARB=SDL_GL_GetProcAddress("glPointParameterfvARB"); Add this near the end of void set_new_video_mode(int fs,int mode) in gl_init.c and void init_particles_list() in particles.c //Add perspective to point particles. On my system //these settings match size with textured quad particles, //but point particles have 4x as many particles. It's hard coded. //Tune particleAtten[2] if you like. if ((ELglPointParameterfARB!= NULL)&&(ELglPointParameterfvARB!= NULL)) { GLfloat particleAtten[] = {0,0,.01}; //This is a dumb place for this ELglPointParameterfvARB(POINT_DISTANCE_ATTENUATION_ARB, particleAtten); //This is a dumb place for this ELglPointParameterfARB(POINT_SIZE_MAX_ARB, 5000.0); //This is a dumb place for this ELglPointParameterfARB(POINT_SIZE_MIN_ARB, 0.01); //This is a dumb place for this } Change the call to glPointSize in void draw_point_particle_sys(particle_sys *system_id) in the file particles.c to this : //play with this if particle size is wrong. See also particleAtten[]. glPointSize(system_id->def->part_size*15.0f); Tell me what that last line was originally if you like, I deleted mine, but it might be smart to keep it and set a global have_point_param variable just in case a system that supports point particles doesn't support the GL_ARB_point_parameter extensions. Also please tell me if I left anything out. Enjoy!

I'm pretty sure reflections are just inverted geometry in the client. There is a fair amount of work to changing them, I think. I've been avoiding looking at them. At the moment I'm putting off using the stencil buffer to do sky reflections. Using the reflection code as is was just ugly. It broke many things in my skybox. Mind you I'm playing with the projection matrix and doing multipass stuff with the depth buffer disabled, so it's probably my fault

I don't know about the ocean, but there is a call for improved water in general. There are several places in the game where players can walk in shallow water. If you were to make vertex shader waves then you need to decide whether the players will interact with the waves when they walk through water. Also I'm pretty sure the reflection scheme will need to be revisited if you take on water. Maybe you could leave the flat reflections and just superimpose specularly lit waves? Or do you have a plan?

My skybox work has brought up an issue that should probably go here, and should also be included in any discussion of improving the map editor. Click here for previous discussion. I propose a simple cell system that will section off obviously mutually occluded areas of maps. Each area can be tagged with a sky. I have three predefined sky types: Underworld, Weather-based Cloudy Skies, and Plain textured (a simple sky or rocky ceiling texture could be attached to it). I plan to make a generic skybox for playing around with that will expose several different types of layers. I plan to use a modified version of the sound area definitions. An extension to the editor that can draw rectangles or polygons around parts of the map and set information about them would be very nice. If the work is to proceed we will need a sky and cell attribute specification, preferably one that leaves room for portals in the future. If someone else wants to take on the work feel free to claim it. The whole job involves: Designing a cell and sky specification language (Sound is a good starting point). This may involve getting me to guarantee a c interface for setting up the generic skybox(will probably require a few texture arrays, animation variables, and a bitmask for turning layers on and off) and simple sky(one texture) . Neither is implemented yet. I expect cells to be 2D polygons that split up the map. Not 3D volumes. [*]Writing/copying loaders for the language. [*]Changing the map loader optionally to sort map objects into seperate rendering lists based on their cell. [*]Adding a sky to each cell list when cell lists are created. [*]Loading textures specified in for the generic skybox and simple sky into a format compatible with my interface. Textures for the other skies will be provided. Currently only one is used: cloud1.bmp [*]Writing or adapting code to find what cell the player is in. I can provide a simple inside/outside test for convex polygons, and I'm pretty sure I've got one for convex/concave polygons too. [*]Writing code to specify and set up the sky to render based on the cell the player is in. I'm switching the sky with a function pointer right now: void (*render_sky)() Available targets right now are: //stubs void generic_sky(); void simple_sky(); //<-- This will change tonight //Overworld outdoor sky with moving clouds, //weather based cloud density, stars, day, night, //sunset and sunrise. Configures itself based on //what the client knows about weather and time. void variable_cloudy_sky(); //Fiery horizon with swirling red, orange and black clouds. void underworld_sky(); Just so you know. [*] Modifying the editor to provide a view for specifying cells and sound boxes and their attributes then saving them to disk. The work would take me a long time alone. If I've missed something obvious or non-obvious please comment. I don't know where to put this. It is not quite LOD, not all sky, and partially map editor. Should this go in a new thread?