[3D] (algemene) beschrijvingstaal voor een 3D scene

[Boegel]

Voor een Ray Tracer die ik zelf wil schrijven, ben ik op zoek naar een beschijvingstaal voor 3D scènes.

In de verschillende referenties die ik doorzocht heb, ben ik al reeds op SDL (Scene Description Language) en GML (Geography Markup Language) gestoten, hoewel die laatste me niet echt geschikt lijkt...

Bestaat er een standaard hierin, die ondersteunt wordt door de verschillende 3D modelleringsprog's (zoals 3DS Max, Maya, Blender, enz...). Op die manier kan ik makkelijk kleine test scènes bouwen, en die dan op die manier 'doorgegeven' naar mijn toekomstige ray tracer (die overigens in Haskell zal geschreven worden).

[6K]

Ik zou het nog niet bijna weten, maar misschien dat Oogst je de goede kant op kan helpen

hij heeft nl. ook ziets gedaan <klik>

[ Voor 38% gewijzigd door 6K op 16-07-2004 14:21 ]

[Qylos]

6K schreef op 16 juli 2004 @ 14:20:
Ik zou het nog niet bijna weten, maar misschien dat Oogst je de goede kant op kan helpen

Correct, Oogst heeft zijn eigen Raytracer geschreven. Hij is in staat jou verder te helpen. Helaas is hij op dit moment niet aanwezig op dit forum.

[ Voor 11% gewijzigd door Qylos op 16-07-2004 14:23 ]

[Boegel]

6K schreef op 16 juli 2004 @ 14:20:
Ik zou het nog niet bijna weten, maar misschien dat Oogst je de goede kant op kan helpen

hij heeft nl. ook ziets gedaan <klik>

Weet ik, heb hem zelfs al gemaild ivm zijn projectje

Misschien hebben meerdere mensen hier ervaring mee, vandaar dat ik gewoon effe een nieuw draadje maak... Als Oogst tips heeft, post ie ze wel

Qylos schreef op 16 juli 2004 @ 14:23:
[...]

Correct, Oogst heeft zijn eigen Raytracer geschreven. Hij is in staat jou verder te helpen. Helaas is hij op dit moment niet aanwezig op dit forum.

Eigenlijk is dit veel ruimer dan raytracing eh... Het gaat eigenlijk over de manier waarop 3D modelleringsprog's hun boel opslaan (of een bepaalde universele mogelijkheid daartoe)

[ Voor 42% gewijzigd door Boegel op 16-07-2004 14:27 ]

[Verwijderd]

Op deze site vindt je veel beschrijvingen van diverse o.a 3D bestands-formaten
http://www.wotsit.org/


Ik gebruikte vroeger .ase later het .obj formaat.
Meestal een model maken in 3D-max, en dan exporteren naar een
bepaald formaat, deze kon ik dan weer inlezen in mijn eigen software.

processing .obj testje +source (java-alert)
http://www.xs4all.nl/~elout/proce55ing/meshtest04/index.html

[rashmatash]

Misschien kun je Renderman gebruiken. Dat is een taal ontwikkeld door Pixar om scenes te beschrijven. Kijk op www.Pixar.com of daar specificaties staan. ze moeten ergens te vinden zijn. Er zijn ook nog boeken over deze 3d taal.

EDIT: https://renderman.pixar.com/products/rispec/index.htm

EDIT2: Ik geloof dat als je Maya hebt met Renderman plug-in, dat je dan een scene kunt exporteren in Renderman formaat.

[ Voor 31% gewijzigd door rashmatash op 16-07-2004 16:36 ]

[Boegel]

rashmatash schreef op 16 juli 2004 @ 16:22:
Misschien kun je Renderman gebruiken. Dat is een taal ontwikkeld door Pixar om scenes te beschrijven. Kijk op www.Pixar.com of daar specificaties staan. ze moeten ergens te vinden zijn. Er zijn ook nog boeken over deze 3d taal.

EDIT: https://renderman.pixar.com/products/rispec/index.htm

