This project has moved and is read-only. For the latest updates, please go here.

A call for testers (FP 2.1)

May 27, 2009 at 7:16 PM
Edited Jun 1, 2009 at 5:53 PM

As you can see here, we are very close to a release.

We need to ensure that our library runs great on all platforms (Silverlight, XNA, Xbox360, others). We continuesly test the library by running our samples, but getting you to test Farseer Physics Engine 2.1 in your games, we ensure that we have not overlooked something important.
There are still some changes we need to do, before the real testing begins. This post is a callout for testers that I can keep contact with - and when we are sure that all features are implemented and working, we would like you to test it.

So if anyone here would like to test FP 2.1 - Just reply to this thread with your current platform (CPU, ram, graphics card / Xbox360 version etc. etc.) and I will report back when the real testing begins (along with a checklist on how to test FP 2.1).

Testing checklist
It's important to make sure that you test under the following conditions:

1. Clean Farseer Physics Engine 2.1 installation. - To make sure there are no stale files.
2. Test both in debug and release mode. - Change configuration of your compiler to be in release mode. This will double (and sometimes more) your performance.
3. Don't hold back! - Everything counts. If you find something small, make sure to report it back to us.
4. If you are sure it is a bug, create a bug report.

We are still putting the finishing touches on the library. When you report back, please write down the check-in ID together with the comment.

Known issues
1. Fixed! CollisionGridCellSize does nothing in the factories
2. AdvancedSamples does not work on Xbox360
3. Fixed! Multipolygon textures code is missing
4. Fixed! Auto-divide functionality is missing

May 27, 2009 at 8:19 PM

Hello, I'm working on a game for Xbox 360 (resident evil edition (elite)) and developing on a Intel core 2, 2GB ram, NVidia 8800GTX

I can test 2.1 during the weekend.

May 27, 2009 at 8:21 PM

Sounds great PanzerBattalion. Thanks.

May 27, 2009 at 11:06 PM

I just started a side scrolling platform game. I'm currently experimenting with the different abilities the player will have and testing them on simple levels. 

My main system is an HP laptop, windows vista with SP1 installed. 2GB ram, Intel Core 2 Duo @1.5Ghz. Geforce 8400M GS w/128MB VRAM

Vista Ratings: 4.6 Processor, 4.5 RAM, 3.5 aero, 4.5 3D, 4.8 Disk.


May 27, 2009 at 11:13 PM

We are 4 people so far. Including myself and Matt.

I have some old games that I would like to try FP 2.1 on (but no Xbox). Should write what I have:

Windows Vista X64 SP2, 6 GB FBDIMM, 2x Quad core Xeon 2.33, Geforce 8800 320mb.
Vista ratings: 5.9 on all.

Looking forward to the feedback from the community.

May 28, 2009 at 5:05 AM

me and my workmates will be testing farseer 2.1 and 2.2 quite a lot over the next month or 2 (expesially in the next week or 2) there is 3 xbox 360s we will be running it on (1 launch box, 1 elite, 1 of the new core systems)

and 5 pcs

Windows 7 Build 7100 X64 , 8 GB ddr2 800mhz, Quad core 2.67ghz, Geforce 8800 512mb.
Vista ratings: 5.9 on all.

Windows 7 Build 7057 X64 , 4 GB ddr2 800mhz, Dual core 2.5ghz, Geforce 9600M gt 512mb.
Vista ratings: 5.1 - 5.3 on all.

Windows 7 Build 7100 X32 , 4 GB ddr2 800mhz, Dual core 2.4ghz, Radeon HD 4570 512mb.
Vista ratings: 4.8 - 5.3 on all.

Windows Vista X32 SP2 , 2 GB ddr2, Dual core 1.8ghz, Geforce 7200M 128mb.
Vista ratings: 4.9 Processor, 4.5 RAM, 3.5 aero, 4.5 3D, 4.8 Disk

Windows  Vista X32 SP2 , 1 GB ddr1, Single core 1.6ghz, Intel Onboard 0mb (System Ram Only).
Vista ratings: 3.7 Processor, 3.6 RAM, 2.2 aero, 2.5 3D, 4.1 Disk

