[Bf-committers] Hard vert and face limit.

[Ton Roosendaal]

Hi,

I think you make it a bit too complicated. Using the global G.tot*  
counters should not be considered reliable for rendering, because they  
are meant as a reference for the amounts that are currently being  
displayed in a 3d editor window.

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...

-Ton-




On Wednesday, Sep 3, 2003, at 04:59 Europe/Amsterdam, Robert Wenzlaff  
wrote:

> After showing alltaken how to raise the hardcoded limit in
> blender/source/blender/render/extern/include/render_types.h
> I started looking at making the Vert and Face tables dynamically sized  
> from
> the scene data.
>
> Changing the allocation was easy, coming up with a reliable pixel and  
> face
> count was tough.  R.totvert is counted as the tables are loaded.  The  
> meaning
> of G.totvert changes depending whether you are in editmode, and
> RE_init_render_data() was called before it was set anyway.
>
> So, I changed RE_init_render() to be "reentrant", ie; it can be  
> saffely called
> any time, and added a call to it i do_render().   But G.totverts still
> changed meaning with editmode, and it wasn't set at all if you didn't  
> select
> at least 1 object.   So when init_render_data() is called, if editmode  
> is
> detected, I save the current G.obedit, G.totface, and G.totvert, clear
> G.obedit and call countall().  If you are in editmode, I add the old
> G.totvert and G.totface to the totals, or you miss any new verts and  
> faces
> made in editmode.  It over allocates a little, since the old verts and  
> faces
> are in the non-edit G.tot numbers, but its' still more efficient than
> allocating for 2M verts always.  My .blend went from, allocating 0.91M  
> to
> 0.82M.  My 2.269M vert test file went from 62.43M to 62.34M.
>
> I then allocate the tables based on those numbers >>7 (since they are  
> not even
> powers of 2 they always seem to be too small if  I >>8 ).  When done, I
> restore G.obedit and the counts.
>
> Only 2 other files used these #defines. renderdatabase.c had a couple  
> of upper
> limit checks  that I removed in RE_findOrAddVlak, and  
> RE_findOrAddVert, and
> convertBlenderScene.c had a limit on stars and verts.  There is an  
> alocation
> in sort_halos() that I'm not sure how to handle.  Currently I have :
> R.bloha= (HaloRen **)MEM_callocN(sizeof(void  
> *)*((R.totvert>>7)+1),"Bloha");
> Since I think halos are done after the vert tables are filled,   
> R.totvert
> should be valid.  It hasn't segfaulted yet on me doing halos...    
> Please
> correct me if you think this is wrong.
>
> Anyone see a problem with this method?  Are there other places in the  
> code I
> need to modify?
> --  
> **********************************************
>   Lesson learned from watching 'DragonballZ':
>               Jedis are wimps.
> **********************************************
> Robert Wenzlaff    rwenzlaff@soylent-green.com
> <MaxVert.patch>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton@blender.org  
http://www.blender.org