EDIT2: Ik geloof dat als je Maya hebt met Renderman plug-in, dat je dan een scene kunt exporteren in Renderman formaat.

Allemaal mooi, maar ik vraag me af of het de moeite is om me in te werken in RenderMan als ik enkel vrij simpele scenes wil beschrijven... Zijnde bollen, vlakken, kubussen en dan met reflactie en refractie enzow werken...
Ingewikkelde meshes kom ik wsl niet eens aan, dus of RenderMan dan loont

Obj-files lijken me nog het best van allemaal geloofk... Ik zal er me verder in verdiepen, maar meer tips zijn welkom

edit: Na even de specificaties van het obj-formaat en RenderMan te hebben bekeken, moet ik vaststellen dat obj helemaal niet is wat ik zoek, en dat RenderMan er nogal ingewikkeld uitziet voor mijn doel...

All rendering programs which implement the RenderMan interface must:

- provide the complete hierarchical graphics state, including the attribute and transformation stacks and the active light list.

- perform orthographic and perspective viewing transformations

- perform depth-based hidden-surface elimination

- perform pixel filtering and antialiasing

- perform gamma correction and dithering before quantization

...

Dat is allemaal wat teveel van het goede... Ik wil niet vasthangen aan een interface om mijn raytracer te bouwen, ik wil zelf beslissen welke en wanneer ik bepaalde features invoer...

Verder zoeken dus... Nog iemand tips ?

[ Voor 33% gewijzigd door Boegel op 16-07-2004 19:37 ]

[rashmatash]

Boegel schreef op 16 juli 2004 @ 17:57:
[...]


Allemaal mooi, maar ik vraag me af of het de moeite is om me in te werken in RenderMan als ik enkel vrij simpele scenes wil beschrijven... Zijnde bollen, vlakken, kubussen en dan met reflactie en refractie enzow werken...
Ingewikkelde meshes kom ik wsl niet eens aan, dus of RenderMan dan loont


[...]


Dat is allemaal wat teveel van het goede... Ik wil niet vasthangen aan een interface om mijn raytracer te bouwen, ik wil zelf beslissen welke en wanneer ik bepaalde features invoer...

Verder zoeken dus... Nog iemand tips ?

heb je wel eens van POV-Ray gehoord?
http://www.povray.org/documentation/
het voordeel hiervan is dat het opensource is, dus je kunt zat spieken (er is niks mis met spieken natuurlijk, want in dit geval kun je daar niks mee als je de theorie en achter de code niet snapt en als je dat zelf wel kunt implementeren dan snap je het wel en dat is het doel, toch? maar dat is een andere discussie)

[Oogst]

Hmm, ik denk dat wat jij zoekt niet bestaat. De meest universele file-format die je gaat vinden is waarschijnlijk .3ds, ook al is die ondertussen alweer zwaar verstuurt. Vrijwel ieder programma kan dat openen. Probleem van .3ds is dat die alleen polygonen opslaat en niet andere soorten geometry. Wanneer je een raytracer schrijft zul je waarschijnlijk eerst dingen ondersteunen zoals perfecte wiskundige bollen en dat kun je met .3ds bij mijn weten niet opschrijven.

Enige andere taal die echt universeel is kan ik niet bedenken. Er zijn wel een boel vrij algemene talen, zoals eentje voor NURBS (kben de naam ff kwijt) en een notepad-taal (waarvan ik ook ff de naam kwijt ben). Je kunt ook voor XML gaan, dat is wel lekker universeel, maar dan moet je in XML wel weer je eigen taal gaan definiëren, dus eigenlijk ook weer helemaal niet universeel.

In mijn eigen raytracer is een scene-beschrijvingstaal het eerstvolgende dat ik wil gaan doen, maar ik moet nog zien hoe ik dat aanpak. Ik ondersteun momenteel alleen triangles, dus dat komt meteen mooi uit. Voor de settings maak ik dan simpele .txt-files aan, dus scene en settings gescheiden. Of misschien schrijf ik wel mijn eigen beschrijvingstaal.

