Progress has been very slow, but not stopped. I have been working some more on models. I have been fixing proportions on the base model for units and will be working on a complete but featureless base. That will get worked into the engine as I have no rigging support yet.

My todo list is split into 3 parts right now:

• Get bones in the model
• Textures!
• Load the model into the game and render
• Get the player system working and have character movement

Second list

• Get weapon system ready for adding props and projectiles
• Get libvoronoi working faster (hi-poly models cause slowdowns)
• Add in explosives as projectiles and get a particle system for fx
• Use libvoronoi for destructible objects

Lastly:

• Get libvoronoi working faster in any way, either brute-force CPU-wise or OpenCL
• Add in a point cloud generator system that will generate different clouds for different material types (chunks, sheets, splinters, cubes, etc.)
• Create a system to dynamically texture these newly created fragments and assign rigid body properties
• Create a seeded method to split fragments into physics and particle groups.
• Maybe destruction of models with internal details, such as walls rendering as a solid object, but destroyed into drywall, stud, insulation, and outer material fragments. Would require a lot of processing power to dynamically generate this, but would be great for non-realtime fx.

I am still getting better with Blender, so I am still progressing in one way or another.

Todo-list is being expanded to include rewriting all configuration file formats. I just got shader programs to use protocol buffers and will expand soon.

How do you see particle management working in your engine?

For simple particles, probably a lot of faking it. Having arrays of the position, velocity, and age are required. Angular velocity and rotation vectors could be added as well as scaling. Accelleration will be thrown in either on the compute side, a constant, or per-particle. All client-side for handling. As for the actual effects for them, not there yet.

At some point, I will have to look into integrating Qt Quick-based interfaces since Qt now allows them to render directly to FBOs (they render using OpenGL anyways).

No progress here, but not forgotten.

Quick looks pretty nifty. It's too bad it's QML/JS based though. The idea of a unified scripting layer is pretty appealing.

In terms of it being QML/JS (Customized V8 engine with OpenGL/ES or software rendering), it really isn't bad. I can run it on very low-end hardware and it is very smooth. I still need to get the hang of QML-based UIs, however.

I just mean it seems it would be preferable to have something more Lua-friendly as your UI solution, since that's your primary scripting engine.

That would require that I roll something out on my own or find something else that can render in OpenGL that uses Lua. And I probably wouldn't expose QML for scripting, can't restrict what goes on in it as easily as with Lua.

What about something fun like taking CEF/Awesomium and replacing the scripting layer with Lua hooks instead of JS? The design of Blink/WebKit is modular enough that it should be feasible.

I was contemplating doing that with Python before I switched to JVM. Now I'm rolling my own OpenGL rendering layer for https://github.com/radkovo/CSSBox (and planning to add Jython hooks for <script> tags).

Breaking from normal discussion:

Start of a new quarter, which means I have free time! But wait, my private server storing redintegrate materials (SVN, Trac, build hosting, no Jenkins iirc, that was a different machine) was re-imaged from Fedora 13 (ouch) to latest openSUSE. I was able to grab all web files (includes the repo and such) and discovered that Trac uses sqlite, so my lack of MySQL backups isn't an issue

I will be restoring the repo and possibly upgrading to mercurial (have been working with both mercurial and git, like mercurial more than git, and I don't have as many issues with svn vs. DVCS). I will have to update trac to use mercurial as well as get hosting for these back up, but I should be back on to working on this again, starting with shadows again (which I left off with reworking the effects system to allow effects shaders that will not require hacks/hard-coded functionality in the c++ rendering code (meaning maps can have their own special effects that aren't just simple filters)).

I too prefer Mercurial, so I support that decision. I'm glad you'll have some time to work on this, and I look forward to seeing your exploration of fun graphics engine issues. It sounds like you're saying that shadows are in fact a filter of some sort? I must admit that I'm quite vague on how shadows actually work in today's 3D engines.

Sorry, shadows aren't a simple filter. The current effects and shading code doesn't have a way to handle multiple rendering passes with specially linked textures and FBOs, rather it is stuck with a fixed structure. By making it more flexible, I can make much more complex shaders. (shading, focus blur, AO, etc.)

With the original site files offline, I have decided to move to Phabricator for Redintegrate as well as other small projects. I have all source code in Mercurial and am slowly migrating Trac tickets (all 69) manually with some changes along the way (with wiki pages to come later). I have about 11 tickets moved right now, seems like everything is smoothed out for the rest to get easily imported.

http://en.wikipedia.org/wiki/Shadow_volume is a pretty straightforward explanation.

A bit of python -> bash -> php scripting later and some copy/paste/regexp, I have migrated completely away from Trac

I should be able to get back to working on this soon, but that depends on what sort of other work I will have piled up.

All Redintegrate repos have been migrated to my Gitlab instance and converted Hg -> git. All issues have been dropped to allow for replanning when I work on it again.

Small patches were committed to update CMakeLists.txt to reflect changes in SDL2 libs (sdl2main removed on unix systems, other minor lib changes).