Code center > Darwinbots3
2D or 3D?
Numsgil:
Capsules aren't too hard. If you're doing a SAT test, you just have to test the interval of the centers of the two circles. Which is as cheap as a rectangle, for instance. If you're doing a circle-circle radii test, then you have to do a full two circle vs. two circle test, which is a bit more expensive. But on the whole I think it's manageable. And with any luck something else will end up being the bottleneck anyway
As far as nursery environments, there's been a lot of work in that regard on the forums with the current version. Check out some of the zero bot sim threads, for example.
Numsgil:
Dug around in my notes. This is what I wrote to myself (since I keep ping pong-ing on the issue):
"Other simulators lack key requirements for Darwinbots:
1. Shapes changing size or even shape (both increasing in volume/area and changing shape (circle to capsule))
2. Drag to allow for swimming bots
3. Reversible time step (would be cool, but not required)
4. Stacking (very tall) (for use in something like a plant)"
#3 is entirely ignorable. It was my thinking that debugging bots would be much easier if you could step forwards and backwards in time in the simulation, but it probably has to be implemented using a cache of previous cycles anyway, since things like DNA are NOT reversible.
#2 involves simulating the forces needed for a swimming multibot. You need drag simulated in such a way as to produce torque. Most cheat and do something like velocity *= .99f, which won't work.
#1 is just something I don't think any engines support. They probably should, though.
So really there are 3 core issues that need to be addressed in any library we use, or any library we build.
Cyberduke:
--- Quote from: Numsgil ---Dug around in my notes. This is what I wrote to myself (since I keep ping pong-ing on the issue):
"Other simulators lack key requirements for Darwinbots:
1. Shapes changing size or even shape (both increasing in volume/area and changing shape (circle to capsule))
2. Drag to allow for swimming bots
3. Reversible time step (would be cool, but not required)
4. Stacking (very tall) (for use in something like a plant)"
#3 is entirely ignorable. It was my thinking that debugging bots would be much easier if you could step forwards and backwards in time in the simulation, but it probably has to be implemented using a cache of previous cycles anyway, since things like DNA are NOT reversible.
#2 involves simulating the forces needed for a swimming multibot. You need drag simulated in such a way as to produce torque. Most cheat and do something like velocity *= .99f, which won't work.
#1 is just something I don't think any engines support. They probably should, though.
So really there are 3 core issues that need to be addressed in any library we use, or any library we build.
--- End quote ---
1 and 2 are fair points, and I would be tempted to look into creating a physics interface first to allow for swapping between implementations (either custom ones or mainstream libraries) this then gives a bedrock upon which other features can then more confidently be independently developed and tested whilst the physics behind the interface are honed/swapped out completely.
You are talking me around to the idea of a custom ‘tailored’ physics engine though, which I would normally be hesitant of due to fact I have a feeling it could become a large and frustrating time sink, and especially in light of recent talks of vapourware.
But it would mean that we could play about with using a quad tree (I like quad trees) for the broad phase for both the collision detection and the sensor lookup spreading the cost of maintaining a quad tree across both features. (Yeah I am not sure how that plays with the interface idea yet either)
3 would also be good if we ever wanted to produce a multi-user single instance sim for correcting client side prediction faults, but I think we can forget that.
4 hmmmmm, I would be very tempted to just cheat on that one. I would be very impressed if you got that working satisfactorily.
Numsgil:
My view towards interfacing the modules is to hold off until there's something working. That way practical need drives the interfaces instead of the other way around (I want to avoid the "hmm, we might need this" trap.)
I've worked out stable stacking for squares and other polygons on paper. Well, so long as their angular velocity per cycle is not too high. Circle-circle stacking, though, is considerably harder, especially if you want one circle to roll down the other without slipping. But you're right, it's a huge time sink.
Maybe we just take an existing engine as a base and modify the crap out of it. That gives us something that works, for the most part, right away, and lets us add features as necessary.
bacillus:
My knowledge in this field is quite close to zero, but it seems that all is needed to hold two circles in place is to calculate the amount of force that is tangential to the static circle (a kind of x-y coord taking the radius as x and the tangent at the pint they meet as y), then calculating the friction between the two circles that the tangent force needs to overcome. And if it comes to that, bots could just stick themselves together in a certain form, sort of like squashing together snow to make a snowball.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version