Help with procedurally created geoms

So I’m trying to get my feet wet again by creating a simple Minecraft clone. So far I have 3 different block types. Each block gets 12 triangles (2 for each face).

I have one GeomNode, which has 3 primitives, one for each block type. To make this geom, I adapted the example found here: [Creating a tiled mesh at runtime)

I have two questions. In order to ‘remove a block’ so it no longer gets rendered, I need to remove its triangles from the primitive. I’ve read that one way to do this is to recreate the primitive and leave out the triangles. Wouldn’t this be slow for a primitive with 10,000 triangles?

‘ninth’ suggests splitting the primitive into smaller ones, so that recreating them isn’t as painful. Would having a geometry with 1,000 primitives be bad? I know that you can render a 10,000 poly model quickly, but having 10,000 panda nodes with a 1 poly node each renders slowly.

Yes, recreating a 10,000 triangle primitive sounds likely to be slow. So does rendering a Geom with 1,000 individual primitives. You can try them, of course. (Actually, 1,000 individual primitives wouldn’t be out of the question, especially if there’s nothing else going on.)

But, yeah, dynamically operating on large grids such as for Minecraft will generally require some cleverness to adapt to a 3-D engine like Panda.


So I refactored the code a bit so that the environment is made up of chunks (like minecraft is) that are 16x16x16. Whenever I want to add or remove a block, I mark the chunk as dirty, and then during the next update, the geometry gets rebuilt. Rebuilding one of the chunks takes about 150ms, and the system freezes while it rebuilds.

I don’t really mind that it takes 150ms to notice the block change, just that the system hangs. Can I throw the code that creates the geometry data structure into a thread, and then update the GeomNode after the thread completes? I don’t have a ton of experience with threads, but my intuition is that it would be ok since if I create a new geom in the thread and then have the GeomNode point to the new one instead of the old one once the thread returns, I wouldn’t be altering any existing data in memory and wouldn’t run into any concurrent modification problems.

Yes, in principle, that should work. You’ll want to use the buildbot version (1.8) rather than 1.7.2, since it’s compiled with full thread support.


I know this thread is old, but if I use 1.8 and embed a p3d file in a webpage, will users get the benefit of using threads?

You can’t build a p3d file with 1.8 yet, not until 1.8 is officially released. But when it is, yes, it will include the same full thread support that’s in the SDK.