Microsoft wordt lid van Open 3D Foundation die opensource-3d-engine maakt

Microsoft is premier member geworden van de Open 3D Foundation. Dat is een onderdeel van de Linux Foundation dat de Open 3D Engine beheert. De eerste grote release van die opensource-3d-engine kwam eind vorig jaar uit.

Als premier member krijgt Microsoft een plekje in de raad van bestuur van de O3DF. Paul Olivier, bij Microsoft in dienst als Principal Group Program Manager, neemt die taak op zich. De stichting wordt gesteund door tientallen bedrijven. Naast Microsoft zijn Adobe, AWS, Huawei, Intel, Niantic en Tencent premier members.

De Linux Foundation heeft de O3DF vorig jaar opgericht met als doel de ontwikkeling van 3d-games en -applicaties te versnellen. De engine van de stichting is een opvolger van Amazons Lumberyard-project, dat op zijn beurt gebaseerd was op de CryEngine van Crytek.

In december vorig jaar bracht de O3DF de eerste stabiele release van de Open 3D Engine uit. Dat betrof versie 21.11 en op het moment van schrijven is dat ook nog de recentste stabiele uitgave. De engine is beschikbaar voor Windows en als previewversie voor Linux.

Open 3D Engine 21.11

Reacties (44)

[darthdrinker]

Meer opensource keuze is op zich goed maar voor een opensource alternatief die bruikbaar is voor beginners of kleine studio's kan je kijken naar GODOT game engine.

De GODOT engine bestaat al jaren is ook al vrij compleet en is ook volledig open source, het verbaast mij toch licht dat hier geen aandacht voor is. Als je direct super grote AAA games gaat maken misschien niet geschikt maar juist voor de indie markt is de GODOT engine denk ik veel beter geschikt.

[Wolfos]

Alleen minder geschikt voor consoles. Wat dat betreft zijn ze actief aan het misleiden, met zinnen als:

In practice, the process is quite similar to Unity and Unreal Engine, except that you need to contact a third-party developer to handle the porting process

Dat is best wel even een dingetje. Ze hebben eigenlijk helemaal geen ondersteuning voor consoles, maar doen alsof dat wel zo is.

Qua PC, als je 2D titels maakt verder wel geschikt. Wat betreft 3D denk ik dat je tegen een hoop kleine dingetjes aan gaat lopen.

[Reactie gewijzigd door Wolfos op 23 juli 2024 00:45]

[darthdrinker]

Het verhaal over consoles is bekend en GODOT is daar heel open over. Dit komt voort uit het feit dat die consoles geen open source compatibel manier van releasen hebben. Eigenlijk ben ik dus wel benieuwd hoe ze dit bij die club hierboven precies doen EN ook open source claimen te zijn. Dit is feitelijk juridisch niet mogelijk en dus best misleidend als je het mij vraagt.

Daarnaast is het voor jou als maker wel degelijk mogelijk om GODOT games naar consoles te brengen, je kan dan echter niet meer claimen open source te zijn. Als dat je niet veel uitmaakt zijn er zelfs meerdere partijen en uitgevers die je, tegen vergoeding, hierbij kunnen helpen.

3D is trouwens prima te doen maar uiteraard wachten de echte GODOT liefhebbers op GODOT 4.0 die ook met 3D hele grote stappen gaat maken. Zeker leuk om eens op te zoeken.

[SuperDre]

Probleem met 3d is dat het allemaal beloofd wordt, maar voorlopig is het er nog niet en verre van Unity of UnrealEngine kwaliteit, naast dat die dus ongelooflijke tools hebben en bij UE zelfs complete toegang tot de megascan library, dat alleen al mag je niet onderschatten in kosten.

[Sp3ci3s8472]

Klopt, de engine is erg goed voor 2d spellen. Daarnaast zijn er allemaal plugins om de workflow daarvan te versnellen.

Zelf gebruik ik de editor eigenlijk nauwelijks voor mijn spel, ik gebruik de nodes die geleverd worden en dat is het. Tot nu toen moet ik zeggen dat ik best onder de indruk ben van GODOT, maar dat komt ook omdat naast hun eigen taal c# goed wordt ondersteund.

Als laatste pluspunt, in tegenstelling tot Unity of Unreal zijn er geen licentie kosten! Wat ideaal is, zeker voor indie developers. Ik ben niet van plan om nog eens zoveel procent aan die grote engine makers te geven van de waarschijnlijk toch al kleine omzet.

