[VS-C#] Newton Physics Engine

[jvaneijk]

Beste mensen,

Ik ben bezig met een game te maken, ik doe dit in C# en wil nu gebruik gaan maken van Newton als physics engine. als Game/3d engine gebruik ik trueVision3D.
Nu is een beetje het probleem want newton is geschreven in C++ en ik kan op een of andere manier niet de DLL's van newton importeren.

Heeft iemand enig idee hoe ik dit kan doen.
ik heb al gezocht op Google en hier over hoe ik foreign dll importeer in C# maar kan niets vinden.

melding die ik krijg tijdens adden van de ref is dat het geen geldig com ding is

[mulder]

DLL Import Succes -of eerder- sterkte!

[royteusink]

aii trueVision3D bah , waarom schrijf je de engine niet zelf? Kep er laatst ook zelf 1 geschreven, niet af maar oke http://www.codersforcoders.com/Engine < screenshots

Maar er zijn ook dll's beschikbaar van newton voor .net, soort van wrapper of zo iets. ff googlen

DLL import is idd ook een goede oplossing voor dit. Succes!

[ Voor 13% gewijzigd door royteusink op 24-04-2006 10:40 ]

[Verwijderd]

DLL-import van C++ naar C# is geen goede optie als je het mij vraagt. Aangezien je voor iedere geëxporteerde functie die calling convention moet uitschrijven, ben je 20 jaar verder voordat je de wrapper geschreven hebt voor de hele API. Dan zou ik, zoals royteusink al zegt, even zoeken naar een .net API (wat al dan niet een wrapper is).

Nog een andere optie is - mits het een opensource API is, niet gekeken, of als je de broncode hebt - er geen aparte DLL van te maken, maar de code op te nemen in hetzelfde project, gecompileerd met de #managed en #unmanaged pragma's. Dan kun je de functie normaal gesproken rechtsstreeks aanroepen vanuit je managed gedeelte, los van een aantal type-conversies die je zult moeten doen. Maar dat lijkt me minder werk dan een complete wrapper schrijven voor je API.

Dus ik zou of:

* De .net versie van de API, of een wrapper zoeken

of

* De broncode als unmanaged code in je project opnemen, zonder de DLL te gebruiken.

Bij die laatste kun je ook nog eens de engine zelf aanpassen waar nodig.

Succes!

[jvaneijk]

Bedankt voor de reacties. Toch heb ik nog even een vraagje, weet iemand nog een goede Physics engine die niet gebruik maakt van wrappers als je hem in C# wilt gegruiken maar dus een Physics Engine die in C# zelf geschreven is.

[Verwijderd]

jvaneijk schreef op maandag 24 april 2006 @ 11:22:
Bedankt voor de reacties. Toch heb ik nog even een vraagje, weet iemand nog een goede Physics engine die niet gebruik maakt van wrappers als je hem in C# wilt gegruiken maar dus een Physics Engine die in C# zelf geschreven is.

Ik weet niet hoe geavanceerd je engine moet zijn, of hoe veel werk je er in wilt steken, maar een basis engine voor physics-simulatie is niet zo complex als je misschien verwacht. Beknopt gesproken ben je al een redelijk eind met het volgende:

C++:

// Update the velocity and position
m_fVelocity         += (m_fGravity * m_fMass) * fTimeDelta;
m_fPosition         += m_fVelocity * fTimeDelta;

Als je deze berekening doet om de n seconden, simuleer je al zwaartekracht op een object. Doe je dan ook nog dit er bij:

C++:

// Should we bounce?
if (m_fPosition > m_fFloorY)
{
    m_fPosition = m_fFloorY;
    m_fVelocity = -(m_fVelocity * (1 / m_fDamping));
}

Dan stuitert je object ook nog eens. Oftewel, steek een beetje tijd in de research van physics-engines, is een hoop te leren, en erg toegankelijk!

[Verwijderd]

Een goede, gratis physics engine is ODE. Je moet hierbij wel gebruik maken van wrappers, maar die zijn al voor je geschreven door mijnheer Raine. Ik heb er een beetje mee aangerommeld en het ziet er allemaal mooi netjes uit.

Voor wat meer ideeen rond physics zou je eens kunnen kijken in de broncode voor deze 2 simpele games, de laatste twee items op de pagina (jaja, shameless plug ).

@royteusink, heb je je normal mapping toevallig van onze MDXInfo site vandaan? Gewoon interesse, zou mooi zijn als we er zowaar ook nog Nederlanders mee verder helpen

[ Voor 7% gewijzigd door Verwijderd op 24-04-2006 12:33 ]

[.oisyn]

royteusink schreef op maandag 24 april 2006 @ 10:40:
aii trueVision3D bah , waarom schrijf je de engine niet zelf? Kep er laatst ook zelf 1 geschreven, niet af maar oke http://www.codersforcoders.com/Engine < screenshots

Omdat het schrijven van een 3d engine gewoon heel erg veel werk kost? Let wel, een renderer is nog geen 3d engine. Iets op het scherm krijgen is zo gebeurd, het echte werk zit 'm in het resource management en culling.
Klik hier voor screenshots van mijn laatste engine

@ websjwans: ODE is wel aardig idd, hebben we ook gebruikt voor Coronel Indoor Kartracing. Het gaf echter wel performanceproblemen op het moment dat je in een kettingbotsing-situatie zit, maar goed dat was in 2003 dus ik weet niet wat de stand van zaken momenteel is.

[ Voor 22% gewijzigd door .oisyn op 24-04-2006 12:44 ]

[.oisyn]

Verwijderd schreef op maandag 24 april 2006 @ 11:31:
Dan stuitert je object ook nog eens. Oftewel, steek een beetje tijd in de research van physics-engines, is een hoop te leren, en erg toegankelijk!

Ik denk eerder dat de topicstarter vooral doelt op collision detection, wat idd eigenlijk geen onderdeel uitmaakt van een physics engine maar wel vaak onder die noemer gestopt wordt. Daarnaast gaan physics engines wel wat verder dan het simpelweg toepassen van een versnelling, het vereist toch wel wat kennis van integraal-rekenen en mathematische concepten als matrices en tensors. Toegankelijk is het allerminst, en elk fatsoenlijk (game)physics boek gaat er toch wel vanuit dat de lezer in staat is wiskundige notaties te ontcijferen (en dat is vaak waar de meeste hobbyisten afhaken)

[ Voor 14% gewijzigd door .oisyn op 24-04-2006 12:53 ]

[Verwijderd]

Klik hier voor screenshots van mijn laatste engine

Baas boven baas Als jullie een keer een eigenwijze tools programmer nodig hebben...

ODE is wel aardig idd, hebben we ook gebruikt voor Coronel Indoor Kartracing. Het gaf echter wel performanceproblemen op het moment dat je in een kettingbotsing-situatie zit, maar goed dat was in 2003 dus ik weet niet wat de stand van zaken momenteel is.

Bij een van de demo's op James Raine's site kun je een aantal boxes in de lucht spawnen, waarop collision tests uitgevoerd worden met het grondvlak en alle andere boxes. Op m'n P4D 3GHz draait het nog netjes op 60fps tot zo'n 800 boxes, misschien biedt dat enige vergelijking... van de andere kant, die 800 boxes worden volgens mij wel 1 voor 1 getekend, dus misschien speelt batch submission ook een rol bij deze 'limiet' en valt de performance van ODE positief mee.

Toegankelijk is het allerminst, en elk fatsoenlijk (game)physics boek gaat er toch wel vanuit dat de lezer in staat is wiskundige notaties te ontcijferen (en dat is vaak waar de meeste hobbyisten afhaken)

Om nog maar te zwijgen over de wiskundige achtergronden van shaders (Navier-Stokes, iemand? )

[ Voor 31% gewijzigd door Verwijderd op 24-04-2006 13:08 . Reden: Sympathie & plug ;) ]

