[ak-73]

Hi, first post, so please be gentle... 

I have been coding the last few days on an import/export script for .pof files for Gmax and 3dsm4+.

The import side has been finished already, the export side awaits implementation.

Is there any interest in such a script around here? Is there some site around where I can upload the finished product eventually?

As a side note, it might be interesting to mention how Gmax export works: I am writing output data to listener window. This output
gets grabbed automatically by a small app that is based on the NWMax tool from the Neverwinter Nights modding community. It also follows
a specific format that gets passed to another small .exe (t2b) that comes from the GTA modding community (yes, I get around...  ) and which
translates text into binary format.

I've written similar importers/exporters already in the GTA community and they work simultaneously for Gmax and 3dsm4+ due to the custom functions I employ.

Any interest in that? Or is Truespace all-pervasive?

Alex

[skygunner58203]

i'd be willing to give it a shot.  just need to download gmax

[ak-73]

i'd be willing to give it a shot.  just need to download gmax

Is there a (reference) model that uses the GLOW chunk?

Plus, as I have said, export awaits implementation so you might want to wait a few days. It shouldn't take too long to implement though. If I encounter any problems, I will post questions here.

Alex

[skygunner58203]

i'm actually not sure....never put glow on any ships other than thrusters.  I usually do finishing touches in pcs2.  still learning to texture and map tho.

[chief1983]

That sounds pretty awesome.  By the way, have you seen this?

[ak-73]

That sounds pretty awesome.  By the way, have you seen this?

No, hadn't seen it, thanks. I don't code things like this for money though. Plus I probably don't want to implement support of the collada format. But since it's going to be an open source maxscript anybody else will have the permission to modify the script to import/export collada files accordingly and earn themselves the money.

I'd be quite content if it was possible to import models into gmax (and therefore 3dsm4+), modify them and export them into the game again. Or to set up a new model in gmax/3dsm and to export directly.

Alex

[chief1983]

You're more than welcome to pass on accepting the money then, that was just added incentive

I just thought since you seemed to be fairly adept at working with various model formats we might be able to persuade you to help out with that project as well, it's not really related to this though.

[Nuke]

pretty cool, but i like max 8 better and apparently im good at making models that don't get chewed up by the max exporter. but still the more tools in the tool box, the easier it is to do the job.

[ak-73]

I seem to have arrived at the most difficult point of the script - how to organize the geometry data (vertices, normals, etc) for export according to the .pof format. Is there any documentation on this? Does anyone have an algorithm for that (in whatever language)? Any kind of information would be appreciated because otherwise I'll have to figure it all out myself from scratch...

As for the I/O script... after release I'd like to hear some feedback by artists...things that could be improved to make their life easier.
 
Alex

[Water]

http://alliance.cvs.sourceforge.net/alliance/pcs2/

[ak-73]

Thanks - the bsp splitting looks somewhat complicated; I'll have to take some time to get through this.

Alex

[Vasudan Admiral]

The biggest problem tools that save POFs have had in the past is with collision meshes. It's taken Kazan and Bobboau a long time to get PCS2 to the stage it's at now, so I'd definitely recommend a PMF rather than POF export script.

PMF is the format PCS2 uses as its internal format, and it was developed to be a lot easier to work with than POF structure-wise. Since PCS2 can open these files and then convert them to POF already, it's supposed to be the ideal midpoint between 3d application formats and POF files where the old COB/SCN files are not used.

Applications that directly save POFs have had a long legacy of unstable end results that cause in-game holes, missing polys and sometimes the complete lack of a collision mesh. Not saying it can't be done, but it would be a lot more work than it would need to be.

Oh, and:


That's a pretty awesome way to go about a first post BTW.

[ak-73]

The biggest problem tools that save POFs have had in the past is with collision meshes. It's taken Kazan and Bobboau a long time to get PCS2 to the stage it's at now, so I'd definitely recommend a PMF rather than POF export script.

Collision meshes? I haven't taken a look at that issue at all yet. However, currently my intention is to re-use the MakeTree function of PCS2 to create a small command line tool to convert data exported from max into .pof bsp data.

PMF is the format PCS2 uses as its internal format, and it was developed to be a lot easier to work with than POF structure-wise. Since PCS2 can open these files and then convert them to POF already, it's supposed to be the ideal midpoint between 3d application formats and POF files where the old COB/SCN files are not used.

I agree, however, it seems quite easy to reuse only the bsp tree building algorithm. My export tool will be able to pass the output to a configured app automatically for post-processing. The first step will be to convert the ascii output of gmax into binary format. As a next step my current intention is to pass the geometry output data of the exporter to the MakeTree function and use the output of that function to finalize the .pof. The gmax user will not notice anything of that, ideally.

Applications that directly save POFs have had a long legacy of unstable end results that cause in-game holes, missing polys and sometimes the complete lack of a collision mesh. Not saying it can't be done, but it would be a lot more work than it would need to be.