[Reactie gewijzigd door Sp3ci3s8472 op 23 juli 2024 00:45]

[Pompidompi]

Bij een kleine omzet hoef je niet bang te zijn voor licentiekosten voor de Unreal Engine de eerste één miljoenen Dollar is namelijk vrijgesteld.

https://www.unrealengine.com/en-US/eula/unreal

[SuperDre]

Ja, moet eerlijk zeggen dat C# toch wel weer een gemis is bij de UnrealEngine.
Maar licentiekosten van de unrealengine vallen wel mee, de content waar je gratis toegang tot hebt maakt dat meer dan genoeg goed, en zoals Pompidompi aangeeft, je betaalt tot 1 miljoen dollar geen royalties, daarna 5% van de verkoopprijs (niet de netto prijs), BEHALVE als je via de Epic gamestore je game verkoopt, dan blijft het totaal 15% waar je bv bij steam dus 30% voor steam + 5% voor epic.
Dus daarom kun je je wel indenken dat een developer van de ene kant wel voorkeur heeft voor de EGS als je puur naar wat je overhoudt kijkt.

[Sp3ci3s8472]

Dat was voor mijn overigens een zwaardere weging dan de royalties uiteindelijk; met c# kan ik in hele korte tijd iets bouwen en nette code schrijven. Je moet natuurlijk nog steeds op je geheugen gebruik letten ondanks de GC, maar je bent er minder mee bezig dan als je puur c++ pakt.
Daarnaast is de Unreal Engine ook wel erg grof geschut als je een simpel 2d spel wilt maken. Ik vermoed dat je dat veel sneller met GODOT kan. Het heeft mij minder dan een week gekost om prototype in GODOT te kunnen maken. Unreal Engine heb ik dan nog nooit geprobeert maar alleen de download al is enorm.

Unity met hun component systeem is erg leuk, maar ik vind dat GODOT je iets meer vrijheid geeft in wat je doet. Nu moet ik wel toegeven dat de laatste versie van Unity die ik heb gebruikt volgens mij 3.5 of 4.0 was. Om een voorbeeld te geven; in GODOT kan je een klasse een Node laten overerven en nog steeds die klasse zelf instantieren, bij Unity kon dat niet direct.

Wellicht voor een toekomstig (simpel 3d) spel dat ik eens naar de andere engines kijk; maar ik vermoed dat GODOT 4.0 als dat uit is prima voldoet. Aan de andere kant is het misschien ook leuk om een keer naar de nieuwe trent te gaan kijken met data-oriented game engines.

[SuperDre]

UE moet je ook niet gebruiken voor doorsnee 2D games, ook al kan het daar zeker wel mee, behalve als je misschien ook 3D er in wil verwerken.

[Wolfos]

Flax Engine regelt dit door de ports via de console developer kanalen beschikbaar te stellen.

[HTPeter]

Dat hangt puur af van wie de open source status claimt en hoe men uitvoering op consoles implementeert.

Het is technisch mogelijk om bijvoorbeeld in een virtuele machine zonder GUI (die gewoon wordt geladen bij het starten van een game) een (eveneens zonder GUI) helemaal van alle overbodige functionaliteiten gestripte Linux-versie te draaien en dáár vervolgens een game mee te laden.

Consoles hebben in wezen een 3700X onder de motorkap, maar met een andere geheugencontroller en een GPU eraan gekoppeld. Dat is genoeg rekenkracht voor én een moderne game-engine + een laag virtualisatie eroverheen gelijktijdig te draaien zonder dat de gebruiker iets merkt. Elke game draait namelijk ook probleemloos op een 3600, en 2 CPU-cores zijn voldoende om een virtual machine + een soort van onzichtbaar OS te draaien. Vervolgens is alleen voor de virtualisatie een gesloten software-omgeving nodig.

Wat is er in deze constructie ineens niet langer open source aan de engine die gebruikt wordt?

[Reactie gewijzigd door HTPeter op 23 juli 2024 00:45]

[darthdrinker]

Dit heeft allemaal niets met hardware te maken maar met de juridische zaken die moeten worden geregeld als je met je game engine officieel een console wilt ondersteunen. Hiervoor moet o.a. een officieel bedrijf NDA’s ondertekenen, de hoofd contributer van Godot heeft dit al meermaals uitgelegd en ook waarom Godot dit dus niet kan doen. Alleen omdat iets technisch kan wil niet zeggen dat de blood sucking lawyers dit toestaan. Ga maar eens zoeken waar Nintendo allemaal toe in staat is. 😉