We will be running the stuff we do on these machines and i will let you guys know of any odditys that i find on any of them (so far i have seen that farseer scales very well with clock speed and fast ram)

also i update our version of farseer with stable builds from your svn ever week or so. so it should be a good set of machines to test it on

May 28, 2009 at 6:01 AM

Hey genbox mind if i squeeze in here?

I cant bring much new to the table though, although I would be able to test on the lower end for pc's

I  have an xbox 360 elite

and a crappy laptop

256 mb of ram

1.7 ghz processer

 and some version of ATI radeon for graphics

It be great to nab a look at the new version,

and tomorrow is my last final and then ive got summer vacation so I will be using it alot

May 28, 2009 at 6:40 AM

the more the merryier i would think

what kind of stuff are you working on tlegion?
some of the stuff im working on is here

May 28, 2009 at 10:28 AM
Edited May 28, 2009 at 10:51 AM

I'd help but im using 2.01 currently and dont plan to use a beta in my game however i will try and find some time to grab a source control copy of 2.1 for testing (write up some tests for the various parts of farseer) sometime tomorrow, friday, or the weekend.

I have:

Intel Core 2 Duo 1.8 GHz (Overclocked to 2.4 GHz)

2 GB DDR2 Ram

Windows 7 RC 64 Bit

XFX NVidia GeForce 8800 GTS Superclocked w/ 256 MB video memory

Windows Experience Index Ratings:

Processor: 5.9

Memory (RAM): 5.5

Graphics: 5.9

Gaming Graphics: 5.9

Primary hard disk: 5.4

On that note, i found a bug in the polygon subtraction code:

using the sample, place a circle and a square down with Q and A respectively
union them so that the middle right vertice on the edge of the cube almost (but not completely) lines up with the top vertice on the circle
add a circle with E

place it so that the "double vertice" (on the middle right of the cube part of the cube/circle shape) is contained within the circle you placed

presto you have a wierd geometry (although it collides properly :S)

a bit more testing shows that it is possibly broken drawing routines (as the operation seems to be working perfectly ), though its late here and i cant investigate further

May 28, 2009 at 3:36 PM

@danthekilla: Thanks. Pretty big setup you have. Would be great to have many setups to test with.

@tlegion: Can't wait to see the performance on your laptop :) FP2.1 should be just as fast as in release mode. My tests show very little variation and considering all the stuff we added, it's a good thing.

@RCIX: I've also played a lot with the demo and seen the same thing as you. Back when we had the PhysicsSimulatorView draw the polygon, I also saw some weird behavior. My guess is that the vertices end up in the wrong order and that the PolygonBrush (and PhysicsSimulatorView) draw it in the order they get it from the geom. Needs a little more testing - I'll make a bugreport right away.

May 28, 2009 at 5:57 PM
Edited May 28, 2009 at 6:03 PM


As crappy as my laptop is it is probaly the best piece of crap ever, it can run literaly any program with required specs FAR higher than that of my laptop

But the piece of shit cant run firefox for more than 2 minutes without blue screening, i cant close it or it blue screens, i have a room fan running under it all times as overheating is very prevelent

haha anyway cant wait and I will be sure to report back on as much as possible


I am having a crisis with my project right now,

I have alot of it done but there are two particular things that have completely stopped progress in its tracks

1. Assembling my characters body, figuring out how to orientate arms a body a head and a weapon whilst leaving the door open for custimization whilst keeping a slick natural look is IMPOSSIBLE

the head is easy, i make a spritesheet with a style and all the moods in columns, then i have random selection as to which style to choose then the column is controlled by a mood enumerator, simple

the body is a bit bulkier but its still very easy, make a style and a sheet with all the movement actions

the arms suck as my only choice is to make them seperate from the arms if I want to customize them while not having a million combinations by including the weapon as part of the arm

But doing the two seperatly would require seperate updating of position and rotation while keeping the aligned and keeping the moement and handling natural

Also rotating is pissing me off as it looks disgusting and unnatural, this must be why flash games having floating hands with a weapon

