[ak-73]

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.

Yes, I am not used to this "data-driven" process. Yet. With GTA VC, vehicle or pedestrian replacement was a straight-forward process.

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.

That's a consideration: how long does take bsp generation under pcs2 on average?

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

My io script allows to store all the pof data on an object in a (g)max scene. There's a user interface for most custom data, like radius, properties, center of mass, etc. I could also very easily add a checkbox to the export rollback with which a modeller could signal that no bsp data has been changed. This would allow my command line to simply re-use the existing bsp data of subobject chunks without recompilation of bsp trees.

That much is no problem.
In theory.

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

No offense intended but my question was though whether some other files needed to be changed for modification of an existing model. Does the .pof contain all relevant data related to the model itself or do some .tbl failes for example require adaption? If I finish the exporter over the weekend, I need to be able test the output by putting it into the game. That's why I got to press this issue.

Alex

[chief1983]

A table entry is usually created after a model is done, or at least after it has been well defined.  The table only refers to names in the POF typically, placements of those things are controlled in the model, and statistics for those things are in the table.  So a turret's location and movement is defined in the model, the weapons loaded into the turret are defined in the table.  A subsystem's name, location and size are all in the POF, the hitpoints and other flags are in the table.  It depends on how you want to modify an existing model.  A lot of modifications can already be done in PCS2.  Complete geometry makeovers can be done without editing a table file though, as long as subsystem names are maintained.  You may wish to add features to a model that require adding entries to the table though.  But the original retail table info will usually suffice for most edits I think.  Also, you won't need to recreate a VP file to replace a retail model.  Just create a mod folder, put a data folder in it, and a models folder in that, and drop the model there.  If it has the same name it will take precedence over the VP model.

BSP caching is something that PCS2 does already as well, but unless you maintain the same versioning, going between the two apps will still entail a regeneration of the data every save in PCS2 at least.  Also, allowing people to simply keep the cache means that it could easily become unreliable, when people cache the BSP even when your bspgen has been upgraded.  Using the same code to decide if it should be updated automatically would be best.

BSP generation is entirely dependent on the complexity of the model, and as that increases, it only takes longer.  It could take 10-30 seconds for a sufficiently complex model, maybe worse for works of art like Omni's Battlestar or Brand's ISD, and that's on a fairly modern computer.

[ak-73]

Very informative, thank you. Right now I am considering configuration of the io script to store the location of a fs2 installation. It sounds like it might make sense if some .tbl data could be configured from the io script directly based on the geometry set-up. The less often one has a need for anything else but the script when creating a model, the better. But then again I should first focus on getting the basic io working...

As for caching... how about asking the user per messagebox when a version difference has been detected? Is there some batch update functionality? Like bringing all .pof in \models to the new bsp version?

Alex

[chief1983]

I would recommend just using a general save dialog, and at most save the last used location.  I wouldn't try to force people to save to an FS2 models folder all the time.  There is no current batch process, although I think someone (maybe even me) proposed it in the past.  Might not have been mentioned though, but I know I've thought of it.

[Flaser]

There is another reason why the PMF format was introduced: the POF specifications or altogether the POF format itself may be changed in future versions of Freespace Open.

This is quite likely, as collision detection is one of the greatest bottlenecks of the current engine and it's closely tied to the models themselves.
Further features like decals, damage modeling etc. may also invoke a new approach to storing geometry data.

[ak-73]

There is another reason why the PMF format was introduced: the POF specifications or altogether the POF format itself may be changed in future versions of Freespace Open.

This is quite likely, as collision detection is one of the greatest bottlenecks of the current engine and it's closely tied to the models themselves.
Further features like decals, damage modeling etc. may also invoke a new approach to storing geometry data.

@chief: I didn't think of forcing users to save their pof to a specific folder. I was just thinking that it might (or might not) make sense to update a related .tbl automatically if you add a turret to a model or something like that. Since I haven't opened a .tbl yet ... it was just a passing thought.

