Code center > Suggestions

Outsourcing physics

<< < (2/3) > >>

Carlo:
Hello everybody. Seems a great idea. My only doubt is that - as EricL suggested- common physics engines may be designed for handling with great accuracy the interactions of few, complex objects in a 3d space, while in DB the need is to make thousands of simple objects interact in a 2d space. Sound like the opposite, though I don't know if this is a problem. If it's not, I surely vote yes.

EricL:
Nice to see you Carlo.  I've heard so much...  

Anything that could offload even the low level vector arithmetic could make a huge difference.  Both VectorSub and VectorScalar are at the top of the list when I profile.  They each get called several million (yes, several million) times per cycle in a sim with 1000 bots.  Even a small improvement in the perf of these routines would have a large impact.

Higher level APIs that could do say, ray-capsule intersection would be huge and might be more ameanable to hardware acceleration as the routines are larger and more complex.  That is, hardware can have a larger impact when offloading larger, complex routines.  VectoSub is such a simple routine that probalby half the time is taken just by loading and poping the stack.  

Does VB6 have macros?  I'll check.

Edit:  No, no inline statements or marcos in VB6.  Too bad.

Numsgil:
I've seen alot of stress tests for physics engines that have hundreds of boxes or spheres running in real time.  They're definately built with that sort of massive numbers game in mind.

I won't know if they do it better than our own home grown engine until I compare run times.

Numsgil:
ODE is my current running favorite.  It's specifically built with our sort of physics in mind (Virtual creatures in virtual reality).  It's feature set is a very close match to exactly what our feature set needs to be.  Especially important is the stability and robustness of the simulation being edited in real time.

Better yet, it has both a OO and a pure C procedural interface.  Meaning it has the potential to be used in both the VB and C++ code without making compromises in either.

Lastly, it's open source, which is nice because we can edit it if the need arises for some reason, and I like to support open sourced projects when I can.

Really, it's the physics engine I'd make if I made a physics engine, I think.

EricL:
The only probelm with using Open Source is that it makes it impossible to do anything commercial with the code.   The open source agreement, which we would implicitly agree to if we used any Open Source code in DB, is viral.  It states that whatever you use it in itself becomes Open Source.  Perhaps not a problem with DB although Carlo and others have copyrights in the code that would essentially be invalidated.  But if you ever want to do anything commercial, don't ever use anything Open Source, not even tools.  Your code won't be yours.  You will lose any copyright or patent lawsuit you get into and you won't be aquireable since you have no exclusivivity to your asset.  Beleive me, I know.

DB is open source in that the source code is available and people can use it non-commercially, but it's not Open Source in that there is no viral Open Source license agreement.  We could still do something commercial with it if we wanted.  That would change the moment we used any Open Source in the DB.

Navigation

[0] Message Index

[#] Next page

[*] Previous page