Sorry if that doesnt make sense, it dont matter its my problem anywho

2. And the other one is my map editing

It works fine, saves great, loads great, functions perfect, BUT since i am not doing a tile engine i cant reuse textures

i have to pre-create ever large 1024x1024 texture, by making a huge 4048x15000 texture than manually exporting each block

then i have to use dxt compression and since it has to be to the power of two i make them 1024 ahead of time but its an unholy amount of work and it takes up huge amounts of space and the environment ends up being static and alot of work

I do not in anyway desire to switch to a tile engine at this point in the project but its looking inevitable


BUT thats my problem as well, and now to actually answer your question hahahaha

I am working on a game without having any clue on the direction I wanna take it

I have my player who can run, jump, use a grappling hook, increase/decrease its length, pickup items, drop items, manage a crappy inventory, enter a lockpick mini game on an item box, which also holds items which can be used.

And i have enemies which have dynamic vision using a raycasting class(it calculates points along a line based on a vector 2 which calculates a hypotenuese of an angle) i made which dynamically calculates the length of a line by checking for geometries and i can check the tag of the geometry to give the enemies specific methods to execute when they see certain things, they can see walls and jump over them, but if they are to high they turn around, they have two destinations on the map and will pathfin to both, they will see the player and will go through finite states of suspicion and alert, then they will traack and follow the player for a certain amount of time before giving up.

Ive been under the impression i was making a stealth, shooter, with rpg elements and a fallout 3 style and i was well on my way, but I dont know anymore.



o yeah /bitching

although its weird isnt it '\n' to append a line in c++

and \ to end a line in c#

should it really be \bitching

meh i dunno nevermind : )


edit edit:

also its a sidescrolling game if it wasnt obvious. And i suck at animations and art and anything creative in c# which is probaly my problem


triple Edit:

That game looks badass dan

May 29, 2009 at 3:33 PM


I´ve got a Laptop with:

Intel Core 2 Duo T9400 @ 2.53 GHz

4 GB Ram

ATI Radeon 3650HD 512MB


May 29, 2009 at 6:06 PM

Count me in. I've been meaning to integrate the 2.1 progress stuff with my build, so being a tester should motivate me :)

Intel Core2 Quad Q6600 @ 2.56 GHz

4GB Ram

Vista Home Premium SP1 32 bit, score 5.6 - 5.9

Xbox 360 Pro


I have two artists with similar setups to mine but no Xboxes and one has Vista64. Also, here's a blog with some images from my game. Please feel free to add it to the Farseer games list:

May 29, 2009 at 10:42 PM


really great job roonda

May 30, 2009 at 12:36 AM

I've updated the first post to include a checklist and list of known issues. Let the testing begin and please report back with anything you find. We are very interested in anything from performance to inconsistencies.

You can find a list of new stuff included in 2.1 inside the Documentation folder. (The revision history document). To download the latests source code checkin (Version 2.1 Beta) go here: Source code

A big thanks to everyone who tests version 2.1. It's much appreciated.

May 30, 2009 at 5:50 AM

I actually decided to run 2.1 beta for my game ,hope to give it a good workout. :)

May 30, 2009 at 8:03 PM

Alright so I tested it in my game on both xbox and pc

It seemed to run much faster on xbox but then i ran it again and it was back to the same pace

Also one thing consisten on both pc and xbox was when anything colliding with a polygon it just became an unholy amount of slow just frozen in place for a while.

I can only assume its somehow related to SAT's lack of affection towards subdivision but i do not know.

The problem still remains that the more enemies I add the slower it gets,

like 5 on the xbox makes it painfully slow

I am not sure what it is

I turned off collision detection with polygons for just about everything and it still ran extremely slow.

I am going to try and isolate that and also try to change my polygon creation code and report back.

May 30, 2009 at 9:02 PM
Edited May 30, 2009 at 9:03 PM

@tlegion: Using one core on the Xbox is the same as a low end PC CPU; Low performance is expected, but you should be able to simulate more than 5 geometries at one time. Did you try it with Release mode? Optimizations are not enabled unless you run in release mode - Farseer Physics was optimized a lot by hand and thus it ran just as fast in debug, as in release mode. Since 2.0 we have relied a lot more on the JIT compiler to do the optimizations, and thus, you need to run in release mode.