@Flaser: I would recommend keeping backwards compatibility.  Anyway, if you add new chunks, expanding the io script isn't too much work either. As for collision detection and damage modeling, you might want to draw on my knowledge of GTA. Perhaps it doesn't have to involve any new data chunks, just maintaining a specific naming scheme (vehicle parts in GTA have suffixes _ok and _dam). (Although GTA loads models and collision data seperately - the collision data must get loaded immediately in any case... if you really get fast in GTA, you can run into buildings whose geometry hasn't been loaded yet. )

As for the news on the io script: I have been able to successfuly export and reimport the geometry of .pofs. My estimate is that it shouldn't take me longer than 3 days to get a beta out... lol, which means that it probably will take until September...

Alex

[ak-73]

Newsflash: the first beta of the IO script is 95% finished. Import/Export on GMax works. Just some finishing touches and then testing whether it works equally on 3dsm (it should because the special formatting I used is set-up for parallel development) on a friend's computer and we're good to go for a first flight.

Alex

[ak-73]

We have a Beta Release:

.POF Import Export Script v0.9: http://rapidshare.de/files/40070611/fsmax_v09.zip.html.
Works both for 3D Studio Max 4+ and GMax.

I did not get to test any exported models in-game yet but re-import works pretty well.

Therefore: Beta testers wanted. I'd like to hear some feedback over this.

Future versions will include more extensive documentation, a helper rollout for creating various nodes (Waypoints, Thrusters, etc.),
moi calculator, perhaps some rearrangements in the representation of chunk data, etc.

Questions? Suggestions? Bugs? Feel free to post here.   

Alex

[Aardwolf]

(although you seemed to refuse to hear this argument earlier)...

What's wrong with what you're doing:

The PMF format is capable of handling any changes that might be made to the POF format. If you export directly to POF, then in order to make any edits to the POF data, you'll have to open it in either PCS2 or the importer/exporter anyway. PCS2 already has all the features you've described, and then some. Furthermore, PCS2 is usable for more modeling programs than just MAX... anything that can be in some way converted into a .cob file can be opened with it, and it may eventually get expanded to import from other formats.

So please stop trying--consciously or otherwise--to outdo Kazan (the original maker of PCS2). We don't need another set of buttons and text boxes and such to have to learn in order to get to POF format.

What you should have done, and still can do:

Export and import to and from PMF. You've said you can store all the POF data inside Max. If that's true, you can still store it inside Max when it's loaded from a PMF.

Don't focus on editing/specifying the non-mesh data. Focus on allowing the user to edit the mesh without destroying the rest of the to-be-POF data.

While it should be possible to import, make sure that the export contains all of the same data that was imported, unless the user changed something, in which case only that should be changed.

Bonus ideas, if you're interested:

Come up with some sort of version/compatibility checking system.

In conclusion

I don't mean to sound like a jerk, I just happen to agree with Flaser, chief1983, and I think some others as well, and it seems like you're deliberately ignoring their advice, even when they clearly present an accurate explanation.

[Getter Robo G]

Actually, get off your high horse Aardwolf...

This is not meant to offend Kazan, but he does not have a lock on conversion application development.

In fact, if this ap solves one of my problems then more power to AK-73!

I found your post to be mostly a sense of discouragement due to a perspective that this ap would somehow be in competition to PCS2. A tool is a tool and people will use what they like/need.

When more feedback comes in from people who've used this and comes out of beta I will look into this as a way to avoiding .cob as PCS2 will not make .cobs on my computers into .pofs (but I can work with existing pofs fine which is besides the point when tryignt o make a conversion inteh FIRST place)

Until the mysterious PCS2 issue is solved I am FORCED to continue to use PCS1 and Modelview.

So either step up and try to help people sometime, or get out of the way...

This post in no way lessens Kazan's achievement or PCS2's place in Fs2 modding, BUT I am not the only one with PCS2 issues that we would like to see eventually resolved.

 

[Omniscaper]

Amen, Getter Robo G.

Because I'm a heavy 3dsmax user, I'll be following the development of this tool closely, ak-73. I'll have time this weekend to give feed this beta all sorts of models from 3dsmax and will post results.

[Aardwolf]

I know when I've gone beyond what was necessary. I'ma go be quiet somewhere.

[Vasudan Admiral]

Excellent work!
Newsified.

[ak-73]

If you export directly to POF, then in order to make any edits to the POF data, you'll have to open it in either PCS2 or the importer/exporter anyway.

The point to the Max IO script: unifying modelling the geometry and the setting of semantic data under one hood. You set up everything within one program (gmax/3dsm) and you're finished. Add to that the quality of gmax and especially 3dsm as a modelling tool. I simply like this idea.

PCS2 already has all the features you've described, and then some. Furthermore, PCS2 is usable for more modeling programs than just MAX... anything that can be in some way converted into a .cob file can be opened with it, and it may eventually get expanded to import from other formats.

No problem with that. But for those who want everything under one single hood (like myself), they might prefer the IO script, once it is functional *and* has all the helper functions that await implementation.

So please stop trying--consciously or otherwise--to outdo Kazan (the original maker of PCS2). We don't need another set of buttons and text boxes and such to have to learn in order to get to POF format.

I see the benefits of pluralism. As for outdoing anyone, I didn't know this was a competition (and if it is who is the jury and what is the prize?-... just kidding).

Seriously... I just like the idea of being able to do everything from inside a professional modelling tool like gmax/3dsm. I am not trying to outdo anyone. I don't even know if there's a single other person out there who feels about it like me. I have been foremostly coding it for myself and am offering it to the public. I won't be offended if not a single person downloads it.

I found your post to be mostly a sense of discouragement due to a perspective that this ap would somehow be in competition to PCS2. A tool is a tool and people will use what they like/need.

I know when I've gone beyond what was necessary. I'ma go be quiet somewhere.

Well, I think I understand aardwolf's point: updating the format will require an update of the script everytime it happens. It's a valid point of criticism. Just be reassured that I don't see myself in competition with anyone or trying to make anyone's work invalid even.

Alex

PS What I forgot to add to the readme: the script is pretty much public domain as far as I am concerned. Anyone can modify it as they see fit. Just so that I don't forget to mention it.

[Bl4ckj4ck]

Not sure if I'm doing this right.  I tried to import a model via extraction of a .pof from a .vp, then using your rollout to import, but I get an error using both Max 8 and Max 2009:

~Unknown property: "count" in undefined

The pop-up says that it is a MaxScript Rollout Handler Exception.

Er, when you say 3dsmax 4+, you really mean any version 4 or later, right?  Just checking.

[midnightjoker]

i noticed i got the 'count' error when opeing a pof i had edited but using the ones from sparky_fs2, they opened fine.  i havn;t explored it more than that.  great little tool.

[Omniscaper]

I've hit a snag in the export process. I'm using 3dsmax 8 and have formatted my model to the naming conventions required. I have imported a stock fs2 model and its components (gunbanks, missile banks, thrusters etc) But the export fails due to an "Unknown radius" for my base object.

I see special rollouts for the stock model's base object that I'm not able to replicate on my base object. How do I use this script to put such settings on my model? I'm about to attach the geometry of my base object to that of the stock base object, hoping to inheret such properties.

ALso, any stock fs2 models I import, doesnt export, a prompt quickly appears and disappears.

Any suggestions or advice?

[varsaigen]

is there a way I can turn pof into 3ds and then open with milkshape? or do i also need 3dsmax?

[Water]

is there a way I can turn pof into 3ds and then open with milkshape? or do i also need 3dsmax?

1/ - Use PCS2 to turn pof into cob
2/ - Use Accutrans http://www.micromouse.ca/ to convert the cob to 3ds.
3dExploration can do the same job, and so can Truespace7.6.

[varsaigen]

Yeah, I tried 3DExploration but that works better on my oither computer. (I should test it though...) But so far, I'm trying the AccuTrans 3D as a trial for what I need at the moment. Thanks!