Erik McClure

I really, really have to avoid thinking about HDR, because once I start working on one thing, I become completely and utterly obsessed with it. I'm talking an obsession more extreme then my love of bunnies. I'm talking an obsession that would have kept me up all night if I had let it. I've tried approximately 240 different equations in my head and none of them work. The approaches don't work. Nothing seems to work other then a few key things:

1. Bloom is subtle
2. Bloom is only visible under high contrast environments

Problem: How the fuck does one determine what exactly high contrast is?

3. IRL bloom behavior is a certain threshold below the brightness in question, and then anything getting too close to the original HDR brightness is completely eliminated.
4. It almost seems like you could just subtract the original source from the bloom, then somehow add this back into the calculation and do the HDR threshold calculation. This doesn't make sense mathematically though.

5. The IRL bloom tends to extend extremely far, but at the very edges its incredibly faint and just barely noticeable. This is stupidly hard to implement in a graphics pipeline because when you get things that faint they tend to just drop out completely instead of being subtle. if you try to use the inverse square law, squaring the values just removes the lower ones completely. I have been unable to find (for LDR anyway) an equation that preserves the subtle low values while throttling the high values. It might be that working with values of 0 to 1 is flawed and I though instead add 1 so that the lowest possible value is 1, thereby enabling division that makes sense. I implemented a version of this that did a really nice job of throttling the HDR values, but it still didn't seem to work very well for bloom.

6. I'm fairly confidant the key here lies in operating under HDR conditions by throwing out the assumptions normal bloom shaders use that are often used just to compensate for woefully inadequate spectrum analysis.

7. One thing that's really annoying is that I'm not entirely sure what I'm looking for each time I attempt to implement this. Furthermore most HDR pictures are corrupted by natural bloom which fucks with my own bloom if I try to use them. For an ideal testing scenario a full HDR pipeline must be implemented with proper HDR spectrum analysis for any of this to be effective. Attempting to put proper bloom on a traditional HDR crush algorithm will look stupid because the image has already been irreparably destroyed by the flawed HDR processing.

8. Note that the hilariously bad HDR example in the directX SDK has a natural bloom technique that, when not being grossly overused, is actually reasonably accurate in that it is circular and has a linear falloff. Ideally the falloff would be more exponential but that's proven to be stupendously difficult, so a subtler version of this would work really nicely.

9. hidden