Oh, and:


That's a pretty awesome way to go about a first post BTW.

I've brought along a preview of the io script (so that you know that I am not just talking hot air): 

http://rapidshare.de/files/39956327/POF_IO_preview.ms.html

The import side is pretty much functional, although glow/glox/sldc are not supported and it could use some polish. I decided to not represent various ship parts by the ubiquitous dummy helpers but by various geometry nodes. Form and color should give an immediate clue as to what the object you're seeing is. Please note that the main object and all subobjects will have their own rollouts for manipulating the custom attributes.

Wrt all aspects of the import side I would like to hear some early feedback by 3d artists how they think import should be set up. This here is just a first pass and probably not all aspects of a .pof are represented properly for a 3d artist. To make a long story short: criticism/feedback is welcome.

2ndly and more importantly I need some help. The MakeTree function expects input in a specific form. What assumptions does the function have to make about the input data (and this means especially the polygon_list)? I would assume the main problem here is in grouping triangles as polygons, right? Passing only tris (as I noticed takes place in the .ase section) is probably inefficient, right? So what do I do about this? Do I expect the max user to specify which tris compose a polygon or would it be preferrable to generate polygons automatically from exported triangle data? And what about vertex data? Any specific assumption that MakeTree makes wrt that?

Alex

[Vasudan Admiral]

Heh, not a Max modeller nor a coder sorry - so I can't even help test it let alone code it.

Hopefully once you're at the need-testers stage of development we can get you an announcement and/or a highlight to try and grab the right peoples attention.

About the collision mesh, well basically there is none - the game just uses the display model for both roles ATM. The problem is that all POF saving apps we've had (cob2fs2, segletuch, cob2pof, modview32, the current Max exporter, PCS and PCS2) have or at one time had massive collision detection errors in-game, rendering those versions all essentially useless for stable mod creation. Only late versions of PCS1 and current versions of PCS2 have overcome these errors as far as we have been able to tell.

That's why I think you'd have a far easier time writing a PMF exporter and letting PCS2 handle all the dirty POF work.

[ak-73]

Heh, not a Max modeller nor a coder sorry - so I can't even help test it let alone code it.

Hopefully once you're at the need-testers stage of development we can get you an announcement and/or a highlight to try and grab the right peoples attention.

About the collision mesh, well basically there is none - the game just uses the display model for both roles ATM. The problem is that all POF saving apps we've had (cob2fs2, segletuch, cob2pof, modview32, the current Max exporter, PCS and PCS2) have or at one time had massive collision detection errors in-game, rendering those versions all essentially useless for stable mod creation. Only late versions of PCS1 and current versions of PCS2 have overcome these errors as far as we have been able to tell.

That's why I think you'd have a far easier time writing a PMF exporter and letting PCS2 handle all the dirty POF work.

The point is this: the bsp generation is sufficiently complex for me to not try to reproduce it in max when I have the source of pcs2 at hand. What I can do is pass the output of gmax to a command line tool. So the current plan is this: I write a suitable command line tool myself... The first step of it will be to pass the ascii output of gmax to another command line app (t2b) to convert it into binary form. Then I will locate all the bsp segments in the converted file and pass it directly to the generation routines of pcs2 itself and finally save the output of it all as .pof. If all goes right the end user will not notice any intermediate step. It will just look like the gmax has been saved directly as .pof.

So to make it short: if the routines of pcs2 are working, so will the gmax export. As far as the bsp trees are concerned, the output will even be *identical*.

The only problem with that is if their is some bug fixing/update in pcs2 itself, my command line tool will also need a rebuild. What would be best was some .dll that exposes this bsp generation to other apps (as all other aspects of .pof building seem to be fairly trivial).

Alex

[chief1983]

The routines of PCS2 are working, but they're a living codeset, not necessarily 100% done yet.  So, instead of simply allowing them to develop independently and making your tool only dependent on what you code, you'll be making it so that any time a major issue is discovered with PCS2, you'll have to update your tool as well.  If you used the PMF format, you wouldn't have to worry about any changes to PCS2, unless they relate to the PMF format itself but I don't see that happening, at least not in any way that breaks current compatibility.  Kaz hasn't change it since started releasing PCS2 preview builds, so I think it's very stable at this point.  If you were going to copy routines, or modify them from PCS2, you'd probably be better off taking the cob importer and seeing how it generates a PMF instead, since that has been much more stable as well.  I believe that you can make it work your way, it just seems like it will become a nuisance to keep up to date, and likely be less accepted down the road for not using the PMF format.

[ak-73]

Another possibility would be, as mentioned, if the pcs2 folks would put the bsp generation into a .dll. I realize what you're saying, it's just that I am not too fond of (another) intermediate file format. Ideally it should be possible to convert directly from max into the format of the game engine.

