[java] populariteit van 3d api

[Verwijderd]

Misschien niet echt een super discusie topic maar ik ben gewoon benieuwd hoe andere mensen hier tegen aan kijken.
Ik vind zelf na wat onderzoek(website, bieb, boekhandel) dat er weinig te vinden is over de 3d api van java als je dat vergelijkt met opengl of D3D.
Dit terwijl ik zelf vind dat de java 3d api goed en makkelijk in het gebruik is.
Daarom vind ik dat de api ten onrechte impopulair is.
Wie kan mij het tegendeel bewijzen met goede argumenten?

PS. Het doel van deze discusie is 50% om te kijken of het handig is om verder te dev-en met de java 3d api.

[whoami]

Is Java gewoonweg niet te traag als het gaat over 3D programmatie?

[GarBaGe]

Een half jaartje geleden heb ik nog met de 3D API gewerkt. Ik vind hem nog erg onvolwassen. Er zitten hier en daar nog wat onvolkomenheden in en zowel de memory footprint als de performance laat serieus te wensen over (bij grotere apps).

In het vervolg zou ik sneller gaan voor een OpenGL oplossing...

[hobbit_be]

i could be wrong, maar ik nam aan dat Java 3D uiteindelijk gewoon wordt "vertaald" naar OpenGL / (of D3D). Java3D is ook veel meer highlevel dan OpenGL wat toch in feite alleen maar een Triangle Pusher is. D3D is dan al een pak hoger. Java3D steekt daar dan nog eens boven (beetje alla OpenInventor). Tja en waarom onpopulair: SPEED . 3D apps zijn meestal toch dingen die tegen de limit moeten gaan en daar is Java echt nog (if ever) voor gemaakt. Als je Java leuk vind waarom niet verder spelen - maar je kan ook gewoon OpenGL for java installeren enzovoorts (en die kan echt wel snel gaan). Persoonlijk vind ik OpenGL de 'beste' API omdat ie zo low level is, daarboven kune je dan middle tier spul plaatsen voor de 'managment' van 3D (BSP/Collision/etc)... D3D is ook lekker maar tja == Windows he.

[Soultaker]

Van wat ik vaag meegekregen heb, schijnt de Java 3D API best aardig in elkaar te steken, maar of het nu aan de gebruikers ligt of aan de API, ik heb er alleen nog maar prutsprojectjes mee gezien. Helemaal niets wat in de buurt komt van de OpenGL demo's die er volop op het internet te vinden zijn (uit de demo scene).

De slechte reputatie van Java3D komt waarschijnlijk dan ook van de het suffige imago van lelijke VRML demo's dat ermee verbonden is. In principe geloof ik best in de mogelijkheden van Java om een 3D engine mee aan te sturen (ik zou niet weten waarom dat niet zou kunnen) maar als ik nooit iemand zie die er daadwerkelijk iets moois mee kan creeëren, vind ik het eigenlijk nauwelijks de moeite waard om me er in te verdiepen. Dat is natuurlijk een beetje van mezelf uit geredeneerd (en ik heb wel makkelijk toegang tot DirectX en OpenGL vanuit C/C++) maar ik kan me voorstellen dat andere mensen ook zo redeneren.

Verder weet ik niet zeker of de Java3D API over de benodigde features beschikt om echt geavanceerde programma's te schrijven. Denk daarbij aan het compileren van hardwarematige pixelshaders, het weergeven van splines en parametrische patches, en dergelijke. Ook plaats ik mijn vraagtekens bij de schaalbaarheid en performance van de engine. Ik zie de Java3D API dan ook meer als een high level tool terwijl een API als OpenGL (en ook DirectX) op een veel lager nivo werken. Het voordeel van een techniek als OpenGL over Java3D is dat je er alles mee kan maken, omdat je de low level bouwstenen hebt. Java3D geeft je alleen high level tools.

Ik denk zelf dat niet zozeer de high-level benadering een probleem is, maar wel de lage kwaliteit van de implementatie (voor zover ik dat dus kan beoordelen). Als de achtliggende engine snelle, hoge kwaliteit en schaalbare scenes kan renderen, dan zou ik niet weten waarom deze API niet zou kunnen concurreren met low level API's als OpenGL en DirectX.