[Jan VP]

>> wachten de echte GODOT liefhebbers op GODOT 4.0
Is de naam gekozen om die grap te kunnen maken?

[dustsuckersnake]

Als je het "actief aan het misleiden" noemt ben je zelf aan het misleiden. Ze geven duidelijk aan wat je zelf kunt/moet doen om een game op consoles te krijgen. In de documentatie staat onder andere: "Port the engine to the console platform or pay a company to do it." en "Console ports of Godot are offered by third-party companies (which have ported Godot on their own). These companies also offer publishing of your games to various consoles."

[qsecofr]

FD: ik heb verschillende (recente) console devkits.

Porten zelf is niet echt een probleem; dat zijn gewoon visual studio plugins (voor xbox en PS3/PS4/PS5) met de bijbehorende compiler toolchains. Ook zijn dingen zoals eg SDL courant zodat je makkelijk een generieke fallback layer kan doen. Waar het lastig word is als je bv in publieke source trees `#ifdef` statements maakt om met deze SDKs overweg te kunnen - NDAs zijn meestal erg strict, waardoor legal dat makkelijk als information disclosure gaat zien en dat je zo je SDKs kan kwijtraken. Zelfs het vermeend risico dat je dit kan doen is al genoeg als chilling effect; die toestellen zijn echt wel enorm duur en zowel Sony als MS zijn ervoor gekend om consoles actief te bannen. Vanaf xbox one en PS4 is er ook regelmatige online activatie nodig met je developer ID vanaf een whitelisted IP.

[Muna34]

Ja, dat heb ik ook al eens eerder gehoord. Echter, als je onafhankelijk wilt blijven dan mag je wel verwachten wat meer werk te doen om je onafhankelijkheid te behouden. Anders kun je bijvoorbeeld toch net zo goed voor een Unity of Unreal gaan?

Ik ben totaal geen expert op dit gebied maar weet wel dat de grote engines gratis zijn totdat je een bepaalde omzet gaat halen. Daarvoor terug krijg je het gemak dat ports een stuk makkelijker worden. In andere woorden; you can't have it all ofcourse maar het blijft wel zoals je zegt een dingetje...

[Wolfos]

Qua prijs hoef je je niet zoveel zorgen te maken over Unity of Unreal. Wat wel een dingetje is met Unity is de gesloten broncode, dus als je een bug hebt kan je die zelf niet altijd oplossen - hoewel dat dankzij open source componenten steeds vaker wel het geval is.
Met Unreal heb je dat probleem niet.

[Reactie gewijzigd door Wolfos op 23 juli 2024 00:45]

[Muna34]

En niet te vergeten dat Godot ook al een hoop randzaken heeft zoals bijv. die templates, demos, documentatie, Blender exporter en het lange bestaan waardoor documentatie in overvloed is om een goede start te maken.

Ik denk wel dat mensen veel sneller op Godot uitkomen als ze een game willen maken; vanwege de grote identiteit het geworden is over de jaren heen.

[SuperDre]

Mwa, ligt er aan wat je wilt maken, 2d, ja, 3D, niet echt, zeker nu kom je dan toch eerder uit op UnrealEngine of Unity.

[Sando]

Ik vind het ook een klein beetje zonde van de dubbele moeite, maar in de O3DF Material Editor in dat screenshot zie je dat material-preview-model van Godot als ik me niet vergis. Zelfs dat kasteel op de frontpage van O3DE is oorspronkelijk een Godot-demo volgens mij, dus als O3DF zo makkelijk van Godot kan lenen, dan kan Godot dat uiteraard ook andersom. Dus waarschijnlijk is het alsnog een win-win.

[Reactie gewijzigd door Sando op 23 juli 2024 00:45]

[dieAndereGozer]

Ik ben zeer pro opensource, echter hoe verhoudt dit zich t.o.v. een Unity?

[Caayn]

Ik vraag mij af wat de voordelen voor MS zijn. Naast het gebruik van Unreal Engine, en een redelijke inhouse expertise met deze engine, heeft Microsoft een aardige stapel aan goede inhouse game engines, zoals bijv. ForzaTech en IdTech. Mislukte projecten zoals de Slipspace engine uiteraard niet vergeten

offtopic:
Ik vindt het nog steeds jammer dat wij sinds de PS4/XB1 nog amper wat van Cryengine horen en het vooral Unreal Engine is die de trom slaat (naast Unity). Al was Cryengine V niet in alle opzichten een vooruitgang te noemen.