Consider the people who are looking for a collada <-> pof conversion tool. I bet to them having a bspgen.dll would also be helpful. As I have said - it's the only non-trivial part in .pof generation and as such it might be helpful to unify it across tools. One way to do that is to enforce use of the .pmf format. Another would be to create a .dll and allow tool creators to make use of of it. Updating would then be as easy as replacing the .dll.

In any way I will most likely go ahead with .pof export. If the pcs2 routines are somewhat stable, that is good enough for the moment, I'd say. If major bugs aren't fixed every month, the hassle might not be all that big, I'd say.

Do you happen to know how face smoothing works with the pmf format and how the facet_angle property of the pmf polygon figures into that?


Alex

[chief1983]

Actually the people wanting Collada<->POF dont' mind if it's Collada<->PMF<->POF.  People will be using PCS2 regardless.  As PCS2 uses PMF internally, going from Gmax to POF, then would require making PCS2 convert to PMF internally, and then reexport to POF again.  You're really just wasting the time it takes to make an initial POF, since it will likely be scrapped anyway.  Granted the BSP may be cached, but as that's one of the most volatile things, any update to PCS2 would negate the BSP of a model made with the previous bspgen.  Collada support will very likely be DAE->PMF and vice versa.  However, if you want a bspgen dll, you're more than welcome to make one yourself.  All the code is there.  But you've agreed that bspgen is a non-trivial portion of the process, so I'm just wondering why you're so intent on doing it when it's not really necessary.  Hopefully any docs on the PMF are in the code, if not Kaz would probably have to answer your questions, or someone who has had more experience with PCS2.

[ak-73]

Actually the people wanting Collada<->POF dont' mind if it's Collada<->PMF<->POF.  People will be using PCS2 regardless.  As PCS2 uses PMF internally, going from Gmax to POF, then would require making PCS2 convert to PMF internally, and then reexport to POF again.  You're really just wasting the time it takes to make an initial POF, since it will likely be scrapped anyway.  Granted the BSP may be cached, but as that's one of the most volatile things, any update to PCS2 would negate the BSP of a model made with the previous bspgen.  Collada support will very likely be DAE->PMF and vice versa.  However, if you want a bspgen dll, you're more than welcome to make one yourself.  All the code is there.  But you've agreed that bspgen is a non-trivial portion of the process, so I'm just wondering why you're so intent on doing it when it's not really necessary.  Hopefully any docs on the PMF are in the code, if not Kaz would probably have to answer your questions, or someone who has had more experience with PCS2.

I think most of the stuff I have already figured out from the source code, however, theorizing over code is always error-prone. As for the bspgen.dll, I would be very much willing to create it, if the pcs2 folks would be willing to subscribe to the idea of using the .dll themselves and updating the .dll code whenever an update is necessary. I don't think it would make more work once the .dll was properly set up. If they are not interested, this would defeat the purpose of the .dll, I think.

Maybe you can help me with this question though: let's say I import a model into gmax and modify it, then I export it again with my to-be-finished exporter. Do I have to do anything but to replace the original .pof in the .vp? Do I need to manipulate some config data when adding turrets, thrusters, weapon slots, etc.? Because at some point I will need to test if the export works.

Alex

[Vasudan Admiral]

Ideally it should be possible to convert directly from max into the format of the game engine.

Do I have to do anything but to replace the original .pof in the .vp? Do I need to manipulate some config data when adding turrets, thrusters, weapon slots, etc.?

Ah, I think I see where you're coming from here, but I don't think that concept quite applies to the FS modding process as it does to other games.

Most games use a model format as little more than a geometry container file. All the nessecary data related to that geometry is contained in an accompanying text file of some kind. For that kind of setup, a one step modelling program -> ingame model format conversion is ideal, because you're not (usually) constantly re-converting to tweak the geometry itself - you're just tweaking the text file.

For FS however, the POF format stores multiple pieces of geometry as well as loads of text based data; mostly of co-ordinates and their associated commands and names etc. This data does need a lot of tweaking to produce quality models, and that's where a one-step conversion would definitely not be ideal, as it would mean waiting while the BSP was generated during re-conversion for every tweak you wanted to make. Given the complexity of current models, that would mean a long time waiting each time you needed to say, adjust the radius of a subsystem or something.

I can almost gaurentee that this kind of tweaking happens on all models (certainly all release quality models), and that pretty much every modeller would then open the POF in PCS2 to make the adjustments. As soon as they do that, PCS2 is almost certain to purge the BSP cache anyway and resave it itself, in effect cancelling out all the work you would have done to get the export script producing stable POF models. (We need to do this already with the existing POF exporter for Max to correct bad collision detection problems its use often produces.)

Basically, the PMF format was designed for exactly this sort of intermediate step that the FS modding process requires.