Code center > Darwinbots3
Helping
Numsgil:
In the short term just submit SVN patches. I'll look them over and check them in if they look good. After I get sick of doing that much work, I'll set you up with proper credentials to check in changes yourself :)
...
If you're feeling adventurous here's some meatier problems. They involve a lot of math and reading, but it sounds like you don't mind giving it a go:
...
I'm working on fluid physics right now. I wouldn't mind some help, but there's a lot of weird ideas and vocab you need to get familiar with for any of it to make sense. Here's some papers/links:
[*] Modelling of Steady & Unsteady Flow Around 2D Airfoils Using Panel Methods
[*] Fluid Simulation for Video Games
[/list]
Basically I'm working on an incompressible "inviscid" "discrete vortex element"/"panel method" fluid sim. Only I'm mostly interested in fluid/boundary interactions, so I'm strongly considering ignoring vortices entirely and only using a "potential flow". Which represents a weird sort of fluid that has properties of both inviscid and really really viscous fluids at the same time. But it's pretty fast to calculate.
...
For rigid body physics, right now, in Annulus, there's some code to do moving polygon vs moving polygon collision detection, and it's only partially finished. In order to handle rotations and translations, I've been decomposing the polygons in to vertices and edges, and using numerical root finding techniques to find roots. I think there's some edge cases (quite literally :) ) I haven't solved yet. It's not conceptually too difficult, though you need a certain foundation in numerical root finding and a basic understanding of equations of motion. And there's a lot of code to handle (it's very verbose for some reason. Something I was going to refactor at some point. )
...
Also in Annulus the straight skeleton code I mentioned earlier is technically correct for all the toy problems I've thrown at it (and that involved way more work than I'd care to admit), but I've noticed that for larger polygons it can get confused and break for numerical reasons. Even writing the unit tests for more complex cases would be helpful, as it takes a lot of work to transcribe the vertices for the polygons and find a straight skeleton solver somewhere online to give the "correct" answer. Fixing the code up would be fantastic :)
...
There's a lot of linear algebra code in Azimuth.DenseLinearAlgebra. Right now it's all direct methods (QR decompositions, Cholesky decompositions, etc.). But some iterative methods would be useful, too. Especially because I've noticed that decomposing even medium sized matrices (with about ~40 ros/cols) starts to introduce some numerical error. Being able to "polish" answers with an iteration or two of some iterative solver would be really nice. I don't know a whole lot about iterative solvers, though. But it shouldn't be too hard. If that sounds interesting you could work on that. I can probably dig up some references to get you started.
...
This very week I've been working on optimizing the x86 assembly that the very low level linear algebra code is getting compiled to by the C# JITter. However I'd like to be able to use AVX/SSE as well. But there's no way in C# to indicate that those instructions should be used by the JITter. So I need someone to explore various ways to force their use. One possibility is slimgen. Another possibility is having a C++/CLI version of the DenseVector code, but that adds a whole lot of complexity to the build process (since now it needs a C++ compiler, and separate DLLs for x86 and x64 builds). And I'd like to the program to autodetect which instruction set is supported and automatically load the appropriate version, which means someone needs to much around with the internals of the JITter. And I'd still like to test all the different versions against the unit tests, so there's that.
...
Those are all really meaty and hard to just jump in and start working on, but they're also IMO the most interesting problems. Feel free to poke around the code base in the mean time and get a feel for things at least.
Botsareus:
cool stuff. I have to say it was a brave move to use 4 point polygons instead of circles. I don't know even where to begin to figure out fluid dynamics OR collision detection on these. :) (Not that we had any proper fluid physics in DB2 anyway, even still)
--- Quote ---n the short term just submit SVN patches. I'll look them over and check them in if they look good. After I get sick of doing that much work, I'll set you up with proper credentials to check in changes yourself
--- End quote ---
So you are saying that the SVN patches I submit do not make changes to the vb6 version? Or, is there like a virtual copy of the stuff I am working on?
Numsgil:
You've been committing changes, which are different from patches. Patching produces files that have the diffs in them, and then someone else can use those to get your changes.
Botsareus:
oh cool
rwill128:
I'll keep poking around in the code to learn more, but I think that starting off with Azimuth.DenseLinearAlgebra might be a good idea. If you have any of the resources that you mentioned, please send them my way.
It's starting to look like I'll need to be familiar with Azimuth to a large degree as well to make sense of Annulus anyway, so that'll help with any physics or collision detection that I attempt to contribute to in the future. Thoughts?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version