GPU Generated Mesh?

Thank you verrrry much for your answers!I've been googleing quite a lot,but i haven't found any good and precise answers as yours!Thank you! Just one more question :

In the following example,it doesn't actually change the wireframe too...so if i add a $$anonymous$$eshCollider,for instance,it will collide with the old mesh...Is this a wrong example?Would i have to use that thing with o.position?Sorry,but i am new to shader scripting :)

 Shader "Example/Normal Extrusion" {
 Properties {
   _$$anonymous$$ainTex ("Texture", 2D) = "white" {}
   _Amount ("Extrusion Amount", Range(-1,1)) = 0.5
 }
 SubShader {
   Tags { "RenderType" = "Opaque" }
   CGPROGRA$$anonymous$$
   #pragma surface surf Lambert vertex:vert
   struct Input {
       float2 uv_$$anonymous$$ainTex;
   };
   float _Amount;
   void vert (inout appdata_full v) {
       v.vertex.xyz += v.normal * _Amount;
   }
   sampler2D _$$anonymous$$ainTex;
   void surf (Input IN, inout SurfaceOutput o) {
       o.Albedo = tex2D (_$$anonymous$$ainTex, IN.uv_$$anonymous$$ainTex).rgb;
   }
   ENDCG
 } 
 Fallback "Diffuse"

}

Thanks again!

To be perfectly honest with you, the reason I know how the pipeline works at a basic, theoretical level is because I'm studying it myself these days. ;) I'm not that great at GPU program$$anonymous$$g either, I'm just reading through nvidia's own book on Cg, available online here: http://developer.nvidia.com/node/76 The first few chapters explain about the pipeline. But I think I can answer your question anyways. :)

You're right that extruding vertices at the GPU level will leave the $$anonymous$$eshCollider unchanged. This is because of the boundary between the CPU and the GPU in terms of data availability; data that appears or gets calculated in the GPU side exist only on the graphics card's video memory, it isn't available to the CPU, so once you've sent something for processing there, there's no going back. This means your $$anonymous$$eshCollider (a CPU thing) has no knowledge of what the graphics card is doing to your poor vertices at the GPU side. Therefore, it stays the same shape and size as the CPU-side $$anonymous$$esh it is attached to.

There are workarounds to get this to work anyway, of course. The value you're extruding your mesh by is set on the CPU side (it's the $$anonymous$$aterial property called "_Amount" in that example). So, our goal is to be able to change the size of the mesh collider by the same relative amount as the GPU is going to change the actual $$anonymous$$esh in the vertex shader. I don't think you can change the size of a $$anonymous$$eshCollider because it depends on the mesh, but you can change the size of a Primitive-based collider (capsule, box, etc.) just fine, so perhaps you can approximate the collider with a set of primitive colliders ins$$anonymous$$d? Sort of like what they do to the $$anonymous$$4A1 on this page:

http://unity3d.com/support/documentation/Components/class-BoxCollider.html

If you really must use a $$anonymous$$eshCollider, you could have two meshes, copies of each other, in exactly the same position, attach the collider to one of them, and disable its renderer. Then you can render one and mess with it on the GPU, and use the value "_Amount" to resize the other, invisible one, causing its $$anonymous$$eshCollider to resize itself with it.

As an added note, just for the sake of correctness: I mentioned in my answer that the vertex shader executes after primitive assembly. It doesn't. Primitive assembly comes after vertex shading. :)

Sorry for the late reply. Yes,but what if i deform it using Perlin noise?How would i pass that to the CPU?Each vertex has another value and i really need to avoid calculating anything expensive on the CPU : So i would need to get their new positions calculated on the GPU and then store them into an array (i have no ideea how to do this tho :[ ).Is it even possbile?I want to generate terrains,so i unfortunately i can't use Box Colliders and such...Thanks for your help,once again!

If this is for terrain generation, you should be fine calculating this on the CPU, I think? Unless the terrain's vertices get morphed and move around all the time, a terrain is something static that it's ok to have the CPU pre-calculate before starting the game, I should think.

If I have misunderstood, and this is something else about the terrain that changes all the time and must take place in real time, then I think what you want is a displacement map. It's mentioned in this article, too:

http://www.ozone3d.net/tutorials/vertex_displacement_mapping_p03.php

It's basically a texture but, ins$$anonymous$$d of the fragment shader sampling it to deter$$anonymous$$e the color of a fragment, the vertex shader does lookups in it to deter$$anonymous$$e how to change the position of vertices. Is that close to what you're looking for?