Cookies op Tweakers

Tweakers is onderdeel van DPG Media en maakt gebruik van cookies, JavaScript en vergelijkbare technologie om je onder andere een optimale gebruikerservaring te bieden. Ook kan Tweakers hierdoor het gedrag van bezoekers vastleggen en analyseren. Door gebruik te maken van deze website, of door op 'Cookies accepteren' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt? Bekijk dan ons cookiebeleid.

Meer informatie

Open 3D Foundation brengt eerste grote release van opensource-3d-engine uit

De Open 3D Foundation heeft de eerste grote release van zijn Open 3D Engine uitgebracht. Deze is gebaseerd op Amazons Lumberyard-engine. De engine kan gebruikt worden om 3d-software te ontwikkelen, zoals games en simulaties.

De Open 3D Foundation meldt in een blogpost dat de Stable 21.11-versie van zijn engine is uitgebracht voor ontwikkelaars. De engine is een opvolger van Amazons Lumberyard-project, die op zijn beurt is gebaseerd op de CryEngine van Crytek. De O3DF brengt de Open 3D Engine uit onder de Apache 2.0-licentie. De stichting heeft de broncode van de engine gepubliceerd op GitHub. De O3DF maakt ook een Windows-installer en een native Debian-package voor Linux-systemen beschikbaar.

Met de release kunnen ontwikkelaars 3d-games en -simulaties maken, meldt de O3DF. De Open 3D Engine kan ook door ontwikkelaars gebruikt worden als 'stabiele basis' om een eigen engine te ontwikkelen. Versie 21.11 krijgt verschillende functies mee ten opzichte van de eerdere previewversies, waaronder een ingebouwde benchmarktool en een 'experimenteel terreinsysteem'. De engine krijgt ook een sdk, die gebruikt kan worden om de engine aan te passen met platformondersteuning voor Windows, Linux, macOS, iOS en Android.

De Open 3D Engine werd in juli al aangekondigd door de pas opgerichte Open 3D Foundation. Deze stichting wil met de release van zijn opensource-engine het ontwikkelen van 3d-diensten stimuleren. Aan de O3DF doen meer dan twintig verschillende partijen mee, waaronder Adobe, Amazon, Huawei, Intel, Niantic en Red Hat. De O3DF is een onderdeel van de Linux Foundation.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Door Daan van Monsjou

Nieuwsposter

05-12-2021 • 17:05

54 Linkedin

Submitter: himlims_

Reacties (54)

Wijzig sortering
Is dit dan een alternatief voor Blender ?
Nee, ik denk dat deze gefocused is op realtime games/apps. En niet een hele ontwikkel omgeving zoals Blender heeft. Dit is een "Engine"

Unity/Godot/UE zijn allemaal afhankelijk van externe 'design' programmas.

Overigens is Godot ook een open source 2D/3D game engine: https://godotengine.org/

[Reactie gewijzigd door Nimja op 5 december 2021 17:13]

Correctie blender zal geen eigen game engine meer gaan voeren zoals voorheen.
Echter, blender is wel bezig om e integreren met andere game engines.
De blender foundation zal niet aan game engine code gaan werken.
Maar het staat anderen vrij om plugins te maken om in blender te integreren.
(Godot etc), er zijn al een paar engines, die hier aan werkenm
Jep, maar een MIT licentie heeft nogal wat andere restricties dan gpl versie of apache licenties.

Welke weet ik niet maar toch.

[Reactie gewijzigd door rob12424 op 5 december 2021 18:06]

Dat moet je toch even toelichten. Ik dacht dat de MIT licentie niet restricitiever is dan de Apache license.

Zelfde uitgangspunten, maar Apache meer gedetaileerd in het uitsluiten van patenten.
Mit is het minst restrictief. Je mag er zo goed als alles mee doen, inclusief clonen en verkopen voor commerciële doeleinden.
Wat is dan in het kort het nut van het uitgeven van de licentie?
Voor een bedrijf is het een zeer prettige licentie om mee te werken. Ze is niet viraal zoals GPL, ze kan er niet voor zorgen dat je patenten waardeloos worden zoals bij Apache enz.

