In this section you can check out what I'm currently working in, practically in real time.
If some of this seems cryptic it's because the logs seen here come directly from my personal productivity tool prio, and are really just "notes to self".
Nevertheless, if you are interested in what I'm currently working on, this space will certainly be updated FAR more often than the news section.
00:55:00 sandblox CLOCK: 00:53 hours
00:51:00 sandblox LOG
More testing of current lighting and persistence, not managing to crash it anymore but there may be a devious bug in there somewhere...
Tried out storage cubes and of course the no longer work (the cell is correct but there is no object). This is because they used to be saved explicitly.
It is very tempting to look into implementing their persistence using events, but this is just the kind of interconnected causality stuff that I was thinking about earlier. If storage cubes are to be derived from events, then all inventory transactions need to be as well, including avatars. This in turn means that at least some of avatar state need also be derived from events.
Making the Model completely deterministic and running EVERYTHING from events should work in theory, but it might not be workable if I'm to go with lots of authority on clients (especially for avatar responsiveness). I'm thinking however that running everything based on events except for per-tick avatar stuff might be a very slick solution.
It basically boils down to tracing IEventTarget stuff and storing events in the appropriate places, and that is far from all cases. Looking at the interface now it seems like barrel explosions, crate breaks, everything related to items and inventory (from pickups to swapping and gun loading, dropping items, etc). This should take care of persistence.
In addition to that "dynamic stuff" need be both explicitly persisted as well as transmitted in real time across the network. This means avatars, mobs, and drops.
Actually this is looking fairly straightforward, and it will be interested to see if the theories hold up.
23:57:27 sandblox LOG
To recap about the main tradeoff with the persistence system:
I haven't done any real profiling, but I'm just assuming that a block read of a chunk from disk would be faster than recalculating it from scratch since this involves lots of noise and lighting and stuff. Of course the storage scheme and lookup stuff (the previous system had all chunks in a single file) was complicated, so without real profiling it's a toss up.
Avoiding explicit storage (except for the event stuff) is awesome; the code is so much simpler, and the data actually stored is so much smaller. The events are currently all stored in a single linked list, and processed for each new chunk that is created (which happens constantly), so a xyz map for the stuff that is local to chunks (like the current material set events are) sounds like a good idea.
On the other hand, events still need to be ordered correctly or the determinism will break. Will there be events that are more of a "global" nature and hence not fit into a "chunk local" scheme? I guess it sort of depends if there are lots of causality linkages between various kinds of events, something I'm too tired to think of right now. As always cross that bridge when you get there...
23:51:13 sandblox LOG
Initial implementation of event based persistence was surprisingly simple and a very minor "overlay" to what is now a purely procedural system.
To recap; I am no longer storing chunks / cells on disk at all. There are lots of ugly defines in the code now since I have been worried that I will have to revert to the explicit storage system, which is very complex. However with this new event / history based scheme it seems like I can get away without it.
What happens on chunk creation is simply that the procedural algorithm runs as usual, and then the history events that pertain to that chunk (there is currently and preferably only a single global event list, not stored in the chunks) are applied. Very simple but it seems to work fine.
This jacks directly into the network protocol (as in COI). Of course there are a lot of other things (from a purely deterministic point of view) that depend on changes in cells, but I'm thinking that this will be a hybrid protocol (again like COI) with some of the state being pushed real time, but with everything pertaining to the cells / chunks being event based and run thru various deterministic algorithms (for example lighting) on each node / client.
23:44:36 sandblox TASK: implement history based cell storage
17:45:00 sandblox CLOCK: 01:06 hours
19:07:26 sandblox LOG
The lighting finally works now, with very very minimal artifacts that are completely acceptable. There are tons of optimizations to try, but currently I'm running at 60Hz with acceptable amounts of frame drops. Everything is of course very dependent upon the complexity of the world function.
18:21:22 sandblox CLOCK: 0.1 days (03:21 hours)
17:41:04 sandblox TASK: implement new lighting
17:41:01 sandblox TASK: light update (not explicit version bump) for chunks that the player edits
11:20:59 sandblox CLOCK: 0.1 days (01:50 hours)
11:19:12 sandblox TASK: optimize light bleeding (adjacent chunk cache)
03:06:31 sandblox CLOCK: 0.1 days (02:39 hours)
02:59:10 sandblox TASK: implement light bleed in testlight
01:13:44 sandblox TASK: refine testlight to process Chunks via traversable
00:24:01 sandblox LOG
Very very very tentatively optimistic about progress on the lighting...
17:32:15 dreamler CLOCK: 0.3 days (08:21 hours)
15:41:10 dreamler TASK: IContext / command writing
15:40:46 dreamler TASK: persist user name
11:50:50 dreamler LOG
Background processing for receiving net data DOES NOT help, as the response from the server is initiated by the client first sending something.
16:56:33 dreamler CLOCK: 0.3 days (07:15 hours)
16:44:02 dreamler LOG
Basic graphical client today, using DXUT / Gui stuff. Right now the avatars work, including view areas. Lots of design discussions should follow.
16:43:19 dreamler TASK: basic graphical client
16:43:16 dreamler TASK: dxut rig
09:41:16 dreamler CLOCK: 00:41 hours
22:48:30 sandblox TASK: use core::BoxPacker to minimize light updates
15:29:54 sandblox CLOCK: 0.1 days (01:21 hours)
18:07:32 sandblox CLOCK: 0.1 days (02:28 hours)
11:19:02 codebase CLOCK: 0.1 days (01:52 hours)
00:38:37 sandblox CLOCK: 0.2 days (03:38 hours)
16:49:16 music TASK: video reference for ACE to orhan
16:00:00 dreamler CLOCK: 0.3 days (07:00 hours)
17:23:45 dreamler TASK: test 2 level0 clients at once
17:23:30 dreamler CLOCK: 0.2 days (04:04 hours)
16:28:12 dreamler TASK: validate level0 protocol
12:05:35 dreamler CLOCK: 0.1 days (02:11 hours)
11:05:53 dreamler TASK: move relevant code to dreamler svn
09:53:59 dreamler CLOCK: 00:53 hours
21:22:27 sandblox CLOCK: 0.1 days (01:38 hours)
17:01:59 sandblox CLOCK: 0.1 days (01:36 hours)
13:26:25 sandblox CLOCK: 0.1 days (02:42 hours)
13:26:17 sandblox TASK: default lighting function
13:26:05 sandblox TASK: remove nbr
12:07:35 sandblox TASK: remove water
00:25:38 sandblox CLOCK: 0.1 days (02:56 hours)
00:14:55 sandblox LOG
The current plan for lighting is to rip out the nbr stuff and go with something that works like the 2d testbed. The basic light-flow is the same, but the way that edges cases are handled is different (and potentially more expensive) as the algorithm runs vs an world-space interface that doesn't expose chunks.
The upsides are of course the fixed edge cases, a terminating algorithm, as well as the probably speedup of using a "top map" to track where the tops of each vertical stack of cells is. This has proven to GREATLY speed up the initial lighting pass (sky light) and hence limit the number of iterations required to spread out the light and finish the calculations.
I still need to figure out how to specify update regions in the 3d case. The fact that the world data changes when the avatar moves around may require some tests in 2d as well.
00:10:40 sandblox LOG
If the new ideas on how water flows are to be used, a faster visualization (than building blocky meshes) is needed, mainly due to the fact that water moves around more.
The current idea is some kind of billboard / sprite / splatting to basically fill / saturate as mass of pixels on the screen. These are as before only needed where water neighbors non-water (i.e. surfaces).
These can of course be culled, but I'm worried that figuring out exactly which cells are candidates can be costly. I currently don't see any real point in caching this stuff as the water will be moving about a lot.
00:06:37 sandblox TASK: test water billboards idea
16:32:15 sandblox CLOCK: 0.1 days (01:42 hours)
16:32:12 sandblox TASK: rgb light support in testbed
14:51:15 sandblox LOG
Have been working on a new lighting and water model in a 2d testbed for the past few days. Progress is good, and I plan on simulating most of the stuff I need for the 3d case here first before changing anything in the game.
11:49:19 sandblox CLOCK: 00:11 hours
11:28:11 sandblox CLOCK: 00:48 hours
21:44:14 sandblox CLOCK: 00:52 hours
19:00:13 sandblox CLOCK: 00:26 hours
13:11:06 codebase CLOCK: 0.1 days (01:58 hours)
13:01:29 codebase LOG
Really terrible bug in VS2010; it seems that if a project references another that is no longer in the solution, you get an error, cannot build anything, but it doesn't specify which project is having problems. This is bad when you have upwards of 170 projects in your solution...
04:37:58 codebase CLOCK: 0.2 days (04:16 hours)
14:32:58 sandblox CLOCK: 0.1 days (03:17 hours)
16:57:12 dreamler CLOCK: 0.1 days (01:59 hours)
13:21:40 dreamler CLOCK: 0.2 days (03:51 hours)
18:00:00 dreamler CLOCK: 0.2 days (05:00 hours)
12:30:00 dreamler CLOCK: 0.1 days (02:47 hours)
20:34:37 sandblox CLOCK: 0.1 days (03:24 hours)
15:02:02 sandblox CLOCK: 0.1 days (01:24 hours)
22:34:32 sandblox CLOCK: 0.1 days (01:31 hours)
18:11:44 codebase CLOCK: 0.1 days (02:05 hours)
14:35:21 codebase CLOCK: 0.1 days (02:56 hours)
02:46:28 codebase CLOCK: 0.2 days (03:38 hours)
01:45:09 codebase TASK: what happens if delaunay is fed with PLSG segments instead of implicit hull from point cloud?
01:45:08 codebase TASK: move tesselation stats from PLSG to own Stats class
01:44:52 codebase TASK: better description of dxut::HardMesh
00:42:27 codebase TASK: dxut::ResourceDescriptor
21:59:23 codebase CLOCK: 0.1 days (02:09 hours)
19:09:56 codebase CLOCK: 0.1 days (01:30 hours)
16:45:24 codebase CLOCK: 00:10 hours
15:08:42 codebase CLOCK: 00:14 hours
14:51:11 codebase CLOCK: 00:36 hours
14:43:15 codebase CLOCK: 00:11 hours
14:29:46 codebase CLOCK: 00:43 hours
12:54:34 codebase CLOCK: 0.1 days (02:15 hours)
01:30:00 codebase CLOCK: 0.2 days (04:44 hours)
00:55:22 codebase LOG
Very explicit GPU resource tracking in the works, functional in ACE. Will evaluate with remaining projects before committing.
20:13:19 codebase CLOCK: 0.2 days (03:51 hours)
18:04:27 ace TASK: fix limited demo replays (shouldn't be three minutes)
06:01:04 sandblox TASK: default inventory from chunk function
05:07:40 sandblox CLOCK: 00:40 hours