terrain auf purer shaderbasis?

Posted By: Antitrone

terrain auf purer shaderbasis? - 12/11/03 05:36

ich hab mal so 'n bissel über shader gegrubelt und bei dem kapitel über objekte aus splines in hardware errechenn lassen habe ich mich spontan gefragt ob man nicht vll. einen kompletten satz HMP -texturen. also HMP-bild,detailmaps (und was nach multitekturing noch so dazukommt) nicht einfach alles als mehr oder weniger genaue splines durrechnen lassen könnte und man dann die ganzen ecken im terrain los wäre?.
sry. wegen meinen langen sätzen aber das hab ich von meinem deutschlehrer geerbt.
Posted By: Alexander Esslinger

Re: terrain auf purer shaderbasis? - 12/11/03 21:52

Theoretisch kannst du dein Terrain auch mittels Splines definieren, allerdings müsste der CPU diese immer noch in Vertices und Faces umrechnen. Mittels Vertex-Shader funktioniert das nicht, da man keine neuen Vertices erstellen kann.
Posted By: Antitrone

Re: terrain auf purer shaderbasis? - 12/11/03 22:37

öhh. für was VERTEX wenn man damit keine machen kann - is doch irgendwie schon schwachsinn oder?... dachte mal was von normal maps gehört zu haben , basiert das nicht praktisch komplett darauf? über shader auf seite 5 - high order surface tesselation. da steht doch das die gpu aus splines, vertics und dreiecke macht - also nicht über cpu .- ich meine das splines ja dann in dem fall schöne übergänge haben würden quasi die ganzen terrains ( auch bei niedriger rasterdichte) alle absolut ohne ecken dastehen oder seh ich das jetz falsch?
wenn das hinkommt kann man dann eigentlich in der gpu direkt aus ner bitmap ein terrain erstellen lassen (vll noch mir multitexturing für echte 3d unebenheiten) oder is das nun wirklich aufgabe der cpu?

Posted By: ello

Re: terrain auf purer shaderbasis? - 12/11/03 22:47

vielleicht mittels displacement mapping
Posted By: ventilator

Re: terrain auf purer shaderbasis? - 12/11/03 22:57

marco grubert hat doch mal ein plugin gepostet das high order surface tesselation für ati karten aktiviert hat? ich kann mich nicht mehr genau an den source code erinnern und finde das plugin nicht mehr aber war das nicht einfach nur ein direct3d state der aktiviert werden musste? vielleicht können in 6.2 high order surfaces ohne plugin und individuell für einzelne models / terrains aktiviert werden?
Posted By: Antitrone

Re: terrain auf purer shaderbasis? - 12/12/03 00:29

ist marco gruber der typ von thiny things? - da hab ich nämlich auch erst ne terraindemo gefunden.
ich meine wenn der gesammte terraingenerierungsprozess in gpu abläuft wie stehts dann aber mit der tatsächlichen renderzeit. klar der agp port wird entlastet aber muss die karte nich deshalb trozdem die ganzen dinge rendern oder geht das dann auch schneller?. wenn das nämlich trozdem noch gleich schnell gerendert wird kann man ja auch glei einen shaderinternen optimierungsprozes für entfernte terrainteile machen.

-zum ursprungstopic: eigentlich war der grundgedanke die erstellung von terrains auf der basis einer bitmap (gpu intern)- wenn das nämlich geht öffnet sich mir gerade enite tür zu einer neuen welt.

-mal allgemein. wird eigentlich nen kleinen editro für "nicht programmer" geben?
was kleines um die hirarchie vonm multitextures zu bearbeiten wär schon mal nich schlecht.

-kann man mit shadern eigentlich dann diese klassische texturverzweigung wie in 3dsmax machen? - also eine textur für die bereiche wo ne andere textur hin soll, dann die nadere textur festlege, für die vll noch ne kleine untertextur.usw?

sry wegen den vielen fragen aber mein kopf wird grad von einer wahren flut neuer idee'n gesprengt
Posted By: Phantom88

Re: terrain auf purer shaderbasis? - 12/12/03 01:02

Quote:

ist marco gruber der typ von thiny things?


Nein, Marco Grubert ist von conitec, und arbeitet an 3DGS(Map-compiler, phys-engine)