[mad_dog]

hmmzz, ik had er nog nooit van gehoord ( ben nog n00b ), dus ik downde ff een voorbeeld van de sun site, het spel tempest.
Naja dan komt het:

Installing:

add "lib" to CLASSPATH

If you need to compile, run the "build" script, or:

javac -d lib -O -nowarn -sourcepath src src/jsw/j3d/util/geometry/*.java src/jsw/j3d/behavior/*.java src/*.java


Running:

turn off the lights.
turn on some techno music.

add "lib" to CLASSPATH

Windows:

java -noclassgc -mx32m -mx64m Tempest

nu snap ik t ff niet meer
ik heb geen classpath tussen me environmental variables staan, ik gebruik altijd Eclipse om te coden. Dus ik heb geen idee hoe ik ding draaiende kan krijgen...
enige hulp zou gewaardeerd worden
hier kan je hem downloaden
[URL:http://java.sun.com/products/java-media/3D/demos/downloads/Tempest98.zip]tempest.zip[/URL]

[Soultaker]

hobbit_be schreef op 29 July 2003 @ 18:50:
i could be wrong, maar ik nam aan dat Java 3D uiteindelijk gewoon wordt "vertaald" naar OpenGL / (of D3D).

Yep, dat is het geval. Zowel OpenGL als Direct3D worden gebruikt (afhankelijk van de beschikbaarheid).

Java3D is ook veel meer highlevel dan OpenGL wat toch in feite alleen maar een Triangle Pusher is. D3D is dan al een pak hoger. Java3D steekt daar dan nog eens boven (beetje alla OpenInventor). Tja en waarom onpopulair: SPEED . 3D apps zijn meestal toch dingen die tegen de limit moeten gaan en daar is Java echt nog (if ever) voor gemaakt.

Tja, daar kwam whoami ook al mee:

whoami schreef op 29 July 2003 @ 18:45:
Is Java gewoonweg niet te traag als het gaat over 3D programmatie?

Maar daar ben ik het dus niet mee eens. De Java 3D API is juist zo opgezet dat je op een hoog nivo met de rendering engine werkt (je doet niet veel meer dan een scene graph configureren). Het echte renderen, dat inderdaad snel moet gaan, wordt in de onderliggende 3D engine gedaan, en die kan best snel en goed zijn.

In bijvoorbeeld 3D spelletjes zie je ook al dat >90% van de tijd gaat zitten in het renderen van frames en veel minder in netwerkcommunicatie en het verwerken van de wereld (extrapolatie van frames). Dat verschilt natuurlijk een beetje per toepassing. Daarom is het gebruik van een scripting engine voor die tussenliggende 10% dus helemaal niet zo onrealistisch. The Nebula Device gebruikt deze aanpak ook, door scripting met behulp van Tcl/Tk, Python en Lua te ondersteunen. Ook is er een port van Quake 2 met een Java game engine. De complete Quake 2 game code draait dus in de Java virtual machine en de Quake 2 engine draait gewoon vanuit native (C) code. Dat werkt dus uitstekend, aangezien de game code maar een klein deel van de totale user time gebruikt.

offtopic:
Quake 2 is trouwens ook naar .NET geport: http://www.vertigosoftware.com/Quake2.htm
Hoe dat verder werkt, weet ik niet.

[ Voor 4% gewijzigd door Soultaker op 29-07-2003 19:04 ]

[Soultaker]

mad_dog schreef op 29 July 2003 @ 18:52:
hmmzz, ik had er nog nooit van gehoord ( ben nog n00b ), dus ik downde ff een voorbeeld van de sun site, het spel tempest.

Dat "spel" illustreert mooi mijn punt. Het ziet er dus zo uit:

(Klikbaar)

Behalve dat het er niet aantrekkelijk uitziet, kan ik een 3D Engine die in deze tijd dit soort graphics produceert niet serieus nemen. Op m'n MSX2 kon ik dit soort spellen al spelen. Uiteraard is het vaak het artwork (textures, models, etcetera) dat een demo er mooi uit doet zien (en niet zozeer de API die gebruikt werd) maar het vervelende met Java 3D is dat dit soort demo's alles is wat je ooit te zien krijgt. Is dit nou echt het beste wat mogelijk is?

nu snap ik t ff niet meer
ik heb geen classpath tussen me environmental variables staan, ik gebruik altijd Eclipse om te coden. Dus ik heb geen idee hoe ik ding draaiende kan krijgen...

Ik heb gewoon de J2SDK en de Java3D SDK onder Windows geinstalleerd en het werkte. Ik vrees dat je het lastig gaat krijgen met Java programmeren, als je de boel nog niet eens geïnstalleerd krijgt, dus ik denk dat je toch gewoon even goed uit moet zoeken hoe je alles in moet stellen.

[ Voor 5% gewijzigd door Soultaker op 29-07-2003 19:17 ]

[mad_dog]

right, dr is een 3d SDK
en lastig met programmeren....valt wel mee, ik heb alle programmeervakken van t eerstje jaar informatica aan de tu delft gehaald (* mad_dog = beetje trots )
maar ik geef eerlijk toe, dat stelde weinig voor

[KompjoeFriek]

Die 3D SDK heb ik een half jaarje geleden ook eens geïnstalleerd om dat een 3D voorbeeld het nodig had.
Was een applet om een aantal algoritmes te demonstreren.
* KompjoeFriek zoekt naar een url...
Gevonden!
Je hebt die SDK alleen nodig om hem te compilen zie ik, hij runt hier meteen zonder de 3D SDK geïnstalleerd te hebben

[edit]
nog een ander dingetje gevonden
nou weet ik weer waarom ik dit niet uit heb zitten pluizen. Moet je voor de grap de snelheid eens opvoeren...
(ik draai het hier op een 2Ghz bak, en nog draait ie stotterend)
EN er wordt nix gerenderd, dat zou je toch wel verwachten van 3D tegenwoordig

Ik denk dat dat 2 perfecte redenen zijn om er niet iets spectaculair moois mee te maken, maar voor een simpel 3d progje/applet zou ik het wel willen leren en gebruiken

[ Voor 79% gewijzigd door KompjoeFriek op 29-07-2003 20:16 . Reden: Site Gevonden ]

[Soultaker]

KompjoeFriek schreef op 29 juli 2003 @ 20:03:
Je hebt die SDK alleen nodig om hem te compilen zie ik, hij runt hier meteen zonder de 3D SDK geïnstalleerd te hebben

Inderdaad de SDK is de software development kit, maar je hebt minimaal de runtime editie nodig.

nou weet ik weer waarom ik dit niet uit heb zitten pluizen. Moet je voor de grap de snelheid eens opvoeren...
(ik draai het hier op een 2Ghz bak, en nog draait ie stotterend)

Weet je zeker dat dit ding Java 3D gebruikt en niet binnen Java rendered?

EN er wordt nix gerenderd, dat zou je toch wel verwachten van 3D tegenwoordig

Hoe bedoel je, niets gerendered? Ik zie 'm toch echt wel dingen renderen, al gaat is het inderdaad niet spectaculair.

[Verwijderd]

java3d api is gewoon erg traag en heeft niet de luxe truukjes als hlsl enzo. daardoor is het gewoon een stuk moeilijker om mooie apps er in te schrijven. als je even de mogelijkheid hebt zou ik toch aanraden opengl of d3d te gebruiken. er zijn opengl plugins voor java, maar let wel op dat als je met java gaat werken met bijvoorbeeld opengl dat het draaien via VM nogsteeds erg langzaam kan gaan. naar native compileren is dan ook zeker een aanrader. maar op de eerste plaats zou ik toch aanraden naar bijvoorbeeld C++, C, etc over te stappen met gebruik van directx of opengl.

[Creepy]

Ik denk dat de topicstarter na een jaar of vier wel zijn of haar eigen conclusie heeft gemaakt

[ Voor 6% gewijzigd door Creepy op 23-04-2007 13:46 ]