Asynchronous mesh generation with GCD

cocos2d for iPhone » Programming » cocos3d

Asynchronous mesh generation with GCD

(25 posts) (2 voices)

Started 5 months ago by Virl
Latest reply from Bill Hollings

Tags:

Virl
Member

Greetings.
I'm developing the game using cocos3d, in which large part of models are procedurally generated (like landscapes in Minecraft).
To keep good user experience, I need to populate their meshes in separate thread (via GCD).

Can someone give me advice on is it possible with cocos3d?
Not about /using/ cocos3d for that, of course, but about how to make such async mesh population compatible with cocos3d single-thread model.
Can I just call methods of CC3VertexArray from separate thread? (I suspect I cannot).

Or can I generate mesh in separate thread in CC3VertexArray as long as I didn't bind it to mesh or called createGLBuffers on it?

Or, in worst case, do I need to generate vertex arrays separately with my own classes in another thread and then just copy their buffers data into CC3VertexArray in main thread?

Posted 5 months ago #
Bill Hollings
Moderator

@Virl

You can load or build additional models asynchronously on another thread, but be sure to pass them back to the main thread to actually be added to the scene (ie- make the addChild: invocation from the main thread via NSOperationQueue.mainQueue addOperationWithBlock:).

More explicit support for this will be coming out early next year, but for now, it requires a bit of a roll-your-own approach.