If you have performance problems, you need to make sure that it is actually FP and now your own code (5 geometries is a ridiculously low number). Try running the samples and see how it works out.

May 30, 2009 at 9:04 PM

@tlegion: Thanks for testing. Subdivision is not nessary with SAT. Please try temporaryly disabling your subdivision and I bet there is a huge difference. Also I am preping the Auto-divide feature and let me say that seems to make SAT fly. But I still need to do some stress tests to make sure.

Just to be clear the type of subdivision I am referring to is at the end of the Farseer manual in the Known Issues section. SAT requires the opposite of the Distance Grid which is described in the manual.

May 30, 2009 at 9:43 PM

I am referring to Vertices.Subdivide

and yes i was in release mode for both,

the enemies contain a geom a body and the rest is basically just textures vector2s and alot of methods and logic

they do contain a raycasting class I made bu even when i disable it, it runs very slow.

I can run around 10 enemies alright on my POS laptop but only 4 on my xbox

I have tons of geometries mainly static rectangle geometry ad bodies and two polygon pieces.

Its really not much at all,

i will run the samples though and report back, It must be something in my players logic because its directly related to the amount of players i have, and more specifically whenever they are in the air.

I checked my jump states to see if i was updating something awkwardly or inneficiently but it turns out i turn off almost all updates in the air.

Its truly confusing and is pissing me off.

I have put them in release mode but I dont think it automaticaly was set to optimize code so I will do more testing with hopes of improved performance.

May 30, 2009 at 10:26 PM

Doing it in release mode will give more performance. If it indeed is the engine, I'm wondering where in the engine the problem might be. It would be great if you could include the PhysicsSimulatorView in your project (from the samples) and enable the performance panel (eveything else you can disable, not needed right now).

See if you can tell what part of the engine that takes the most time. Better yet, write down (or take screenshot) what the numbers are - including the total miliseconds it took to update.

May 30, 2009 at 11:07 PM

Good idea i never thought to use that,

I will add it later tonight and screenshot a bunch

May 31, 2009 at 2:54 AM
Edited May 31, 2009 at 3:01 AM

I just downloaded 53313 and ran the advanced samples (for some reason, the simple samples start up in a window that is half way off the top of the screen so I can't see anything and I can't move it so I can.

Times in this email are for the release version - run without debuging (Ctrl-F5)

Anyway, here's the average stats with the multi-threaded stacking demo:Multi-threaded (with boxes at rest, stacked):
Update TOtal: 10.06
Cleanup: 0.04
Broad Phase Collision: 2.63
Narrow Phase Collision: 4.95
Apply Forces: 0.03
Apply Impulses: 2.28
Update Positions: 0.13
Bodies: 212
Geoms: 221
Arbiters: 403

Hitting the stack so that it is in the process of collapsing only appears to improve the performance, though slightly.

Here is object pre-loading:

Object pre-loading/caching (this is with pre-loading turned off - there was literally no difference when pre-loading turned on):
Update total: 0.35
Broad Phase Collision: 0.17
Narrow Phase Collision: 0.00
APply Forces: 0.03
Apply Impulses: 0.00
Update POsitions: 0.13

Couple of things I noticed:
With the wind and grenades demo, if you push the stack of blocks to the right side of the screen, and then hold the dryer to the left of the stack so the blocks are pushed against the wall but can't go anywhere, they just "wiggle" in place, but the wiggling causes the blocks to noticeably penetrate their neighbors.

Secondly, and it probably has always been this way, but I just noticed that the debug view has considerable difficulty rendering stacked bodies. My FPS goes from almost constant 100fps on the multithreaded stacking demo to jumping between 5 and 25fps with debug view turned on. I expected some slowdown but this is more than I expected.

[Edit: The inactivity controller still needs work. If you pick up a block from the stack and swing it in circles so it just barely misses the stack, the stack will activate and wiggle very noticeably every time (even sometimes falling over). I'm sure some tweaking is needed, but I've seen inactivity controllers work a bit better (if still not perfectly) in other physics engines so I think there is definitely some room for improvement here. ]


May 31, 2009 at 3:37 AM

Hey genbox i just svn updated to get the new builds and i have noticed that demo 4 in advanced samples is running very weirdly

if you grab the ball with the mouse and drag it around into the other body it then starts jumping and teleporting very strangly

is this normal should i be seeing this?

May 31, 2009 at 3:41 AM
Edited May 31, 2009 at 3:43 AM

@JeroMiya: Thanks for reporting back.

The simple samples window is a change made by mistake. Matt is running a higher resolution on a widescreen (figured that out from the settings). I've changed it back to run on 1024x768. (use the latest check-in)

As for the mutithreaded pyramid: The bottleneck in the pyramid is the arbiters. The engine can easily take 200+ geometries, but not if they all are colliding at the same time. Destroying the pyramid should improve performance, because the geometries not colliding does not create arbiters. (400+ arbiters is a lot)
I just changed the pyramid basecount to be 16 instead of 20 because it might make low end machines lag badly.

The preloading demo is useless when using SAT :) You still gain some performance (ticks per ball went from 1900-2000 to 50-80 on my machine) because of the overhead of creating objects and the garbage collector. When using the distance grid, the object creation overhead gets more obvious. Thanks for pointing this out, never even run the preload demo in the new version.

