Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Kazan on September 01, 2003, 01:29:40 pm
-
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
-
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.
-
'Cept maybe Phreak :nervous:
-
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
#define MAX_POLYGON_VECS 3500 //6500 (7x)
#define MAX_POLYGON_NORMS 5500 //6500 (3x)
-
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 :D
Flipside.
-
thanks flip
good to know bob.... maybe i'll have it allocate a larger buffer ... say a 2 meg buffer or so
-
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
-
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 :D
-
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
#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?
-
yess, though the norm count is still probly a limeting factor