Darwinbots Forum

Code center => Darwinbots3 => Topic started by: Numsgil on September 07, 2007, 02:04:14 AM

Title: About Darwinbots3
Post by: Numsgil on September 07, 2007, 02:04:14 AM
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: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 (https://svn2.hosted-projects.com/Numsgil/Darwinbots3/), 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.
Title: About Darwinbots3
Post by: Numsgil on October 04, 2007, 08:23:08 PM
This wiki page (http://www.darwinbots.com/WikiManual/index.php?title=Darwinbots_3) is where I'll dump everything needed to bring people up to speed.
Title: About Darwinbots3
Post by: Numsgil on October 04, 2007, 11:37:49 PM
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.
Title: About Darwinbots3
Post by: Numsgil on September 30, 2008, 10:27:27 PM
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.
Title: Re: About Darwinbots3
Post by: Moonfisher on March 29, 2014, 09:12:31 AM
Is there an approximate release date for DB3 yet?  :D
(Can't help out, sorry, no time at all lately)
Title: Re: About Darwinbots3
Post by: Numsgil on March 29, 2014, 03:37:00 PM
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.
Title: Re: About Darwinbots3
Post by: Numsgil on March 30, 2015, 07:06:29 PM
Split a discussion off to this thread (http://forum.darwinbots.com/index.php/topic,6775.0.html).
Title: Re: About Darwinbots3
Post by: Peter on April 04, 2015, 03:14:00 PM
Is the currect source out of sync. As in some changes haven't been checked in or am I doing something silly. :wacko:

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.
Title: Re: About Darwinbots3
Post by: Numsgil on April 04, 2015, 06:01:04 PM
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.
Title: Re: About Darwinbots3
Post by: Numsgil on April 04, 2015, 09:04:27 PM
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.
Title: Re: About Darwinbots3
Post by: Peter on April 06, 2015, 03:57:58 PM
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.
Title: Re: About Darwinbots3
Post by: Numsgil on April 06, 2015, 04:25:15 PM
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.
Title: Re: About Darwinbots3
Post by: Numsgil on April 06, 2015, 04:30:02 PM
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.
Title: Re: About Darwinbots3
Post by: Peter on April 06, 2015, 04:55:09 PM
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.
Title: Re: About Darwinbots3
Post by: Numsgil on April 06, 2015, 05:11:08 PM
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.
Title: Re: About Darwinbots3
Post by: Numsgil on April 06, 2015, 05:16:17 PM
Actually transferring only changes in general is something Blacklight could use.  For the native DirectX visualizer it gets tricky because after a certain point just grabbing all the scene data and redrawing it is preferable because you can do a memcpy from the sim data to the DirectX buffers instead of hopping around updating things, but having the option and doing the perf comparison probably isn't a bad idea.
Title: Re: About Darwinbots3
Post by: Peter on April 08, 2015, 04:18:02 PM
For the actual drawable objects all I need is the DrawPrimitive and AffineMatrix(from EnqueueDrawable), correct?
In affineMatrix I see 6 Scalars or 3 Vectors. How to draw a circle or rectangle from it? I tried to extract it from it's being used in the DX version, but that didn't make it more clear for me.

Basically a ellipse got the following tags in svg. How would it match with the objects going in?
cx x-pos
cy y-pos
rx x-size
ry y-size
size

A rectangle
width
height
x x-pos
y y-pos

A polygon
A list of points
Title: Re: About Darwinbots3
Post by: Numsgil on April 08, 2015, 05:09:13 PM
For the actual drawable objects all I need is the DrawPrimitive and AffineMatrix(from EnqueueDrawable), correct?

Looking through the code I think the easiest thing to do is subclass Blacklight.Core.WindowHandle.  There's a few abstracts to implement.  Among them is an overload of EnqueueDrawable that takes in the primitive and transform.  The transform it gives you includes all the baking from different levels of the hierarchy.  Blacklight.SharpDX9 isn't all that readable (interfacing with GPUs just seems to breed ugly code) but it should give you an idea about how the WindowHandle is set up there.  You'd also want to subclass Blacklight.Core.IModule.  Note that it gets passed in a raw win32 pointer to a window, which is how DirectX works.  That's mostly moot for what you're trying to do.  I'm not sure exactly the best way to approach this, but it's mostly an architectural question so we can probably ignore it right now.

If you're trying to send the draw commands to a browser over http, say, your WindowHandle might just bake the drawables in to XML and put it somewhere (memory or disk) for a http server to serve.  And the way it's set up right now is very much based on how DirectX/OpenGL group similar commands in to "draw calls".  Most of that is just overhead if you're working with SVG.  So feel free to bend the code to work in a way that makes sense for SVG and we can try and figure out a better way later.  But I'd still consider working through the WindowHandle interface if it's even a little reasonable, as it's doing all the work around keeping things consistent for you.

Quote
In affineMatrix I see 6 Scalars or 3 Vectors. How to draw a circle or rectangle from it? I tried to extract it from it's being used in the DX version, but that didn't make it more clear for me.

It's an Affine transformation matrix.  There's an implicit row at the bottom with [0 0 1].  Position vectors are assumed to have an implicit 1 at the end [x y 1] and direction vectors are assumed to have an implicit 0 at the end (x y 0).  The rules are a bit weird but it means you can combine two transformations (translations + orientations) using just matrix math.

SVG has this capability built in I believe.  Which is obviously very nice for us :)  See TransformAttribute (http://www.w3.org/TR/SVG/coords.html#TransformAttribute).

Quote
Basically a ellipse got the following tags in svg. How would it match with the objects going in?
cx x-pos
cy y-pos
rx x-size
ry y-size
size

If your browser works correctly I think you can just draw it as a circle and the skewing/stretching will happen as part of the affine transformation.  That said I had some difficulty getting that working when I played with it last (again, different browsers are better about this than others).

Otherwise you can extract out the ellipse from the transformed circle.  I have to do this for the shader code for SharpDX9.  Basically you can take a singular value decomposition of the 2x2 matrix (that is, drop the third column from the affine transform) to turn it in to rotation * scale * rotation.  Since circles are radially symmetrical you can drop the last rotation.  The scale gives you the x/y scale of the circle, which turns it in to an ellipse.  Then the rotation puts it in the right orientation.

See Main.fx (http://svn.darwinbots.com/Darwinbots3/Trunk/Modules/Blacklight/SharpDX9/SharpDX9/Shaders/Main.fx) and MatrixDecomposition.fx (http://svn.darwinbots.com/Darwinbots3/Trunk/Modules/Blacklight/SharpDX9/SharpDX9/Shaders/MatrixDecomposition.fx) and search for SVD.

...

For polygons, it's a little conceptually tricky.  Basically polygons in Blacklight are drawn with some uniform thickness border.  To make drawing this easier, polygons are decomposed into a collection of monotone polygons, each of which has exactly one of the original edges of the original polygon.  These are the BorderPolygons.  When you draw them, you want one half of them to be the interior color and the other half to be the exterior color, based on the distance of the pixel from the border.  Or just ignore it entirely (probably reasonable for now).  Either way they store a triangular decomposition, so you can draw them as triangles.

If you think it'd be better to spit out the raw polygon points, we'll need to rearchitect things in Blacklight.Core/Drawables/Polygon, as right now the Polygon builds the BorderPolygons which build the BorderTriangles, and all the intermediaries are discarded.
Title: Re: About Darwinbots3
Post by: Numsgil on April 08, 2015, 06:06:31 PM
Looking/thinking about it more maybe going through WindowHandle is overkill and you can just write something to take in a Scene and spit out the XML/SVG.  I'm pretty sure SVG can handle nested transforms, which is most of the reason WindowHandle can't just take the raw primitives in.  Is there an equivalent in SVG to Collages and Cels and the like?
Title: Re: About Darwinbots3
Post by: Peter on April 09, 2015, 03:12:36 AM
I think the g element gets close. https://developer.mozilla.org/en-US/docs/Web/SVG/Element/g
Title: Re: About Darwinbots3
Post by: Peter on April 09, 2015, 04:46:08 PM
Silly issue. The svg I generate is upside down mirrored when I compare it with the dx9 version. I'm likely switching some parameters around, but I don't know which ones.

With the w3c link (http://www.w3.org/TR/SVG/coords.html#TransformAttribute).
W3C says: matrix(<a> <b> <c> <d> <e> <f>)
I'm using : matrix(M00,M10,M01,M11,M02,M12)

edit: added dx9.png
Title: Re: About Darwinbots3
Post by: Numsgil on April 09, 2015, 04:50:41 PM
Do you know what "quadrant" SVG draws in?  That is, which corner of the screen is the origin in?  Or is it in the middle?  GPUs draw in the 4th quadrant, so the origin is the top left of the screen and increasing values of y go down (increasing values of x go to the right).  That's either how Blacklight works or I switched it to use the 1st quadrant so the origin is in the bottom left.  I don't remember which.
Title: Re: About Darwinbots3
Post by: Peter on April 09, 2015, 04:56:08 PM
I don't have a clue, google search seem to point to top left.

Numbering goes up down and to the right anyway. Top left are the lowest coordinates.
Title: Re: About Darwinbots3
Post by: Numsgil on April 09, 2015, 06:44:58 PM
My math might be screwy in Blacklight, I'm not sure.

I'm guessing you're not going through the camera/viewport classes at all?  You might take a look at how they do their transformations.  eg: viewport.cs (http://svn.darwinbots.com/Darwinbots3/Trunk/Modules/Blacklight/Core/Core/Cameras/Viewport.cs).  Basically a viewport is a mapping between the rectangle on the screen measured in pixels and some generic "clip space", which is normalized.  Camera handles the mapping between world and viewport.
Title: Re: About Darwinbots3
Post by: Peter on April 11, 2015, 01:24:00 PM
I did a scale(1,-1) on all objects and that seemed to put it back into perspective, didn't (yet) find where to extract it the proper transformation from. :x

Is there some kind of unique identifier for the objects? As to be able to 'follow' movements for objects, know that this rectangle drawn is the same as the rectangle in a previous frame, but at a different location/angle.
Title: Re: About Darwinbots3
Post by: Numsgil on April 11, 2015, 02:53:53 PM
There's nothing right now.  I thought about it a couple times but I could never decide if it was a good idea to add.  For DirectX you're not necessarily better off updating existing things over just pushing an entire new array, and usually you're more interested in updating a spatial section of the scene that the user can see than updating entities 2, 4, 7, and 9, say.

And you'd probably want to have the unique identifier you're using encode the hierarchy of scene->cel->collage->collage->collage->...->entity in some way.  At the simplest we could encode it in a string so each scene, cel, collage and entity had a unique name and the final entity's pedigree name would be like "scene1.background.tree47.branch12.leaf6.triangle39" or something like that.

Maybe the hierarchy only goes down to the first collage.  The collages are supposed to represent things that basically don't move relative to each other, so assuming anything downwards from the collage has the same relative transform it had the frame before is probably fair.
Title: Re: About Darwinbots3
Post by: Peter on April 12, 2015, 11:06:50 AM
Updating existing things seems necessary. I'm animating the slipstream testbed a few seconds and I'm up to a few MB. :wacko:
Normally it doesn't do any updates between cycles, does it?

Also, svg doesn't seem to want to take affine matrix into animations. Is there a method to calculate the angle/scaling I'm overlooking?
Title: Re: About Darwinbots3
Post by: Numsgil on April 12, 2015, 04:56:26 PM
Updating existing things seems necessary. I'm animating the slipstream testbed a few seconds and I'm up to a few MB. :wacko:
Normally it doesn't do any updates between cycles, does it?

It resends everything every time the viewport gets invalidated.  I don't remember if there's a timer that forces it to draw at 60 FPS but certainly everytime you drag the display or zoom in/out it redraws.

Quote
Also, svg doesn't seem to want to take affine matrix into animations. Is there a method to calculate the angle/scaling I'm overlooking?

Isn't there an <animatetransform> tag?

If you have to you can extract the scale, rotation, skew and translation from an affine transformation, you'll need to SVD decompose the first two columns like I was mentioning before.  The translation is just the last column, though, so that part's easy :)
Title: Re: About Darwinbots3
Post by: Peter on April 13, 2015, 04:42:09 AM
Updating existing things seems necessary. I'm animating the slipstream testbed a few seconds and I'm up to a few MB. :wacko:
Normally it doesn't do any updates between cycles, does it?

It resends everything every time the viewport gets invalidated.  I don't remember if there's a timer that forces it to draw at 60 FPS but certainly everytime you drag the display or zoom in/out it redraws.
It would send the same basic drawings then? Just to be certain. There isn't something that calculates what's between 2 frames and draws that. It just draws the situation of a frame. If 60FPS is on, it may draw exactly the same multiple times.

I'm asking because SVG does intermediates itself. I don't think intermediate calculating happens currently, I just want to make sure.

Also, svg doesn't seem to want to take affine matrix into animations. Is there a method to calculate the angle/scaling I'm overlooking?

Isn't there an <animatetransform> tag?

If you have to you can extract the scale, rotation, skew and translation from an affine transformation, you'll need to SVD decompose the first two columns like I was mentioning before.  The translation is just the last column, though, so that part's easy :)
<animatetransform> doesn't want a affine matrix, but scale, rotation, translation and skew. :(

I'll take a good look at the .fx files you linked. I already had the translation, that was the one where I was quite confident I was going to implement it correct.
Title: Re: About Darwinbots3
Post by: Numsgil on April 13, 2015, 12:21:20 PM
Updating existing things seems necessary. I'm animating the slipstream testbed a few seconds and I'm up to a few MB. :wacko:
Normally it doesn't do any updates between cycles, does it?

It resends everything every time the viewport gets invalidated.  I don't remember if there's a timer that forces it to draw at 60 FPS but certainly everytime you drag the display or zoom in/out it redraws.
It would send the same basic drawings then? Just to be certain. There isn't something that calculates what's between 2 frames and draws that. It just draws the situation of a frame. If 60FPS is on, it may draw exactly the same multiple times.

It sends the same thing, yeah.  If it's humming along at 60 FPS it just sends through the current transform of everything 60 times a second, changed or not.
Title: Re: About Darwinbots3
Post by: Numsgil on April 14, 2015, 04:27:34 PM
On the issue of the SVG getting quite large quite fast, I think it supports compression.  See SVG#Compression (http://en.wikipedia.org/wiki/Scalable_Vector_Graphics#Compression).  So the server could spit out a compressed stream of SVG files.  Even if we do a complete SVG file once a frame, that might be fine bandwidth-wise for the local host.
Title: Re: About Darwinbots3
Post by: Peter on April 14, 2015, 05:14:11 PM
A uncompressed stream on localhost would be as good as compression, it would only compress it send it to the browser which decompresses it.

With the league topic in mind, it would be nice to be capable to store matches on the server and play them like a video in the browser. Apart from storage space, it would be best if the whole SVG can be properly loaded as a file at once.

A lot of the current growing SVG is due to slow moving particles(slipstream TestBed). With 1000 particles it can climb up quite a bit. A way to decrease is to keep track of particles and for example state that it moved one to the left between the 9th and the 10th second instead of each frame a small update. I'll try playing with it when I can properly can reproduce the same animation as DX9 gets.

It's actually not that far from sending out a complete SVG every frame currently. :P
Title: Re: About Darwinbots3
Post by: Numsgil on April 14, 2015, 05:38:23 PM
Yeah I don't think storing a complete match would be that hard.  The positional data frame-to-frame has a lot of spatial coherence, so it's possible to compress it.  Either with some standard compression algorithm like gzip or with something that understands what the data is, like fitting splines to it.  It'd be nice if whatever the full match "movie" format is, a browser could load it up without any extra help.  But even if we have to write a small app to "uncompress" the stream and send that to a browser, I'm fine with that.

I guess there's two use cases to consider: a realtime viewer of what the DB3 simulation is currently doing, and an "offline" movie format that can playback a recorded stream.  For the realtime viewer you might not be able to do much better than sending a fresh SVG every frame.  At the very least I'd be interested in what sort of framerate you can get from that.  Graphics doesn't block the sim from running, so even if you can only manage 20 FPS the sim can run unhindered at 100s of cycles/sec, so that's probably good enough.  It would be a good excuse to look in to only drawing things the current viewport can see certainly.

For the offline movie format, it's a bit trickier, especially because objects can get created and destroyed over time.  But in principle I'd start with a big array and set the calcMode to discrete, and then later on we can apply some type of compression to remove elements that the different SVG calcModes could handle.  eg: if something is well modeled as a series of splines we can chuck all the intermediate values that aren't necessary to specify the splines and set the SVG calcMode to spline.
Title: Re: About Darwinbots3
Post by: Botsareus on April 14, 2015, 06:18:44 PM
As this project is maturing it begins to make more and more sence to me. Some of the rendering ideas sound incredible. Also the descriptions of the collision engine and the shapes/corpse mobile shapes sounds cool.

I am mostly concerned about backwards compatibility. To the point where I am scoping out my own port of DB2 based on the Revelations Book. :P (Can not give more detail then that)

Maybe one day we can do a hybrid and keep the best of both systems.
Title: Re: About Darwinbots3
Post by: Numsgil on April 14, 2015, 06:44:11 PM
It might be possible to hook in some of the DB3 modules to DB2.  It's a bit tricky because you'd have to go through COM, but it's possible in principle.  Sunweaver, for instance, could pretty much drop right in without much effort.  Blacklight would be more effort but still not too hard (the hardest part would be figuring out how to build up the data hierarchy for what to draw.  Either XML or manipulating instances of classes.  Probably XML (or something like it.  Lua code isn't a terrible data format, actually, and a bit more compact than XML)).

Not a task I ever really want to do myself, but something I'd support.

Going the other way, pulling in DB2 code to DB3, is a different story.  DB2 code is not really modular, and trying to extract out individual components from it would be self flagellation at best.  It could be made modular, but that's a massive refactor, and I don't think it could be done without introducing numerous new bugs.
Title: Re: About Darwinbots3
Post by: Botsareus on April 14, 2015, 06:55:17 PM
I always wanted to make DB2 moduler. Phd thesis anyone?
What I mean is we can port settings and DNA files from DB2.
For example we can expend the memory range to 1500 to allow for newer sysvars and then have a translator that works something like

Code: [Select]
Value Memory store 'done only if Memory is not a fixed value

Into:

Code: [Select]
Value Memory 1000 modi store

Done to keep compatability where modi is a new 'mod inclusively' command.
And I even throw in Spikes NOR request if I get that far.

Anyway, just stuff I have been thinking about due to the fact I have alot of down time right now.
Title: Re: About Darwinbots3
Post by: Botsareus on April 14, 2015, 07:44:45 PM
Anyway, just keep the DB2 wiki up there for a good 6 years and will see what happens. That's all for now... Have fun.
Title: Re: About Darwinbots3
Post by: Numsgil on April 14, 2015, 08:23:09 PM
What I mean is we can port settings and DNA files from DB2.

At a certain level it's apples and oranges.  The two programs just won't be much more than superficially similar.  But for DNA you could use def tags and codules to pretty much mimic anything you could do in DB2, with some caveats.  But even the sysvars won't really match up 1:1, so I don't think you could automatically "port" DB2 bots to DB3.  Like, they'd "work" in the sense that the DNA would execute and store stuff in the appropriate memory locations, but it wouldn't mean the same thing it did in DB2.

Aside from bots, the physics settings will be pretty much N/A, for instance.  Z gravity and friction values won't have any corresponding things in DB3.

Quote
Anyway, just keep the DB2 wiki up there for a good 6 years and will see what happens. That's all for now... Have fun.

Realistically I don't think I'm on the verge of getting DB3 up and running any time soon.  It could be 6 years before I even get something working as well DB2 (but I'm really bad at estimating how long something will take to do so who knows).  So DB2 isn't going anywhere :)
Title: Re: About Darwinbots3
Post by: Shadowgod2 on August 09, 2016, 11:25:02 PM
just wandering how's db3 going?
Title: Re: About Darwinbots3
Post by: Numsgil on August 10, 2016, 02:03:59 PM
just wandering how's db3 going?

I'm almost done with a simple "bot testbed".  Basically a simulation with just a single bot in it where you can program its DNA.  And the only thing the bot can do right now is change its shape.  But it's a good opportunity to flesh out and test all the different sub systems together in a single app, and figure out the high level multithreading strategy to keep the UI, renderer, and simulation threads separated so if one is slow or crashes it doesn't hurt the others.  Basically it's the first "vertical slice" of lots of the features all working together at the same time.

By almost done I mean the thing I have mostly works, but I'm still polishing some of the UI and making sure when it does crash people can send me useful crash reports.  I'm hoping to release it by the end of the month maybe, but I also haven't been actively working on it the last month or so, so we'll see.

Once that's released, I want to try and add in the fluid model, so we can see if bots can swim with it or not, and I'd like to play around with phagocytosis (eating other smaller bots by engulfing them) and mitosis (splitting in half to produce two daughter bots), since they both involve how the bots change their shape and they're probably the biggest question marks in my mind.  There's also an overhaul of the DNA I'd like to do at some point (collapse the boolean stack and the integer stack in to a single stack) to make it faster and some low level architectural stuff I'd like to finish that should allow the program to scale more easily to new features.
Title: Re: About Darwinbots3
Post by: Shadowgod2 on August 10, 2016, 02:09:20 PM
nice 8) your actually farther than i thought.
Title: Re: About Darwinbots3
Post by: Botsareus on August 11, 2016, 01:24:09 PM
Finally Darwinbots will have good error reports.  :P
Title: Re: About Darwinbots3
Post by: spike43884 on August 21, 2016, 05:04:40 AM
Oh nice work nums.
It'd be nice to store a few (hundred?) more memory locations...That, and a dedicated server :P Then it won't take 5 years for botsareus to evolve something.
Title: Re: About Darwinbots3
Post by: Botsareus on August 21, 2016, 09:13:56 AM
That is a good point Spike. I never actually figured out what the ideal ratio of used and unused memory/sysvars is. In DB2 we just piled up more sysvars and hope it still worked. But tbh even with the ratio slowly shrinking over time the robots seem to evolve quite well.
Title: Re: About Darwinbots3
Post by: spike43884 on August 23, 2016, 10:14:12 AM
That is a good point Spike. I never actually figured out what the ideal ratio of used and unused memory/sysvars is. In DB2 we just piled up more sysvars and hope it still worked. But tbh even with the ratio slowly shrinking over time the robots seem to evolve quite well.

I mean more for programmed bots, as more features = more sysvars needed, but its nice to have a lot of free slots (preferably in a big clump) so that you can perform complex mechanics inside your bot.

One idea as far as features go, perhaps as a replacement to in/out. I'm just guessing, here, but I suspect DB3 will have more advanced mechanics for getting food / poison etc. and it'll perhaps be more different "chemicals" (so-to-speak) which exist which are utilized, rather than a couple of *suit-all-your-needs magic arbitary compounds*. Then along with actually using them, for MB communication you could just dump some out when your in the presence of your species, to convey a message.
Title: Re: About Darwinbots3
Post by: Botsareus on August 24, 2016, 08:18:45 PM
I was considering not to reply here, but I will out of respect for Numsgil.
Lets try something theoretical here (because I know how much you love theoretical stuff)
Lets say instead of the way venom works now you need 10 different chemicals (that is, you need to store to 10 separate memory locations) to achieve the same result. Why would a robot magically evolve 10 unique stores all at the same time? It is already having trouble evolving 3...

So I do actually agree here that it will not take me 5 years to evolve something. :)