[Python] 3D spill moduler?

[Gjest Slettet+6132]

Hei. Jeg har kodet i python i sirka 1 år nå. Litt over. Og har kodet veldig mye rart. Har prøvd meg med Pygame mange ganger å den modulen har jeg likt. Men jeg har lyst å prøve meg på 3D? Men vet ikke hva jeg skal velge?
Og hvordan jeg lærer å bruke dem. 3D er helt nytt for meg.

Jeg har sett på disse:

OpenGl
Pyglet

Men har ikke forstått noe av det.
Post hjerne doc's til modulene du råder meg til å bruke,

Finnest det andre 3D spill moduler? Og hvor kan jeg lære å bruke dem?

Endret 14. november 2015 av Slettet+6132
TS fjernet innlegg.

[Axxxy]

*Kjapt google søk viste meg denne siden: http://www.panda3d.org/

Man kan velge å programmere i enten Python eller C++.

 

*Soya3D
Er også en mulighet, men er leste at det kunne være litt lite dokumentasjon.

 

*pyOgre

 

*PyGLet

 

 

Har ingen anelse selv på 3D programmering i Python. Har vært interessert selv, og gjort en god del research i hvordan man kan lage alt mulig i Python, men ingen av mulighetene er spesielt store. Det er her C++ eller Java kommer inn. Men å få en feeling på 3D programmering i Python er nok en god start, da Python er ett lett språk i forhold til mye annet. Og da kan du i senere tider utforske andre språk.

 

 

Unity3D er fantastisk bra da det funker for både amatører og experter. Man importerer texturer, modeller, osv. Legger til ferdig-programmerte funksjoner som; fps kontrollere, fysikk(i.e. gravitasjon), for deretter å skrive ett kort script til spiller, motstander, objecter, osv.

 

Det finnes muligheter for å programmere med Python i Unity3D, men det er ikke like effektivt. Men Unity3D tilbyr å programmere i 'Boo' som skal være svært likt Python.

 

 

-Daniel

[Gjest Slettet+6132]

Spill 3D modulene til python inneholder så lite dokumentasjon eller ikke dokumentasjon i det hele tatt.

Så jeg har begynnt litt på C++ og liker syntaxen sån greit. Men det er en tungt å hoppe av Python på C++

der alt er helt forsjelligt.

 

Men etter jeg har lært C++ med programering i OpenGl eller annen modul der. Så tror jeg det blir lettere n¨r jeg komme til Python.

 

C++ er jo et mer brukt språk som har vel mer dokumentasjon da.

[GeirGrusom]

Sitat

Spill 3D modulene til python inneholder så lite dokumentasjon eller ikke dokumentasjon i det hele tatt.

Så jeg har begynnt litt på C++ og liker syntaxen sån greit. Men det er en tungt å hoppe av Python på C++

der alt er helt forsjelligt.

 

Men etter jeg har lært C++ med programering i OpenGl eller annen modul der. Så tror jeg det blir lettere n¨r jeg komme til Python.

 

C++ er jo et mer brukt språk som har vel mer dokumentasjon da.

C++ er nådeløst. Du burde heller fokusere på Python dersom du kan dette.

 

edit: Pyglet ser jo ålreit ut.

Endret 4. mai 2020 av Uderzo
anonymisert brukernavn

[Axxxy]

C++ er ganske tøft ja..

Java derimot, er kanskje litt bedre. Selvfølgelig vil det bli en utfordring å starte med det, men når du har kommet over de første kapitlene, så blir resten lettere forstått. Startet selv med Python, siden det skulle være en enkel start. Der lærte jeg konseptet med programmering, looper, moduler, funksjoner, osv. Dette er jo annerledes i mangen andre språk, men vil ikke si det er verre enn å gå fra Bokmål til Nynorsk; mye det samme.

 

Java kan dessuten kjøres på alle mulige platformer, samt letter enn C++ da du slipper å holde så stort fokus på ram/memory leaks.

 

Prøver ikke å få deg over på ett annet språk, prøver å vise deg mulighetene om du skulle finne ut at 3D i Python ville bli for 'kringlete'.

 

-Daniel

[GeirGrusom]

Jeg mener det bare er å kjøre på med Python. Jeg er ikke noen stor Python-fan egentlig (What? Finnes det ikke private eller protected? Varierer størrelsen på heltall med PLATTFORMEN??), men det å lære seg et språk og lære seg det godt er noe av det viktigste man gjør i programmering.

Endret 18. november 2013 av GeirGrusom

[Lycantrophe]

C++ er nådeløst.

Jeg synes dette alene er verdt å både sitere, utheve og memorere.

 

Well put!

 

Java derimot, er kanskje litt bedre.

Nei.

[Axxxy]

Så du mener Java er verre enn C++?

 

C++ er bedre enn Java i ytelse.

Jeg personlig synes java er enklere. Man slipper å tenke på minne i så stor grad som C++, samt hele oppsettet er mye greiere. Java er bedre å jobbe med, synes jeg.

[GeirGrusom]

Før var jeg veldig opptatt av ytelse. Å velge riktig språk, runtime etc. I dag har jeg en helt annen oppfatning. Ytelsesproblemer forbundet med spillutvikling i småprosjekter er et innbilt troll. Det finnes ikke. Dersom spillet går dårlig så er det beste du kan gjøre å finne en bedre algoritme, eller endre algoritmen for å passe applikasjonen bedre. Å kassere et språk du kan godt til fordel for et du ikke kan godt på grunn av en innbilt ytelsesfordel vil bare føre til at prosjektet havner i limbo. Ytelsesproblemer må måles, ikke innbilles.

 

