[chief1983]

Yeah, I'm definitely getting a lot of crashing on the .cob export as well.  I don't think I've saved a .cob successfully in a long time.  It sometimes seemed like the export worked, but then crashed anyway, now it seems it's not creating anything near a complete file.  I tried exporting a retail ship to cob (capital03 I think, the big Vasudan one), it crashed during export, and when opening the cob in pcs2, most of the geometry is gone.  So yeah, cob export seems to need some work still.  Might I suggest fixing that, and then making sure everything has been committed for a RC2 release, to squash any more remaining bugs?

[Bobboau]

"it would also be really cool to be able to open VP files and look at any models in there."
well if you have PCS2 associated with POFs you can use any existing VP extractor to open POFs by opening them from there.

we should probably make an installer.

"Might you be able to generate at least some initial hierarchy based on the object names?"
this is basically what I was thinking when I said "some hacked together solution".
basically looking at the last letter in the object name and if it's 'a' -> LOD0 'b' -> LOD1 ect... if it's name starts with "hull" or "detail" its the parent of that LOD, stuff like that.

[chief1983]

As long as it's consistent and well-documented, hopefully within the app even, maybe even a one-time popup describing what's required when someone tries to do obj import.  Or at least some included help files or something, so we don't have to rely on online stuff that always gets moved around.

[Scooby_Doo]

Could it be possible to tell you exactly what subobject caused a bsp error?

[Kazan]

yes and no, it's nice to have an internal format not dependent on POFs, but the way geometry is organized is horrifically ineffecent. if you would have used a index based representation of the geometry rather than a pure vertex based representation (that is a list of vertexes and polygons represented as a list of indexes into this list of vertexes rather than polygons being simply a list of vertexes) it would have been several orders of magnitude better. most (all that I am aware of) file formats are arainged like this and it's the cause of 90% (this is an understatement) of the time BSP compiling takes (tree generation for extremely complex models only takes about less than half a second, converting from PCS2 internal geometry to indexed geometry takes 30 seconds or more). the first thing I want to do after release is change this, because it's the biggest limiting factor in the programs design.

the format was NOT designed for speed of rendering - index based is not easily edited.  it's designed for easy editing, not fast rendering.   Making the change that you wish to make will limit our ability to implement promised features on the roadmap - such as geometry editing capabilities, etc.

Internal formats for games, and internal formats for editors have vastly different requirements - incompatible ones in fact.  The differences between PMF (easily editable, not suitable for high performance) and POF (difficult to edit geometry, suitable for high performance in previous generations) highlight the differences well.

[Kazan]

"it would also be really cool to be able to open VP files and look at any models in there."
well if you have PCS2 associated with POFs you can use any existing VP extractor to open POFs by opening them from there.

already covered by file associations

we should probably make an installer.

for 2.0 official release we will

"Might you be able to generate at least some initial hierarchy based on the object names?"
this is basically what I was thinking when I said "some hacked together solution".
basically looking at the last letter in the object name and if it's 'a' -> LOD0 'b' -> LOD1 ect... if it's name starts with "hull" or "detail" its the parent of that LOD, stuff like that.

not necessary - if your lods generate out of order it's easily corrected in the header editor, and "a" vs "b" stuff is already handled by being a child of it's lod

[Vasudan Admiral]

well if you have PCS2 associated with POFs you can use any existing VP extractor to open POFs by opening them from there.

Well I was more thinking along the lines of modviews VP browser thing, but that would probably not be much more useful overall.

this is basically what I was thinking when I said "some hacked together solution".
basically looking at the last letter in the object name and if it's 'a' -> LOD0 'b' -> LOD1 ect... if it's name starts with "hull" or "detail" its the parent of that LOD, stuff like that.

Cool then. Do you have any way in mind to do auto-gen info like firepoints?

not necessary - if your lods generate out of order it's easily corrected in the header editor, and "a" vs "b" stuff is already handled by being a child of it's lod

That's the problem though - .obj doesn't appear to support hierarchy, so any PMF convertor for that format would need to figure out some of it based on object names.

[Kazan]

then we'll have to allow drag'n'drop on the hierarchy tree - though i would prefer NOT to support any object format which cannot store such information

what do you mean autogen info like firepoints? light's another thing .obj doen't support?

[Bobboau]

the format was NOT designed for speed of rendering - index based is not easily edited.

I don't think so, let me make a simple example, what if I have selected a point and I want to move that point, in an index based organization you need to know the index of the vertex and you move it, in the vertex based organization you need to know the index to all the polygons involved and the index of what that point is in each of those polygons and you need to move each of them separately. this is a vastly more complex and error prone undertaking than if it was index based.
models are not collections of unrelated polygons in space they are collections of points which make up polygons in space.
not to mention the difference in memory requirement or any algorithm that works on inter polygon relationships.
what factors were you considering when you decided this would make things easier? I came to my decision after trying to actually implement the geometry editor and not being able to implement the simplest of editing functions, and determining that our current method slows down virtually all polygon/vertex/normal operations by rediculus factors.