~Phantom88~
Posted By: Antitrone

Re: terrain auf purer shaderbasis? - 12/12/03 01:16

aso - sry marco
wusst ich ned...
Posted By: ello

Re: terrain auf purer shaderbasis? - 12/12/03 05:02

hallo, das hab ich bei ati gefunden. vielleicht kann ja jemand was damit anfangen(ist englisch):

In Antwort auf:


TRUFORM™ FAQ


If you any questions on the contents of this page, please contact ATI Developer Relations at devrel@ati.com.


What is TRUFORM™?
Is there any research to back this up?
Why should I consider using TRUFORM™ in my game?
How much work does it take to start using TRUFORM™ in my game?
Can I control the order of TRUFORM™ tessellation?
Can I use TRUFORM™ as an extension to my existing LOD techniques?
How can I author art for TRUFORM™?
I've heard that TRUFORM™ is incompatible with skinning. Is this true?
How much does using TRUFORM™ impact my performance?


What is TRUFORM™?

TRUFORM™ is a technology developed by ATI which enables higher-order surface rendering through traditional triangle rendering APIs. In DirectX 8, these surfaces are referred to as N-Patches. In OpenGL, they are referred to as PN Triangles and are accessed through the ATI_pn_triangles extension.
See the TRUFORM White Paper for more details.


Is there any research to back this up?

ATI recently co-authored a paper on this technology with researchers from the University of Florida and Microsoft. This paper, Curved PN Triangles, was presented at the ACM Symposium on Interactive 3D Graphics in March 2001.


Why should I consider using TRUFORM™ in my game?

When a game uses TRUFORM™ to tessellate geometry that should have smooth organic shapes, the silhouettes and lighting of the objects are improved. This is particularly important on characters, whose blocky shapes so often detract from the immersive experience of a game. TRUFORM™ is unique in that the same data and same API entrypoints are used when using TRUFORM™ as when not using TRUFORM™. This means that any application that uses TRUFORM™ is backward compatible with chips that do not render any higher order surfaces (i.e. all previous generations of graphics chips). Additionally, models require little tuning to look good with TRUFORM™, even for a game near completion or already released . Most models "just work." This ease of integration was one of the fundamental goals in the creation of TRUFORM™.


How much work does it take to start using TRUFORM™ in my game?

In terms of visual impact for time spent on the coding, TRUFORM™ is one of the best features you'll ever integrate into your engine. It was designed to be that way from the start.
There are three basic steps to using TRUFORM™ in your game:
Art preparation
Vertex Buffer creation/layout
Rendering

