About Darwinbots3

[Numsgil]

Edit: see next post

Darwinbots3 is a new version of Darwinbots I'm working on that will start from scratch and build on the techniques I've been practicing for the last year or so.  Pretty much every aspect of the program will be redesigned to some extent or another.

On the tech side, the program will:

• Be written in C#.  I'm going to be heavily using C#'s superior error handling, reflection, IO, GUI, and networking abilities.  If nothing else, there should be more descriptive error messages to debug.
• Be module based.  The modules can operate independantly of one another, which allows them to be used independantly of the main program as well.  A DNA unit tester is in the works, for example.
• Be unit tested, which will (hopefully) mean the program will be more stable from Day1, and allow easier modifications without breaking older features.

The program will be hosted on an SVN server I rented for my own personal use several months back.
  The SVN can be anonymously viewed here, however note that it currently doesn't contain anything of interest (I haven't been updating to it regularly).

For any programmers interested in working on one aspect or another with me (I highly encourage this), I'll be trying to set up an introduction article in the next few days that explains code dependancies, downloading from the SVN, coding practices, etc.  There are, unfortunately, a great many steps that a novice programmer would need to accomplish to get the code compiling that might not be immediately obvious (I'm working hard to minimize this effort, however).

Lastly, I expect this project to take somewhere between one to two years to finish.  However, due to the nature of the methods I'm using (unit testing, modules), I'll routinely set up mini releases that demonstrate some aspect of the program, probably every month or so that I'm working on Darwinbots and not something else.

[Numsgil]

This wiki page is where I'll dump everything needed to bring people up to speed.

[Numsgil]

I've uploaded the DNA module's code into the repository and reorganized it slightly.  Also added various ignore flags, etc.  I'm still debating wether or not to upload the DLL dependancies (I don't have unlimited space...)

See the wiki article for instructions on getting the code and running it.

[Numsgil]

I've updated the wiki page.  It's now much easier to set up the projects.  Hopefully I'll streamline this process even more in the future.

[Moonfisher]

Is there an approximate release date for DB3 yet? 
(Can't help out, sorry, no time at all lately)

[Numsgil]

Not yet, though I'm on the cusp of putting the physics and graphics together so I might actually have something interesting to show soonish.  Real life is a bit crazy atm, so I haven't been able to do much coding.  Hope that'll change in the next few months.

My plan is currently to have a first playable at around August 2015.  So in about a year and a half.  I think I'm on track for that.

[Numsgil]

Split a discussion off to this thread.

[Peter]

Is the currect source out of sync. As in some changes haven't been checked in or am I doing something silly.

Darwinbots3GUI is calling DNA instead of Chromosome.(or should it be DNA)
Slipstream testbed tries to set nonexisting antialiased in Blacklight.
Lodestone solver call a nonexisting method from LinearLeastSquares.

No testbeds show anything for me too. But that may be because of computer settings.

[Numsgil]

I have some local changes from experiments I haven't checked in yet, and some of the "more derived" modules get out of date from time to time.  I'll try to clean up stuff tonight and get the repo in good working order, or at least let you know which modules are healthy and which are in a transitional state.

[Numsgil]

Okay, I've checked in the changes I had locally on disk that were in a good state.

Darwinbots3GUI should work now.  Though it's not exactly compelling.
Slipstream Testbed should work.
Lodestone is broken because it's pending changes I'm working on relating to the linear least squares solvers.  There's not a whole lot there right now anyway.

Baring some failed tests (which are sort of like TODOs at this point), Azimuth, Annulus, Sunweaver, and UnitTestSharp are mature modules that pretty much do what they're supposed to.  Blacklight is a little less mature architecturally, but the basic functionality is there  (that is, based on using it so far, the API is in a rough state, but it works).  Slipstream is somewhere between mature and experimental, as is Seshat.  Core, Darwinbots3, and Lodestone aren't much more than rough sketches at this point.  The few other modules I didn't mention don't have a lot to them either way.

In terms of interesting things to run, I'd say Blacklist.Testbed, Slipstream.Testbed, and Sunweaver.Standalone.  Darwinbots3GUI isn't much to look at but you can run it as well.

[Peter]

Thanks!

I'll play around with SVG. Want to see if I can create a streaming SVG animation, it's already theoretically possible says the guy writing the W3C SVG streaming spec.

I plan to implement it like a Blacklight module, and render in a browser through webforms, unless you have a better idea.

[Numsgil]

I thought about something similar a while back but I had enough trouble getting SVG to render properly in different browsers when I was using it to display graphically some failing unit tests relating to polygons that I didn't pursue it.  Obviously it would be quite neat

I would say either animated SVG or HTML5 or both maybe?  My knowledge of client side web technology is basically nill, but I'm sure it's both possible and a reasonable thing to do .  There's some things to think through around how much of the view the DB3 server keeps track of, how much info the server sends at once (several frames?  Just the most recent?) and RPC data formats (a snapshot of the current simulation?  Or just requested data?) and the like.  My current plan is to have the DB3 server (ie: just the simulation) and the DB3 client (ie: the rendering, UI, etc.) architecturally separate.  Makes things like running a server on a linux machine and keeping a steady display rate and responsiveness even if the sim chugs much easier.  But there's a lot of details outstanding I haven't thought through.

Anyway, yeah, play with it and keep an eye towards issues around API.  I feel like the current Blacklight API is a bit overwrought, but I haven't played with it enough from a user standpoint to know what to fix.

[Numsgil]

Oh, I'll say if you want to take a look at the SVG stuff I've played with already you're welcome to.  It's in Annulus: http://svn.darwinbots.com/Darwinbots3/Trunk/Modules/Annulus/Annulus.UnitTests/CSG/StraightSkeletonBuilderTests.cs  Search for SVG.  It uses some javascript to handle using the mouse to translate and zoom in/out.

[Peter]

I've seen it, you've linked it earlier. Makes it clear DB is quite suitable for using SVG.

With SVG I need to play around a bit to see what's possible. I like to send only what's changed to the client. i.e. if a shape keeps the same proportions but only turns, only send that angle.
First start with a frame, then a animated svg, streamed animated SVG(with all date each frame), then optimize stuff(frames/sending less info) and think what the server could do.

Quite new to SVG, but it shows promise. I'll assume when DB3 is released all browsers follow the SVG spec.

Didn't even think about html5 video, is more mature, may work more easily. I think more bandwidth is needed and more cpu time to  generate it.

[Numsgil]

I think the HTML5 canvas lets you specify elements using SVG.  But we're well outside my wheelhouse so if you don't think it's a good fit feel free to ignore me

Blacklight scenes are approximately set up hierarchically like an XML document, so the first step might be to codify that and actually have a XML "visualizer" for Blacklight, and then construct the SVG elements from that.  Then do the SVG "translation", which should be pretty one-to-one since SVG is already XML.  Or if SVG is a reasonable enough format for the XML even if the final visualizer isn't SVG just stick with it natively.

For only updating what's dirty, maybe you could push some sort of XML diff patch?  I'm not sure if that's a thing or not, but that's how I'd approach it.