glad you are back and that you are doing well!
Sounds like a big turning point in your live, wish you all the best for that and that you enjoy that new part of your life a lot!
Well thanks, however I wouldn't be overoptimistic with the new Unity3D version 5.4. There seem to be some very interesting features in it pretty usable for various usecases for universe stuff, but for some of the planetary surface issues we faced here I have doubts that there is something revolutionary new in. But I still have to look into some of the details to figure out how to use this or that best. I've not been putting too much time into this yet, as continouing on a beta version can be a bit anoying. Now as 5.4 went into the final version, I've recently upgraded to 5.4 with my latest project, which is now a third iteration of the prototype I am building from scratch (well, still utilizing lots of the techniques and classes previous built, but I felt it is time to do that to structure the creation of space objects more efficiently). And besides that writing a few blog articles/tutorials so that the next one does not have to go through some of the same pains. I look really forward to rebuilt some of the parts, e.g. the handling of scales and management of multiple objects when it comes to LOD, and make some things more natural (better denser asteroid fields, or placing planets more realistally around sun). We'll see. And, as the new 5.4 features are stable, it now makes sense to use them too.
That would be a huge step forward!! For us here on the forum for our specific procedural planet usecase of course, but I have seen many requests on the Unity3D forum as well. Being able to get GPU data back to CPU would allow to implement many features we are currently blocked. I you find your time and manage to do this, a lot of people would owe you something thats for sure.
Well... I fear that we mght have overrated the MaterialPropertyBlocks a bit. My current impression is, looking what blocks the batching, that MPBs are more meant for a more elegant way to pass the same material properties (textures, buffers, floats, etc) to different objects at once instead to set each one seperately. I hope I am wrong, but that is how it looks to me.
I've been in contact with one of the developers (zeroyao) describing our very specific problem that different buffers break batching. This has been the response.
Firstly I'm sorry that the previously mentioned DrawMeshInstanced API
has been postponed for 5.5. There was some interdependencies to the
other team's work and after we came back from HackWeek it was too late
And for your particular problem I think the best way to do is to set the
big ComputeBuffer and the texture to your shared material, and have
some instanced properties in each MaterialPropertyBlock for reference
different location for the buffer and texture (e.g. a UV offset for the
Currently textures and computebuffers can't be instanced automatically.
Only float values (scalar, vector or matrix) There is this new
TextureArray API you can try out, but some manually texture packing code
is required. ComputeBuffers can never be an array. Use a big combined
buffer and use instanced properties for location as mentioned above.
Hmmm. Sounds reasonable and could work. As you see from his comment, not only the buffers are a problem to batching, different materials such as textures are as well. Anyway maybe there is an opportunity in his suggestion. I have a raw layout of a dynamic management/pooling of multiple shared textures and buffers in my head which I plan to refine and implement in the next couple of weeks.
Besides that implementation I am going to see if the Texture2DArray is a helpful alternative to the atlas and if it helps for batching. Aras had a good talk on that topic here: http://forum.unity3d.com/threads/texture-arrays.392028/
In any case I recommend to have a read on this thread. Its an interesting discussion of users (and Unity members) reporting about GPU instancing and the batching behavior.
Same here, looking forward to some interesting and fun discussions!
EDIT: I finished implementing a "shared RenderTexture" management/pooling. Right now on request of a new RenderTexture, a slot of a configurable larger texture (basically an atlas) is being provided including indivual UV coordinates. If all slots of a shared texture are used a new one is being created in the background. Including house-keeping (use the next free slot and release shared textures again if not used).
The dimensions (or number of slots) of the shared textures in the background are configurable in width and height. E.g. in case you use 256x256 textures for normalmaps, those are being stored for example on a 1024x8192 texture in the background, which means it offers 128 slots.
I have to combine this now with our current GPU/ComputeShadee-based procudural planet/asteroid implemenation. If this basically works (the texturing works with these shared textures and individual UV coordinates), then I'll expand the shared concept to ComputeBuffers too. At that time then, the magical batching should start to work in Unity fingers-crossed