As for the debugview performance - The same thing happens on my machine. The overhead of actually drawing the debugview affects the performance of the engine. You can mesure anything without it having an effect on the thing you mesure. The edgeview of the debugview is to blame - I've disabled it as it is not even needed. Thanks for pointing it out.

The inactivity controller needs work indeed. It requires a lot of tweaking, but will enhance performance in most platform games. It is terrible for stacking - a place where it actually should improve stacking stability. Anyway, we are looking into a lot better inactivity controller for future versions of FP.

May 31, 2009 at 3:48 AM

@danthekilla: My guess is that this is because the geometry to the right is concave and that does not work correctly with SAT. I'll make sure it is decomposed into convex geometries tomorrow. Right now I need some sleep (it's 04:47 in the morning here). Thanks for reporting that. Very much appreciated.

May 31, 2009 at 3:49 AM

no worrys go get some sleep :)

May 31, 2009 at 4:21 AM

Damn, I was sure I changed all the settings back to stock. About the debug view I wouldn't worry about it, its just for debugging anyway. Right now SAT is the primary collider and I spend way more time tuning performance then checking all the demos thats why I have you guys. Thanks for finding some of the bugs, me and genbox will get them sorted out as we continue to improve 2.1

May 31, 2009 at 7:06 AM

Actually the performance of the multi-threaded demo is fine without the debug view. I get a consistent 100FPS even with 400 arbiters. The update step is relatively high, but the CPU apparently can still do everything it needs to with time to spare in the 1/100th of a second it has to display the frame. Which sounds about right with a 10ms update time.

I was just commenting on the debug view performance. It might draw faster if it were changed to use draw primitives for edges, and point sprites for the collisions and vertices (or just non-textured points about 3 pixels in size) instead of using SpriteBatch. It wouldn't look as nice but it's just a debug view anyway.

May 31, 2009 at 1:05 PM
Edited May 31, 2009 at 2:41 PM

I agree. Debug view could definitly be rendered a lot faster using some different techniques. Farseer 3.0 will have a brand new debug renderer and I will do my best to make it faster.


As for the bug list -

  • Demo 4 Advanced - uses a concave polygon with SAT. Add auto-divide. EDIT - fixed but hole support is broken.
  • Demo 7 Advanced - jittery geoms (lol) looking in to it. EDIT - lowered the BiasFactor to 0.3 and Restitution to 0.0f (stacks hate restitution, especially with SAT)
  • Demo 9 Advanced - no checks it polygon is ready to be added to engine and needs auto-divide to use SAT. EDIT - fixed.

These are the bugs I am working on now. Please let me know if I missed something.

May 31, 2009 at 5:05 PM
Edited May 31, 2009 at 5:17 PM