[Bobboau]

then we'll have to allow drag'n'drop on the hierarchy tree - though i would prefer NOT to support any object format which cannot store such information

ummm... drag and drop hierarchy editing is already in place...

but the thing with obj support is it's extremely common, and it supports everything POFs do other than the hierarchy, specifically smooth groups, I'm not sure how well supported in other file formats, but it's there.
I'm planning on obj to be a partial model (ie submodel) file format primaraly however. I'm expecting it's primary usage will be to import/export one subobject at a time, so if someone notices a glitch on a ship's hull they don't have to reimport the whole model, and all the old data from the old POF, just the damaged part. it would also allow people to make chunks of models, you could simply make the hull of a capship, import that, then make a turret, import that, setup the turret if nesisary, then copy it as many times as you need, this will bring the editing capabilities of PCS2 into more of a light. (and as you just demonstrated a lot of people who should know about PCS2s editing abilities don't)

[Kazan]

i misunderstood you a bit on what you were talking about with the PMF format changes - you're just talking about a master list of vertexes and then each polygon contains a list of numeric references instead of individual copies of the vertex

i did it this way for two reasons

A) laziness
B) independant polygon editing

B can be done with your way, you just have to split the vertex into two when needed.


as for performance issues with the render window... i've seen none what so ever (Then again, look at the rig in my sig) though on my weakling laptop i see no problems either - so i don't know where this "dismal render performance complaint" is coming from: it's an editor, not a game.   Your VBO code breaks a LOT of things at this point - including all context editors (they're wrapped in the else part of your if statement)

VBO rendering can be put off till 2.1 - when we'll be implementing the main features it may interfere with as well.

I'll add that and switching to vertex list PMF into the 2.1 roadmap

[edit]
oh.. and we need to SERIOUSLY write a tutorial and full help document.

[chief1983]

If you don't already have PMF Version support in the PMF format, you might want to add it before PCS2.0 goes final.  If you plan on making serious changes to the format, not only would future versions know which version they're dealing with easily, older version would have a reliable way to tell if they can or can't open the file based on that version alone, and then also know why they can't, and generate a usable error to the user.

[Bobboau]

what did you think I meant?

I have no problem putting it off for a while, it's mostly working at this point (I do have context working on my machine but there seems to be issues on other machines, the 'flaming' error I'm sure you got quick of seeing in a hurry). but I can assure you the performence levels were quite apparent on a 32 bit Athlon 3000+XP + Radeon 9800 128MB, I can only imagine how slow it is on some of our lower spec machines.

[Kazan]

If you don't already have PMF Version support in the PMF format, you might want to add it before PCS2.0 goes final.  If you plan on making serious changes to the format, not only would future versions know which version they're dealing with easily, older version would have a reliable way to tell if they can or can't open the file based on that version alone, and then also know why they can't, and generate a usable error to the user.

light years ahead of you - the very first version of the PMF format to save to file had a version tag

[Getter Robo G]

Kazan, do you or Bob have the very latest build? (who' link)

I ask cause the last two builds do not show textures (or even appear to load model except for the bar progress) PCS1 did though. Unfortunately I deleted the build I was previously using so I don't know the date but I know it showed them.

Also did Gary make that higher poly cob2pof .exe (the architect oriented version?) Could that have something useful in it for you?

[Bobboau]

are you trying the build in my sig, I just synchronized with CVS and everything looks fine here. do you see anything in non-textured/wireframe mode?

[Kazan]

Also did Gary make that higher poly cob2pof .exe (the architect oriented version?) Could that have something useful in it for you?

no.. i used everything gary ever had to contribute in 1.x

[Getter Robo G]

Ok strange, here is the older model I converted no problem and DOES show up...(although I did this with pcs1 last year. (Destroyer)

Now second file is the newer Battlecruiser by same artist, no idea why model does not load right nor textures show. any ideas?

PCS1 loads it and pofs.

I hope this brings something to light for the program. If it's something on the model end np, just thought it was worth mentioning.



[attachment deleted by ninja]

[chief1983]

I think this loading dialog box could be modified a bit to make it possible to see all the text during a file load (see attached).  Also, I received an error about an unrecoverable geometry error, and thinking of children, dammit.  Is that an error we're supposed to see, or does that mean it went somewhere it wasn't supposed to? 

[attachment deleted by ninja]

[Bobboau]

was the message
"*ERROR*:uncorectable geometry encountered!

Truly this is the darkest of hours."

if so I must see this object which has defied my geometry filter.

if you get that message it means you have a polygon which is concave and my algorithm was unable to correct it. now you are no worse off than if the geometry filter did nothing, however there is a strong possibility that you will have rendering and collision issues, and perhaps BSP or smoothing errors (among many other possible nightmare scenarios) for that polygon.

now I thought that I had covered all my bases with that thing so I am very interested to see exactly what killed it, the only thing I can think about that could have done it is if it was both concave and severely non-planar.