Ow, nog iets dat misschien nuttig is voor je: de winged edge datastructuur. Alleen voor polygonen, maar daarvoor ook wel weer erg handig.

[Boegel]

rashmatash schreef op 16 juli 2004 @ 19:58:
[...]


heb je wel eens van POV-Ray gehoord?
http://www.povray.org/documentation/
het voordeel hiervan is dat het opensource is, dus je kunt zat spieken (er is niks mis met spieken natuurlijk, want in dit geval kun je daar niks mee als je de theorie en achter de code niet snapt en als je dat zelf wel kunt implementeren dan snap je het wel en dat is het doel, toch? maar dat is een andere discussie)

Daar ben ik op terecht gekomen bij het zoeken naar SDL... Dat is blijkbaar de scene specificatie taal voor POV-Ray, en lijkt me dus uitermate geschikt voor mijn raytracer... Ondertussen kan ik in POV-Ray kijken hoe de scenes er moeten uitzien met een deftige raytracer, en kan ik idd ook de code even bekijken om snelle implementatie-methodes enzo te bekijken...
http://www.povray.org/documentation/view/3.6.0/47/
http://www.donovansweb.com/~chaffe/quickref.html

@Oogst, met die SDL van POV-Ray kan je dus wel perfect bollen enzo beschrijven, wat idd nodig is voor een raytracer... Ik had ook al gedacht aan XML, maar dan moet je idd zelf een structuur in elkaar botsen, en ik zou het erg vreemd vinden moest er geen 'universeel' formaat bestaan hebben...

90% kans dat het SDL wordt dus, maar nu heb ik effe geen tijd om me er in te verdiepen, dat zal in het beste geval voor zondagavond ofzo zijn...

Thx aan iedereen die al tips gegeven heeft

edit: linkjes erbij, altijd handig voor mensjes die ook info hierover zoeken...

[ Voor 8% gewijzigd door Boegel op 16-07-2004 23:08 ]

[Boegel]

Kickje...

ik begin nu ernstig te twijfelen of ik wel met SDL (of een andere beschrijving) ga werken...
Het is allemaal nog omslachtig, vooral omdat er eerst een parser moet geschreven worden die alle info uit de SDL beschrijving haalt... Daarbij moet ik vast rekening houden met typo's, keywords, numerieke data enz...
Dat lijkt me nogal omslachtig voor een simpele raytracer...

Zijn er mensen die suggesties hebben ? Ik ben nu van plan om de nodige data gewoon via de commandlijn op te geven, niet echt gebruiksvriendelijk, maar een parser schrijven is nogal veel werk naar mijn idee..

[Oogst]

Een parser zul je toch wel moeten schrijven, het is alleen een kwestie of die parser simpel of ingewikkeld moet zijn.

En die taal van POVray is heel leuk, maar POVray doet geen polygonen. Daarom vind ik POVray ook zo'n prutprogramma. Maar misschien dat de taal wel polygonen toestaat, dan heb je er nog wel wat aan. In de praktijk wordt namelijk ongeveer 99% van alle 3d-modelling met polygonen gedaan, dus zo'n progje als POVray is echt alleen voor wetenschappelijk doeleinden interessant.

[Boegel]

Oogst schreef op 28 juli 2004 @ 13:47:
Een parser zul je toch wel moeten schrijven, het is alleen een kwestie of die parser simpel of ingewikkeld moet zijn.

En die taal van POVray is heel leuk, maar POVray doet geen polygonen. Daarom vind ik POVray ook zo'n prutprogramma. Maar misschien dat de taal wel polygonen toestaat, dan heb je er nog wel wat aan. In de praktijk wordt namelijk ongeveer 99% van alle 3d-modelling met polygonen gedaan, dus zo'n progje als POVray is echt alleen voor wetenschappelijk doeleinden interessant.

Mijn doel is ook 'wetenschappelijk' (eindwerk aan unief).