Je kan dus zonder problemen deze code integreren in je eigen code base en/of er uitbreidingen op maken die je op een traditionele manier commercialiseert (lees, door verkoop). Je kiest zelf wat je teruggeeft en wat niet van wijzigingen enz. Maar het belangrijkste is wel dat het niet dezelfde risico's heeft van een GPL of andere copyleft licentie met betrekking tot al bestaande intellectual property die je als bedrijf opgebouwd hebt in het verleden.
In dit concrete geval: geen risico dat je als game developer plots je hele game moet open source maken door wat onvoorzichtig te zijn met includen van bv GPL software.

Dus indien je wil dat de adoptie van je software zo eenvoudig mogelijk is, is MIT een goede keuze. Misschien krijg je niet alles terug wat ontwikkeld wordt, maar dat hoeft niet altijd voor iedereen een prioriteit te zijn.

edit:spelling

[Reactie gewijzigd door bomberboy op 5 december 2021 21:46]

MIT licenties zorgen dus dat jou code aantrekkelijker is voor anderen om in hun projecten te integreren zonder consequenties mochten zij een commercieel doeleinde hebben.

Klinkt inderdaad niet gek als je wilt dat anderen gemakkelijk van jou code gebruik kunnen maken. Klinkt ook als handig voor bedrijven om goedkoop en veilig aan code te komen.

Bedankt voor de uitleg. Ik heb de verschillende licenties nooit zo goed begrepen. Dit was mooi beknopt en een duidelijk begin voor verdieping :).
Hier een overzicht van alle bekende open source licenties: https://choosealicense.com/licenses/

Edit: Een goed artikel gevonden die gaat over copyleft VS permissive licenses: https://www.jakesden.com/...ft-vs-permissive-licenses

En hier wordt ook goed uitleg gegeven: https://opensource.stacke...ive-and-copyleft-licenses

[Reactie gewijzigd door Remzi1993 op 6 december 2021 00:08]

Sterker nog: je bent als ontwikkelaar van zo'n project ook zelf aantrekkelijk voor bedrijven om aangenomen te worden als ze (van plan zijn om) een deel of je gehele applicatie of library in hun product of dienst te gebruiken. In tegenstelling tot copylefted-code, hoeft dan voor dat product of dienst niet het wiel opnieuw worden uitgevonden, om te voorkomen dat programmatuur van het bedrijf zelf gepubliceerd moet worden. De bestaande copyfree code kan gewoon gebruikt worden.

[Reactie gewijzigd door RoestVrijStaal op 5 december 2021 22:35]

Het zou veel beter voor de maatschappij zijn als iedereen verre zou blijven van octrooien en auteursrecht. Het is dus het meest ethisch verantwoord om altijd alles onder GPL te doen, onder het huidige recht.
Handig, heb je net vijf jaar aan een roman gewerkt, dan iedereen hem verspreiden zonder dat daar een vergoeding tegenover staat.
Toch zijn er genoeg open source ontwikkelaars die voor hun inkomen afhankelijk zijn van open source en ook voldoende inkomen hebben om te kunnen leven.

Misschien moet je dan als schrijver je businessmodel anders kiezen.
Als jij lang gewerkt hebt aan een origineel verhaal mag je daar inderdaad voor gecompenseerd worden, dat zal niemand betwisten. Wat ik persoonlijk wel belachelijk vind is dat het recht op een vergoeding door loopt tot 70 jaar na de dood van de originele auteur, maar dat is nog een hele andere discussie.