I need to shut down my train of thought here before it overrides everything else (it's finals week for crying out loud), but hopefully the next time I become obsessed with this, it will be next year, about this time, when I have the proper environment to work in. When that happens I need to do some research on photographic HDR analysis, since I'm pretty sure they've figured out equations for a lot of the spectrum analysis.

I must have accidentally imbued my to-do-list with rabbits or something, because it just gets bigger and bigger.

To-Do
- _bucketsort cRBT_list isn't working because the getnear function doesn't differentiate between a "before" and an "after."
○ Implement checking for this so it can fail appropariately
○ Figure out if it needs to be a before or an after for the actual getnear call in the alloc function
- Do stress tests on the memory allocator and make sure it doesn't fail under any circumstances
- Do a test on the string pool allocator being inside the DLL and try to figure out why the hell the allocator gets initialized like 6 times.
- Finalize the string pool for usage
- Finish the last bit of the string table

- Build kd-tree implementation.
○ Each layer swaps between x and y and has a value that specifies where to make the split.
○ A balance integer is required so the tree can keep itself roughly balanced, but this should be athreshold difference of about 5 or so to prevent a single object from constantly resizing the tree.
○ Each layer holds a list of renderables of that depth. A renderable's total radius must fit entirely inside the branch in question, or if it has no rotation, do a simple bounds check.
○ Most of the work is done when a renderable is inserted, because this is when the bounds checks get made
○ When a renderable moves, it just checks its nearby nodes for a needed crossover.
○ When a renderable changes dimension, it may need to be moved to a higher level.
§ Note that you may be able to combine the scale and movement checks into a single bounds check
- Remove the radial check from anything using the kd-tree, but cImageZ doesn't use the kd-tree so keep the radial check for that one.
- Because use of the kd-tree is optional, you need a way to standardize its use. Some kind of function somewhere saying "Add to render queue" or "add to kd-tree" or something.
- Swap the render buffer to use an additive memory allocator
○ You will need to create a separate render buffer to maintain a list of renderables that don't use the kd-tree.
○ To do this properly you'll want to create a tree merge function with a mass allocation, which will allow for the transfer of memory in one batch per-frame, which should be crazy fast.
○ Do this first, then start adding in stuff from the kd-tree.
- Do stress testing on the kd-tree
○ Make line renders for the tree (that'll be a lot of fun to watch)
○ Ensure optimal performance on low and high density images.
§ Also check the resulting performance hit on a single image

Implement front-to-back transparency blending
- First, undo all that stuff you just did.
- The first thing that needs to be working is the multi-texture technique.
- Then, you need to make sure the blending is there, and that the backbuffer has an alpha (Should be done already)
- At the end of the render, reset the alpha channel to opaque
- Now you should be able to see the results. Ensure the blending functions properly under high tranparency complexities and adjust it as necessary
- Once the blending is working perfectly, enable the stencil buffer and do a write when the pixel is opaque (or in the case of this algorithm, completely transparent.
- Now extend this to multi-texture scenarios
- Then, ensure that it still works with the lighting technique.
○ Later on you can figure out if the alternate lighting method is still viable
- Done properly, the normalmaps should automatically use this technique as well. You may need to tweak that a bit though

- Go back to implementing the lighting system
○ Ensure blending functions correctly
○ Implement shadows (No penumbra! but still use the same circle calculation so your getting the correct umbra)
○ Calculate soft shadow points
○ Build soft shadow triangles
○ put in option to have object either be affected by light or not (Do it as a flag)
○ Put in coronas
○ put in option to have light cast shadows instead of be occluded. This is used for things like the sun, where color is ignored.
○ Optimize
○ Implement arc culling
○ ensure rect culling is working
○ Ensure backup textures allow it to work on the laptop

- Implement new text renderer
- Do C# interop

Fuck economics. I studied dutifully for that test and almost everyone in the class was still confused over badly written, misleading questions. In math, either you are right or you are wrong. In philosophy, either you make a convincing argument, or you don't. In economics, either you are wrong, or you are very, very wrong. I swear to god there is no "right" in economics, there are only varying degrees of wrongness and you must strive to be as not wrong as possible in order to pass the stupid class. Either that or you need to be telepathic.

I want my fucking programming classes, damn it.

Whenever I do intensive performance testing on delicate math operations, the results almost always surprise me. Today I have learned that if a program preforms a divide-by-zero on a floating point operation (which does not blow up the program), the resulting performance hit is almost equivalent to taking a square root.

Accessing the internet while I'm riding the bus home has to be one of the most awesome things I've done in a while. A pity the UW security is too ridiculous for me to tunnel through with hamachi on my router. But no worries, I'm getting the hell out of that shithole in less then 3 weeks, and then I won't have to worry about taking my clothes back and forth and back and forth... just my laptop.

Whispers are working except the Router plugin for Raknet is apparently not actually supported... but it turns out that it's rather unnecessary except for insane peer-to-peer connections anyway, so I replaced it with an RPC that's working quite nicely. Now I am programming a PHP serverlist that will double as a facilitator for a NAT punchthrough technique, which should remove the issue of we-have-to-use-hamachi-to-connect. Then its off to the most difficult networking task in the entire project - Physics interpolation. My task will be to both get a physics object to update itself over the network in an efficient manner, and I will require a networking interpolation hack in box2D in order to make it work in the first place, which of course must be optimized to ridiculousness. Luckily i think there's a way to put in a negative step into the interpolation function to get it to interpolate backwards, which would solve my security issue, although not the collision problem. I'd have to basically discard all collisions for the reversal. I'm really not sure how to get that to work, especially since I still need to figure out how and which collisions to disregard for the interpolation forward.

Once that works the only remaining physics problems to solve are 1. how to stagger the update packets based on proximity to an active player and 2. how to interpolate complex animated objects. The latter will be done whenever i get around to having complex animated objects, but the former will have to be the result of ongoing optimization and fine tuning.

In other news, I have invented a method of document reconstruction that would allow art programs to recover all information from a drawing-in-progress even in extreme circumstances, such as power outages. Unfortunately while this isn't that difficult to implement, it requires a subtle feature that is implemented from the ground-up, so i wasn't able to code a proof of concept in paint.net :C

You know somethings going wrong when the RakNet examples for chat networking can't connect to each other over a LAN :\

To-Do-List
----------
//- Figure out weird-ass networking problem
- Get Remote procedure calls to work
- Build cPlayer struct for player info passing
- Use RPC to implement chat
- Go back and build a packet filtering system
- Define 4 levels of physics information
- Finish writing box2D networking interpolation hack
- process packets and implement interpolation on a simple level
- Network physics
- throw bricks
- Implement destructables
- Implement a physics callback system
- Use this to implement impact damage based on relative physics formulas
- Sync destructables using RPC calls
- Put in health bars, network names, and other information
- Sync all this, including rudimentary score information as held by the server
- Build a functional basic shape editor
- Implement protocol buffers
- allow testbed activation on editor using in-game logic
- Build weapon system core
- Implement inventory
- Implement basic grappling gun
- Give GUI basic functionality (Weapon ammo tracking + health, etc.)
- Build options window and ensure most graphics options are functional
- Sync spawned weapon objects
- Build property-based weapon creation system
- Build weapons editor
- Design and implement weapon-centric distribution system
- Design weapon deadliness algorithm
- Implement weapon hashing and self-correcting danger network handling
- Implement anti-cheating weapon designs (weapon combination blacklist too)
- Differentiate between weapon restricted servers and open weapon servers
- Add LUA scripting core
- Integrate into weapons
- Extend weapons editor
- Implement complex object handling system
- Extend physics syncronization to handle complex objects
- Implement 2D nearest neighbor algorithm
- Test interpolation for complex object special cases
- Design complex object animation and syncronization schemes
- Extend weapons to allow for complex objects
- Extend editor to account for complex objects in generic cases
- Extend editor to handle basic animations for complex objects in generic cases
- Implement FX system
- Extend animation editor to handle animations for FX special cases
- Build specialized physics model for client-side FX.
- Integrate FX system into weapon subsystems and physics response system on a generic basis
- Make explosions
- Design hovering situation special-case for physics response system
- Apply this to giant hovering bases
- Ensure large physics object special-case in physics response system is stable
- Adapt 2D nearest neighbor algorithm for 2D lights
- Ensure lights act appropriately in indoor environments
- Implement powerups (including special-case physics response)
- Extend inventory to handle items on an abstract interactive basis
- Extend GUI into final mockup
- Implement unique kill registers for physics callbacks as dependent on weapon type/class/ID, as well as for specific event IDs
- Implement adaptive animation overloading system for complex avatars
- Ensure proper death animation as well as weapon swapping
- Abstract out the entire avatar into a class-system that must adapt for different body shapes.
- Implement class-specific statistics
- Create generic statistic trackers
- Build an interaction response system
- Combine interaction system with complex objects to create a generic vehicle class
- Convert base into a vehicle
- Build vehicles
- Implement vehicle spawn system and vehicle generic handling
- Build adaptive GUI system
- Create specialized vehicle GUI modifications
- Implement Map handling system
- Build map object spawn factory
- Network dynamic map changes
- Integrate LUA core into map scripting
- Compile list of basic map triggers
- Migrate objects over to map object handling
- Allow for multiple situational physics layers on base
- Get that stupid elevator to work
- Implement aircraft as a vehicle subset (this requires a physics response special case)
- Create Resource System
- Modify all spawned upgrades, powerups, vehicles and weapons to have generated resource costs.
- Implement drops
- Implement team resource counter as well as individual resource sharing systems
- Sync these over the network and apply anti-cheating subsystems
- Implement generic multiplayer statistic tracking over the client/server model
- Create the Lobby
- Add rooms
- Build server tracking system using the superserver
- Implement anti-cheating core on superserver and its authorization channels
- Ensure there are sufficient game creation options
- Test initial join and in-game join combinations
- Implement multiplayer statistic tracking over the entire superserver model and website (concept of a 'confirmed kill')
- Website integration
- Implement Clans
- Implement Medals
- Implement Ranks
- Vent support
- Further website integration
- Finalize ambient music tracks
- Final design overview
- Final polish
- Push to upload
- Design final commercial trailer