[Scooby_Doo]

Is there a reason why this is happening, besides the obvious poly error.


This is what it's suppose to look like

[Getter Robo G]

er... What are we looking at?

  a.) only 3 parts are actualy modeled and showing (which means if you used Truespace you accidently clicked on those parts and saved the file, thus riuining the model and when you reload it only those parts are inteh model file)

 b.) Only those parts of teh model are textured(or missing textures)... Either they are unmapped sections, OR teh texture names are messed up and you have soem that are correct so it looks splotchy...

Please define as the above screen is either of thsoe two cases... Luck!

[Scooby_Doo]

I've reuploaded the truespace rendered picture again (you may need to force a refresh)

Everything is getting exported to the cob file and using the texture inspect there is a texture applied to them.
The medium sized blob is the cockpit and the other two blobs plus the missing pieces use the same texture.

[Taristin]

I've never had that render window working correctly, and Kazan himself admitted it was merely hacked in. How does the model look in Modelview?

[Scooby_Doo]

I've never had the texture work either, just white.. however the shape is correct...

Modelview shows the same thing, huge chunks are missing.


Oh my Modelview converts it correct
Anything I should be aware of from using modelview? Whats the scaling ratio?

[Nuke]

i have a feeling its putting the polygroups in the wrong lods. convert scn files instead of cob. cobs have a tentancy to stick everything in a selection group, which ****s up hierarchy. converting a scn fixes this. cob files suck.

[Scooby_Doo]

Nope sorry nuke, that produced the same results.     I also went back and collapsed all the objects (baring the cockpit) into one object and tried to convert just LOD 0 and still produces the same results.

Edit: I did my usualy routine to fix stack errors. (Create box then do a intersect boolean) Still produces the same result.

[Starman01]

Try to rotate the converted model in modelview, and then look if some of the faces appear from the other side. I had this problem very often in the past, this is some sort of misunderstanding between truespace and PCS. Most propably those faces are flipped.  Unfortunately, this isn't visible inside truespace, it always renders them.

[Scooby_Doo]

It shows up as complete and non-reversed.  I think I might be having some success with modelview with it.  Is there any tutorials out there (search and google brought up nothing useful) to setup heirachy? I only need to know how to setup lod levels, the other stuff I can import through PCS.

[Vasudan Admiral]

That looks like it might be (intended to be) debris - is it?

Also, I'd advise caution when using modview to convert stuff. I've done a number of tests with simple and complex, small and large pofs - and NONE of them turned out right. IIRC, most of them lacked any sort of collision meshes at all, and the ones that did had massive errors in it. It might be less noticable with fighters though.
My strong advise would be to work out what's wrong with it when converting using PCS, and fix that rather than use modview.

As for hierarchy setup, I posted this in the lithunwrap 1.2 thread - at least the first of which you already glanced over.

=> IPAndrews' Ship Creation Guide
=> Bobboau's PCS guide
=> Karajorma's turreting tutorial

If they don't help, post the cob and I'll give it a look at if you like. Sounds like an interesting error.

[Scooby_Doo]

Nope, I don't use debris on my stuff. I've already got those sites bookmarked a long time ago   
Thats what I'm worried with modelview.
Heres the scene.  http://www.badongo.com/file/1430917

[Vasudan Admiral]

Wow, err, I'm honestly surprised you got PCS to convert it at all. Mine just locked up and didn't respond, even if I leave it for 10 mins, which is longer than any other model I've ever converted.
Deleting all but the lod0 objects didn't help either, so something is very wrong with your basic geometry.

I think I know what it is too - in TS, select just about any face on your lod0 pieces and try moving it around. Especially on the port wing. It does this when I select and move random faces up:

The faces are only partially - if at all - attached to their surrounding polys. Thus when PCS tries to convert it, it's encountering half polys, edges with no polys, disconnected polys, edges and verts - the lot.


BTW, it's far better practice to build your models in one continuous mesh rather than chunk by chunk as you have here. For a start it's much neater, and you avoid issues like these, but it's also a lot more efficient and easier to bughunt/fix because you don't have to go shuffling through subobjects to find the one on which the error is.
I personally find it encourages more detailed meshes too. Ie, you begin to think in polys rather than chunks.

Oh, and hierarchy wise you had everything but the lods named correctly. Lods should be detail0, detail1 and so on rather than detail-1a, detail-1b and so on. I think PCS might just run on whichever object comes first in the hierarchy though, so it probably wouldn't matter much.