We hebben het hier echter niet over kunst of andere mediavormen, maar over software. In de praktijk blijkt het prima mogelijk om geld te verdienen met het leveren van services op software, zoals de distributie en ondersteuning. Red Hat is hier een van de meest succesvolle voorbeelden van. Alle code die Red Hat maakt is beschikbaar onder een copyleft licentiemodel en toch zijn ze een financieel gezond bedrijf. Helaas wel klein genoeg om opgeslokt te kunnen worden door een grote jongen als IBM, maar zo werkt het in die wereld nu eenmaal.
De vergelijking met romans is interessant. Neem Doom, waarvan de engine open source is. Je moet nog steeds voor de inhoud betalen om het te kunnen spelen. Bij romans betaal je dus ook voornamelijk voor de inhoud en niet voor het medium (kostprijs daargelaten). De boekdrukkunst is open source, zeg maar.
Het aantal mensen in Nederland dat van romans kan leven is op een paar handen te tellen. Heeft totaal geen zin. Maar als je boek echt goed verkocht wordt, kun je wel degelijk een inkomen verdienen met andere bezigheden, zoals lezingen, signeersessies, voorleessessies, subsidie, enz. enz. Tegelijkertijd heeft het systeem enorme nadelen. Het is bovendien principieel slecht voor de mensheid om het verspreiden van kennis kunstmatig te beperken.

Als het doel echt is om het maken van kwalitatief goede kunst te stimuleren, kan dat veeel beter gebeuren door die direct te stimuleren. Dat is veel goedkoper, en heeft niet de enorme schadelijke neveneffecten van auteursrechts. En dat gebeurt ook al op grote schaal. Het zijn vooral rijke bedrijven die veel geld verdienen aan auteursrechten, niet eens de mensen die echt goede kunst maken.

M.i. zou de staat dan ook niet zo'n ingrijpende wet moet hebben die de vrijheid van iedereen beperkt, voor een zeer marginaal en betwistbaar voordeel.
Anderzijds zeg je met de GPLv3 ineens verantwoordelijk te zijn voor alle downstream users inzake patentinbreuken in jouw code:
When you distribute a covered work, you grant a patent license to the recipient, and to anyone that receives any version of the work, permitting, for any and all versions of the covered work, all activities allowed or contemplated by this License, such as installing, running and distributing versions of the work, and using their output. This patent license is nonexclusive, royalty-free and worldwide, and covers all patent claims you control or have the right to sublicense, at the time you distribute the covered work or in the future, that would be infringed or violated by the covered work or any reasonably contemplated use of the covered work.

If you distribute a covered work knowingly relying on a patent license, you must act to shield downstream users against the possible patent infringement claims from which your license protects you.
Het is me niet 100% duidelijk of dat stukje dat ik italic heb gemaakt nu als filter werkt op "all patent claims" of eerder naast "that would be infringed or violated" staat.
Lijkt me toch een zwaar financieel risico om als individu op te nemen.

[Reactie gewijzigd door rubenvb op 6 december 2021 19:13]

