Here’s the situation:
I’m in art&&code in Pittsburgh (the awesome kinect hacking conference organised by golan levin)
there’s a tonne of people coming tomorrow and i want to demo some amazing things in vvvv
but right now i’m stuck on 1 thing:
making a mesh out of depth data because I can’t tex2dlod on my ATI graphics card.
Now there’s a few ways around this:
Get the guys here tweeting for people to bring an NVidia card
Try to create the mesh in plugin
It’s too slow to build the mesh outside of a plugin
So if we go with option 2. We can start with
protected override Mesh CreateMesh(Device device)
FLogger.Log(LogType.Debug, "Creating Mesh...");
return Mesh.CreateSphere(device, 1, 32, 32);
//return Mesh.FromFile(device, FFilename, MeshFlags.Dynamic);
//this method gets called, when Update() was called in evaluate,
//or a graphics device asks for its mesh, here you can alter the data of the mesh
protected override void UpdateMesh(Mesh mesh)
//do something with the mesh data
var vertices = mesh.LockVertexBuffer(LockFlags.None);
for (int i = 0; i < mesh.VertexCount; i++)
//get the vertex content
var pos = vertices.Read<Vector3>();
var norm = vertices.Read<Vector3>();
pos.X = (float)xyz[i](i).x;
pos.Y = (float)xyz[i](i).y;
pos.Z = (float)xyz[i](i).z;
//to write the data move the stream position back!
vertices.Position -= mesh.BytesPerVertex;
I can’t initialise a sphere with res 640,480 (i get an exception)
There doesn’t appear to be a method to create a simple grid patch.
hei elliot, can you elaborate on what you’re trying to do here?
i’d guess you want a highres grid that you displace by the depth of a texture? you’d do that with tex2dlod in the VS but it doesn’t work. then isn’t there an error? don’t have an ati-card around to test atm.
and in the alternative approach what would the sphere be for? some more words please…
the alternative approach would be to displace the vertices directly on the mesh
This approach is fine performance-wise on VBO’s in openFrameworks. But I’m not sure if we’re doing something equivalent in the above approach (i.e. whether we can update 640*480 vertices per frame)
the idea of the above is to work around not being able to displace in the vertex shader (if vs3 worked here, then could use a grid ex9.geometry)
will try more with vs. if it’s supposed to work then a few tweaks will possibly fix the issue
couldn’t get 640x320 as a grid either. i’m stuck somewhere at 182x182.
i wonder if its something about the indexbuffer in slimdx which is of type short. theoretically that could be a limit on how highres a mesh can get. though the native grid doesn’t seem to have any problem with that.
but distorting the grid even via plugin is no fun at those spreadcounts anyways.
have a try if you want.
the reason for that constraint is that the mesh primitives only use 16bit index buffers. not sure if that can be changed. when you create your own grid-mesh based on vertex and indexbuffer you can use 32bit indexbuffers and then go to a resolution of 640x480 as vvvvs Grid (EX9.Geometry) can.