NURBSs zijn in principe gewoon wiskundige definities van lijnen en de vlakken ertussen. als er in de viewports van een 3d pakket een nurbspatch met trims e.d. getessellate en gerenderd kan worden dan zullen daar ongetwijfelt al demos van zijn waarin NURBS kunnen worden gerenderd. Het tesselaten van de NURBSs en dan de polies renderen zal het probleem dus ook niet zijn.
Wat denk ik wel een probleem zal worden zal het verkrijgen van texture-coordinates zijn. Als je als vereiste meegeeft dat iedere aptch zich tussen 0 en 1 bevind in de UV space en deze (wanneer ongetrimt) 100% benut lijkt het haalbaar, maar dan zit je met distortion in je maps. Je artist moet dan tijdens het painten rekening houden met distortion in de patch en voor iedere pixel inschatten/berekenen met welke distortion deze gepaint moet worden om de distortion in het model te compenseren. Tenzij die een 3dpaint programma gebruikt die NURBS verstaat. Photoshop CS4 extended kan dit in ieder geval prima met
polies, ik zie een vergelijkbare interface die met NURBSs zou kunnen werken om binnen redelijk tijd iets toonbaars te krijgen.
Dan nog kun je de map alleen op de getessellate versie van het model toepassen en moet je dus per tessellation een andere map gaan bouwen omdat anders je UVs niet meer bij de vertices passen en dus je map allerlei vage distortion krijgt. Als je dan verschillende hoeveelheden van details tessellate in je 3d programma en die apart unwrapped heb je dus in principe hetzelfde resultaat. Maar dat bestaat al en heet level of detail (LOD). Meerdere resoluties van hetzelfde model gebruikt voor verschillende afstanden.
Als je een NURBS model hebt zonder de verticees (want die hebben NURBSs helemaal niet) word het moeilijk om je UVs ergens aan te koppelen. Je zou dan alles wat normaal een diffusemap zou zijn in-cut moeten maken, iets dat je polycount astronomisch maakt bij een keer tesselaten. Bedenk dan dat je misschien ook 2/3 maps per patch zou willen.
Wat ook zou kunnen is zorgen dat de patch lay-out zo is opgezet dat alle patches zo goed als vierkant zijn, allemaal de de UV-space 100% gebruiken en ieder een eigen map meegeven. Soort van alsof je met tiles werkt. Dan zou het best wel eens kunnen werken omdat de positie van verticees in de getesselate patch makkelijk te berekenen zouden zijn.
Zelf denk ik dus niet dat een NURBS-based game-engine op korte termijn zal verscheinen. Als hij er komt dan zal het een nieuwe techniek zijn waarin de patches niet worden omgezet in polies. Verder zou het waarschijnlijk een raytracer zijn (o.a. ivm de ongelimiteerde normals van NURBSs en het gebrek aan triangles) en zou het dus gebruik maken van openGL noch Direct3D. Daarmee kun je misschien heel de tessalation-stap omzeilen omdat je op basis van de hoek waarop de ray van 1 pixel een surface-point raakt de kleuren bepaald die de lichtstraal uiteindelijk aan de pixel meegeeft. De polycount van je scene is dan dus 0 en de zwaarte van de scene of object hangt van af van vooral het aantal te renderen pixel en de complexiteit van de patches. Als je dan je maps in vector images kan maken (eps, ai, dwg) kun je ook de kleur van die pixel zeer exact berekenen. In principe heb je dan een ongelimiteerde resolutie voor zowel je model als je map. Dat willen we wel graag denk ik

.
Misschien als het volledig op de grafische kaart draait in cuda b.v. en je per patch per map een core aan de slag kunt zetten is het over een paar jaar wel op 30 fps te renderen. Het plannen van patch-layouts word dan wel uberbelangrijk.
Dus nee, ik denk niet dat hardware-tesselation een bijdrage levert aan het realtime renderen van NURBSs voor in games vanwege problemen met het texturen ervan.
jezus wat een verhaal. leuk om over na te denken, dat wel

.
[Reactie gewijzigd door ErwinPeters op 24 juli 2024 18:35]