[Kazan]

I am sick and tired of getting PMs talking about "upping limits in PCS"

PCS has exactly two limitations:
*max 20 verticies per polgyon ---- Imposed by the FreeSpace 2 Engine
* 400Kbyte buffer for BSP/IDTA data, this appears to be more than the origional freespace 2 could handle, if it's less - or if SCP has upped the limit post here and I will up that limit


as for the other limits:
You can have INT_MAX (4 to the 32nd power - one) : pturrets, sturrets, pguns, sguns, lights, sobjs, glows, etc


it should be noted though: the more complex a model is the longer it will take to compile -- if the program completely freezes it probably means a geometry flaw has caused the program to go into some sort of exception state

[IceFire]

I know a few people mentioned upping limits in PCS but I was under the impression that the "upping the limits" was incorrectly refering perhaps to some kind of error that they ran into that looked like it was a "limits" kind of problem.

Of course, you always have different limits to work with no matter where you go  Its not like anyone can wave a magic wand and make them go away.

[diamondgeezer]

'Cept maybe Phreak

[Bobboau]

the BSP data buffer I beleve is one of the few things in FS that is malloc'ed, so there is no limit in this, there is however a maximum of (origonaly 800) verts wich I beleve was bumped up to 3500;
checks
current defpoint limits

Code: [Select]

#define MAX_POLYGON_VECS 3500 //6500 (7x)
#define MAX_POLYGON_NORMS 5500 //6500 (3x)


[Flipside]

Must admit, I swear by PCS, I use three POF programs for various things, but COB to POF is always done in PCS. The only time I have hit problems, it's either been my bad model design causing bounding box problems, or my habit of shrinking everything in Truespace to the point where I can actually see it, which causes poly-clashing if I don't return it to size before converting, rather than relying on the 'Scale factor' in PCS

But either way, I rely heavily on PCS, and think it's great

Just wanted to make my position clear

Flipside.

[Kazan]

thanks flip

good to know bob.... maybe i'll have it allocate a larger buffer ... say a 2 meg buffer or so

[Bobboau]

2 megs sound like it should handle just about anything we'll need in the near future, if posabe (and it it isn't so alredy) an error mesage saying something about a BSP buffer overrun to see if it is in fact what is causeing problems

[Kazan]

Originally posted by Bobboau
2 megs sound like it should handle just about anything we'll need in the near future, if posabe (and it it isn't so alredy) an error mesage saying something about a BSP buffer overrun to see if it is in fact what is causeing problems

i could also theorectically find the largest BSP structure and multiply it's size by 3500 and that should definantly do

[KARMA]

Originally posted by Bobboau
the BSP data buffer I beleve is one of the few things in FS that is malloc'ed, so there is no limit in this, there is however a maximum of (origonaly 800) verts wich I beleve was bumped up to 3500;
checks
current defpoint limits

Code: [Select]

#define MAX_POLYGON_VECS 3500 //6500 (7x)
#define MAX_POLYGON_NORMS 5500 //6500 (3x)
[/B]

ehm bob you mean that pcount (or vertcount) x subobject have been increased in fs2open to 3500?

[Bobboau]

yess, though the norm count is still probly a limeting factor