Art Preparation consists of making sure that the triangle-based art that comes out of the end of your art pipeline has crease polygons in the right places. For much of your art, this will "just work." For edges in your models which are defined to be hard edges (by MAX's smoothing groups, for example), you will need to insert crease polygons. We have both a MAX previewer and a sample exporter (with a standalone viewer) that you can look at to see how this can be done for automatically. The TRUFORM™ resources page on our website has these downloads.

Vertex Buffer creation and layout merely consists of making sure that you are passing both positions and normals to the API (Direct3D or OpenGL). This is necessary for TRUFORM™ rendering since the Bézier control mesh is derived from the position and normal information associated with each polygon. In cases where you are currently doing your own lighting in the application and not using the 3D API for lighting, you may not be currently passing normals to the API. You should pass the normals to the API when using TRUFORM™ and let the hardware do the lighting, environment mapping etc on all of the vertices, including the ones generated on-chip by the TRUFORM™ tessellator. In Direct3D, you'll be using either a flexible vertex format (FVF) or a stream declarator (the first parameter to CreateVertexShader()) to define the layout of your vertex buffers and vertex streams. When using a stream declarator, it is necessary to use the D3DVSDE_POSITION and D3DVSDE_NORMAL tokens appropriately when specifying which components of your vertex are the position and normal. Your vertex structures don't have to change; you just have to be specific about where your positions and normals are. There are no restrictions on the data types of the components. For example, you have traditionally used float triples (D3DVSDT_FLOAT3) for normals, but you could use D3DVSDT_SHORT4 and it would work just as well.

Rendering consists of turning on TRUFORM™ and drawing your models. In Direct3D, this means that as long as your vertex buffers are created with the D3DUSAGE_NPATCHES flag and the vertex buffer has positions and normals, you can just draw with the usual DrawPrimitive() entrypoints, setting the D3DRS_PATCHSEGMENTS render state to control the amount of tessellation. Setting D3DRS_PATCHSEGMENTS to 1 means tessellation is essentially off, as each triangle edge has one "segment" by default. Setting D3DRS_PATCHSEGMENTS to 2 means that the triangle has two segments per original edge (or one new vertex per original edge), which results in 4 triangles for every original. In OpenGL, you use the following code: glPNTrianglesiATIX (PN_TRIANGLES_TESSELATION_LEVEL_ATIX, tessLevel). In OpenGL, the numbering scheme for tessellation levels refers to the number of new vertices added along the edge of the original triangle. In this scheme, level 0 refers to no tessellation, level 1 refers to four triangles generated from the original and so on. Also keep in mind that OpenGL also has an explicit gl{En|Dis}able(PN_TRIANGLES_ATIX) for enabling and disabling tessellation.

If your models are prepared for TRUFORM™ tessellation, the only cases in which this is not as simple as flipping bit are if you were previously using a custom software lighting model or environment mapping method that is not expressible in the fixed-function API. In this case, you should use a hardware vertex shader to do the custom lighting on all of the vertices post-tessellation. This will include the ones generated on-chip by the TRUFORM™ tessellator. In DirectX 8.0, N-Patches were exposed via the D3DRS_PATCHSEGMENTS render state. As long as you've created a vertex buffer with the D3DUSAGE_NPATCHES flag and the vertex buffer has positions and normals, you can just draw with the usual DrawPrimitive() entrypoints. By default, you will see cubic interpolation of positions and linear interpolation of normals.


Can I control the order of TRUFORM™ tessellation?

TRUFORM™ supports linear or cubic interpolation of position and linear or quadratic interpolation of normals. In DirectX 8.0, this was hard wired to cubic position and linear normals. In DirectX 8.1, you have more control over the interpolation order of the positions and normals of the generated vertices. Specifically, the new D3DRS_POSITIONORDER and D3DRS_NORMALORDER render states control interpolation order. The position interpolation order can be set to either D3DORDER_LINEAR or D3DORDER_CUBIC. The normal interpolation order can be set to either D3DORDER_LINEAR or D3DORDER_QUADRATIC. In OpenGL, use the following code: glPNTrianglesiATIX (PN_TRIANGLES_POINT_MODE_ATIX, PN_TRIANGLES_POINT_MODE_{LINEAR|CUBIC}_ATIX).


Can I use TRUFORM™ as an extension to my existing LOD techniques?

TRUFORM™ is designed to fit right in with an application's own geometry LOD techniques. Essentially, you can think of TRUFORM™ as a means of providing LOD models beyond those already used in the application.


How can I author art for TRUFORM™?

Since the input to TRUFORM™ is just a triangle mesh, your art pipeline needs very little modification. As mentioned earlier, we have provided a 3DS MAX plug-in which will allow your artists to preview their art with TRUFORM™ tessellation right in a MAX viewport, without ever leaving the tool.



I've heard that TRUFORM™ is incompatible with skinning. Is this true?

A correct statement would be "higher order surfaces are incompatible with matrix palette skinning." Anyone who is saying that their higher order surfaces are compatible with matrix palette skinning is doing a large amount of work on CPU thus negating the bandwidth saving benefits of hardware higher-order surfaces. ATI's TRUFORM™ implementation occurs completely in silicon. Because of the fact that matrix palette indices cannot be interpolated across a polygon in any meaningful way, it is not possible to index into a matrix palette for the newly-generated vertices. This makes higher-order surfaces and matrix palette skinning incompatible. It is possible, however, to use traditional 4 (or more) matrix skinning where the references to the bones is implicit. The downside to this is that the model must be broken down into sub-chunks and rendered in several API calls. In practice, however, we have not found that segmenting a character into chunks is nearly the performance penalty that most game developers believe it to be.



How much does using TRUFORM™ impact my performance?

Often times, graphics chips are fill-rate or memory bandwidth limited. This means that the chip may be capable of more geometry throughput than you ever see, due to the fact that the memory systems simply aren't able to feed the voracious geometry processor. One of the major goals in our creation of TRUFORM™ was to allow you to feed the geometry processor despite memory bandwidth limitations. In this way, you can think of it as a form of geometry compression, like any higher-order surface. Since your low-polygon geometry is what is input to the chip, you keep memory bandwidth low, while increasing geometry detail with TRUFORM™ tessellation just prior to vertex shading. The result of this is that you may see no performance impact at all when using TRUFORM™ tessellation if you weren't limited by the geometry processor's power in the first place.






Posted By: ventilator

Re: terrain auf purer shaderbasis? - 12/12/03 05:12

für mich sieht es so aus als müsste man in einem effekt nur

npatches=true;
patchsegments=<mtlskill1>;

oder sowas einfügen! leider habe ich keine ati karte. hat niemand mehr das plugin von marco? da war source code dabei...
Posted By: ello

Re: terrain auf purer shaderbasis? - 12/12/03 05:33

das hab ich ausprobiert. es kommt zwar keine fehlermeldung, aber es tut sich auch nix.
allerdings hatte ich patchsegments=2 gesetzt und einmal mit 10 . war kein unterschied. aner mit <mtlSkill1> hab ichs noch nicht probiert... kein unterschied
Posted By: Marco_Grubert

Re: terrain auf purer shaderbasis? - 12/13/03 09:59




DLL/source can be downloaded here.

Quote:

öhh. für was VERTEX wenn man damit keine machen kann - is doch irgendwie schon schwachsinn oder?


Noe, urspruenglich waren die Vertex Shader ja mehr fuer Animation gedacht. Man schmeisst ein Standard-MDL rein und laesst dann den Shader neue Koordinaten berechnen. Ich vermute, dass die naechste groessere Version (VS3.0?) Anweisungen enthaelt um Vertices zu erstellen, aber in naher Zukunft ist das nicht moeglich.

Quote:

... dachte mal was von normal maps gehört zu haben , basiert das nicht praktisch komplett darauf?


Nein, aber Displacement Maps erstellen neue Geometrie basierend auf Bitmaps. Das wird allerdings intern in der Karte gemacht und kann nicht per Shader beeinflusst werden (TruForm ist eine Art "Displacement Mapping light")

Quote:

über shader auf seite 5 - high order surface tesselation. da steht doch das die gpu aus splines, vertics und dreiecke macht - also nicht über cpu .- ich meine das splines ja dann in dem fall schöne übergänge haben würden quasi die ganzen terrains ( auch bei niedriger rasterdichte) alle absolut ohne ecken dastehen oder seh ich das jetz falsch?


Einige neue Karten haben interne Spline Tesselation, ist aber noch nicht Standard und ich weiss nicht wie gut DirectX 9 damit zurechtkommt.

Quote:

wenn das hinkommt kann man dann eigentlich in der gpu direkt aus ner bitmap ein terrain erstellen lassen (vll noch mir multitexturing für echte 3d unebenheiten) oder is das nun wirklich aufgabe der cpu?


Ja, sollte in ein paar Jahren funktionieren.

Posted By: ventilator

Re: terrain auf purer shaderbasis? - 12/13/03 21:35

http://www.beyond3d.com/articles/directxnext/

die geplanten features für das unified 4.0 shader model klingen ziemlich vielversprechend!
Posted By: Antitrone

Re: terrain auf purer shaderbasis? - 12/13/03 21:57

danke an alle die mir hier so die einzelheiten erklärenm. ich hab zwar nich so das gefühl das alle durchblicken ( ausnahmen sind wie immer die regel) aber im großen und ganzen regen mich diese shadergeschichten zu immer wahnwitzigeren experimenten an. hab nur kein plan von shadderprogramming- bin eher jemand der sich über die theoretische verfahrenswege gedanken macht um ein ziel zu erreichen. den weg gehen kann ich selber leider nich. noch nicht

@marco: was passiert denn bei normal maps genau? - das ergebnis is ja klar(ein scheinbar perfektes objekt aus relativ bis extrem simplen formen)

kann man also theoretisch mit displacement maps große terrains erstellen die die fps weniger belasten als cpu?. soweit theoretisch ja klar das die grafik stimmt aber 3dgs muss ja doch irgendwie colisionserkennung durführen- kann man irgendwas trickes ( ein ersatzterrain als nur colisionsmodell das nicht gerendert wird und auch nicht über den agp mus?
kann man bei displacementmapping dann auch multitexturing für die displacement map verwenden?

- noch ne gaaaaaaanz große frage. ist es generell (mal von dem terrain abgesehen) möglich die ganzen firlefanzerreien wie sie in terragen auftreten- also dunst,generieret wolken, schattenfarbe, usw. (die allgemeinen möglichkeiten sind ja von bekannt). also das man diese alle als pixelshader niederschreiben kann?- also ne quasi 1zu1 umsetzung von cpu-render in gpu-render.

für weitere antworten bin ich überdankbar
Posted By: Zapan@work

Re: terrain auf purer shaderbasis? - 12/14/03 22:10

Diese displacment maps sind eine tolle sache. Nur ist sowas fuer terrain realtiv unnuetz _wenn_ du auch kollisions erkennung haben moechtest. Wenn das der fall ist, kommst du so oder so nicht drum herum, die vertices des terrains von der cpu berechnen zu lassen -> eben wegen der kollisions erkennung.

Das ist auch der grund, warum die naechste spiele generation auch _nicht_ auf displacment maps setzt, zumindest was _reines_ terrain angeht.
Posted By: Antitrone

Re: terrain auf purer shaderbasis? - 12/14/03 22:46

genau das habe ich befürchtet. naja - imerhin weis ich jetzt das es eine möglichkeit gibt das terrain zu runden. ist doch schon mal ein schritt in die zukunft. -aber für'n echtzeit intro oder ne reine grafikdemo bestimmt mal ganz nützlich
Posted By: ello

Re: terrain auf purer shaderbasis? - 12/19/03 21:52

hey, das hier könnte von interesse sein:
http://www.gamedev.net/reference/articles/article1936.asp
Posted By: Antitrone

Re: terrain auf purer shaderbasis? - 12/21/03 02:18

äuserst interessant...
wenn man jetzt nur zum beispiel hingeht und ne normale HMP nimt mit vll 128x128 und das ganze mit multitexturing macht sieht das ja schon schöhn aus. kann man jetzt auch hingehen und für jede multitextur eine displacement map zuweist.bei ati karten dann vll noch truform rein.dann hätte man ein recht ordentliches terrain das mit vielen kleinen 3d details übersäht ist die nicht auf der cpu lasten und dabei noch eine anehmbare kolierkennung zulassen. ..
soweit die theorie.. kann da jemand vll nen code zu posten und anleitung- bin ja selbst die absolute shader und script hinschreib null. die technik raf ich aber wie man das dann so hinbiegt ist mir zu hoch.

am besten wär ein prog in dem man seine hmp's und detailmaps und alles reinladen kann und sich dann das gleich in realtime anschuen kann. also ein eigener terrain-editor mit so häckchen hinter den sachen für z.b. displacement map, bumpmap... usw. - wenn das connitec nicht so macht kann sich ja vll jemand anders für bereiterklären.das würde das landschaftsnievau in 3dgs produkten um ca. das 10fache verbessern

hat jemand die details von den terrains in project IGI zur hand? die sind doch mehr als perfekt.

also grübelt mal fein brav über weihnachten.
PS: shader sind geil!... ich denk ja bald so oft an shader wie an meine freundin- und an die denk ich sehr oft
PS: PS: kann man das nicht deichseln das die graka von der displacementmap den teil auf dem sich objekte besinden die kolierkennung brauchen einfach an die cpu gibt und die dann berechnet werden. also praktisch ein wandeelndes dreick unter dem player das imemer mit ihm mitläuft , unsichtbar ist, und nur der kolierkennung diehnt ... das grenzt an psychopathismus. gibts aber nicht zufällig auch ne shaderfunktion für oder ?
Posted By: Loetkolben

Re: terrain auf purer shaderbasis? - 05/21/04 08:39

In Antwort auf:





DLL/source can be downloaded here.





hi, marco grubert

bin zufällig über diesen eintrag gestolpert.

kann aber diese nicht downloaden ???.
was brauch ich den da für ein usernamen und password?
das von der a6pro funzt nicht und das vom forum auch nicht.

würde mir mal gerne das anschauen um vieleicht mein programm zu verbessern.
© 2024 lite-C Forums