Stap 6: Three.js: Particle systemen
WebGL en ThreeJS in het verlengde daarvan, zijn groot bij het weergeven van grote en gedetailleerde mazen in 3-ruimte. Dat is wat veel 3D-modellen bestaan uit, en zelfs wanneer modellen zijn nog andere dingen ("stoffen" of "NURBs") ze uiteindelijk aan het uw computerscherm worden weergegeven door eerst worden omgezet in zogenaamde "render mazen".
"Points" niet echt een ding.
Particle systemen zijn in principe een manier voor het beheren van 3-dimensionale mesh geometrie waar u geen zorg over de randen. Als u over de randen van een mesh vergeet, hen onzichtbaar maken en dan een soort van punt-achtige materiaalkwaliteit geven door de snijpunten, hebt u een particle systeem. Particle systemen kunnen u alle punten van een Kabelhoes om afzonderlijk verplaatsen, en kunnen grote voor effecten die meestal als deeltjes weergegeven worden. Ja, u kan een model van een zandloper op deze manier als de individuele deeltjes van zand stroom langs elkaar, maar je kunt ook iets doen zoals wolken, sneeuw, Ja, sterren, gek zelf-organisatieof een Heilige puinhoop. Hoekpunten zijn ook krachtig in andere opzichten. Als u bereid bent om zelf een vertex shader schrijven, is het vrij snel om naar een mooie chroom bal.
Ik eigenlijk niet gebruik particle systemen voor een groot deel, maar threejs maakt het gemakkelijk toe te passen alleen-hoekpunt materialen op particlesystems. Particle systemen gaan hand in hand met particle systeem materialen. Dus in plaats van cubegeometry + materiaal = kubus (van boven), kunnen we zeggen particleSystem + particleSystemMaterial = Object3D, en dat aan de scène toevoegen. Voor meer informatie over deze basisversie adviseer ik de Aerotwist leerprogramma op deeltjes. Uiteindelijk heb ik een iets andere manier gaan: mijn eigen aangepaste gewalste vertex- en fragment shaders.
De JavaScript is ongecompliceerd genoeg:
<script type="x-shader/x-vertex" id="vertexshader"> attribute float alpha; attribute float size; attribute vec3 ca; varying vec3 vColor; varying float vAlpha; void main() { vColor = ca; vAlpha = alpha; vec4 mvPosition = modelViewMatrix * vec4( position, 1.0 ); gl_PointSize = size * (1.0+ 300.0 / length( mvPosition.xyz ) ); gl_Position = projectionMatrix * mvPosition; } </script> <script type="x-shader/x-fragment" id="fragmentshader"> uniform vec3 color; uniform sampler2D texture; varying vec3 vColor; varying float vAlpha; void main() { gl_FragColor = vec4( vColor, vAlpha ); gl_FragColor = vAlpha * texture2D( texture, gl_PointCoord ); } </script> Maar de elementen van het "vertexshader" en "fragmentshader" vermeld zijn WebGL-code uit een buitenaardse planeet:
for (each row) { for (each column) { do something to pixel at (row, column); } } Schrijven van deze code arcering was pijnlijk voor mij, omdat ik niet WebGL weet en nog steeds niet. Wat ik heb geleerd langs de weg, naast enkele kleinigheden die niet nuttig zijn om te delen, was een interessant feit. Ik heb nooit geweten waarom een GPU was nuttig. Tuurlijk, het is goed om te beschikken over een tweede processor. Maar waarom niet twee CPU's? Gewoon omdat een GPU goedkoper is?
Het verschil is parallelle verwerking. Voor een CPU's architectuur te schilderen van elke pixel op het scherm, in feite heeft code die elke pixel in de juiste volgorde doet te hanteren:
// animation loop function update() { // note: three.js includes requestAnimationFrame shim requestAnimationFrame(update); // Move things around as need be: if (interactionHandler.frozen === false) { particleSystemsArray[0].rotation.z -= 0.00008; particleSystemsArray[1].rotation.z += 0.00002; particleSystemsArray[2].rotation.z += 0.00012; particleSystemsArray[3].rotation.z -= 0.00009; particleSystemsArray[4].rotation.z += 0.00016; particleSystemsArray[5].rotation.z -= 0.00005; sky.rotation.z += 0.00015; // rotate the background image too! } // The little tags that travel with stars need to have updated positions interactionHandler.getTagManager().updateActiveTagPositions(); // draw. I'll explain this code later, but you can think of it // for now as renderer.render() _.each(Galaxy.Composers,function(composer){ composer.render(); }); } De GPU-code ziet er anders uit omdat GPU's pixels in parallel, niet in volgorde verwerken. U toepassen een effect op het hele scherm in een keer, en laag-effecten op elkaar. Dit kunt u doen wat echt spannend materiaal met zeer weinig code. Zie postprocessing later voor een voorproefje.