[Verwijderd]

.oisyn schreef op maandag 24 april 2006 @ 12:51:
[...]

Ik denk eerder dat de topicstarter vooral doelt op collision detection, wat idd eigenlijk geen onderdeel uitmaakt van een physics engine maar wel vaak onder die noemer gestopt wordt. Daarnaast gaan physics engines wel wat verder dan het simpelweg toepassen van een versnelling, het vereist toch wel wat kennis van integraal-rekenen en mathematische concepten als matrices en tensors. Toegankelijk is het allerminst, en elk fatsoenlijk (game)physics boek gaat er toch wel vanuit dat de lezer in staat is wiskundige notaties te ontcijferen (en dat is vaak waar de meeste hobbyisten afhaken)

Snap ik volledig, vandaar de zin "Ik weet niet hoe geavanceerd je engine moet zijn, of hoe veel werk je er in wilt steken, maar een basis engine voor physics-simulatie is niet zo complex als je misschien verwacht." Met een simpele versnellingsformule en een beetje creatief programmeren is het bijvoorbeeld prima te doen om in een paar uur twee op elkaar stuiterende blokken te maken. Dat is natuurlijk in die vorm niet geschikt voor een uitgebreid en complex spel, maar nogmaals: als basis kun je met dergelijke dingen leuk spelen, en afhankelijk van je behoefte nog gebruiken ook.