Het hele systeem is gewoon door en door rot. Had nooit moeten worden ingevoerd. Hopelijk raken we er snel weer van af. In de geneesmiddelen zie je al dat de protesten tegen zgn. 'intellectueel eigendom' steeds toenemen.
Blender is een applicatie om 3d content te genereren. Bv 3d afbeeldingen of hele films.
3d engines zijn software libraries die door applicaties, zoals games, gebruikt worden om 3d in real time interactief weer te geven.
Bovendien gebruiken ze verschillende technieken. Blender en consorten gebruiken raytracing terwijl 3d engines voornamelijk vector (triangles) graphics gebruiken.
Tegenwoordig kunnen deze ook gemixt worden.
Zo zit het niet, Eevee is niet een ray tracing engine, en ook workbench is geen ray tracing engine.
Bovendien, blender is juist driehoekjes, en ngons. En realtime is altijd relatief...
Ik ben ooit begonnen in Blender omdat ik hun game engine wou gebruiken. Dat was nogal ingewikkeld, niet leuk en ik ontdekte toen al snel Unity (het ging nogal chaotisch eigenlijk).
Van Blender naar Unity heb je een goede overzet, Blender dient dan enkel voor het modelen van de geometrie en UV mapping.
De vraag werd al snel of Unity ook beter renderde dan Blender.
Voor Blender zat ik op C4D, die raytracing enkel gebruikt waar expliciet nodig. Dat ziet er dan wel snel plastic uit, maar je spaart, euhm, erg veel tijd. Zonder GPU acceleratie kan dezelfde scene iin Blender toch al snel twintig keer langer renderen.
Bij Blender baalde ik dus zwaar van de rendertijd én de renderkwaliteit. Je moet erg veel trukjes toepassen om een glad resultaat te krijgen bij harde oppervlakken. Standaard waren de resultaten met de built-in renderer én Cycles erg korrelig en met veel 'fireflies'. Betere resultaten kunnen, met 2,4,8,16 maal langere render tijden... Dat is dan overnacht renderen zoals tien jaar eerder.
Of je gaat express op zoek naar instellingen om zonder raytracing te renderen- weer plastiek.
Maar je kan dezelfde render, zonder raytracing maar met environment maps, en specular, etc. in Unity realtime weergeven...
Ik geef grif toe: ik had gewoon niet de grafische kaart om Blender écht een eerlijke kans te geven. Anderszins, ook Unity kan natuurlijk mooier renderen met een betere grafische kaart.
Ondertussen kan ik me moeilijk voorstellen dat ik ooit nog iets met hard surfaces in Blender ga renderen... en tegen dat ik me wil bezighouden met huid met subsurface scattering en zo is er waarschijnlijk ook een geschikte shader te vinden in de Unity asset store.
Waar zal Blender me dunkt wél nog uitblinken? Procedurale shaders. Die bestaan in Unity ook, maar in Blender (en andere 3d programmas) kan je er écht ver in gaan.

[Reactie gewijzigd door L2GX op 6 december 2021 11:24]

