Ik heb nu ook de machines voor de armen, die staan helemaal onderaan:

En
in het groot.
Hopelijk komt er vanavond een filmpje dat laat zien hoe de onderdelen eerst in de juiste vorm gegoten worden voor ze er op gezet worden. Daarvoor is deze pic te klein, maar het is dus even renderen.
Nog te doen:
-machine voor het linker been;
-machine voor het rechter been;
-machine voor het middel;
-machine die hoofden aanneemt en er op zet;
-animatie van het mannetje terwijl het wegloopt;
-alles zo linken dat met het verplaatsen, draaien en scalen van het hoofdplatform ALLES netjes meebeweegt, zodat Atgast hem in het museum kan plaatsen.
Het slopen van het mannetje gaat Putjesschepper animeren, zo heb ik van hem begrepen.
inquestos schreef op 25 april 2003 @ 14:20:
Vraag aan
atgast: hoe zit het met
particles. Die kosten bij mijn weten geen polygonen, maar het lijkt me sterk dat daar geen limiet aan zit. En werk je nog aan je museum, of wacht je ermee tot je een goeie schatting van het aantal inzendingen hebt?
Particles kosten wel degelijk gewoon polygonen die gewoon worden aangegeven tijdens het renderen. Maar dit aantal is niet constant en stijgt natuurlijk met het aantal particles. Daarom moet je er dus goed op letten dat de particles op tijd weer verdwijnen.
Maar een algemeen probleem met particles is sowieso dat ze vanaf hun eerste frame berekend worden en dat is dus geen doen op frame 8000, zelfs als er nooit meer dan 10 particles tegelijk aanwezig zijn duurt het extreem lang om op frame 8000 uit te komen. Hier staat wel tegenover dat je dit probleem niet hebt tijdens het bekijken of renderen van een gewone serie frames: van frame 8000 tot 8001 hoeft maar één frame doorgerekend te worden. Dus bij het renderen van frame 8000 tot frame 8100 moet dus één keer de beweging van frame 0 tot 8000 berekend worden, wat lang duurt, daarna kost het geen extra tijd meer. Mijn mening erover is dus dat ze in principe wel gebruikt zouden moeten mogen worden, omdat particles gemakkelijk uitgezet kunnen worden tijdens het animeren en dan pas weer zichtbaar zijn bij het renderen. Maar het is aan Atgast om te beslissen of het mag.
inquestos schreef op 25 April 2003 @ 15:36:
Volgensmij was 't ook maar een programma van 4 kb of iets. Ik heb een keer van zoiets gehoord. Ik heb geen idee waar ik dat zou kunnen instellen, dus als jij 't wel weet zou ik het graag horen
BTW. Zit nu met een probleem.

De animaties moeten constant herhaald worden... Op zich geen probleem, gewoon loopen dacht ik, om de 120 frames. Een deel van de animatie moet om de 120 frames herhaald worden, dus ik dacht, ik voeg een key op frame 119 toe (0 t/m 119= 120 frames), en laat hem loopen.
Kijk ik dan bijvoorbeeld op frame 25 + 120=145, blijkt ie 1 stap achter te lopen op frame 25

. Op frame 25 + 2*120=265 blijkt ie dan 2 stappen achter te lopen op frame 25.
Dus mijn vraag/vragen is nu:
1. Maak ik nu een gruwelijke denkfout, moet de keyframe toch op frame 120, is dit een fout in max, of is het goed zoals het nu is?
2. Kan dit loopen niet makkelijker? Moet nu van elk object aangeven dat de beweging om de 120 frames herhaald moeten worden. Op zich geen probleem, maar als het makkelijker kan...
Ja, hier snap ik MAX ook even niet. Inderdaad moet je frame 120 nemen in plaats van frame 119, ik heb dit vandaag ook zitten testen. Waarschijnlijk legt MAX de eerste frame van de nieuwe cirkel in de loop over de laatste frame van de vorige heen en pakt voor die ene frame het gemiddelde, zoiets. Gek is het in ieder geval wel.
Deze key heb je trouwens altijd nodig en je komt er gemakkelijk aan door een object dat hem nodig heeft te selecteren, naar de betreffende frame te gaan en daar een key toe te voegen, duurt niet lang als je het consequent bij elk object direct doet.
Dit is een rekenonnauwkeurigheid in MAX die helaas niet te omzijlen is (tenminste, niet tot en met MAX 4 en ik heb niks gelezen over veranderingen hierin in MAX 5, dus ik neem aan hierin ook niet). Waarschijnlijk gaat het berekenen hierdoor enorm veel sneller, maar toch jammer.
Overigens is dit bij water niet eens zo heel erg, druppeltjes spatten altijd rond dus het valt niet op.