[Scooby_Doo]

I've found the cultprit! Sorry after removing subobjects till the mesh appeared correctly, I found it was cockpit glass that was doing it  
 
I've always used detail-1X, and pcs hasn't complained in the dozen or so models.  Its the order in the cob file thats important, not their exact numbering.  (same with sub lod turrets too)

As for using a single object versus multiple, I've found it to be the exact opposite.  Try tracking down a bad part on a whole object rather than just a part of an object (i.e.  remove all non-errorous parts).  Also try building the model from one mesh, it'll take a lot longer than using seperate objects and it's usually easier to UVmap too.  Also don't forget if you do weld them together you'll end up with more polys.  Not to mention if I need to move/resize/delete a subobject it won't affect the others.

I should have done this from the start (we wouldn't have needed this entire thread LOL)  I dread having to do it through, like having root canel drilled LOL

[Vasudan Admiral]

Post disection time!

I've always used detail-1X, and pcs has never complained in the dozen or so models.  Its the order in the cob file thats important, not their exact numbering. (same with sub lod turrets too)

Yeah, thought as much. The "detail#" format tends to be standard though, which is why I use it at least.

As for using a single object versus multiple, I've found it to be the exact opposite.  Try tracking down a bad part on a whole object rather than just a part of an object (i.e. remove all non-errorous parts).

Thing is though, if you build your ships up as one piece, you usually have a pretty clear idea of where the error is going to be based on the complexity of the geometry in various locations, so in the very rare case that you do have a problem in geometry, you know where to look anyway.
I've never had any geometry errors worse than two faces using the same verticies, and even they don't make it past UV mapping. Certainly never geometry errors that crash PCS or modview during conversion or otherwise.
Basically, what you lose by not being able to delete pieces never matters.

Also try building that model from one mesh, it'll take a lot longer than using seperate objects.

If it takes much longer, then you'd have to be doing something wrong. Attaching one piece to another takes a few seconds in any program I've used.

It's usually easier to UVmap too.

Why? There's no reason it would be easier that I can think of. Besides, UVing is really easy on just about every ship anyway!

Also don't forget if you do weld them together and ending up with more polys.

To do so on your ship with the wings, central spar and main hull pieces would add around 48 polys to your ship. I count 56 unnessecary polys on the edges of your port wing.
Either way, it's not many polys at all, and the stability it brings is well worth it.

Not to mention if I need to move/resize/delete a subobject it won't affect the others.

You can box selecting groups of verticies and moving/re-sizing/deleting them quite easily. Again just takes a couple of seconds to select more complex parts.
And how often would you need to do that anyway, really?

[Scooby_Doo]

Yeah, thought as much. The "detail#" format tends to be standard though, which is why I use it at least.

Someone must have used the "-" in the past while I was trying to figure it out.  I hope pcs uses either detail-1 or detail-A (or something to that nature instead of 1a,1b, 1c.

Thing is though, if you build your ships up as one piece, you usually have a pretty clear idea of where the error is going to be based on the complexity of the geometry in various locations, so in the very rare case that you do have a problem in geometry, you know where to look anyway.
I've never had any geometry errors worse than two faces using the same verticies, and even they don't make it past UV mapping. Certainly never geometry errors that crash PCS or modview during conversion or otherwise.
Basically, what you lose by not being able to delete pieces never matters.

I've found out, even with this one, completexy doesn't mean thats going to be whats causing the problem.  For example, I would have been hunting all over the wings trying to find what caused it when it was the glass (which was quite simple) all alone.  Divide and conquer.. Actually I've found when your UVing you can find erronous (sp?) polys rather easily, when something doesn't quiet fit in or is connected to wrong vertices, then theres a good chance you've got an internal useless poly.

If it takes much longer, then you'd have to be doing something wrong. Attaching one piece to another takes a few seconds in any program I've used.

Look at my creature meshes, try doing that with just one mesh    Wait a monent, are you just talking about mesh attach and not booleaning them together? If so then we're argueing about nothing then If your just joining that won't solve geometric problems.

Why? There's no reason it would be easier that I can think of. Besides, UVing is really easy on just about every ship anyway!

If your doing mesh attach, then we're on the same wavelengths, otherwise you'll need to do multiple mesh selects.

To do so on your ship with the wings, central spar and main hull pieces would add around 48 polys to your ship. I count 56 unnessecary polys on the edges of your port wing.
Either way, it's not many polys at all, and the stability it brings is well worth it.

Again if your just joining meshes then theres no change.  If you boolean, look at my creatures again, last thing you want to do is boolean all those spikes 

[Vasudan Admiral]

I've found out, even with this one, completexy doesn't mean thats going to be whats causing the problem.  For example, I would have been hunting all over the wings trying to find what caused it when it was the glass (which was quite simple) all alone.  Divide and conquer.. Actually I've found when your UVing you can find erronous (sp?) polys rather easily, when something doesn't quiet fit in or is connected to wrong vertices, then theres a good chance you've got an internal useless poly.

The cockpit was just a material fault by the looks of it, but the thing is here, that there are massive geometry errors in the wings, but having it split up into objects hasn't helped.
Having it all one solid continuous object would likely have prevented said geometry errors in the first place, but wouldn't have affected the glass either way.

Look at my creature meshes, try doing that with just one mesh

I have actually.
_{(Ignore the terrible smoothing though. It's an old model.)}

  Wait a monent, are you just talking about mesh attach and not booleaning them together? If so then we're argueing about nothing then If your just joining that won't solve geometric problems.

Heh, I take it you use 3ds max then? No, I did mean attaching them, but I mean something closer to booleaning rather than just Max's Attach button. (I say closer, because I don't really like booleans. I much prefer to do anything they would normally do manually.)

Incidentally, why don't you use the Max POF exporter if you are using max?

If your doing mesh attach, then we're on the same wavelengths, otherwise you'll need to do multiple mesh selects.

Thats easy though. And again the increased stability it brings is well worth it, along with better use of the available texture space, since everything rendered to the model will actually be seen rather than hidden inside another piece.

Actually, that reminds me of another reason for solid continuous meshes - shadows. If shadows are ever reintroduced in the way Bobboau originally designed them, multiple piece geometry like this will cause some really weird effects, since it works with solid or mostly solid objects.

Again if your just joining meshes then theres no change.  If you boolean, look at my creatures again, last thing you want to do is boolean all those spikes 

For small extrusion details like that, no - there's no need to boolean them. Neither though is there a good reason to have them as an alltogether separate object from the hull. In such cases, the attach button in max is perfect.

Using your model here as an example, were I building it I'd have the hull, engines, wings and cockpit neatly joined (meshwise) together, and then have the tiny details like the guns a part of the same object, but not nessicarily connected to the rest of the mesh. In max terminology, my rule would kinda be 'Boolean the big things, attach the small things'.
So by the time it's ready for conversion, PCS only has to deal with one piece of geometry rather than having to merge them all together just to create the hull as you currently have it do. That's likely where errors are going to arise.

I'm not worried though - as your models become more complex, I'm fairly sure you'll learn to merge them into one mesh for the same reasons I did.

[Scooby_Doo]

The cockpit was just a material fault by the looks of it, but the thing is here, that there are massive geometry errors in the wings, but having it split up into objects hasn't helped.
Having it all one solid continuous object would likely have prevented said geometry errors in the first place, but wouldn't have affected the glass either way.

I don't think it was a material problem, since it had only one simple texture thrown on it.  Actually I used to have everything in one object but the stack fault errors drove me up the wall. Thats one of the reasons I quit merging them unless it's necessary (for shining maps).  Plus it's much faster to leave them as is.  I do merge objects that have a wide angle connection, but for tight corners or areas that are never seen, no sense waisting time. Oh ya, seperate objects make it easier to LOD, just delete.

Actually for the creatures most of the objects (not the spikes) will be merged into one object (for shine maps)

Incidentally, why don't you use the Max POF exporter if you are using max?

It never has worked for me, usually crashes.

Using your model here as an example, were I building it I'd have the hull, engines, wings and cockpit neatly joined (meshwise) together, and then have the tiny details like the guns a part of the same object, but not nessicarily connected to the rest of the mesh. In max terminology, my rule would kinda be 'Boolean the big things, attach the small things'.
So by the time it's ready for conversion, PCS only has to deal with one piece of geometry rather than having to merge them all together just to create the hull as you currently have it do. That's likely where errors are going to arise.

Yup large areas are booleaned together and trimmed, small or hard to see connections are left as is.. such as the base of the starboad wings.

I'm not worried though - as your models become more complex, I'm fairly sure you'll learn to merge them into one mesh for the same reasons I did.

Yup and then comes an error and you end up tearing it all apart again. 

Edit: ugh i wish quoting was easier to do LOL

[Vasudan Admiral]

I don't think it was a material problem, since it had only one simple texture thrown on it.

Just tried a cube with that material applied, PCS interpreted it as no material at all (ie, it appeared solid red in modview). So there is definitely a problem there.
Anything the game finds no texture on will be completely invisible in game IIRC. So you'll actually have no glass over the cockpit if you try converting the model with that on it.

Actually I used to have everything in one object but the stack fault errors drove me up the wall. Thats one of the reasons I quit merging them unless it's necessary (for shining maps).

(The POF exporter) never has worked for me, usually crashes.

Ok, I'm beginning to think there may be something you're doing during construction that....'shatters' the geometry really badly as I demonstrated with the pic earlier. Add to this that you say the POF exporter always crashes, and the fact that you have to do a lot of error hunting - and something's definitely going wrong.

Also, if you're refering to the error in PCS where you get a message to the effect of 'Stack overflow protection was engaged', then I'm 100% certain that'll be because of this shattered geometry.

By splitting models up as you now do, you've certainly not fixed the stack fault errors - just gotten the number of them in each object down to something that PCS can just barely manage to work through - though it will often choke on a particularly bad bit.

I have absolutely no idea what could be causing such bad shattering, but if you've been having these sorts of crashes for a long while now, it sounds like it must be something you do with every or at least most models. Any ideas there?

Plus it's much faster to leave them as is.  I do merge objects that have a wide angle connection, but for tight corners or areas that are never seen, no sense waisting time. Oh ya, seperate objects make it easier to LOD, just delete.

Lodding is a valid point for separate objects - but that's easy enough to do already by welding verticies together when talking about a single solid object. Likewise deleting all those attached but not mesh-joined pieces is easy enough without having those pieces as separate objects.

I'm not worried though - as your models become more complex, I'm fairly sure you'll learn to merge them into one mesh for the same reasons I did.

Yup and then comes an error and you end up tearing it all apart again. 

I've never gotten any geometry errors more serious than the odd unwelded vertex or the like. As I said before - nothing's ever crashed for me because of a geometry error. You have to have really serious geometry faults for it to crash PCS.

[Nuke]

i used to do solid meshes, then taylor got rid of all the bugs and freespace seems friendlyer tward multimesh and non-solid objects. back in the old days, i used to use *cringe* booleans to join sections. this caused problems. so i started doing the booleans on copys of the models i wanted to join, then created new virtices on the original and moved them to the same coords as the new ones created on the booleaned copy, after this i extruded and re-creades the section o wanted to attach. it was time consuming and always added way too many polys, but it worked really well for making a stable model. nowadays i just subtract the one model from the other, and remove the faces on the inside that you couldnt see anyway. its better for keeping a good poly order, thus allowing you to use transparency in the same model and texture without artifacts. the only ship i made that has any artifacts is the pb sepulture, which was booleaned together. save my first couple of models, ive never had any conversion trouble as shown in this thread. i attribute it to not hopping formats (which you have to do when using free modeling tools).

i still think that moving from per-subobject rendering to per-texture rendering would be a massive performance booster. things live vwep and heavily animated models would be better handled, as would capships with all their ****ing turrets.

[Scooby_Doo]

But then I rebuild the glass reapplied the texture and it didn't complain, so who knows, vertex data could have been corrupted during the conversion from max->3ds->cob->pof. LOL  Yes I'm quite aware of invisible objects, in fact I"m fixing one on the destroyer as I'm writing this  

Well it's either shattered geometery, which STL modifier indicates no errors, or the more the rounding in truespace.  Well if I find the bad one and redo it so it doesn't fail and everything looks good in fs2 then theres no error. Course if there are errors then merging them into one big object will just result in a big object with lots of errors then.

Well as for this error, I've had it one other time, with one of sagas ships.  I think it was due to it being converted and reconverted over and over that broke something or flipped polys.  I ended up just building a new one that looked like the old one.

Actually I haven't had the game crash in quite some time now... that was due to a dock pathing problem if I remember right. (course i shouldn't speak   LOL)

HORRAY At least I can read now that pirates day is over LOL

btw, is anyone having troubles login in to photobucket? It seems to stall here.