[.oisyn]

En daarbij negeer je de eerste zin van mijn post voor het gemak even . Collision response kun je immers pas toepassen als er een collision gedetecteerd is, en daar ligt in eerste instantie de moeilijkheid.

[Verwijderd]

.oisyn schreef op maandag 24 april 2006 @ 14:40:
En daarbij negeer je de eerste zin van mijn post voor het gemak even . Collision response kun je immers pas toepassen als er een collision gedetecteerd is, en daar ligt in eerste instantie de moeilijkheid.

Negeren... ongeveer wel ja . Het heeft geen meerwaarde om hier een aangepast ray-tracing algoritme op te sommen zodat er twee ballen mooi tegen elkaar aan kunnen stuiteren. En nu dus een zin van mij die je expliciet moet lezen: "Met een simpele versnellingsformule en een beetje creatief programmeren is het bijvoorbeeld prima te doen om in een paar uur twee op elkaar stuiterende blokken te maken". Afhankelijk van wat je er mee wilt doen kun je blokken gebruiken voor je collision boxes i.p.v. spheres of iets dergelijks; collisions berekenen tussen boxes onderling is redelijk eenvoudig. En als je het op dit niveau houdt, blijf ik er denk ik toch bij dat een vereenvoudigde physics engine best toegankelijk is.

[ Voor 4% gewijzigd door Verwijderd op 24-04-2006 15:09 ]

[.oisyn]

Die zin had ik ook expliciet gelezen, ik had het blokkenvoorbeeld in eerste instantie ook in mijn post staan maar ik heb het herschreven. Mijn ervaring hier op GoT leert dat het detecteren van een botsing tussen twee lineair bewegende blokken of bollen toch een lastig probleem blijkt bij de meeste mensen. Een overlap-test is natuurlijk dead-simpel, hoe te handelen na een overlap (moet het object nou naar links of naar rechts stuiteren? En wat als meer dan 2 objecten elkaar raken?) is andere koek.

Maar goed, hoewel je vast weer gaat reageren met een bold stukje in een quote van jezelf laat ik het hierbij; de topicstarter vroeg immers om een physics engine, niet hoe hij 2 blokken op elkaar kan laten stuiteren.

[eamelink]

Collisions tussen spheres onderling zijn anders nog een heel stuk simpeler hoor

[.oisyn]

Collision detection tussen 2 aligned blokken met lineaire non-angular movement is anders ook gewoon een ray-box test, wat in de minst optimale vorm weer gewoon 6 ray-plane tests zijn. Nóg simpeler

[Verwijderd]

Ik denk dat het inderdaad weinig zin heeft om over het exacte gebruik van de engine door te doen: dat kan ts zelf wel bepalen. Ik blijf hoe dan ook van mening dat de toegankelijkheid tot een zeker niveau geen probleem hoeft te zijn. Ik ga er alleen geen argumenten meer voor aandragen omdat ik bang ben dat ik dan mezelf weer ga quoten. Maar ik denk dat niemand er slechter van wordt als je weet hoe hetgene dat je gebruikt grofweg werkt.

[jvaneijk]

Oke even voor de goede orde bedankt iig allemaal weer voor de vele en snelle reacties maar moet er nog wel even bij zeggen dat ik collision detection als regel das geen probleem. Ik ben bezig met een autosim achtig iets. die over bergen en door water gras enz. moet komen te reiden. dus voornamelijk dat soort dingen eventueel vering en zwaarte kracht bij springen en ga zo maar door.

[royteusink]

@royteusink, heb je je normal mapping toevallig van onze MDXInfo site vandaan? Gewoon interesse, zou mooi zijn als we er zowaar ook nog Nederlanders mee verder helpen

Kep verschillende soorten resources gebruikt eigenlijk, en mn eigen ASM kennis er in gepropt
Ik denk wel dat ik je verder zou kunnen helpen, ik heb mijn engine in C#.net 2003 geschreven. Btw mn bumpmapping werkt op videokaarten met minimaal ps 1.3 en vs 1.1 < aangezien mijn videokaart ook niet al te best is haha (Geforce 4 Ti 4200 128MB)

In de zomervakantie ga ik mijn engine totaal opnieuw schrijven, hij is nog niet echt handig en ik kan dynamisch nog geen objecten toevoegen.

Als iemand me op msn wilt hebben (royteusink [at] hotmail [dot] com)