Blender 3.0 is vorige week uitgekomen. Renderen gaat nu als een malle 3 tot 5 keer zo snel als eerst =D
+ over de jaren is Blender steeds beter geworden en met de laatste update is Blender echt een monster van een programma.
Ik zou denken voor Unity eerder.
Nee, maar wel voor Unity
Blender is een programma om 3D objecten (en omgevingen) in te maken. Een 3D engine zoals dit dient in de eerste plaats om een 3D object (of wereld) in weer te geven en is wat je gaat zien gebruikt worden in vele projecten. Blender zal zijn eigen rendering engine aan boord hebben, maar je hebt ook Unity en Unreal bijvoorbeeld. Het is de basis om een applicatie op te bouwen die 3D wil weergeven. Dat kan gaan van een design programma maar kan evenzeer gewoon een computerspel zijn.
Vroeger had Blender een eigen game engine:
https://en.m.wikipedia.org/wiki/Blender_Game_Engine
Die is in 2018 verwijderd omdat ie niet goed was en niet onderhouden werd. Soms is het goed om taken te scheiden. Tekenen en animeren kunnen wel alletwee met Blender, maar interactie is blijkbaar een stap te ver; ik stel me voor dat je je modellen met Blender maakt en vervolgens importeert in O3E.
Ik meen me te herinneren dat zo'n 1.5 jaar geleden sprake was van belabberde performance van Amazon's Lumberyard engine. Dat Amazon er zelfs over dacht om een switch te maken naar Unreal Engine. De problemen zijn inmiddels opgelost? Anders zie ik weinig waarde in dit nieuws.
Nieuwswaardig is het wel wat mij betreft, maar of het een interessant product is om mee te werken kan je over discussiëren. Hoewel ik een groot voorstander ben van Open Source software voelt dit voor mij een beetje als een brak stuk software open sourcen in de hoop dat dat genoeg interesse opwekt voor anderen om je project vlot te trekken.
Ik denk dat Amazon gewoon de rekening gemaakt heeft van hoe nuttig het is om vertikaal te integreren en alles zelf te doen in een sector waar 'project gefaald, developer failliet' zowat de default uitkomst is.
Lumberyard was gebaseerd op CryEngine, wat echt een probleemkind is. Maar gezien hoezeer de hele opzet van de engine verandert is in O3DE lijkt me dat er met een schone lei begonnen word.
Origineel gebaseerd op de CryEngine die Amazon heeft gelicenceerd van Crytek, en nu omgezet naar open source, dan vraag ik me toch wel af of Crytek hier wel zo mee eens is.
Ben wel benieuwd hoe deze engine zich houdt tegenover de UnrealEngine of Unity, waar toch wel heel veel degelijke tools en integratie met workflows er ondertussen zijn. Als het zich kan meten met die engines is het wel interessant, maar met de hele marketplace en gratis toegang tot de Quixel megascan is het voor veel 'indie'developers de UnrealEngine toch wel een stuk interessanter.
Waarschijnlijk niet. Voor studenten, hobbyisten, Indie en AAA developers is er eigenlijk niets beter en gebruiksvriendelijker dan de Unreal Engine. Tijdje geleden met cryengine aan de slag gegaan, maar er is gewoon niet genoeg documentatie te vinden zoals bijvoorbeeld met UE en Unity
Daar ben ik het toch niet helemaal met je eens. Voor AAA’s is Unreal waarschijnlijk het meest gebruiksvriendelijke dat ze kunnen krijgen, maar voor indies is het vooral een engine die Epic voor zichzelf heeft gebouwd.
C++ is nou niet de meest gebruiksvriendelijke programmeertaal, en de documentatie voor hun API is erg minimaal.
Maar C++ is helemaal niet de main taal die je gebruikt om games te ontwikkelen met de UnrealEngine, het is eigenlijk voornamelijk de bedoeling dat je dus blueprints gebruikt, en C++ om hooguit hier en daar performance te verbeteren waar nodig. Voor indie developers is het juist een degelijke engine omdat je ook nog toegang hebt tot de gigantische quixel megascan library wat ook echt niet onderschat moet worden.
En dan nog, zelfs voor een beetje indie developer moet C++ echt geen probleem zijn, tenzij je geen programmeur(s) bent/hebt, maar daarvoor is dus blueprint JUIST de oplossing.
C++ is gewoon een stuk minder productief. Juist daarom is Unity zo aangeslagen onder indies.
Een ervaren programmeur ga je niet aan de blueprints krijgen.

[Reactie gewijzigd door Wolfos op 6 december 2021 12:21]

