[opengl] rotatie matrices
 

Ik hoop dat er hier iemand is die wat van opengl afweet. mijn probleem is als volgt:

sinds kort heb ik ontdekt hoe ik zelf matrices kan gebruiken om translaties en rotaties uit te voeren in opengl (dus met glmultmatrixf() ipv met glrotatef() en gltranslatef()).
op het moment dat ik nu een simpele kubus om zijn as laat draaien met behulp van die matrices, wordt op de een of andere manier behalve de positie, ook de belichting beinvloed. de belichting veranderd voor die kubus (en alleen die kubus) voortdurend van verzadigings sterkte, terwijl ik de waarden voor de positie en de ambient van mijn lichtbron toch echt niet aanpas.
weet iemand misschien waar dit door komt, en hoe ik het kan verhelpen?
alvast bedankt

ik ben zelf nog niet met belichting bezig maar uit je tekst afgeleid denk ik dat opengl met glrotatef en gltranslatef alleen het object op een andere plaats en in eren andere positie weergeeft maar dat belichting al vantevoren wordt toegevoegd waardoor het licht dus altijd op hetzelfde vlak van je kubus schijnt.
als dit zo is zul je je object handmatig moeten rotaten en verplaatsen en op die nieuwe coordinaten je belichting toepassen

hier een stukje theorie over het handmatig berekenen van rotaties en verplaatsingen (met een voorbeeld in C++ mocht je daarin programeren): http://www.gamedev.net/reference/art...article877.asp

(al is het overigens wel aan te raden om met quads te werken ipv vertices om gimbal lock te voorkomen)

Ik denk dat het daar inderdaad aan ligt. heel vervelend, want ik wilde juist expres niet alle hoekpunten van de kubus opslaan, maar alleen het zwaartepunt en een richting :(. ik zal ze toch maar uitrekenen.
bedankt

met quads werken in plaats van vertices om gimbal lock te voorkomen? wauw, wat een wijze woorden :cool::p weet je wat vertices zijn?

4 vertices per quad, maar wat is gimbal lock?.. googled -> i see. wat ik meestal doe is mijn eigen matrix laden, en hem dan roteren. als de rotaties dan door opengl worden uitgevoerd, krijg je toch niet zoiets als gimbal lock? die matrix kan ik dan met gegenereerde standaard vertices (records met xyz) op de hoekpunten vermenigvuldigen, en die vertices kan ik dan eventueel in een quad-functie invoeren. dat werkt dan toch gewoon?

hehe dat 'ipv vertices' moet daar gewoon niet staan :o
(en ja ik weet wel wat vertices zijn anders gaat het bouwen van een mmo engine niet echt ;) )

dat is dan toch nog geen probleem als je niet de hoekpunten wil opslaan? als je alleen het zwaartepunt en de richting opslaat dan werk je met kubussen van een vaste groote neem ik aan, dus je weet de hoekpunten (staan in je code ergens opgeslagen waarschijnlijk dus), met de richting reken je uit waar ze staan na verdraaiing en dan tel je er nog even het zwaartepunt bij op.

ja goed, maar dan moet ik ze steeds opnieuw uitrekenen :). ach, daar heb je computers voor, is ook :) eerst roteerde ik de matrix dus gewoon rond het zwaartepunt, en tekende dan een kubus. toch goed dat die belichting me er even op wijst dat dat niet goed is :)


edit: een stap verder, bedenk ik me dat ik die punten toch moet genereren voor collision detection. het werkt nu, hartstikke bedankt :)

bedoel je dan ook niet heel toevallig quaternions in plaats van quads? :o:p

hoe ben je tot die eigen matrix gekomen? als dat ook gewoon een vermenigvuldiging is van verschillende rotatie matrices dan heb je precies hetzelfde eindresultaat als wanneer je voor elke rotatie een glRotate() functie gebruikt dus hou je ook de gimbal lock :)

jah ook al :o gaat wel lekker zo met posten :(