[java] oo 2d/3d engine commentaar aub

[Alarmnummer]

Voor een opdracht voor school moeten we wat met graphics bezig en ik kan het natuurlijk niet laten om er dan meteen maar iets moois van te maken, zodat mijn docent zo nu en dan ook nog goeie hoop krijgt dat er ook echt mensen zijn die de moeite nemen om iets te ontwerpen.

Ik heb een engine geschreven die verder niet specifiek 3d of 2d is, maar generiek. Verder kan alles erin geparametriseerd worden en was ik voor de werking van 2d maar 3 objecten nodig, en voor 3d was ik 4 objecten nodig (meteen 2 soorten perspectief). Verder is naar mijn mening alles goed oo opgezet alhoewel de code nog wel wat opgeschoond moet worden. (vooral de code van opdr1 en opdr2)

Ik vraag jullie om er even naar te kijken en jullie commentaar te spuwen

http://www.alarmnummer.net/files/graphics.tar.gz

[ Voor 4% gewijzigd door Alarmnummer op 02-12-2002 14:21 ]

[SimplyMe]

sorry hoor
maar als ik je bestand download hou ik alleen maar een rijtje *.java en *.class over
wat moet ik daar dan mee doen.

[Janoz]

Doe eens wat aan je tijd .. Ik wordt hier flink met "time stamp 2002-12-02 19:52:28 is 20604 s in the future" om m'n oren gegooid

[Janoz]

SimplyMe schreef op 02 December 2002 @ 14:08:
sorry hoor
maar als ik je bestand download hou ik alleen maar een rijtje *.java en *.class over
wat moet ik daar dan mee doen.

Wat had je dan verwacht??

[D2k]

SimplyMe schreef op 02 December 2002 @ 14:08:
sorry hoor
maar als ik je bestand download hou ik alleen maar een rijtje *.java en *.class over
wat moet ik daar dan mee doen.

alt-f4 en dan yes

en nooit meer in P&W komen

[whoami]

Janoz schreef op 02 december 2002 @ 14:10:
[nohtml]
[...]
[/nohtml]

Wat had je dan verwacht??

Een UML diagram.

[Janoz]

hmm .. Ik krijg dit:

Dec 2, 2002 2:20:09 PM java.util.prefs.FileSystemPreferences$3 run
WARNING: Could not create system preferences directory. System preferences are unusable.