Så derfor mener jeg at TS burde bare fortsette med Python. Til tross for dårlig dokumentasjon så kan jeg love TS at det er enklere å prøve/feile og spørre på forum med biblioteket enn det er å lære seg C++ (som alene er et enormt prosjekt), STL, OpenGL, glm, GLFW, DevIL, GLEW og OpenAL pluss en rekke andre biblioteker enn også trenger for spillutvikling som jeg ikke klarer å komme på i farta.

[Lycantrophe]

Så du mener Java er verre enn C++?

Utrolig nok, ja. Java er grusomt.

[siDDis]

Du om det! Eg ser på Java som dagens mest moderne utviklingsplattform.

 

Og eg er einige med GeirGrusom at det er bare å forsetja med Python. Nehe har mange OpenGL eksempler med Python.

 

Likt spørsmål og svar på Stack Overflow http://stackoverflow.com/questions/12121916/using-opengl-with-python

[Lycantrophe]

Du om det! Eg ser på Java som dagens mest moderne utviklingsplattform.

Det er JVMen isåfall. Det er ingenting moderne med Java.

 

Og eg er einige med GeirGrusom at det er bare å forsetja med Python. Nehe har mange OpenGL eksempler med Python.

Jeg har et love/hate-forhold til Python, men jeg er enig her. Fortsett med Python.

[GeirGrusom]

- Java kom sent med lambdasyntaks.

 

- Hvor sent da?

- Java kom så sent med lambdasyntaks at når de fikk det så hadde C++ allerede implementert det!

 

[Massiv latter fra salen]

[slacky]

Pyglet fungerer også på PyPy, noe som etter min erfaring er nesten nødvendig når det er snakk om 3D-spill (når du kommer et stykke). CPython sliter veldig med den store hastighets-begrensingen, men PyPy fiker dette i en stor grad.. Når vi ser på 3D-looper (for z.. for y.. for x..) så blir det fort et stort antall iteratsjoner, og spill inneholder endel matematikk (i disse loopene), noe som igjen CPython sliter VELDIG med.. Loops med mattestykker gjennomføres opp til ti-talls ganger rasker i PyPy.

Du finner forresten også noen små spill (3D) som er skrevet med PyGlet, kun for å lære bort hvordan det "fungerer", kommer på denne Minecraft-inspirerte demoen:
https://github.com/fogleman/Minecraft/

Endret 20. november 2013 av warpie

[siDDis]

PyPy er ikkje så raskt som alle skal ha det til....i nokre tilfeller vil det vere raskare og i andre tilfeller treigare.

Det som derimot er meir viktig er å få ting til å fungere, så å knote med PyPy er ikkje å anbefale.

http://stackoverflow.com/questions/18946662/why-shouldnt-i-use-pypy-over-cpython-if-pypy-is-6-3-times-faster

[Axxxy]

Men det spørs jo hvor langt *bruker* klarer å komme før han møter på ytelsesproblemer. Og før den tid, kan teknikkene og forståelsen for 3D være ganske høy. Da står flere muligheter åpne, og det vil være lettere å forstå/lære andre ting. I.e ett annet library i Python, som har ett annerledes "språk".

 

-Daniel

Endret 4. mai 2020 av Uderzo
anonymisert brukernavn

[zotbar1234]

(...) (What? Finnes det ikke private eller protected?

tja, __ gir deler av det "private" gir utenfra (og det tar ikke mange tester som gjør "#define private public" før man tenker seg om ikke dokumentasjon/navnkonvensjon ville ha gjort en bedre nytte).

 

Varierer størrelsen på heltall med PLATTFORMEN??),

Python er langt i fra alene om det.

[GeirGrusom]

tja, __ gir deler av det "private" gir utenfra (og det tar ikke mange tester som gjør "#define private public" før man tenker seg om ikke dokumentasjon/navnkonvensjon ville ha gjort en bedre nytte).

 

 

Python er langt i fra alene om det.

#define private public er code-smell. Tegn på fullstendig fraværende dependency injection.

 

Og om python er alene om int-størrelser er fullstendig likegyldig. Det er likevel tåpelig.

Endret 25. november 2013 av GeirGrusom

[zotbar1234]

#define private public er code-smell. Tegn på fullstendig fraværende dependency injection.

Det er likevel MYE enklere å satse på konvensjon, nettopp fordi testingen blir enklere.

 

Og om python er alene om int-størrelser er fullstendig likegyldig. Det er likevel tåpelig.

Det er tåpelig å skrive kode som krever spesifikk int-størrelse (det er kun på grensen mellom ekstern representasjon og konvertering til den interne at den type kunnskapet overhodet skal fremtre i koden).

[GeirGrusom]

Det er likevel MYE enklere å satse på konvensjon, nettopp fordi testingen blir enklere.

Dependency injection har en klar fordel over å endre private medlemmer. Dersom private funksjoner krever egne tester burde de være separert fra klassen. Funksjonaliteten til en privat funksjon burde være dekket fullstendig av unit-tester for alle public funksjoner. Det som ikke er dekket er irrelevant ettersom det burde være død kode.

 

Du skal ikke trenge #define private public, for da er det rett og slett noe galt med koden din.

 

Det er tåpelig å skrive kode som krever spesifikk int-størrelse (det er kun på grensen mellom ekstern representasjon og konvertering til den interne at den type kunnskapet overhodet skal fremtre i koden).

Sjekket nå, og Python promoterer et integer dersom det får overflow. Så da er det egentlig ikke et problem

 

Det kom fra en diskusjon på reddit hvor jeg hevdet at det er helt idiotisk at PHP konverterer et heltall til flyttall dersom overflow skjer, og det ble hevdet at Python også bare har 32-bit heltall på en 32-bit prosessor av en annen bruker.

 

Når jeg sjekker nå også, så bæsjer PHP på leggen, men Python oppfører seg akkurat som jeg ville forventet av en fornuftig implementasjon.