Hi, I've been pouring over the Ageia physics(Nvidia) physics sdk and I look at the User Allocator code example which isn't really a memory pool and decided "let's make a memory pool". Well ok so I started but now I'm kinda perplexed looking at NxScene,NxActor and boost::pool. I have a few questions regarding them and their is no source really just static libs so wondering if anyone ran into these problems before: 1) Does anyone know if NxActor or NxScene are having variable length or constant length? My main issue with this is I want to statically create a big chunk of memory but at the same time because their are virtual memory restrictions I'm really looking at some kinda of tree-> link list scheme. My main concern here is if the list grows whoops now your writing memory where your not supposed to. 2)Anyone have posted a true memory pool for ageia and can share their experience? 3) I've also been toying around the notation of blowing a big chunk of memory by making a tree scheme with 64 nodes and 1 64 bit register bitwise array to track what memory is used by node. The idea here is to get rid of the worst case scenario linear search scenario by a segragetd pool and use a couple jumps for a tree scheme(however I know it's gonna cache very well....) but I'm thinking just using boost::pool<> to prototype first. 4)Also, has anyone used the boost pool before and know of any memory issues with it. As I'm kinda leaning towards my own mainly because I'm kinda clueless on how I would perform a full traversal. After all I wanna pool the memory in advance and not at runtime if possible.... Thanks for any input you guys have. As I'm still kinda wrestling which method to implement. Any input would be appreciated. Cheers,

From the docs:

"The SDK does not guarantee any particular usage patterns that allow you to make a truly specialized allocator. In many cases, the SDK will allocate a chunk of memory with your allocator at startup, and then internally manage this block for its internal allocation needs."

So a memory pool doesn't sound like the best idea for NxUserAllocator.

*** ageia. Thanks for the reply. Yeah looking at the documentation I see a big Ugly enumeration with NXMemoryType. This is a big bummer. I'll just prototype with the default memory for now and change it if the profiler screams later on....

O wait a second. I can just malloc a really large chunk of memory and internally and be really wasteful with the memory with a second memory reserved for a list of pointers +


| bbbbbbbbbbbbiiiiMEMORYiiiiiiiiggggggggggggggg chunk of memory |

/\
| list of address |ptr+(size_t) |


of course now virtual memory could be a issue again and this could be potentially wasteful. Hmm but I'm intrigued. K I'll post again after some more coffee(c) + coding.

Thanks again!

:-)