Couple more observations (now with version 53392):


Water sample: 

* The default wave step should be adjusted a bit. Currently it's set so practically no waves will occur.

* The Wave Max Z and X keys are reversed. Z should increase and X decrease the property. It's reversed now.

* The Wave Step keys, Damping, Density, Linear Drag, and angular drag keys are also reversed. I think actually they should be kept the way they are, but switch the Wave Min keys (the only property that actually does what the text says they do), and just update the text so it says the right keys.

* If you exit from the main menu, it just goes to a blank screen instead of exiting the application.

* That first line segment of the water to the far right looks very odd and fake looking.

Weld joint sample:

* Middle mouse button creates tables but the code doesn't check the previous mouse down state to make sure the button was actually clicked that frame, so holding the mouse button too long can cause the simulation to explode when you put down 30 or so tables in the exact same place.

[Edit: added Ragdoll comment]

Ragdoll sample:

* What kind of springs/joints are you using for the ragdoll? I seem to be able to pull the arms off with enough force, and sometimes they get tangled when they snap back into place, causing the ragdoll to go into convulsions. 

Pretty much all samples:

* If you resize the window, then somehow I think it messes up world coordinates, because the mouse spring is offset. Other things are off too, like the water level in the water sample is rendered offset from the physics. [Edit: hmm.. looks like it's not all of the samples, will have to narrow it down a bit, but I know that at least the water sample suffers from this]


May 31, 2009 at 8:40 PM

@JeroMiya: Great work!

1, 2 ,3 : I will let Matt fix those as he is the one that created that part of the sample.

4: The water demo no longer has a menu. It was not needed. The demo starts right away with the presentation screen. When Exit is selected, it now quits the game correctly.

5: Also in Matt's department. I think that the water should fill more of the screen - also so that the wave generator is not visible.

6: Just fixed that one. Thanks.

7: I used the pinjoint to create a very simple ragdoll. Since pinjoints have a little "give" when a lot of force is applied to it, you can get in a situation where the bodyparts gets stuck. (The knees can entangle).
I've increased the mass on the bodyparts. This will not fix the problem completely, but make it more unlikely since more force is required to move it as violently as before.

8. I've noticed the water sample bug too. The demos will be edited to run fullscreen when released. This is because of several things: a) XNA has a bug that makes the mouse pointer return the wrong position ingame compared to out of game. Maximizing the window or run fullscreen will fix this. b) Some samples use custom drawing that does not follow the window when resized - like the water in the water demo. Running fullscreen will also prevent this.

When the XNA team fix the mouse bug, I will change the samples to work both in windowed mode (better compatibility) and in fullscreen mode.

Jun 1, 2009 at 3:57 PM

Hey genbox, I'd love to test out the new 2.1 with the Trash Bash really needs the SAT and new collision code to fix the problems that it has currently, so I'd love to give you some feedback as to how well things work.


AMD Phenom II 2.4Ghz


GeForce 260

Windows 7 RC1

Jun 2, 2009 at 9:50 AM

Sign me up for testing too. I'm currently using a source build from about two weeks ago, but I'll update and test the current source tree.


Jun 2, 2009 at 11:13 AM

@seiggy and DrDeth: Thanks. We have fixed a lot of bugs already, let me know if you find any.

Jun 2, 2009 at 1:40 PM

@seiggy and DrDeth: You can go ahead and download the latest changesets if you like. Just click on Sources and download the topmost one.

Jun 3, 2009 at 8:26 AM

I've been using 53437. I haven't really done a lot of testing, but I've noticed significant performance boost. Nice work. 

I did notice one new *feature*. I tried to call Geom.Collide(Vector2) after adding it to the sim but before the adds have been processed. This caused a crash because the Geom's reference to the narrow phase collider was null. Not a large issue because I can just process the adds for now.

I decided to bite the bullet and integrate my project with FPE 2.1. In doing so, I noticed an issue that I reported a while back ( I've fixed this and also added a new feature to the Path and ChainFactory classes which decouples geom width from the initial distance between the geoms. Should I upload a patch with these changes? If so I'll add another chain in the chain demo to show the difference.

@Matt, The Auto-Divide worked a treat. Were you ever planning on making it return less polygons that were as large as possible without being concave? I'm not sure how much benefit this would be to performance, but I imagine it would help somewhat.


Jun 3, 2009 at 4:11 PM

@roonda: I'm going to take a look at the Geom.Collide() bug. Thanks for reporting it.

I wrote to Matt about that bug, but he must have been to buzy to take a look at it. He has worked hard to get a lot of new features into the engine. I'll take a look at it and try out your fix.
If you have any improvements to the Path class, feel free to upload a patch in the patch section

Jun 3, 2009 at 4:29 PM

I've fixed the Geom.Collide(vector2) bug in checkin 53791.

As for the path bug, I'll wait until you have uploaded the patch.

Jun 4, 2009 at 10:57 AM

Currently keeping up with the latest updates. Will let you know if I find any bugs. Most of the bugs are on my side though :/

I went from 2.0 download release to latest version, and there was signifant performance increase! So far so good :)

Jun 4, 2009 at 3:10 PM

@genbox: I've uploaded that patch now. I made it against the latest checkin (53791). So far no new bugs noticed.


Jun 4, 2009 at 3:35 PM
Edited Jun 4, 2009 at 3:50 PM

@genbox: I have finished most of the car / bridge demo I just need to clean up it a bit and fix a bug I’m having

I was wondering if I could send you it as it is now for you to have a look over?

I’ve added a simple camera that just tracks the car (no smoothness or anything I wanted it to be simple).
I also had to change a few little things to get the picking to work with the camera so you can still interact with it.
The car is basically done really simple with 2 modes swapped by pressing B from using just revolute joints to something with some suspension.
The bridge is also basically done and in there fine too.

I just need to add a big ramp to the world or 2 to simulate hills and clean the code up a little.
I am however having a little problem with objects passing into each other completely from certain angles (mainly why I wanted you to take a look) and to see what you thought of it all.

Jun 4, 2009 at 3:48 PM

@roonda: Thanks. I will take a look at it later today.

@Danthekilla: Sounds great. You can upload it as a patch under the Source Code tab. (it's not obvious, but it's there ;) )
I'll take a look at the bug you are mentioning. It might be a number of things, but I'll make sure to let you know, if it fix it.