Maar wel een scherm met een leuk draaiende dobbelsteen .. Nu nog ff geen tijd om in de sources te kijken .. (En hij sluit ook niet helemaal netjes af waneer ik het window sluit..

[Alarmnummer]

whoami schreef op 02 december 2002 @ 14:13:

[...]


Een UML diagram.

Het is eigelijk niet zo ingewikkeld. Het draait eigelijk om de Structures. Een Structure is een ComposedStructure (bestaat uit andere structures), een TransStructure (een structure waarop een transformatie uitgevoerd kan worden) of een ModelStructure (een structure waarin dus een model zit). En verder is de DefaultStructureToImage wel erg leuk. Oja, en natuurlijk visitors en strategies

[.oisyn]

whoami schreef op 02 December 2002 @ 14:13:
Een UML diagram.

indeed
doe eens een UML diagram, dan laat ik mijn kritisch oog er eens op vallen

.edit: ah bovenstaande reactie stond er net nog niet
al die OO design patterns en dergelijke zorgen natuurlijk wel voor mooie code, maar ze zijn meestal ook behoorlijk funest als het op snelheid aankomt. En dat is nou net een element wat bij computer graphics heel belangrijk is. Bovendien is het niet echt fijn om met getters en setters te werken als het op matrices, vectors en points aankomt (want OOK nog eens een impact heeft op de snelheid). Maar goed, java is in principe een ondergeschikte taal daarvoor aangezien je dat soort objecten niet op de stack kunt alloceren.

Verder zie ik het 'engine' gedeelte niet helemaal terug in je project

[ Voor 60% gewijzigd door .oisyn op 02-12-2002 14:30 ]

[Alarmnummer]

Janoz schreef op 02 december 2002 @ 14:21:
hmm .. Ik krijg dit:

Dec 2, 2002 2:20:09 PM java.util.prefs.FileSystemPreferences$3 run
WARNING: Could not create system preferences directory. System preferences are unusable.


Maar wel een scherm met een leuk draaiende dobbelsteen .. Nu nog ff geen tijd om in de sources te kijken .. (En hij sluit ook niet helemaal netjes af waneer ik het window sluit..

Dat weet ik, die ImageFrame is op dit moment nog een hack omdat ik zo graag even wou testen

[.oisyn]

oh ik kon m trouwens nog niet runnen daar ik een kersverse win XP install heb zonder java

[SimplyMe]

Nee ik verwachte geen UML diagram ook geen mooi grafische vormgegeven interface

ik verwachte eerder een exeutable of iets dergelijk waar mee in in de omgeving kan komen waar over gesproken wordt.
Of iets waar in staat hoe ik hiermee om moet gaan.

oke ik geeft toe ik ben een noob op het gebied van java programmeren.
maar laat mij dan iig weten hoe ik makkelijk deze engine kan bekijken dan wel zichtbaar maken.

[Alarmnummer]

Runnen is is niet interessant. Het gaat om het ontwerp En dan met de nadruk op het oo gedeelte en ik heb me verder dus niet geconcentreerd op performance, alhoewel er wel een zeer fraaie totale matrix vermenigvuldiging optimalisatie in zit (zie DefaultStructureToImage: methode visit(TransStructure s). En verder moeten er ook nog matrix vermenigvuldiging optimalisaties bij Matrix_3_3 en Matrix_4_4 toegevoegd worden ivm het altijd 0 blijven van sommige velden, maar dat is voor het ontwerp niet interessant.

[ Voor 8% gewijzigd door Alarmnummer op 02-12-2002 14:36 ]

[.oisyn]

SimplyMe schreef op 02 december 2002 @ 14:33:
Nee ik verwachte geen UML diagram ook geen mooi grafische vormgegeven interface

ik verwachte eerder een exeutable of iets dergelijk waar mee in in de omgeving kan komen waar over gesproken wordt.
Of iets waar in staat hoe ik hiermee om moet gaan.

oke ik geeft toe ik ben een noob op het gebied van java programmeren.
maar laat mij dan iig weten hoe ik makkelijk deze engine kan bekijken dan wel zichtbaar maken.

uhm ja, blijkbaar heb je niet veel verstand van java als je al niet eens weet hoe je zoiets opstart (hoewel een batchfiletje wel makkelijk was geweest Alarmnummer ). Ik vraag me af hoe je dan commentaar (al dan niet positief) kunt leveren op z'n programma anders dan "dat ziet er goed uit" oid

.edit: damn it Alarmnummer post nou niet steeds vlak voor mij

[ Voor 51% gewijzigd door .oisyn op 02-12-2002 14:36 ]

[whoami]

Alarmnummer schreef op 02 december 2002 @ 14:35:
Runnen is is niet interessant. Het gaat om het ontwerp En dan met de nadruk op het oo gedeelte en ik heb me verder dus niet geconcentreerd op performance, alhoewel er wel een zeer fraaie totale matrix vermenigvuldiging optimalisatie in zit (zie DefaultStructureToImage: methode visit(TransStructure s). En verder moeten er ook nog matrix vermenigvuldiging optimalisaties bij Matrix_3_3 en Matrix_4_4 toegevoegd worden ivm het altijd 0 blijven van sommige velden, maar dat is voor het ontwerp niet interessant.

Tja, een 2D/3D engine waarbij men zich geen zorgen maakte om de performance bij het ontwerp....
Nouja, ik vraag me af op welke manier OO design patterns een negatieve invloed hebben op de performance als je toch al die engine zowiezo OO maakt?

[SimplyMe]

er wordt gevraag of er naar zijn programma gekeken kan worden.

En behalve dat er naar code gekeken wordt
mag er toch ook gekeken worden naar de "front end" als die er al in zit.
Het kan best door er naar tekijekn al gezegd kan worden waar er
misschien een hapering oid in zit

Er wordt iets grafisch gebouw maar ik kan het niet zien
Dus vraag ik hoe moet ik er nou mee aan de gang.
En je hebt gelijk ik heb nog geen programmeer ervaring met java.

[edit]

Heb wel gehoord dat java in OO zeer traag wordt en eigenlijk niet echt geschikd is daarvoor.
Daarom wilde ik je wel alle suc6 wensen met je opdracht op school.

[ Voor 18% gewijzigd door SimplyMe op 02-12-2002 14:44 . Reden: Ontopic ]

[Alarmnummer]

whoami schreef op 02 december 2002 @ 14:38:

[...]


Tja, een 2D/3D engine waarbij men zich geen zorgen maakte om de performance bij het ontwerp....

ach ja.. het is een school opdracht. En ik heb vroeger ook wat 2d/3d dingen gedaan, en het is leuk om daar eens anders naar te kijken. En verder mijn oo kennis weer eens toe te passen op een praktisch probleem (progt de afgelopen tijd niet zoveel).

Nouja, ik vraag me af op welke manier OO design patterns een negatieve invloed hebben op de performance als je toch al die engine zowiezo OO maakt?

Ik denk niet zozeer dat de design pattern een negatieve invloed hebben, maar meer alle getters en setters. En daarnaast het feit dat java arrays ook niet bepaald snel zijn, dus die matrices zijn extreem traag tov zoiets als c.

[.oisyn]

Alarmnummer schreef op 02 December 2002 @ 14:35:
Runnen is is niet interessant. Het gaat om het ontwerp En dan met de nadruk op het oo gedeelte en ik heb me verder dus niet geconcentreerd op performance, alhoewel er wel een zeer fraaie totale matrix vermenigvuldiging optimalisatie in zit (zie DefaultStructureToImage: methode visit(TransStructure s). En verder moeten er ook nog matrix vermenigvuldiging optimalisaties bij Matrix_3_3 en Matrix_4_4 toegevoegd worden ivm het altijd 0 blijven van sommige velden, maar dat is voor het ontwerp niet interessant.

mja, het zou wel handig zijn als je even een diagrammetje maakt en post, dan wordt het ontwerp wel een stuk duidelijker

Heb nog wel wat in je sources gekeken, ik zag daar bijvoorbeeld een PerspectivePointToScreen... dat is over het algemeen iets wat met behulp van een matrix gedaan wordt. Verder begrijp ik niet helemaal hoe nou precies iets op het scherm gezet wordt

[Alarmnummer]

SimplyMe schreef op 02 december 2002 @ 14:43:
er wordt gevraag of er naar zijn programma gekeken kan worden.

En behalve dat er naar code gekeken wordt
mag er toch ook gekeken worden naar de "front end" als die er al in zit.
Het kan best door er naar tekijekn al gezegd kan worden waar er
misschien een hapering oid in zit

Het gaat om het ontwerp en nietzozeer in de specifieke toepassen zoals draaiende dobbelstenen of dansende mannetjes. Je zou daardoor mijn ontwerp ten onrecht goed of slecht kunnen vinden omdat je dus bezighoud met het stuk dat juist niet zo interessant is. Ik hou me veel bezig met oo ontwerp en vind het leuk om er dan ook echt iets leuks van te maken waar ik mijn ideeen een beetje in kwijt kan.

Er wordt iets grafisch gebouw maar ik kan het niet zien
Dus vraag ik hoe moet ik er nou mee aan de gang.
En je hebt gelijk ik heb nog geen programmeer ervaring met java.

Het was eigelijk niet eens de bedoeling dat mensen het zouden draaien

Heb wel gehoord dat java in OO zeer traag wordt en eigenlijk niet echt geschikd is daarvoor.
Daarom wilde ik je wel alle suc6 wensen met je opdracht op school.

Ach ja. Java en graphics zijn niet echt je van het als je het 100% an java overlaat. Maar verder kan je in java wel fijn proggen en die geparametriseerde types die ik nu gebruik geven je een nieuwe dimensie om in te ontwerpen.

[whoami]

SimplyMe schreef op 02 december 2002 @ 14:43:
er wordt gevraag of er naar zijn programma gekeken kan worden.

En behalve dat er naar code gekeken wordt
mag er toch ook gekeken worden naar de "front end" als die er al in zit.
Het kan best door er naar tekijekn al gezegd kan worden waar er
misschien een hapering oid in zit

Als je de source hebt, kan je die compilen en runnen. Dan heb je meteen het programma.

Heb wel gehoord dat java in OO zeer traag wordt en eigenlijk niet echt geschikd is daarvoor.
Daarom wilde ik je wel alle suc6 wensen met je opdracht op school.

In Java is alles OO.

[.oisyn]

Alarmnummer schreef op 02 December 2002 @ 14:43:
Ik denk niet zozeer dat de design pattern een negatieve invloed hebben, maar meer alle getters en setters. En daarnaast het feit dat java arrays ook niet bepaald snel zijn, dus die matrices zijn extreem traag tov zoiets als c.

denk bijvoorbeeld aan het visitor design pattern. Die roept ten eerste voor elk element een methode aan, en ten tweede moet je dus een aparte methode maken die wordt aangeroepen voor elk element. Meestal wil je bepaalde states bijhouden, wat dan niet meer kan in lokale variabele, dus daar moet je dan weer instance variabelen voor gebruiken

Design patterns zorgen meestal wel voor mooie generieke code, maar met een omweg. En die omweg is nou net wat alles ophoudt. Niet per se in pure running time, maar meer ook het ontwerp wat je om moet gooien. Wat je dan krijgt is van die dingen als "het zou handiger zijn als ik vanuit deze methode direct dit kon doen, maar dat kan weer niet door die design pattern"

[ Voor 22% gewijzigd door .oisyn op 02-12-2002 14:53 ]

[whoami]

Alarmnummer schreef op 02 december 2002 @ 14:43:
[...]

Ik denk niet zozeer dat de design pattern een negatieve invloed hebben, maar meer alle getters en setters. En daarnaast het feit dat java arrays ook niet bepaald snel zijn, dus die matrices zijn extreem traag tov zoiets als c.

Dat die getters/setters een negatieve impact hebben op de performance, daar kan ik inkomen.
Tja, die arrays. C/C++ is daar zeer snel omdat die taal geen checks doet op het 'out of bounds' gaan natuurlijk, maar daar kan je nu niet vanonder uit in Java denk ik.

[nohtml]

.oisyn schreef op 02 December 2002 @ 14:46:


mja, het zou wel handig zijn als je even een diagrammetje maakt en post, dan wordt het ontwerp wel een stuk duidelijker

Agrees. * whoami wil ook een diagrammetje zien.

[nohtml]

Alarmnummer schreef op 02 December 2002 @ 14:48:
[...]

Het gaat om het ontwerp en nietzozeer in de specifieke toepassen zoals draaiende dobbelstenen of dansende mannetjes. Je zou daardoor mijn ontwerp ten onrecht goed of slecht kunnen vinden omdat je dus bezighoud met het stuk dat juist niet zo interessant is. Ik hou me veel bezig met oo ontwerp en vind het leuk om er dan ook echt iets leuks van te maken waar ik mijn ideeen een beetje in kwijt kan.

Het was eigelijk niet eens de bedoeling dat mensen het zouden draaien

En ik dacht dat .oisyn gek was....
Jij maakt gewoon programma's gewoon omdat je geilt op het ontwerp. Het is niet eens de bedoeling dat men je programma's draait/gebruikt.
Wat doe je dan met de code als ik vragen mag? Gebruik je die dan als behangpapier oid?

[ Voor 52% gewijzigd door whoami op 02-12-2002 14:54 ]

[Alarmnummer]

Heb nog wel wat in je sources gekeken, ik zag daar bijvoorbeeld een PerspectivePointToScreen... dat is over het algemeen iets wat met behulp van een matrix gedaan wordt.

Dat kan idd ook, maar ik vond een strategy dit keer ook wel grappig. En zeker de duidelijkheid ten goede komen. Verder kan je ook nog zeer eenvoudig camera transofrmaties uitvoeren, door die DefaultStructureToImage even een andere begin matrix mee te geven.

Verder begrijp ik niet helemaal hoe nou precies iets op het scherm gezet wordt

Ik denk dat het komt door die visitor die ik gebruik De interessante class is dus de DefaultStructureToImage, kijk die maar eens goed door. Het is idd een hele andere benadering dan wat ik in de boeken zie (vooral omdat ze daar beetje onhandig omgaan met matrices en ik veel liever werk met complexere boomstructuren met veel relatieve transformaties).

[ Voor 12% gewijzigd door Alarmnummer op 02-12-2002 14:55 ]

[mbravenboer]

whoami: Dat die getters/setters een negatieve impact hebben op de performance, daar kan ik inkomen.

Mwah, dat valt wel mee: getters/setters en andere eenvoudige methoden worden vrijwel allemaal geinlined door de jitter tegenwoordig. Getters en setters hebben daardoor geen serieuze performance gevolgen.

Verder is het enige wat aan Java eigenlijk echt traag is de GUI library. Java zelf kan heel snel zijn en kan bij berekeningen zelfs native implementaties voor schut zetten (zag pas bijvoorbeeld een benchmark van Fibonacci getallen). Helaas ervaren mensen met name GUI libraries en zijn die ervaringen dus slecht.

[.oisyn]

Alarmnummer schreef op 02 december 2002 @ 14:53:
Het is idd een hele andere benadering dan wat ik in de boeken zie (vooral omdat ze daar beetje onhandig omgaan met matrices

daar is een rede voor
Heb je overigens wel eens gekeken naar Java3D? Die heeft een scenegraph structuur die je misschien wel bevalt

[.oisyn]

mbravenboer schreef op 02 December 2002 @ 14:56:
[...]

Mwah, dat valt wel mee: getters/setters en andere eenvoudige methoden worden vrijwel allemaal geinlined door de jitter tegenwoordig. Getters en setters hebben daardoor geen serieuze performance gevolgen.

klopt, ik loop waarschijnlijk ook wel achter met mijn conclusie. Ik had het getest in mijn 3d applet, die toen op JDK 1.1.8 draaide (bovendien van MS zelf als ik me niet vergis). En daar scheelde het dus vrijwel een factor 2 in de framerate

[Alarmnummer]

.oisyn schreef op 02 December 2002 @ 14:59:

[...]

daar is een rede voor

Ik kan me de luxe van langzame graphics veroorloven. Over het algemeen wordt een ontwerp veel complexer (of een wildgroei van hacks) als je daar veel op moet letten. En dat is ook niet de bedoeling voor dat vak.

Heb je overigens wel eens gekeken naar Java3D? Die heeft een scenegraph structuur die je misschien wel bevalt

Ik had zin om zelf iet te ontwerpen en verder mogen we geen gebruik maken van andere api`s. Anders had ik alles wel in opengl gemaakt Maar het kan idd geen kwaad om te kijken naar andere ontwerpen.

[ Voor 5% gewijzigd door Alarmnummer op 02-12-2002 15:02 ]

[.oisyn]

Alarmnummer schreef op 02 december 2002 @ 15:02:
[...]

Ik kan me de luxe van langzame graphics veroorloven. Over het algemeen wordt een ontwerp veel complexer (of een wildgroei van hacks) als je daar veel op moet letten. En dat is ook niet de bedoeling voor dat vak.

valt mee, als je het vaak doet wordt je er handig in, en dat resulteert dan uiteindelijk in mooie doch snelle code

Ik had zin om zelf iet te ontwerpen en verder mogen we geen gebruik maken van andere api`s. Anders had ik alles wel in opengl gemaakt Maar het kan idd geen kwaad om te kijken naar andere ontwerpen.

Ik bedoelde ook puur het ontwerp van die scenegraphs Zo'n scenegraph is een boomstructuur en dat stelt de wereld voor. Elke child heeft de orientatie van z'n parent, met evt. nog een extra transformatie. De camera hangt ook ergens in die boom, dus als je dan wilt weten hoe object X getransformeert moet worden zul je eerst vanuit de camera naar boven moeten lopen tot je bij een parent komt waar object X ook een indirecte child van is, en dan weer naar beneden naar object X. De matrices die je tegenkomt vermenigvuldig je allemaal met elkaar (natuurlijk wel de inverse nemen als je naar boven loopt )
Verder zijn er nog speciale nodes met handige features, zoals de Switch node, waarin je aan kunt vinken welke children wel en welke niet getekend moeten worden.

[Alarmnummer]

.oisyn schreef op 02 December 2002 @ 15:10:
[nohtml]
Ik bedoelde ook puur het ontwerp van die scenegraphs Zo'n scenegraph is een boomstructuur en dat stelt de wereld voor. Elke child heeft de orientatie van z'n parent, met evt. nog een extra transformatie. De camera hangt ook ergens in die boom, dus als je dan wilt weten hoe object X getransformeert moet worden zul je eerst vanuit de camera naar boven moeten lopen tot je bij een parent komt waar object X ook een indirecte child van is, en dan weer naar beneden naar object X. De matrices die je tegenkomt vermenigvuldig je allemaal met elkaar (natuurlijk wel de inverse nemen als je naar boven loopt )

A*(B*C) = (A*B)*C
Doordat matrix vermenigvuldiging associatief is, mag je dat gewoon doen zonder dat je inverses hoeft te bepalen. Alleen met de camera transformatie moet je even goed opletten. En verder heb ik mijn ontwerp net zo opgezet.

Java:

public void visit(TransStructure<M_n_n> s){
        //an extra transformation matrix is going to be applied to the current transformation matrix.
        
        //store the 'lower' transformation (If you are going down again, the original matrix has to be restored)
        M_n_n lowerTrans = _currentTrans;
                
        //because the Matrix multiplication is associative you can calculate the current total
        //transformation matrix in an very efficient way.
        _currentTrans = _currentTrans.multiply(s.getTransMatrix());
            
        //go up: deal with the structure in the TransStructure
        s.getTransformedStructure().accepts(this);
        
        //the original transformation can be restored
        _currentTrans = lowerTrans;
    }

Verder zijn er nog speciale nodes met handige features, zoals de Switch node, waarin je aan kunt vinken welke children wel en welke niet getekend moeten worden.

Dat is idd handig, maar valt buiten het bestek van onze opdracht. Ik zat zelf nog even na te denken over een 'nagloeier' zodat je van die leuke sporen overhoud. Dit kan je ook op verschillende nivo`s inbouwen, maar ik moet eerst dit maar eens afmaken

[ Voor 22% gewijzigd door Alarmnummer op 02-12-2002 15:16 ]

[Verwijderd]

.oisyn schreef op 02 december 2002 @ 14:49:

[...]


denk bijvoorbeeld aan het visitor design pattern. Die roept ten eerste voor elk element een methode aan, en ten tweede moet je dus een aparte methode maken die wordt aangeroepen voor elk element. Meestal wil je bepaalde states bijhouden, wat dan niet meer kan in lokale variabele, dus daar moet je dan weer instance variabelen voor gebruiken

Design patterns zorgen meestal wel voor mooie generieke code, maar met een omweg. En die omweg is nou net wat alles ophoudt. Niet per se in pure running time, maar meer ook het ontwerp wat je om moet gooien. Wat je dan krijgt is van die dingen als "het zou handiger zijn als ik vanuit deze methode direct dit kon doen, maar dat kan weer niet door die design pattern"

Ben het niet helemaal met je eens. In het geval van het visitor pattern boeit het helemaal niet dat je code mooi generiek wordt. Het gaat erom dat je zonder in al je verschillende classes (waar je misschien al niet meer aan mag zitten omdat deze al in teveel systemen gebruikt worden ) te moeten wroeten toch operaties kan toevoegen. Ik moet inderdaad een methode maken voor elk element maar dat kan ik voor die nieuwe operatie dus doen in 1 klasse en hoef hiervoor niet de hele non-uniform object structure aan te passen. Hier is het dus niet een omweg maar juist de tussendoorweg.

Wat ik wel met je eens ben is dat het soms best ingewikkeld kan zijn om bepaalde patterns te combineren, maargoed daar zijn we nou eenmaal programmeur voor, om af en toe ook nog eens iets zelf te verzinnen

[.oisyn]

[nohtml]

Alarmnummer schreef op 02 december 2002 @ 15:15:
[...]

A*(B*C) = (A*B)*C
Doordat matrix vermenigvuldiging associatief is, mag je dat gewoon doen zonder dat je inverses hoeft te bepalen. Alleen met de camera transformatie moet je even goed opletten. En verder heb ik mijn ontwerp net zo opgezet.

ik geloof niet dat je nu begrijpt wat ik bedoel
als je een object X hebt, die in de boom zit als A -> B -> C -> X, dan is de resulterende matrix A * B * C (als je het lefthanded assenstelsel gebruikt iig)

Stel de camera hangt in A -> D -> E. De orientatie van de camera is dan A * D * E. Maar omdat je vanuit de camera kijkt, moet je de wereld draaien met de inverse van A * D * E, oftewel inv (E) * inv (D) * inv (A)
Vervolgens moet je van A naar object X, dus weer A * B * C. Uiteraard vervalt A hier, omdat dat een gezamelijke parent is, dus de uiteindelijke transformatie van object X ten opzichte van je kijkpunt is inv (E) * inv (D) * B * C

jij gaat mij echt niet vertellen hoe matrices werken hoor

[.oisyn]

Verwijderd schreef op 02 December 2002 @ 15:45:
[...]


Ben het niet helemaal met je eens. In het geval van het visitor pattern boeit het helemaal niet dat je code mooi generiek wordt. Het gaat erom dat je zonder in al je verschillende classes (waar je misschien al niet meer aan mag zitten omdat deze al in teveel systemen gebruikt worden ) te moeten wroeten toch operaties kan toevoegen. Ik moet inderdaad een methode maken voor elk element maar dat kan ik voor die nieuwe operatie dus doen in 1 klasse en hoef hiervoor niet de hele non-uniform object structure aan te passen. Hier is het dus niet een omweg maar juist de tussendoorweg.

devtijd != runtijd

[Alarmnummer]

.oisyn schreef op 02 December 2002 @ 14:49:

[...]


denk bijvoorbeeld aan het visitor design pattern. Die roept ten eerste voor elk element een methode aan,

Je bent niet verplicht om een traversal over de hele boom heen te maken hoor. Als je wilt kan je ook gewoon takken skippen.

en ten tweede moet je dus een aparte methode maken die wordt aangeroepen voor elk element.

Die kan je cachen. En ook al cach je hem niet, dan maakt het niet zoveel uit tov de rest van de aangemaakte objecten.

Meestal wil je bepaalde states bijhouden, wat dan niet meer kan in lokale variabele, dus daar moet je dan weer instance variabelen voor gebruiken

Als je dat methode object cached dan zal het je daardoor geen extra tijd kwijt zijn omdat je die instance variablen moet aanmaken. En tov de rest van de instance variable aanroepen maat dit ook niet zoveel uit hoor. Op dit moment is vooral de Matrix de bottleneck.

Design patterns zorgen meestal wel voor mooie generieke code, maar met een omweg. En die omweg is nou net wat alles ophoudt. Niet per se in pure running time, maar meer ook het ontwerp wat je om moet gooien. Wat je dan krijgt is van die dingen als "het zou handiger zijn als ik vanuit deze methode direct dit kon doen, maar dat kan weer niet door die design pattern"

Dan is er denk ik iets mis met je ontwerp. Ik heb er eerlijk gezegd niet vaak last van dat ik ergens niet aan kan komen, en anders moet ik heb ontwerp aanpassen. Ik knoei er niet op los in mijn code.

jij gaat mij echt niet vertellen hoe matrices werken hoor

Damn, en ik net een handleiding voor je typen Maar idd moet je dus opletten bij die camera maar verder heb je er geen last van.

[ Voor 9% gewijzigd door Alarmnummer op 02-12-2002 16:27 ]

[.oisyn]

Alarmnummer schreef op 02 December 2002 @ 16:22:
Damn, en ik net een handleiding voor je typen Maar idd moet je dus opletten bij die camera maar verder heb je er geen last van.

nou, naar beneden in de scenegraph is vervemigvuldigen met de transformatiematrix, en naar boven in de scenegraph is vermenigvuldigen met de inverse van de transformatiematrix. Das dus niet alleen met de camera zo