Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: ShadowPuppet on May 18, 2004, 03:37:56 pm
-
With a model of around 2500 polygons, how long should the conversion take?
I think I have a problem with a model which seems reluctant to convert! PCS sits there using up every bit of resource it can, showing 'not-repsonding' and just seems to hang up.
Either a model takes 10 minutes+ to convert, or I have a problem!
What sort of errors might cause PCS to hang like this?
The model is using 4 textures and around 2500 polys. PC is running an XP1700 and 512Mb RAM. Models with half the polys go instantly....so I think the model is to blame.
HELP !!!
p.s. I am using the latest build of PCS ( 1-3-42 dated 03/04/2004 )
-
Hmmmmmm... non-solid or intersecting polygons can sometimes cause infinite loops and crashes, I seem to recall that could happen on older versions?
-
infinite loops can happen to ANY and ALL versions due to the POF format and how you have to generate it, but i should catch itself at a 500 depth - it sounds like you crashed it
-
Question: Can the source code project take out limitations on POF format, like have it read truespace files instead. Or is the Ferrium
-
Neither as far as I know I afraid :(
The problem is that Truespace objects are stored in a very basic format, since the models are in no particular rush to be rendered etc when in preview mode. And full RayTracing works slightly differently to the POF format which is optimised as far as possible to produce minimum render time and account for things like collision, occlusion (when one object is in front of another, setting this up right can reduce the number of polygons you need to render massively) etc.
In order to do that you would have to sort of merge PCS with FS2 and get models compiled at the start of a mission (and that's not even considering turrets, dockpoints etc), which would be quite a wait in some cases :(
-
reading truespace files = extremely MORONIC from technical standpoints
Crash++++++++
MissionLoadTime++++++++
-
UPDATE!
Now, this is getting odd.....
I tried again this morning on a different PC...and by accident, I forgot to re-set the conversion path in PCS. As a result, it couldn't find the textures... and built in 2.14 seconds! The same model....
I checked the textures I was using, and they are definitely 8bit PCX files. To double check, I pointed PCS at the folder where they were, and sure enough....no build etc. etc. etc.
I checked the COB file I was converting in 3D Explorer, and the textures display just fine.
I was using 4 512x512 textures. I thougt perhaps this was causing the slowdown, so I made them a lot smaller... and that made no difference. Something in the mapping/material process is upsettign PCS.
When I looked at the POF file PCS created with no textures, it had picked up the texture names OK and recognised the materials. Opening up the same model in Modelview again had he correct names, butr found no textures and forced me into flat or wireframe views.
It looks ( haven't tried in game yet ) as though I have a live and viable POF file .... just so long as I don't add a texture!
-
that's odd
-
oh, I've been meaning to mention, PCS doesn't convert very well when the render window is open, I'll click the convert from pof button and the open file dialog will sit there for a few minutes but if you close the render window none of this happens.
-
the render window is indeed finicy - i should probably set to to not render while a conversion is taking place
-
This same error appens to me very often, especially when converting meshes extracted from semewere else instead of built from scratch... PCS just enters loops and won't convert anything.
Odd thing is that the old Cob2Fs2 tool is able to convert them all without any trouble.... :doubt:
Sometimes i can fix this problem by just merging vertex togheter to reduce them (easy way is converting the mech to 3ds, opening it in truespace and saving it as cob, this greatly reduces vertex count often)
-
cob2fs2 doesn't generate the data correctly and therefore it's lax about geometric snafus
-
Originally posted by Kazan
cob2fs2 doesn't generate the data correctly and therefore it's lax about geometric snafus
Probably, you sure know this topic much better than me, but fact is ships created with it never had any problems, and i converted a lot of ships so far... and 2-3 out of 5 of those models made PCS going into loops.
Only issues i have with that old tool is the inability to have autofacet models in game. :blah:
-
ryuune75: then you don't know about it's collision and lighting problems, etc with models generated with it
-
Originally posted by Kazan
ryuune75: then you don't know about it's collision and lighting problems, etc with models generated with it
That is something that interest me, cause i have tons of models generated with it, but how can i find those problems? I never noticed anything odd about them in game, but if there are i need to know.
Can you please explain better what kind of problems may i have with them?
And finally, is there a way can i make PCS convert them if i need to, other that rebuilding them and praying they will work?
-
ryuune75: have you tried running the conversion with the render window shutoff
if you're not seeing blatant collision errors then something odd is afoot
-
I got my model to convert fine using the last release of Modelview32.
I did some tests which seem to highlight some issues that would cause PCS to enter the 'loop of death' ... Chief amongst these was the annoying fact that some welding of verts in Lightwave left anomalous polygons...lacking 3 independant vertices. This was a sure fire crasher for PCS. If you wlded 2 verts of a triangle, the polygon 'remnant' was impossible to see, but still existed.
I found a couple of these. Modelview just ignored them.
That wasn't the whole story though. Even with these removed, I couldn't get the mesh to work in PCS.
Is there a definive 'list' of known mesh problems that can cause this sort of crash in PCS?
-
You're not building your mesh in the native file format that the conversion accept's - enough said
Sorry I don't support people who use non-supported programs and then convert their files into .cob format (well.. maybe with the exception of 3DS users) since it causes so many problems that are unreasonable to fix
-
well....pardon me for daring to use another modelling tool....
Sorry..but not using the 'native' format so you don't support me, is probably the lamest excuse for not knowing the answer I have ever heard.
Since I, as others do, map in Lithunwrap, the final model is written out of Lithunwrap in COB. By Lithunwrap...
ANYONE mapping in Lithunwrap is saving their work as COB that way. THEN I open it up in Truespace and ...what do you know... it doesn't mind what I made. No error message pops up saying 'your mesh has been created in a non-native format', no 'perhaps you should have used 3DS' ..nope.
So, if you can explain why you refuse to help coz I used Lightwave, that might be nice. Also, you might like to explain why Max users are 'OK' in your book...but not Lighwave? How does a Max user get his model into PCS.....er...now, let me think.
If you don't want to help...fine...don't post. If, on the other hand, you prefer to be 'modellist' then I reserve the right to be equally stupid.
-
SP, I use Lightwave myself, I use a little trick here, I just Atlas Map the model, select the stupid 'ultra thin' polys, which tend to stick out a mile, and just delete the buggers. I've converted several models in PCS using this technique without complaint. Another trick is to remember to use 'Merge Points' before saving anything, it's faster than welding polys manually, and most cross-layer actions leave unwelded polygons everywhere :(
I've converted some REALLY 'naughty' objects in my time - Stop it you lot (My island is a non-solid shell) so I promise you, it IS possible to do it :)
-
Thanks Flipside ... I will try it that way. Merge points does quite a useful cleanup job on the verts...but I think I will also need to modify my building technique in some areas. Deleting the polygon BEFORE I weld the verts would avoid problems when simplifying areas of Boolean 'polygon proliferation' .... as would checking for these things before I map ;)
Whatever Kazan may say, I would rather bin PCS than bin Lightwave. Modelview converted the ship just fine and it works in game ..... and thats all I need.
Victory for the Lightwave Liberation Army!
Down with the Truespace Tyrants ;)
-
just open and save in truespace, that should solve the problem, and you'll get corectly formed pofs, PCS _IS_ the only program that generates corect BSP data, it'll look fine, but I assure you it won't be.
-
Originally posted by Bobboau
just open and save in truespace, that should solve the problem, and you'll get corectly formed pofs, PCS _IS_ the only program that generates corect BSP data, it'll look fine, but I assure you it won't be.
This is not helpful at all... you say it won't "look" fine even if it "look" fine... that's just funny.
I converted like 70 ships using tools ranging from PCS to Modelview to Cob2fs2 to Cob2Pof, and -never- found any difference between them.
You and Kazan say it should have problems, but can't point me what those problems are... prolems that neither me nor anyone who have seen my models ever noticed.
I'm not saying you are not telling the truth about this, as i said i'm no expert and you are, but if you want to help just point us in the direction of finding those problems and get rid of them.
-
btw I've converted many models with modelview too, without finding problems on the resulting pofs, I still have to find the time to take shots to show what's my problem with pcs *takes a note*, on the other hand I never got modelview to convert correctly shields.
-
ryuune75: that's because you don't know anyhting about the internals of the model format
try using the mesh debugging features on PCS on a model generated by another program sometime.
------------
ShadowPuppet: Pulling an attitude with me is the fastest way to get my foot up your ass and even less help
People having problems with using 3rd party programs and then *****ing at me is getting older than people asking about FreeSpace 3
Why Don't I support those programs? THEY DON'T PRODUCE PROPER .COBs - If you want a native ****ing .lwo converter DOWNLOAD THE DAMN PCS PLUGIN SDK AND WRITE THE ****ING THING
Remember
A) Cannot have any duplicate polys
B) Cannot have polygons with coincident centroids
C) A polygon should be a plane segment - ie all points in the SAME plane
D) No Polygon should have more than 20 points [FS2 Requirement]
if you have A or B (if you have A, then you have B) then it WILL go into a infinite recursion and mmay not catch itself - it should catch itself, but bad input data breaks the algorithm (*gasp* imagine that! giving an algorithm invalid data an expecting it to work normally causing it to screw up! oh the humanity!)
C and D cause problems ingame (C visual screw ups, D fs2.puke())
What do the other programs do wrong?
They incorrectly generated boundboxes and sortnorms (which contain a boundbox) for the BSP data.
What does this cause? Incorrect collision, lighting and occlusion detection - which results in slow downs, objects passing thrgouh each other, and incorrect light rendering.
What programs suffer from this problem? All programs except PCS versions >= 1.3.4
-----------
Summary: you problem is USER ERROR, and if when told that like before you get belligerent with me that just pisses me off
squawk on about that stupid "lightwave liberation" crap and i'll make DAMN CERTAIN to alter the code to make sure it checks for inconsistencies common to LWO (that are present even in convertable models) and then have it refuse to convert it
-
Originally posted by Kazan
C) A polygon should be a plane segment - ie all points in the SAME plane
That doesn't apply to models built for FSO does it? Just ones for FS2 Retail right?
-
Ahh Kazan.... I think you'll find the first post with attitude was all yours...
1) I didn't *****...I asked some questions
2) I don't think posting a refusal of help is suitable behaviour for a moderator .... If you don't want to help..just don't post.
3) If I want help....you have already made it clear you won't be the one to offer it, so any future posts requesting help will NOT be intended for you.
4) When I set up the hierarchy in Truespace before importing to PCS the final saved output IS from Truespace. So I won't be needing a LWO plugin.
I hear the sound of dead horses being flogged ...
If any moderators are around, I suggest you lock this thread. Kazan has made his opinion clear, and I have formed a clear opinion of him as a result. Nothing is to be gained from continuing this.
-
if you want to see one of the most visable errors caused by the other converters, pass a ship that is between you and a local star, watch the sun glare, it will pop in and out of exsistance through the hull of the ship. you will also likely be able to fly through these sections especaly if you are in a model converted by these programs as well. also PCS does a better (though it copuld still be improved) job of calculateing mass, most other programs simply give each ship an arbitrary amount (ie 500, for everything from a 1 meter missle to a 7 km supper jug).
non-planer polys are less of an issue with FSO, becase FSO (int HTL mode) triangulates everything. it is however still an issue when converting, becase it's hard to tell wich side of a poly another poly is on when the verts of that first polly arn't all on the same side. this is allso the reason why intersecting polys are very very bad, it's hard to tell wich side a poly another poly is on when they go through each other.
Kaz, I had an idea for fixing the problems assosiated with geocentric pollys, you could simply place any two polys that have the same center into the same leaf of the BSP tree, if you look at the data produced by the V converter, you'll find that there are a lot of polygons held in the same leaf, and interesting thing about BSP trees it is sometimes faster to simply test a few polygons than to recurse everything down to an individual poly.
from the sound of it ShadowPuppet, it sounded like you were takeing a model directly from lightwave and converting it to cob without useing truespace, it's hard enough to find a converter that truespace it's self will accept, it is unreasonable to require suport of half complyant file standards of every dolt in the world who wants to make a cob exporter, Kaz only suports files saved by truespace, if you are still haveing issues with getting your model converted maybe you should try a diferent cob exporter, as mentioned 3DE has a proven track record, you should try that, but still open and save from truespace.
-
I just figured out a way to calculate the mass for accurate (and it's a dynamic programming algorithm too! Oh! Eat that Professor Eulenstein! Yeah!) - Sum the volumes out of the BSP::BoundBox in the LOD1 tree and multiply that sum by a scaling constant (that you could play with in the options screen)
karajorma: that is still a requirement
-
Bobboau, Shadowpuppet does say in his post that he sets up the hierarchy in Truespace and saves it from there. Though I might suggest more people try saving as scenes than models, I've had more success using .scn files for conversion.
I'd suggest ShadowPuppets best bet is to get someone to take a quick look at his model and see if it is this which is playing up or if their is something looping in the hierarchy, most people don't realise that the order you create the lights in actually effects how the model is compiled etc.
And Kazan, I'd appreciate it if you didn't make PCS look for Lightwave models and fail, that really wouldn't make my day ;) hehehehe
-
oh.. i found it
http://www.public.iastate.edu/~kazan/screens/BBCompare2.png
the bottom one is incorrect - and that's how all PCSs before 1.3.X and all the other programs generate pof's - the top is correct
see a problem? http://www.public.iastate.edu/~kazan/screens/Bounding.png
-
oooh, i never noticed those two buttons before. :D awesome! :yes:
*scurries off to test stuff*
ugh, 13 models with bad bits. :shaking:
anyways, thanks a ton. :) they easily picked out my models with the known collision errors, and highlighted a few areas on some others i don't think i tested properly.
one question i do have about these functions: what does it mean when the model only has a single red box around it when in 'sort norm bounding debug' mode only?
the models i see this on have working collision IIRC.
like this one:
(http://www.geocities.com/vasudanad/BoundingBoxOddity.txt)
the turrets are wrong, so i'll probably recompile this particular one later anyway, but it's happened on a few models that i had thought were final and fully functioning. does it mean i should recompile them anyway?
-
you either compiled that with PCS before I fixed the error, or you compiled it with one of the other programs
-
PCS 1.1 a long while ago i think yeah.
well, i'll be recompiling it anyway sometime in the future since there are a couple of other places i screwed up in :)
-
<--------- Is scared to do this with his models ;)