Jun 4, 2009 at 3:57 PM

@genbox: Well i uploaded the patch (i think) i didnt really know what i was ment to put in it though so i just put everything it needed to run when unzipped

Let me know if you can fix the bug im having
The items with the bugs are not on by default (i disabled them for testing)

They are in the Demo 11 Screen .cs file
Just uncomment line 57 and 58 in that file for them to go back in

Thanks for your help :)

Jun 4, 2009 at 8:49 PM

@Danthekilla: Hehe, the demo you made made me laugh. It's just fun to see the car hop along the road. I have a few notes:

1. I've not noticed the bug yet, but it might be because you are using the distance grid and need to subdivide the edges of the car (place more vertices).
2. The litter you are placing on the ground needs to be centered around (0,0). example: (0,10), (-10,-10), (10,-10) - Just quickly noticed that there were no negative points in the pointset.
3. The camera is very close (I have 1024x768 resolution :) ) and it seems like forever before the bridge comes up. And when it finally does, the road ends :D
Make a hill (I know you are planning this already), then the bridge and then some road before with a roadstop.

By the way, the cloning of geometries works, but the distance grid does not get cloned with it. I'll fix that in just a moment.

Jun 5, 2009 at 12:59 AM

@genbox: the problem im having is with the little ive placed on the ground
see here

they pass though each other they are cloned objects thou so is the lack of distance grid making this happen

Jun 5, 2009 at 1:05 AM

The problem is that with distancegrid you must have a low collision grid cell size and vertices a long the edges. Normally FPE takes care of this for you, but because you are creating your own polygon with only 3 points, they will collide into each other.

Try running Vertices.SubDivideEdges() on the triangles to put more vertices into the polygon. (If that is not enough) Then try lower the grid cell size until you get the correct collisions.