C++ is nou niet de meest gebruiksvriendelijke programmeertaal,
C++ is gewoon een stuk minder productief.
Het valt me op dat je het tot twee keer toe aanhaalt. Ik ben na een decenia in c# gewerkt te hebben overgestapt naar c++ en ik kan mij hier niet zo goed in vinden. Ik vind c++ bijv. juist heel productief. Mijn dev environment is nog nooit zo duidelijk en stabiel geweest.
Ik heb het laatst even geprobeert met Unreal, maar bij compilatietijden van 40 seconden (in een vrijwel leeg project) haak ik af.
Ja, ik had ook graag native C# gezien voor Unreal en niet via een plugin waarvan je maar mag hopen dat het ondersteund blijft, en moet afvragen wat de performance ervan is.
En klopt, een ervaren programmeur krijg je niet snel aan de blueprints, maar met UnrealEngine 4 (en 5) is het niet zozeer meer de bedoeling dat je nog heel veel met C++ doet (behalve waar snelheid echt noodzakelijk is). Advies is zelfs, geloof ik, kijk eerst via blueprints en daarna pas naar C++.
Uiteindelijk is het ook maar wat je gewend bent hoor, in het begin is elke omgeving best lastig, althans dat is mijn ervaring, want bv met visual studio kan je zooooooveeeeeeel instellen en doen, en als de taal je dan ook nog eens een gazillion ways to do something geeft (bv bij C# langzaamaan alles naar 'var' en dat soort zaken) dan wordt het ook nog best wel eens lastig.
Als ik zelf Blueprints telkens zie dan denk ik, pfffffff, 'geef mij maar gewoon losse code', maar aan de andere kant denk ik dan vaak ook weer, 'maar toch is het wel verrekte makkelijk'.
Ja, jaren geleden was het team voor roadkillwarriors (een UT200x mod waar ik nog een tijdje ook aan gewerkt heb) ook overgestapt op de CryEngine omdat ze die toen zo geweldig vonden, maar na het ene na het andere probleem zijn ze toch maar weer gestopt ermee en teruggegaan, uiteindelijk is het helemaal gestopt helaas.
De Open 3D Engine kan ook door ontwikkelaars gebruikt worden als 'stabiele basis' om een eigen engine te ontwikkelen.
Deze zin zegt al genoeg. Deze engine is nog lang niet af.
Juist, en daarom is dat voor veel gamedevelopers helemaal niet interessant, want zelf een eigen engine ontwikkelen kost ook een hoop tijd en geld, waarbij je dus wel zelf geld er in blijft moeten pompen. Dan is het gewoon voordeliger om een kant en klare engine te gebruiken, waar je overigens ook wel wat invloed op hebt als er fouten in zitten (in iedergeval met de UnrealEngine), en dan dus alle optimalisaties en kosten die daarbij komen kijken mooi overlaten aan het bedrijf dat de engine ontwikkelt.
Eigen engine is leuk vanuit de echte developer perspectief, maar vanuit zakelijk en nuchter perspectief is het gewoon niet slim, in iedergeval niet met de huidige stand van zaken van de beschikbare (commerciele) engines. Die royalties die je op die engine moet betalen zijn echt in veel gevallen een stuk goedkoper dan een paar developers die voor jou je eigen engine onderhouden, en niet te vergeten de extra bijkomende tools.

Misschien als over een paar jaar die engine eindelijk op het niveau is van de huidig beschikbare 'commerciele' engines, dat het dan wel interessant wordt. Maar ik denk dat dan die huidige engines ook weer stappen voorlopen.
Toch kan dit interessant zijn voor grotere teams. Niet zozeer vanwege de royalties, maar omdat je dan een engine hebt die compleet aan je eigen workflows is aangepast.
Klopt, zelf heb ik ook altijd graag liever dat het 100% op mijn manier werkt, maar toch moet je ook verder denken en aan toekomstig personeel dat je aan neemt. Als er in de industrie langzaamaan een standaard workflow, door bv gebruik van de UnrealEngine of Unity, op komt en jouw workflow is toch wel anders, dan is het lastiger voor personeel om daar aan te wennen. En wat je het liefst hebt is personeel die snel aan de slag kan, ipv eerst maanden bezig zijn om aan jouw workflow te moeten wennen. Ook heeft het vaak voordeel met andere pakketten die eerder op bv de commerciele engines geent zijn en jij weer wat moet gaan verzinnen om het op jouw workflow aan te passen.
Tuurlijk heeft een eigen engine ook zeker wel voordelen, maar men onderschat toch echt wat de bijkomende kosten zijn om die te blijven onderhouden. En dan ga ik hier even uit van een 3D engine die ook wel up to date moet blijven met de laatste GPU's en grafische pracht, en zeker zaken als multiplatform of zelfs eisen van platformen waar je op wilt publiceren zoals iOS.
Als 'hobbyproject' is het leuk een eigen engine, maar zakelijk moet je gewoon nuchter proberen te zijn en moet je vooruit kijken.
Je somt vrijwel de grootste nadelen al op inderdaad van een eigen engine. Daarnaast zou ik er ook aan toe willen voegen dat je eigen engine ontwikkelen ook wilt zeggen dat je heel maar ook echt heel veel tijd kwijt bent aan stomme dingen rechttrekken die je anders niet zou voorhebben met bestaande engines. En dan is het nog goed doenbaar als je het houd op één graphics library. Maar vind maar eens personeel dat én DirectX kent, én OpenGL én Vulkan én Metal. En als je dan ook nog eens meerdere platformen wilt targeten dan heb je toch al een team van minstens 10 man nodig die daarna een paar jaar zoet zullen zijn.

Maarr het komt ook met zijn voordelen echter. Namelijk geen licentiekosten, volledig alles in eigen beheer en geen afhankelijkheden van een 3e partij. Plus, het is op maat gemaakt. Grote commerciële engines targeten zo veel mogelijk platforms met zoveel mogelijk features terwijl als jij als bedrijf je enkel richt op PC als het ware, er al enorm veel wegvalt. En daardoor komt je product ook niet met onnodig veel extra libraries en logic dat je toch nooit zou gebruiken.

Er valt voor beide kanten wel wat te zeggen natuurlijk maar voor mij zou de keuze voor een eigen engine vs een commerciële een case to case scenario zijn.
geen afhankelijkheden van een 3e partij
En dat is wat mensen die een eigen engine willen schrijven altijd onderschatten, want je bent wel degelijk afhankelijk van bv leveranciers als Nvidia of AMD met hun drivers. Ga er maar niet van uit dat zij voor een kleine developer problemen met hun driver die jij hebt met jouw engine niet gaan oplossen, tenzij jouw spel heel HEEL populair zou zijn, maar Nvidia en AMD werken toch behoorlijk nauw samen met Epic en Unity bij verbeteren van de engines.

Ikzelf schreef vroeger ook graag mijn eigen engines (was dan nog wel 2d) en moest toen ook niet denken aan 3rd party engines, maar inmiddels ben ik gewoon realistisch en nuchter om wel in te zien dat ik nooit de mogelijkheden zou kunnen creeeren die met bv UnrealEngine of Unity mogelijk zijn, terwijl het geld toch dan moet binnenkomen en ik dus beter mijn resources kan besteden aan het werkelijk ontwikkelen van de game zelf, want met UE en Unity kun je zowat wel alle soorten games maken die je wilt.
Eh, waar staat dat precies? :?
In het artikel.
Er staat in het zinnetje dat jij citeert zeer zeker niet dat de O3DE nog lang niet af is. De aanhalingstekens worden gebruikt om een citaat of uitspraak aan te duiden. In dit geval is het de ontwikkelaar die heeft aangegeven dat de O3DE bruikbaar is 'als stabiele basis voor het ontwikkelen van een eigen engine'.

Of de schrijver van het artikel er goed aan gedaan heeft om ze op deze manier -dus om twee woorden en niet om een zinnetje- in de tekst te gebruiken, is een andere vraag.
Als je op die manier een woord tussen aanhalingstekens plaatst, neem je er afstand van.

Het schoolvoorbeeld is iets als:

A: Neem nog wat worteltjes.
B: Ik houd niet van “worteltjes”.
Wat een onzin, je zuigt dat gewoon uit je duim. Aanhalingstekens kunnen vele functies vervullen.

In dit geval is het gewoon een verwijzing naar iets dat in het bronartikel staat:
With today’s release, developers can build 3D games and simulations, or a customized game engine on a stable foundation (…)
Nadruk van mij.
Een aanhalingsteken neemt per definitie afstand. De vraag is alleen hoeveel. Mogen we er niet eens meer mee lachen?
Open 3D Engine gebaseerd op Lumberyard, gebaseerd op CryEngine :+ . Ik zie het nut van deze engine in wat betreft open source maar vind het doorforken van dit soort engines wel een beetje vaag. Dit gaat de ontwikkeling toch ook een beetje tegen voor dit soort projecten? Of zie ik dit verkeerd.
Lumberyard is getransformeerd tot dit, Amazon is heel erg betrokken bij het project.

Op dit item kan niet meer gereageerd worden.


Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2022 Hosting door True