Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Rampage on November 12, 2002, 06:10:30 pm
-
I heard that there's a recent version of PCS out with the new features for FS2_OPEN3_3. Where can I retrieve the copy?
-
There is slight misunderstanding here.
Kazan CVS´ed PCS for people to download and manipulate
and bobboau started to tamper a bit with the code, but is still getting a unstable build that will crash, if you dont follow some specific schedule of doing things.
search this board, there should be some reference to it somewhere. might even a download link, but remember "unstable".
-
Originally posted by DTP
but remember "unstable".
What else is new... :rolleyes:
-
the ustable part
you see PCS has always been very stable
-
The Alliance Sourceforge page has PCS 1.2 which has support for Glowpoints. (Keeping an older version around might be wise though as, currently, it doesn't let you import data from another POF like the 1.1's did.)
-
the version in CVS is the only version with properly working FS2 Open 3.2 and 3.3 GlowPoints - i need to get aroudn to poinst a new build in the easy-2-download shizat
oh... and i have an idea where the crashing on shutdown/file change is... why is the question - i don't SEE the bug - i just know what function it is in
-
ok.. i've plugged the LEAK - but it's still doing runaway allocation [that upon program termination stops] it was allocating memory at a rate of just over 100megabytes per second on my system!!!!! [rate is most likely framerate dependant]
(http://www.public.iastate.edu/~kazan/memusage.jpg)
-
hmm interesting.. it's not allocating in RecursiveRenderPOF_BSP
-
score!!!! no more runaway memory allocation - and the bug fix also increases performance :D
-
YAY! Is that available? I may actually be able to upgrade to the newest version then. Been sticking with the one just before 3D at the moment...will undoubtedly go upto this one now.
-
i just uploaded a build to my SourceForge FRS
http://sourceforge.net/projects/alliance/
version is up to date - stamp is "PCS 1.2.4 11-19-2002"
-
ok.. here we go - here's the new memory usage
the first little rise you see is POF CS loading - the second one you see is it loading the POF file and initializing rendering - then you can see it's pretty constant
(http://www.public.iastate.edu/~kazan/memusage2.jpg)
-
I've never gotten it to load texturs at all, were does it look and what are the rules,
also when I open a file and then try to open another it crashes
-
i know trying to unload the current file and load a new file crashes - always have - it's a low priority bug
um... it searches your freespace 2 path - VPs included....
-
well I only ever get non-textured mode
my fs directory is in D drive though,
it takes this into acount though, doesn't it?
-
it reads the freespace 2 directory from your registry.... if UAPI can find it all my programs can find it
-
So... am I best getting the latest build, or should I stick with 1.1 until you get everything fixed?
-
were in the registry
the normal fs entry? (doesn't seem to be a path there)
-
should be the normal fs entry.. why don't you have a registry entry?
-
Sorry, I'm getting the same problems; stack overflow and crashing on POF save.
-
crashing on POF save? that's really screwy
if it gives you a stack overflow warning that means your model file is ****ED UP
-
i see there is a saving bug.. nice of people to tell me
-
it's in OBJ2... big suprise [/sarcasm]
-
and another bug bites the dust!
fixed that damn saving bug.. commiting to CVS
-
FS2 doesn't store info in the registry about where it was installed, but it does put an uninstall string in that has the path and that's what PCS uses to find it. Interesting technique.
-
i am well aware of this :D
-
But Bobboau wasn't. ;)
-
so were is it?
-
Probably on his source database thingysite (sorry, its late, im tired).
-
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\FreeSpace2 the UninstallString value. (FYI, I would recommend not changing it because that could cause you to be able to uninstall FS2. :) )
-
OK, as long as we're talking about PCS bugs...
I've had models that convert fine with COB2FS2. However, they either cause a stack overflow in PCS, or they convert fine and crash PCS when I try to save. Also, the 'import values' buttons don't seem to work. At all. Not even a dialog box asking me which model I want to import the values from. I can send you some example models if you want.
That 'clearing current POF from memory' message bugs the heck out of me when I first start the program up. Can't you have it check to see if there IS a current POF loaded? Mouse support in the model viewer would be nice, too, but I don't use it much.
-
FYI, I would recommend not changing it because that could cause you to be able to uninstall FS2.
:lol:
-
the data import buttons were placed as place holders but i haven't got around to writing the functions yet
cob2fs2 doesn't properly generate BSP/IDTA data for the POF - POFCS is more sensative to conditions which cause infinite recursion because of this - infact if you go into infinite recursion your model is very ****ed up because it overcame a 16 perumtation avoidance algorithm that is in there to try and make the model compile anyway
i don't know why anything would be crashing on save except for that mysterious double-save crash bug which i squashed today
the first two "bugs" are well documented facts about PCS
-
I'm sorry. Please define '****ed up' as it applies to COBs.
-
little OT, but... somebody knows if the source of cob2fs2 is avaible somewhere? i need it to have vadar_1 fixing (if possible) a little bug i found sometimes ago
-
Galactic: polygons with the same geocenter - the avoidance algorihtm can handle a few - but having enough to cause a stack overflow = model ****ed up
BSP splits operate off the position of the polygons in the universe - so when you have polygons in the same position it cannot "split" them into different regions and it goes into infinite recursion
-
ok, that got it, finaly works now, I had moved my directory without changeing that, didn't look like the path was stored anywere.
I can't beleve anyone would have the problem of haveing pollys in the exact same position, it sounds as though it would be a little hard to do it on perpose, do you think it could posably be something like the BSP generation code not takeing subobjects offsets into acount thus makeing anymodel with a bunch of turrets (or any submodel for that mater) that look just like each other and in the same orientation,
I have noted a slight bug when converting from a pof to a cob all subobjects are centered at 0,0,0 includeing turrets that are way the hell off center, this means I have to recenter them after conversion, this isn't that big of a pain, but it could be indicitave of this sort of misstep.
or maybe there are subobjects that have polys aligned to each other with faces placed at each others center, to make it look like there together (like the top of a turret base and the bottom of a turret barrel, some people do it that way)
GE see if you'r model has many identical turrets faceing in the same relitive direction, or has subobjects with pollys aligned
-
each SOBJ is compiled seperately - it has to be - and it's coordinate system is relative to it's centerpoint
the polygons themselvs dont have to be coincident - just they geometric centers
-
Originally posted by Bobboau
I have noted a slight bug when converting from a pof to a cob all subobjects are centered at 0,0,0 includeing turrets that are way the hell off center, this means I have to recenter them after conversion, this isn't that big of a pain, but it could be indicitave of this sort of misstep.
You need to center the axis location for each subobject in TS before you convert it to a POF. Many 3D programs only assign 1 axis for all the subobjects. TS allows each object/subobject/combined object to have it's own axis. That's especially important for multi-part turrets, since the axis location is the location that the turret will rotate around. It's best to do the axis stuff before you start gluing things together, because when you glue stuff together each combined object has it's own axis which is taken from the axis of the main object in it. If editing a model that's already glued together, you have up to twice as many axis to fix. The axis center is also used as the object center for things like firing point locations and turret subsystem locations as shown in the HUD targeting box.
-
I know, I have made a few models ;)
but when converting from a pof to a cob the axes of the subobjects are centered at the center
I don't have any problems the other way around
-
the pof->cob code is imperfect, and most likely not in it's final version
it's just another one of those low priority things
-
Originally posted by Bobboau
I know, I have made a few models ;)
but when converting from a pof to a cob the axes of the subobjects are centered at the center
I don't have any problems the other way around
Oops, misread the pof to cob as cob to pof. :)
-
Kazan, I might nto remember my math right, but aren't the only cases that will really hurt a BSP tree building algorithm in cases where polygons are on the same plane or something? I don't see how any other cases could lead to problems with splitting correctly.
-
Originally posted by Fry_Day
Kazan, I might nto remember my math right, but aren't the only cases that will really hurt a BSP tree building algorithm in cases where polygons are on the same plane or something? I don't see how any other cases could lead to problems with splitting correctly.
yes you remember correctly - but there's also the case in which two polygons have the same geometric center - because that's what my system uses to dtermine the polygon's "position"
-
Oh. I see. Tell me, do you use any heuristics for trying to find the best BSP tree (Least amount of subdivisions), or do you simply split along the plane that creates the least subdivisions in each iteration?
-
you split along the longest axis in the bounding box - you split fully until each terminating region has one polygon in it
this is a full tree and proides the greatest acceleration