Het is niet de bedoeling om mij Ray Tracer te doen werken met een 3D-modelleringsprog, maar een eerste idee was om mbv een 3D prog simpel scenes te kunnen bouwen om te kunnen testen... Nu weet ik al dat er een vrij groot onderscheid is tussen polygonen en bollen... De laatste manier is makkelijker voor mij om mee te werken, dus is de POVRay taal voor mij iets handiger

Echter die parser schrijven zie ik niet echt zitten, ik heb het gevoel dat ik daar meer werk aan ga besteden dan aan de eigenlijke ray tracer

[Oogst]

De beschrijvingstaal van POVray is helemaal niet zo ingewikkeld hoor. Tenminste, je moet natuurlijk niet alle features van POVray willen inbouwen, en gewoon kiezen wat je wilt doen. Een vriend van mij heeft dat ook voor zijn raytracer gebruikt en die was daar zo mee klaar. En die was toen net tweedejaars informatica, dus dat mag voor een eindwerkstuk voor de universiteit geen probleem zijn.

Bedenk je trouwens wel dat POVray geen modeller bevat. POVray scenes maak je gewoon in notepad. Er is geloof ik wel ergens een modeller voor verkrijgbaar, Moray of zoiets, maar die heb ik nooit gebruikt.

[Boegel]

Oogst schreef op 28 juli 2004 @ 14:01:
De beschrijvingstaal van POVray is helemaal niet zo ingewikkeld hoor. Tenminste, je moet natuurlijk niet alle features van POVray willen inbouwen, en gewoon kiezen wat je wilt doen. Een vriend van mij heeft dat ook voor zijn raytracer gebruikt en die was daar zo mee klaar. En die was toen net tweedejaars informatica, dus dat mag voor een eindwerkstuk voor de universiteit geen probleem zijn.

Bedenk je trouwens wel dat POVray geen modeller bevat. POVray scenes maak je gewoon in notepad. Er is geloof ik wel ergens een modeller voor verkrijgbaar, Moray of zoiets, maar die heb ik nooit gebruikt.

Ik weet dat POVRay geen modeller bevat, maar het voordeel dat het gebruik maakt van geometrische vormen ipv polygonen is belangrijker dan een modeller (het worden tenslotte ook geen volledige steden die ik wil raytracen)...
Die 3rd party modeller zoek ik even op, klinkt wel handig... Grafisch is altijd makkelijker dan zitten 'klooien' in notepad eh

[edit] http://www.stmuc.com/moray/index.html
Ziet er zeer handig uit, thx voor de tip

[ Voor 6% gewijzigd door Boegel op 28-07-2004 14:15 ]

[Oogst]

Gewoon nieuwsgierig: wat wordt je onderzoeksvraag?

[Boegel]

Oogst schreef op 28 juli 2004 @ 15:49:
Gewoon nieuwsgierig: wat wordt je onderzoeksvraag?

Onderzoeksvraag

Het doel van mijn eindwerk (als je dat bedoelt) is nagaan in hoeverre een functionele taal (eerst theoretisch, dan in Haskell) zich leent tot het schrijven van een grafische (ray tracer) applicatie, en welke nadelen, voordelen, tekortkomingen, bijzonderheden enz daarbij naar voor komen...
Misschien komt er ook een stukje GUI ontwerp bij, maar dat is een stuk lastiger in een functionele taal als Haskell. Zie http://gathering.tweakers.net/forum/list_messages/937451

[Boegel]

Sommige mensen zullen waarschijnlijk geinteresseerd zijn of ik hiermee reeds resultaten behaald heb...
Dat is zo, maar dan voorlopig zonder een parser... Ik hardcode de (vrij eenvoudige) scenes bij het testen, maar ben wel van plan om een noge een eenvoudige parser te maken, die een subset van de POVRay beschrijvingstaal ondersteunt...

Omdat ik geen crosspost wil doen, plaats ik de link maar in 1 topic (het andere ging over een ander aspect, maar op den duur loopt dit toch op hetzelfde uit, daarmee)...

Link naar het topic:

http://gathering.tweakers.net/forum/list_message/21969924/2/