- #Artoolkit tutorial unity how to
- #Artoolkit tutorial unity update
- #Artoolkit tutorial unity pro
- #Artoolkit tutorial unity plus
My criticism was simply the way they are sold - not that the feature exists. It should be noted that drag-and-drop plugins are a good feature (if and when they work), and definitely a selling point. Should I laugh or cry?Ĭlick to expand.I think that's exactly what they're doing.
#Artoolkit tutorial unity pro
But it's still bit of a stretch to sell such convenience as "plugins are a Pro only feature". So I guess the only thing the Pro version offers in this respect is just the convenience of it being in a single project specific location where both the editor can find it and from where it will be published. Or I put it in the same folder as the Unity editor executable: The same folder as a published standalone executable. Or if I put it in the other place where DLLs typically become available to their hosts: But if I put the DLL in the System search path (a normal location for DLLs), eg. The Indie version (not surprisingly) doesn't look there. Now I found the only thing stopping my Indie version of Unit圓D accessing a DLL was if I put the DLL where the docs (for the Pro version) say to put it, ie in: Call apply on the texture to copy the Color data to the GPU. Pass the Color reference to texture.SetPixels.Ĥ.
Copy the memory back into managed memory (using Marshalling) where it is now referenced by a Color reference.ģ. Call a DLL function (which has the unmanaged memory pointer) to populate the unmanaged memory with four floats per pixel (which will be very fast).Ģ. Pass the pointer to a DLL, which holds it for future reference.ġ.
Allocate enough unmanaged memory (using Marshalling) to represent an array of Colors, getting back a pointer to such.Ģ. So in relation to performance of an ARToolkit port I'm assuming the following will be pretty fast:ġ. The only way to use unsafe is compile your own dlls - which defeats what I'm doing since I'm working with Unity Indie. Unity no longer supports the use of unsafe. I'll try leaving Unity shut down for a while. Although I closed down Unity and started it up again, it may be that the compiler is temporarily cached (sitting in memory for a little while). My $mcs_path, '-debug', '-unsafe', '-target:library', '-nowarn:0169', '-out:'.$output, ) īUT - having done the above, Unity is still asking me to set the 'unsafe' option.
#Artoolkit tutorial unity 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 unity 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.
#Artoolkit tutorial unity plus
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)
