[ShadowPuppet]

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 )

[Flipside]

Hmmmmmm... non-solid or intersecting polygons can sometimes cause infinite loops and crashes, I seem to recall that could happen on older versions?

[Kazan]

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

[jdjtcagle]

Question: Can the source code project take out limitations on POF format, like have it read truespace files instead. Or is the Ferrium

[Flipside]

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

[Kazan]

reading truespace files = extremely MORONIC from technical standpoints

Crash++++++++
MissionLoadTime++++++++

[ShadowPuppet]

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!

[Kazan]

that's odd

[Bobboau]

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.

[Kazan]

the render window is indeed finicy - i should probably set to to not render while a conversion is taking place

[ryuune75]

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....

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)

[Kazan]

cob2fs2 doesn't generate the data correctly and therefore it's lax about geometric snafus

[ryuune75]

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.

[Kazan]

ryuune75: then you don't know about it's collision and lighting problems, etc with models generated with it

[ryuune75]

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?

[Kazan]

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

[ShadowPuppet]

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?

[Kazan]

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

[ShadowPuppet]

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.

[Flipside]

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