I have a node containing geometries. It lags/freezes if I don’t optimize it with GeometryBatchFactory.optimize(). When I do that and I pick the node, I get geometries with names “batch” or something. I want to be able to tell which geometry got picked and do stuff to it. Is there a way around this?
I’ve tried attaching an optimized clone of the node into the root node and still keeping the original, but that takes up too much memory and freezes.
hmm I’m sure there is a way to do this, depending on the context. Its mainly used for static scenes though, perhaps look at BatchNode; it batches but also keeps the original geometries so that they can move. Although I haven’t really properly used either
Well since I assume you use a blockworld, you should do the picking in the unoptimized node, and could use geometrybatchoptimizer to get the optimized one.
In a block world, you should not use picking in the first place. In a block world, there are far more efficient ways of detecting wich block was hit then picking 
In a block world, the geometry just represents your world in a visible way. You data is stored in another way.
You could, for example, simply have an int[][][] were you store a value for every block in the area. You would simply check all blocks from your int[][][] along the clicking ray and determine wether they are solid, or not. The first solid block along that ray obvoiusly has to be the clicked one. Since you only test blocks along the ray and not every damn block in your world as you would with picking it is far more efficient.
Or, if your voxel world is more sphisticated like mine, which is constructed from isosurfaces from an scalar field, you’d use the original scalar field to test against instead of the geometry of the isosurfaces mesh (i should add that my world is not editable by the user, at least not in a way similar to MC or Mythruna).
/edit:
Just a clarification: After i read my post again it sounded like i claimed MC or Mythrunas worlds were not sophisticated. That was badly worded. I simply meant to say that my voxel world does not use boxes but has finer details, and therefore the int[][][] approach can not be used in my case, which is why i test against the scalar field. Testing against the scalar field has in my case another benefit, since i use marching tetrahedrons for polygonizing, and polygonize with low iso values for objects farther away for LOD, i can still have very precise picking although the geometry is not that precise in the distance.
2 Likes
I see, thanks 
Not to muddy the waters too much because all of the points still remain the same but a packed array of a chunk of the world is generally the most efficient way to store the block data. Just load the parts of the world that you need. Mythruna doesn’t even pack them (though that’s on my to-do list.)
Given the frequency of access and iteration, sparse data structures usually end up taking more time and don’t provide that much more memory.
Still, don’t do block collisions on the geometry… that’s the hard way.
Just dont use huge arrays with mostly empty entries. Think like myClass.getBlockAt(x,y,z); this way you don’t have to store all the empty ones. In the end you will probably store your data in a database anyway.
Just _dont_ use huge arrays with mostly empty entries.
Yeah, that was just to demonstrate the principle with an easy to understand example ;) Of course a more effient structure is needed for larger data sets. You'd likely use quadtrees or octrees for something like that anyway. Or something else in that direction.
@polygnome said:
Yeah, that was just to demonstrate the principle with an easy to understand example ;) Of course a more effient structure is needed for larger data sets. You'd likely use quadtrees or octrees for something like that anyway. Or something else in that direction.
Yeah I was just mentioning that because some people really don't think about the implications and want to load entire universes in an array and stuff ;)
@EmpirePhoenix said:
Well since I assume you use a blockworld, you should do the picking in the unoptimized node, and could use geometrybatchoptimizer to get the optimized one.
That lagged/froze due to too much memory.
@polygnome I think I'm actually doing something similar to what you did with voxels, except I'm using marching cubes.
Well the approch i posted wors fine for larger worlds, just think in chunks. and only egenerate that chunks. Doing this for the whole world will kill ram of course. (Needless to say that the other approchaes are better choices normally)
I tried BatchNode but nothing seemed to change (it was as if I wasn’t optimizing the node). I used batchNode.batch() instead of GeometryBatchFactory.optimize() after I attached everything to it. I might be doing something wrong…
i only suggested BatchNode because from your other posts, it seems that you aren’t doing a box world, are you doing one? If not then just remember that after you have batched your spatials, every addition/removal, you must call .batch() again. Also do your objects have the same material? And how many objects are we talking about? could you supply a screenshot.
@wezrule I don’t know what exactly a “box world” is, but it is based on voxels. It uses marching cubes. No, they do not have the same material. Some are grass, some are sand, some are snow, etc.
These use .optimize() for most of the objects. It’s still slow, but I think I haven’t optimized the trees.
the bottom screenshot you have 2500 objects, thats far too many. Also batching only works on geometries with the same material