Long story short I want to have a “World Generator” running in the background. It fetches data from classes made of primitives for storage reasons (easy serialization) and generates all the meshes I need in order. Once it has a mesh ready, it sends the mesh over to my main thread for it to be added to the stage.

I’m running into a bit of an issue. I have every class registered and their subclasses using registerClassAlias. The main thread receives a broken Mesh and fails to add the final result to the stage.

I hear that there’s an away3D class called Serialize. Would this be required to serialize a mesh and read it on the other end? If so, how do I use it?

[Stack overflow link (long story)] http://stackoverflow.com/questions/37964644/as3-workers-passing-custom-objects

it prob work better if you only send the geometry vector data via a thread, don’t think materials will work due to the way away3d is setup.

From my experience, serialisation doesn’t work as documented.
However, what does work very well, is to use byteArrays, which is a for meshes ideal. Simply share the vars for each buffers.

main worker.setSharedProperty(“vertices”, vertices);
worker, worker.getSharedProperty(“vertices”) as ByteArray;

in case you need more than the meshes buffers to generate your mesh on worker side, just serialize the entire mesh. Look at awd2 parser for geometry/mesh blocks and do similar.

this how i would do it:

if you need other things like second vs tangents etc just add them the same way

therealloft - 23 June 2016 09:05 AM

it prob work better if you only send the geometry vector data via a thread, don’t think materials will work due to the way away3d is setup.

I only have one geometry object (for now) since they’re all cubes. I mean I do merge clusters of them for performance reasons so it may come in handy for merges. Although, with merges, how would I pass their material? I’d rather the merge occur in a thread.

Fabrice Closier - 23 June 2016 09:09 AM

From my experience, serialisation doesn’t work as documented.
However, what does work very well, is to use byteArrays, which is a for meshes ideal. Simply share the vars for each buffers.

main worker.setSharedProperty(“vertices”, vertices);
worker, worker.getSharedProperty(“vertices”) as ByteArray;

in case you need more than the meshes buffers to generate your mesh on worker side, just serialize the entire mesh. Look at awd2 parser for geometry/mesh blocks and do similar.

Something that just came to mind: If I serialize it, will it still share it’s geometry and material in memory? (I am going to have a lot of meshes on the screen at once)

Also something that has been in my head for future optimization…since I have (basically) a field of cubes, would it be better for me to render, say, a large green plane instead? In the case of giving off the feel of a cube like world, if I clicked on a set of coordinates in the plane, how would you “puncture a whole” in it? I looked up modifying the geometry of an object manually but had no luck.

I had a theory where I figure if I get the coordinates with a mouseevent3d and do some math to fetch where 10 by 10 cube would be, I could modify the geometry of the plane to simulate a destroyed cube when I would just be modifying a plane. It would be complicated to implement and manage but once it was all said and done I figure I could have a lot more objects on the screen at once. The only thing I can do right now to have a steady framerate is to merge 10x10x10 sectors of 10x10x10 cubes into one mesh that are farther from the camera. If the camera is near or gets near, it goes through the process of merging the sector that was previously broken down and recreating a new sector with a whole bnuch of mesh cubes that share geometry and color material with event listeners attached to them for modification.

therealloft - 23 June 2016 09:41 AM

this how i would do it:

var geo:Geometry = m.geometry;
var bytes:ByteArray = new ByteArray();
bytes.writeInt(geo.subGeometries.length);
for(var i:int = 0; i < geo.subGeometries.length; i++){
 var sub1:CompactSubGeometry = geo.subGeometries[i] as CompactSubGeometry;
 var sub:SubGeometry = sub1.cloneWithSeperateBuffers();
 var e:int;
 var n:Number;
 var u:uint;
 bytes.writeInt(sub.vertexData.length);
 bytes.writeInt(sub.UVData.length);
 bytes.writeInt(sub.indexData.length);
 for each(n in sub.vertexData){
  bytes.writeFloat(n);
 }
 for each(n in sub.UVData){
  bytes.writeFloat(n);
 } 
 for each(u in sub.indexData){
  bytes.writeUnsignedInt(u);
 }
} 

if you need other things like second vs tangents etc just add them the same way

I might use this to share merged meshes. The issue becomes how to share materials since I haven’t tested it out yet but I’ll definitely play with this. Thank you!

if you share it’s shared, but if you need serialize from vectors to byteaaray on main, deserialize back to vectors on worker, do the job, reserialize, pass to main, deserialize and update the mesh. Its not gonna work smooth. I you have lots its gonna be a resource monster.
So if you keep your construction, i’d share vectors vs byearray to remove marschalling/garbage.

however reading your second part, i’d say you could look at prob way around.
I’d go for a full voxel sized mesh, all cubes in there, and have a tree to manage.
where basically the only change is uvs. where you got a single map for everything. No workers needed, no merge, you simply have to traverse this voxels block from your cam mouse direction and ask the tree to change uvs to either “add”, “remove” or “select”. A simple flag on a voxel object is enough for traversal check (is visible, uvs in a transparent region)

merging is not ment to be used for runtime, the routines are too generic to be efficient for that too many objects.

i would generate a chunk as one mesh and use a texture atlas for the material like how i did it on this post http://away3d.com/forum/viewthread/5735/