[Reactie gewijzigd door Caayn op 23 juli 2024 00:45]

[Wolfos]

CryEngine staat erg slecht bekend onder ontwikkelaars. Eigenlijk gebruikt haast niemand behalve Crytek het nog.

EDIT:

heeft Microsoft een aardige stapel aan goede inhouse game engines

Het word steeds meer werk om te concurreren met de grote engines. Unity en Unreal hebben honderden ontwikkelaars die aan de engine werken. Een AAA studio misschien 10. Het delen van werk tussen studio's word dan steeds interessanter, en O3DE is misschien wel modulair genoeg opgezet voor AAA games.

Of misschien, zoals Mellow Jack aangeeft niet persé voor eigen gebruik maar puur als ondersteuning voor andere ontwikkelaars als zijnde platform eigenaar.

[Reactie gewijzigd door Wolfos op 23 juli 2024 00:45]

[qsecofr]

Degelijke devtools die 'goed' aanvoelen voor een console platform zijn make or break voor je platform; als je kijkt naar de verschillende geflopte consoles in the laatste 30 jaar merk je telkens dat het vaak mis liep omwille van brakke SDKs waardoor third-parties opgaven of low-effort ports maakten, waardoor de concurrentie uiteindelijk beter uit kwam.

[Mellow Jack]

Beetje koffiedik kijken. Naast het ontwikkelen van games maken ze ook development tools, een game streaming service, een online gaming netwerk en een cloud.

Microsoft is best bij als je geen Microsoft engine gebruik maar wel visiual studio icm github gebruikt om te ontwikkelen en je backend services in Azure host

En op deze manier kunnen ze bepaalde ontwikkelingen stimuleren op een cost efficiënte manier. Als je iets nieuws en expirimenteels wilt doen moet je intern er bijv 10 programmeurs op zetten. Bij opensource kan je 2 developers "sponseren" en hopen dat mensen uit de community aansluiten.

[ari3]

We hebben geen nieuwe 3D Engine nodig, maar een specificatie van een register-set zodat er geen GPU-specifieke drivers meer nodig zijn. Ik vind het absurd dat we wel generieke drivers hebben voor het aansturen van opslagmedia (AHCI), USB/Firewire (xHCI) en printers (PCL), maar niet voor grafische chips.

[Mortov Molotov]

Zou het kunnen dat dat te maken heeft met het gegeven dat GPU's nu eenmaal complexere technologie zijn?

[ari3]

Een GPU is niet complex, de functionaliteit van een GPU kan immers met een generieke API (zie OpenGL, Vulcan, etc.) aangestuurd worden. Er is geen technische reden dat een register-set of instructie-set van een GPU niet met een generieke standaard beschreven kan worden.

[vanviegen]

Klopt. En dan krijg je dus zoiets als Vulkan.

[Wolfos]

Waarom heeft OpenGL dan honderden fabrikant-specifieke extensies? Zo generiek is het allemaal niet.

[Reactie gewijzigd door Wolfos op 23 juli 2024 00:45]

[batjes]

Die zijn er wel. Microsoft heeft ruim 20 jaar geleden veel fabrikanten gedwongen te voldoen aan een zooitje standaarden. Zo kan de ingebakken driver van Microsoft in Windows prima een GPU van Nvidia, AMD en Intel aansturen en daar kan je zelfs een beetje mee gamen (al werken veel zwaardere AAA titels er niet mee).

Net als NIC's (alhoewel vaak met uitzondering van die Realtek meuk) en veel andere hardware, het kan allemaal een basis API spreken. Anders wordt de hardware namelijk niet gecertificeerd voor Windows.

Linux heeft hier enorm veel profijt aan gehad overigens, wat een mooi neveneffect was.

Je kan niet een geoptimaliseerde driver bakken die op elk <type> hardware goed werkt. Nvidia en AMD kaarten werken totaal anders en er zitten veel verschillen tussen de generaties of af en toe zelfs binnen dezelfde generatie. AMD en Nvidia hebben al moeite zat om hun eigen lompe drivers een beetje optimaal te laten werken.

Het is echt veel beter om voor hardware eigen drivers te hebben dan generieke drivers.

GPU's zijn wel degelijk complex, dat het via generieke API's aan te spreken is zoals OpenGL, Vulkan, DirectX. Wil niet zeggen dat het appeltje eitje is die API's goed te laten praten met de GPU's zelf. Dan heb je nog de stapels brakke devs en de gigantische hoeveelheid fixes die AMD en Nvidia toepassen om gare games toch soepel te laten draaien.

