[Bf-committers] Re:Hard vert and face limit.

Robert Wenzlaff bf-committers@blender.org
Wed, 3 Sep 2003 23:10:09 -0400

Ton wrote:
>For the "init rendering" phase, the tables for verts and faces can also  
>be re-allocated dynamically, using the RE_findOrAddVlak and  
>RE_findOrAddVert calls.

>When the current table size is too small, it just can make larger  
>tables, going up in powers of 2. No other code needs to be changed, nor  
>hacking with countall() code...

>From what I read of the code, the tables are arrays of pointers to groups of 
256 VertRen or VlakRen structs.  The structs in the groups are already 
allocated dynamically, but the array of pointers to them is of fixed size.

What I think you are saying is add: 

static int rblovelen=INITSIZE;    /* change init_render data() to alloc */ 		
							 /* this number of pointers */
VertRen **temp;

if (a>=rblovelen){  /* Need to allocate more pointers to groups...*/
		R.blove=(VertRen**)MEM_callocN(2*rblovelen*sizeof(void*), "Blove");
		memcpy(R.blove, temp, rblovelen*sizeof(void*) ); 
		memset(	&(Rblove[a]), 0, rblovelen*sizeof(void*) );  
			/*tests whether group needs to be allocated  with if(v==0) later*/
		rblovelen*=2;  /*Does this really need to be power of 2 or */
						/*  would +=INITSIZE be OK? */

to  RE_findOrAddVert (and similar to RE_findOrAddVlak and possibly halo and 
lamps as well).  #define INITSIZE  to something like 1024 and remove the 
[now] aritficial constraints in other files.  Should rblovelen be a global 
and reset by RE_init_render_data() from do_render()?  If not, if you load a 
large scene, then load a small scene, you'll still have all the extra 
pointers allocated.  Not a big memory leak in the big picture (a one time 40k 
leak for my test scene), but it's there.

This appears to work, (but so did my last attempt).  I also tested with just 
adding INITSIZE pointers at a time with INITSIZE=1024 (and adjusting the 
memcpy() and memset() calls), that also seemed to work and should help 
conserve memory.   With my test scene of 2.6M verts, I reallocated 9 times.

It appears that the guardedmemalloc stuff can be used as linked lists, but I'm 
not all that familiar with it and since this is a once per render process, it 
might complicate things more than neccessary.  I did notice the lack of a 
MEM_reallocN() call and was tempted to provide one.

Did I miss something even more obvious?
               You know you're a techie if -
You refuse to shutdown your computer just to move it

                   . . . . even crosstown.
Robert Wenzlaff                  rwenzlaff@soylent-green.com