Artoolkit tutorial español how to#
The next question is how to get Unity's complier to accept "unsafe" code.Ĭ:\Program Files\Unity\Editor\Data\amework\compile_any.pl Casting a C prepared byte array - to a Colors array! Is that even possible? In C/C++ you can always ensure how every bit of every byte is structured.
You'd have to reverse engineer the internal structure of the Color array - or make some eduacted assumptions and test such - and I'm not sure C# would be happy about it anyway. Now if your data was already an array of Color structs one could (maybe) pass that directly into setPixels. So the bottleneck is in how to populate the array of Colors.
Artoolkit tutorial español update#
But if I try to populate every element of the Colors array during every update call then the fps drops right down to around 20 fps. If I prerender a 1024 x 1024 array of Colors in Startup, I can send this to the GPU, on every update, at about 75 fps. However I didn't find that was the bottleneck. With respect to getting data from the CPU to the GPU - I don't know any other way within the framework of Unity. I'm just using ARToolkit's builtin camera capture (referenced in SimpleTest by "dataPtr" - a single dimensional array of 4 bytes per pixel. something equivalent to:Īn extra mutiiplication and addition per pixel! Plus the loop iterators for generating x and y in the first place:Īnd when you go back to how your original data was obtained in the first place. One should expect this since a loop around setPixel involves the overhead (per pixel) of a function call that, apart from anything else, must calculate an address from the supplied x and y, ie. When I compare the rate difference between setPixel and setPixels there is a significant difference.
0 kommentar(er)