Zelfs in die API's is het een enorme puinhoop qua fixes en workarounds omdat game developers er een zooitje van maken.

GPU's zijn het meest complexe stukje hardware in een (game) PC en dat ze uberhaupt stabiel en soepel games kunnen draaien is eigenlijk een waar wonder.

[TheVivaldi]

Interessant dat zelfs Adobe een premier member is.

[beerse]

Verbazend dat nvidia en amd als grote video-chip leveranciers hier niet in mee draaien. Of heb ik ergens iets mis en worden die geforceerd buiten de boot gehouden?

Voor Adobe: Die heeft met postscript een aardige beschrijvende taal aan boord die al jaren haar best doet om een standaard te worden. Ook de diverse grafische tools doen het nodige aan 3D.

[update]: Zoals ik onder nieuws: Nieuwe stichting wil ontwikkeling van 3d-software verbeteren met Open... al schreef: Hoe open is dit eigenlijk? Vanuit een Linux stichting en dan msWindowsPrimary?

[Reactie gewijzigd door beerse op 23 juli 2024 00:45]

[hottestbrain]

Wellicht is dat een typo en zijn ze premiere member?

[Damic]

Hoe gedraagt de Open 3d Engine tegenover Ogre? Vermits Ogre (https://www.ogre3d.org/) ook opensource en crossplatform is.

[Wolfos]

Ogre is puur een renderer. O3DE heeft ook een editor en wat randzaken zoals physics. Verder werd Ogre vooral gebruikt door kleine teams als basis voor hun 3D engine, terwijl O3DE zich puur op hele grote teams richt.
Ik denk dat Ogre wat in de vergetelheid is geraakt omdat het beheren van een eigen 3D engine voor kleine teams niet meer nodig is, en dat het steeds meer werk is om met een eigen engine competitief te zijn.

[Wolfos]

Vind dit wel een bijzonder project. Het is in feite bedoelt als basis voor in-house engines van AAA studio, niet zozeer als concurrentie op bestaande engines. Voor kleine teams lijkt O3D me dan ook zo goed als onbruikbaar, maar als de grote jongens hun werk gaan delen heeft de hele industrie daar baat bij.

[L2GX]

Is dit niet gewoon Amazon dat geen vat kreeg op de gamedev markt (behalve Star Citizen dan) en dan maar Lumberyard als een ongeleide hoop boomstammen op de markt gooit in de hoop ergens wel iemand stokken in de wielen te steken?

[Verwijderd]

De engine is beschikbaar voor Windows en als previewversie voor Linux.

dat lijkt me backwards..

[Umbrah]

Kun je dat uitleggen? Daar hebben ze eerder een statement over geschreven, immers. Een hoop legacy ligt op Windows, en package management is meer straight forward daar. Niet elke distro is namelijk even handig om iets op te leveren. Het feit dat het open source is en dat je wel degelijk kan builden op Linux, doet niet af dat een release voor een Linux-like niet zo vanzelfsprekend is.

Linus Torvalds gaf zijn eigen ervaringen daarbij ook goed aan, toen hij subsurface (een duik pakket) wou voorzien van een package. Windows, MacOS: prima. Linux? Ze hebben tegenwoordig Snap toegevoegd... en compile instructies.

Hij legt een hoop van die problematiek hier uit: https://www.youtube.com/watch?v=Pzl1B7nB9Kc

Tegelijkertijd overigens is dit (gameengine) wel een prachtig scenario van 'what if'. Een game engine doet namelijk een hele hoop (en Apple is een van de partijen die alles waar een 3d rendering/processing pipeline achter zit lastig maakt de laatste jaren door hun drop van OpenGL en gebrek aan omarming van Vulkan/DX12 equivalents...). Naast 3d rendering komt er meer bij kijken, waardoor het leveren van een package lastig is.

Eigenlijk snap ik, zeker in deze fase (en gezien de legacy van lumberyard) wel waarom deze keuze gemaakt wordt. En het is niet alsof ze het helemaal los laten

[prutsertje]

Jammer dat ik hier niks over een vergelijking met imho het prachtige blender lees...open source met inmiddels een comunity waar je u tegen zegt.

[Wolfos]

Het is hele andere software.

[prutsertje]

klopt, heb me een beetje verdiept..met blender zou je eventueel assets kunnen maken om te gebruiken in een game die je met deze open source 3d engine hebt gemaakt als ik het goed begrijp.

[rgcreator]

Hebben ze ook visual coding.