Some care must be taken with textures, since loading them requires making GL calls at load time, which, if done in a separate thread, can conflict with the texture GL calls on the main thread. However, cocos2d does provide special methods to load textures asynchronously, and if you use this feature to load the textures first, prior to loading the POD models that use them, then you should be able to load those POD models on a separate thread (or building them procedurally if that's what you do), without encountering any GL conflicts.

...Bill

Posted 5 months ago #
Virl
Member

Thanks for response!
So, if I understood you correctly, I can load model's mesh into MeshNode without calling createGlBuffers() - and pass that node to main thread?

Posted 5 months ago #
Bill Hollings
Moderator

@Virl

Yes...good point about using createGLBuffers!

You should only invoke that from the main thread as well.

...Bill

Posted 5 months ago #
Virl
Member

Hello again.

In my app, I'm creating and filling CC3VertexArrayMesh instance on separate thread (in separated NSOperation) and then bind it to node and texture on main thread.

Result - app crashes in "libGPUSupportMercury.dylib : gpus_ReturnGuiltyForHardwareRestart".

If I do the exact same thing on main thread (NSOperation mainQueue) - everything works fine without crashes.

Bill, can you suggest something to resolve this? Does CC3VertexArrayMesh use any OpenGL calls when it created and its contents manipulated?

Posted 5 months ago #
Bill Hollings
Moderator

@Virl

How are you creating the mesh? Programatically? Or by loading from a POD?

If loading from a POD, it will use the GL engine to load textures. If creating programatically, I am not aware of any GL calls other than during createGLBuffers.

...Bill

Posted 5 months ago #
Virl
Member

Programmatically. I'm creating and populating CC3VertexArrayMesh instance in separate NSOperation and then calling createGLBuffers on main thread and then I attach new node to the scene.

Posted 5 months ago #
Bill Hollings
Moderator

@Virl

Try inserting log statements before and after you create your mesh, and also in the CC3OpenGLES11Engine engine method (just before the return statement).

That will tell you if the GL engine is being accessed during the creation of the mesh. And of course, make sure you're not loading any textures during your mesh assembly.

...Bill

Posted 5 months ago #
Virl
Member

Thanks for suggestion, but it seems that CC3OpenGLES11Engine is not accessed during the creation of the mesh. :(

Also there is different behavior on simulator and on iPad 3: on simulator async mesh creation crashes infrequently, but on iPad 3 crashes is stable, reproducible and almost instant.

Posted 5 months ago #
Virl
Member

I'm building only CC3VertexArrayMesh in separate thread, not even CC3MeshNode. And attaching that mesh to the node in main thread with textures.

Posted 5 months ago #
Virl
Member

It seems I'm still using textures in separate thread it is the reason of crash. I'll try to fix it.

Posted 5 months ago #
Virl
Member

I've got following code at the very start of asynchronoues mesh build method:

CC3VertexArrayMesh *vaMesh = [CC3VertexArrayMesh meshWithName:meshName];

int subNodeVertexCount = [self estimatedVertexCountForSubnode:nodeIndex];
int triangleCount = [self estimatedTriangleCountForSubnode:nodeIndex];

//int subNodeVertexCount = 12 * 3;
//int triangleCount = 12;

vaMesh.vertexContentTypes = kCC3VertexContentLocation
| kCC3VertexContentColor
| kCC3VertexContentTextureCoordinates;

vaMesh.allocatedVertexCapacity = subNodeVertexCount;
vaMesh.allocatedVertexIndexCapacity = triangleCount * 3;

If I insert return just after vaMesh.allocatedVertexIndexCapacity - it crashes later in main thread (in other place). If I insert return after vaMesh.allocatedVertexCapacity - it doesn't crash and works fine (with empty meshes).
Same thing happens when I set for subNodeVertexCount and triangleCount constant values like 36 and 12.

It seems the problem in some bug in my code that just doesn't surface in synchronous mesh building. And not in cocos3d async mesh generation per se.

Posted 5 months ago #
Virl
Member

I've fixed everything. Problem was not in cocos3d usage, but in wrong index values for vertex array in my code.
Now asynchronous generation of meshes works fine for me.

Posted 5 months ago #
Bill Hollings
Moderator

@Virl

Good news!

I'm glad to see you got it working.

And thanks for posting your results.

...Bill

Posted 5 months ago #
Virl
Member

Here's some recommendations for future generations of developers about async mesh generation:
1. Use NSOperation and non-main NSOperationQueue to generate/load mesh into CC3VertexArrayMesh. But don't call createGlBuffers on that mesh, don't load textures and don't attach it to node.
2. If you are generating your mesh procedurally, try to manually expand its allocatedVertexCount and allocatedVertexIndexCount by some factor (like 1.25) and setting vertexCount and vertexIndexCount after each iteration accordingly, so no non-yet-generated vertices be accidentally drawn later. Don't try to expand allocatedVertex/IndexCount by constant value if you have many small iterations! It will use realloc inside and call many delegate - so it will be very slow.
3. Use Instruments (Xcode Profiler) to see which part of your async generation needs optimization.
4. Inside your NSOperation, after mesh generation is completed, create another NSOperation and schedule it to [NSOperationQueue mainQueue]. In that operation load textures, call createGlBuffers and attach mesh to node hierarchy.
5. If you are frequently removing heavy-geometry nodes, you can schedule their removal too, but to mainQueue (which runs on main thread).

You can see more about NSOperation at WWDC 2012 Session 211 video ("Building concurrent user interfaces") on iOS developer program web website (or in iTunesU).

Posted 5 months ago #
Bill Hollings
Moderator

@Virl

Thanks for providing all this advice!

It will be quite useful for a number of developers.

...Bill

Posted 5 months ago #
Virl
Member

Bill, btw I suggest to change CC3VertexArrayMesh setAllocatedVertex(Index)Count so that it will not set vertex(Index)Count to new value.
Also I suggest to automatically call ensureVertexCapacity & ensureVertexIndexCapacity when setVertexCount is called with number of vertices(indices) larger than previously allocated count.
And when createGlBuffers is called, it will create buffers with length equal to vertexCount/vertexIndexCount.

Logic behind this suggestion is simple: CC3VertexArrayMesh must have semantics of high-level containers like ObjC's NSMutableArray and C++'s vector.
What I mean is that it must have clearly distinguished properties:
1. Backend allocated buffer (allocatedVertexCount), which grows transparently to class user when new items (vertices/indexes) are added.
2. Collection of items (vertices/indexes), for which class user can set length separately from backend storage allocated size and not knowing anything about that allocated size.

Such approach will allow interesting methods of CC3VertexArrayMesh for procedural mesh generation, like addVertex(), addTriangle(index1,index2,index3), addQuad(index1,index2,index3,4), which will iteratively, transparently and efficiently grow underlying buffer.

Posted 5 months ago #
Bill Hollings
Moderator

@Virl

Thanks!

All good suggestions. I'll add them to the to-do list.

...Bill

Posted 5 months ago #
Virl
Member

Result:

Get the Video Player

Posted 5 months ago #
Bill Hollings
Moderator

@Virl

That is very, very cool!

Minecraft in cocos3d!! Sweet! :^)

If you like, you could try adding some CC3Fog to your scene to hide the visual creation of the edge pieces...although the slide-in effect is pretty cool! A fade-in effect might work as well.

...Bill

Posted 5 months ago #
Virl
Member

> That is very, very cool!

Thanks

> If you like, you could try adding some CC3Fog to your scene to hide the visual creation of the edge pieces

I though about it, but haven't understood how to use CC3Fog to place fog basing not on camera position, but depending on location in the world and radius around it.

> although the slide-in effect is pretty cool! A fade-in effect might work as well.

CCFadeIn was the first effect that I've tried. It didn't work, because I need sprite-like transparency/fadein, and not vertex-based transparency. In other words, with CCFadeIn triangles of models are transparent, but also are seen through each other.

Posted 5 months ago #
Bill Hollings
Moderator

@Virl

Fog is always relative to the camera's viewpoint...as is real-world fog.

However, you might be able to play with the attenuation equation parameters to have it be clear for a particular distance, and then drop off quickly at some defined radius.

...Bill

Posted 5 months ago #
Virl
Member

Another thing to look when implementing async mesh generation: don't hold in your async mesh build function any references to cocos3d nodes, because if it is last reference, it will be destroyed at the end of the function and as consequence OpenGL context will be accessed from non-main thread.

Which will lead to pain, suffering, death and, ultimately, the crash.

Posted 5 months ago #
Virl
Member

After 4 days of pain, suffering and self-mutilation it SEEMS that I've managed to accomplish crash-free async mesh generation.

The main problem is this: if you in your async NSOperation block are using CC3VertexArrayMesh variable (and using ARC), look carefully at your code to eliminate ANY POSSIBILITY that last reference (last -release) of this variable will be released in your async thread.

Please note that if you're using ARC, your NSOperation async block (without special measures) will RETAIN your CC3VertexArrayMesh.

If you fill up CC3VertexArrayMesh and then schedule it to method on main thread, there may be very subtle and painful (and dark) race condition: you mainQueue operation will createGLBuffers and complete before you will exit your async operation. If in such case it will for some reason (that mesh is not needed due to user's scrolling, for example) release its reference to CC3VertexArrayMesh - then you're in big trouble, because it will effectively mean that deleteGLBuffers will be called on non-main thread (which doesn't have OpenGL context).

To debug such situation I recommend placing NSAssert([NSThread isMainThread], @"Haha!"); into deleteGLBuffers method of CC3VertexArrayMesh.

Posted 5 months ago #
Bill Hollings
Moderator

@Virl

Sorry that it has been a lot of trouble for you.

But I appreciate the insights that you've been posting here.

I am keeping track of them, and you can be sure that I will be using them when adding async loading to the framework proper. :^)

...Bill

Posted 5 months ago #

RSS feed for this topic

Reply

You must log in to post.