[Bf-committers] parts rendering inconsistencies and questions/bugs

[Ed Halley]

Previously, I set the buttons max to 1024 for my smooth panoramic 360 
dojo scene, and found no problems.  The code internally was trying to 
ensure that the PRODUCT of the xparts*yparts was 64 or less.  I saw no 
reason for that limit, as everything related was allocated dynamically.

I don't know about the new structure, but I would like the limits to be 
high, to allow for small parts.  The thinner the part, the smoother the 
approximation of a panoramic cylindrical projection.  Someone on Elysiun 
recreated a wonderful Escher image with only 64 parts but it would be 
better with narrower parts.

I agree that xparts=1 yparts=1 should also be possible, though I don't 
know why Ton disabled it.  Maybe it was just to help detect and 
"migrate" the old-style .blend files to a default xparts=4 yparts=4 for 
threaded performance reasons.

Tom M wrote:
> I just was looking at parts rendering
> 
> CVS minimum is 2 xparts and 2 yparts in the codebase, changing it to 1
> doesn't cause any errors I can see, and would make it consistent with
> 2.41
> 
> The python  max yparts is 512 (sceneRender.c), in buttons_scene.c it
> is 64, which is correct?
> 
> If you set xparts and ypart to their maximum, the actual maximum parts
> allowed/used depends on apparently the size of the image?
> 
> 800x600 - limited to 130 parts
> 2400x1800 - limited to 1938 parts
> 8000x6000 - limited to 11750 parts
> 10000x10000 - limited to 24649
> 
> (note watching the default cube render in 24649 is rather amusing
> though a bit slow :) )
> 
> 512*64 = 32 768 max parts so I assume the 64 is correct above, but why
> not 256 * 128 instead?
> 
> LetterRip
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
> 
> 
> 

-- 
[ e d @ h a l l e y . c c ]