Polymesh and... boxes :) (demo inside)

Started by
12 comments, last by b34r 18 years, 9 months ago
Finally got around implementing polymesh/OBB in my coldet library. It's far from perfect especially on the culling side (KDtree/AABB does not work that well here). Compound objects (such as chairs) do not work yet, for some reason (errr, okay bug). The boat mesh is more of a crash test than anything meaningful but it works fairly well. while we are at it I'm interested in how people usually determine the contact set in a poly/OBB collision. I'm clipping the polygon to the OBB but it's nasty because it tends to allow the box to sink or stop in non-equilibrium state. There's not much else to say on the technical side. Maybe that it's SAT polygon/OBB not triangle/OBB so, for example, the floor of the large scene is a single polygon with 16 side... Ah, and yes, the tests are not swept so in the large scene boxes occasionally miss the ground when falling from high enough, of course the lower the frequency the worse it gets. Contacts are processed sequencially because I don't have the per contact depth in the poly/OBB test. That's something I'm thinking about lately, swept test are not especially complicated using the SAT but what to do when a completely missed collision is found? Obviously a penetration correction does not make much sense anymore... or does it? Well, anyway, here it is. Comment and speed report welcome.
Praise the alternative.
Advertisement
great work =)

Its realy fun to play with and it makes me want to finish my own demo right away.
Quote:Original post by glSmurf
great work =)

Its realy fun to play with and it makes me want to finish my own demo right away.


Thanks and go on :). I want to see it! As well as Oliie's one :)
Praise the alternative.
same comment as glsmurf :)
putting boxes in the SUV creates lots of contacts and it runs real slow

also, sometimes you have a box jitter on the uneven ground with like 6 contacts changing every iteration....

usually however it runs very well

[your wireframe draw mode is pretty slow though, at least on my ati radeon 9600se]
Quote:Original post by b34r
Quote:Original post by glSmurf
great work =)

Its realy fun to play with and it makes me want to finish my own demo right away.


Thanks and go on :). I want to see it! As well as Oliie's one :)


You will see it soon ...its just that it has a few bugs in the app framework (view looks skewed) and it won't be much to look at compared to your demo =)
It is not optimized at all, using only brute force collision detection without bounding volumes (aabb or similar).

I code using the simple principle:
1. just make it work
2. make it work better
3. goto step 2
4. sleep/rest/eat =p

currently I'm at step 1 =)
Quote:Original post by sit
putting boxes in the SUV creates lots of contacts and it runs real slow

also, sometimes you have a box jitter on the uneven ground with like 6 contacts changing every iteration....

usually however it runs very well

[your wireframe draw mode is pretty slow though, at least on my ati radeon 9600se]


Yes, well the mesh is a bit too dense for a collision mesh (not to mention dirty) but you are right, I need some sort of contact reduction... The wireframe on polymesh is really debug code so every polygon is CPU transformed before being send one primitive (line) at a time to D3D :) I guess I could use some specific code for rendering wireframe meshes.

Quote:
I code using the simple principle:
1. just make it work
2. make it work better
3. goto step 2
4. sleep/rest/eat =p

currently I'm at step 1 =)


Quite a good way to go :). It's hardly ever possible to make a complex system working perfectly at once. That's what I'm doing, adding things one after the other. But the more you add the longer the TODO list gets :(.
Praise the alternative.
Yes - very nice :) You definitely need swept tests though - the crates very easily get stuck (e.g. go inside the ship cabin and throw some around) - and the problem will get much worse if you use smaller (i.e. normal) size objects. Maybe that's the problem with your chairs?
Quote:Original post by b34r
Quite a good way to go :). It's hardly ever possible to make a complex system working perfectly at once. That's what I'm doing, adding things one after the other. But the more you add the longer the TODO list gets :(.


I started off with the idea of making a realy complex system... but shortly I noticed that the more complex the system became the harder it was to make even smaller changes without causing a huge amount of bugs.
Now I try to keep everything as simple and straight forwards as possible. I believe its alot easier to improve already written code than to write perfect code at once. Actually I love optimizing/improving code, so I guess I have saved the best for last =)
Quote:Original post by MrRowl
Yes - very nice :) You definitely need swept tests though - the crates very easily get stuck (e.g. go inside the ship cabin and throw some around) - and the problem will get much worse if you use smaller (i.e. normal) size objects. Maybe that's the problem with your chairs?


Thanks :)

Stuck in the cabin? I manage that on the safety nets around the deck (sorry my vocabulary is seriously lacking in the boat department :)). Polygons are double sided collision-wise so if you don't take care the camera could be sitting on a wall and the crate might get pushed and caught inside a wall.

Swept tests should help a lot indeed but the mesh is seriously bad anyway. Small objects work good, well at least as good as they did before :). The chair problem is that some compounds of the chair simply miss collision (none detected at all) I don't think the lack of swept test could cause that.

My problem with swept tests is that I don't really have a feeling on how I should proceed with correcting largely missed collisions... I don't think that penetration correction only will work as there could be a large number of invalid collisions. That would mean backstepping the physics solver and retesting overlaps all over the place... errg. :( I don't like this idea. Moving the object directly could be acceptable since it ought to be moving fairly fast so it's not like everything was quietly sitting and stacking around it :).

Quote:Original post by glSmurf
Actually I love optimizing/improving code, so I guess I have saved the best for last =)


Well, if you are like me you will never get there! There's always something new to start :)...
Praise the alternative.

This topic is closed to new replies.

Advertisement