Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: ak-73 on July 07, 2008, 09:41:35 am
-
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
-
i'd be willing to give it a shot. just need to download gmax
-
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
-
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.
-
That sounds pretty awesome. By the way, have you seen this (http://www.hard-light.net/forums/index.php/topic,54757.0.html)?
-
That sounds pretty awesome. By the way, have you seen this (http://www.hard-light.net/forums/index.php/topic,54757.0.html)?
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
-
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.
-
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.
-
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
-
http://alliance.cvs.sourceforge.net/alliance/pcs2/ (http://alliance.cvs.sourceforge.net/alliance/pcs2/)
-
Thanks - the bsp splitting looks somewhat complicated; I'll have to take some time to get through this.
Alex
-
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:
:welcome:
That's a pretty awesome way to go about a first post BTW. :D
-
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:
:welcome:
That's a pretty awesome way to go about a first post BTW. :D
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 (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
-
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. :)
-
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
-
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.
-
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
-
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.
-
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
-
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. :)
-
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
-
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.
-
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
-
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.
-
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.
-
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
-
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
-
We have a Beta Release:
.POF Import Export Script v0.9: http://rapidshare.de/files/40070611/fsmax_v09.zip.html (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
-
(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.
-
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.
-
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.
-
I know when I've gone beyond what was necessary. I'ma go be quiet somewhere.
-
Excellent work!
Newsified. :)
-
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. :)
-
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.
-
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.
-
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?
-
is there a way I can turn pof into 3ds and then open with milkshape? or do i also need 3dsmax?
-
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/ (http://www.micromouse.ca/) to convert the cob to 3ds.
3dExploration can do the same job, and so can Truespace7.6.
-
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!
-
@Bl4ckj4ck: The claim "3dsm 4+" was based on the assumption that higher versions are fully backwards compatible. All my script have been working on higher version so far at least. If they're not or there is some other bug, I would have to know which .pof file you have been importing (so I can try myself) and I would need to see the output of the maxscript listener window at the bottom left of your screen (at least that is where it is in gmax and 3dsm 4).
@midnightjoker: again I would need to see the maxscript listener output. Or better yet upload your file and I'll investigate myself in gmax.
@Omniscaper: Yes, that's a "snag". My first goals was attempting to be able to import and re-export slightly modified models. Helper/Creator utilities are the next step. What works in any case is attaching your own geometry to imported geometry with the desired attributes and then deleting the imported geometry and renaming stuff, etc). Delete the imported meshes material first though. Otherwise you have to do it manually in maxscript in the maxscript listener window. I have to write this from memory as I am posting from university but the script defined a few custom attributes (check out the maxscript documentation for details).
These are the custom Attributes of the script:
GlobalAttributes
SubobjectAttributes
SubsystemAttributes (<- this one is for "Special" spheres)
PathWaypointAttributes
ThrusterBankAttributes
ThrusterAttributes
You must first create an instance of an attribute that you want to you and you do it like this:
<Some Variable Name> = attributes <One of the above Attribute Names>
Example:
attribute1 = GlobalAttributes
or:
attribute2 = SubobjectAttributes
etc.
Then you select the node that shall get this attributes and type:
custAttributes.add selection[1] <The desired one of the above defined Variable Names>
Example:
custAttributes.add selection[1] attribute1
In theory that should work. Unless my memory is failing me. I'll check it out when I'm home again. :)
As for export... the prompt who quickly disappears... is that by chance an MS-DOS window? If so, that would be correct because it means the exported data gets passed to the My_BSPGen.exe for creating the BSP data (that task got outsourced out of 3dsm by me). But normally this should mean that export has been taking place. Anyway, if someone has problems with importing/exporting a .pof, they can upload their models for me and I'll check it out. As for retail models, the name should suffice, however I have been successfully importing almost all retail models and export worked on the 6 or 7 that I have tested.
fighter09.pof, cruiser03 and terransuper have all been tested successfully by me. Most under gmax, a few under 3dsm 4.
If someone has any suggestions on how to better represent imported data, I am still open to suggestions. I was example thinking of adding _" + the subsystem name to the name of specials for easier identifcation in the selection list... stuff like that.
Alex
-
I have written a small (unofficial) update: http://rapidshare.de/files/40110301/update.zip.html (http://rapidshare.de/files/40110301/update.zip.html)
This one makes two changes:
1. You don't have to remember starting the io script before loading a scene with pof model (with custom attributes) anymore. The disadvantage is that all scenes saved with the previous version of the script won't open with the new one.
2. This morning I have written a quick helper script. This will allow creating basic specials, gunpoints, waypoints, etc and assigning custom properties to subobjects and to the base object easily. You will have to rename them properly, link them properly and adjust the custom attributes accordingly though.
Alex
-
Just starting out in 3dsm 2009, and managed to solve the "unknown radius" error for the base model by using your Creation Helper...thanks! I've managed to export a model, but the subobjects aren't showing up in pcs2 even though I've set turrets and non-hull details as subobjects.
-
Just starting out in 3dsm 2009, and managed to solve the "unknown radius" error for the base model by using your Creation Helper...thanks! I've managed to export a model, but the subobjects aren't showing up in pcs2 even though I've set turrets and non-hull details as subobjects.
Try to see if the subobjects re-import into max correctly please.
Alex
-
Bug-fixed version 0.9.1 is out. This one actually works. :) At least I have been able to successfully export a Myrmidon fighter and use it in FS2 and Fred2 (I finally got around to compiling and starting it as Debug). The new release includes the helper script I have published before.
Release Notes:
- a basic helper script has been added
ATTENTION! The new inner organization renders scenes saved with the
v0.9 version of the script incompatible.
- fixed a bug in My_BSPGen that caused BSP data size not to be written to
.pof files, causing crashes
- fixed a bug in the script that caused the game to crash upon ship collisions
due to non-normalized polygon normals
- fixed a bug in the script involving MPNT chunk size that caused subsequent
chunks to not get read (leading to the visible effect of engine glows not being
rendered)
I haven't tried it in pcs2 but if it works in-game it surely works for pcs2 also.
Download link is: http://rapidshare.de/files/40134855/fsmax_v091.zip.html (http://rapidshare.de/files/40134855/fsmax_v091.zip.html).
If anybody gets to work any of this exports in-game, please post a screenshot.
:)
Still any feedback is welcome. Thanks.
Alex
-
Lol, judging from the amount of feedback, I'd say the io script is either running incredibly smooth or not at all. ;)
Alex
-
It is interesting.
However it's not really practical to use for me.
I don't have my own project, only I work on, but I work together with a lot of people using all kinds of 3d apps.
So the Collada support for PCS2 is actually more interesting for me. This way I don't get OBJs and have to do the setup myself, but dae files I only need to load up in PCS2 and save them, without having to do anything about them, while I still can edit them in MAX.
Your script is still interesting, but you should try to stick to the old conventions as closely as possible.
The PCS2 guys pretty much copied the old MAX plugin conventions, so I can export my old modles, made for the max plugin, with only a few changes.
A completely compatible convention would be perfect.
http://www.hard-light.net/wiki/index.php/Collada_Importer
-
I believe that's slightly outdated, I'm not sure what changes have been made by Spicious or I would update it myself.
-
I want to check this out in GMAX tonight.
The price is much better than MAX and I can render or model other formats in Rhino all I want to.
If I can bounce around with GMAX for texturing, and heirarchy with TS 7.6 or GMAX...
I'm finally setup for making models :D
-
I don't have a great version of Max (Only Max4 licensed on a slow machine), so I ran GMax with this....
I got to say, this looks like the easiest and under $1000 legal solution yet.
You get two thumbs up and an open bar tab I ever meet ya m8!
Hmmm lets see, Rhino 4 Student license, $169, GMax - Free, the POF plugin - Free, PCS2 - Free.
If Gmax or Rhino supported Collada then I could adopt this DAE file philosophy,
but so far I havent found the converter for it.
I'm not sure if DAE open format works with the EULA for GMax either.
I ran the 2009 3DSMax trial and it bombed on every attempt to make a DAE file for me.
That is just a standard dae file, not even trying the collada converter these guys are working on so well.
I'm sure their work will bear more fruit.
Max 2009 completely crashed everytime (I let it sit for 2 hrs and it just sat there locked up killing a processor).
So I have yet to even have a real collada file.
Made obj and fbx files all day long, would not make a dae file to save its own skin.
With the price over $1000 for Max doesn't rest well with me.
Even the student license for 3dsmax was only 13 months long where Rhino for the same price on a student license is forever. As long as I am not using it for actual paid production so I am completely legal the way I like it with this route.
I model this stuff for my own entertainment, I have no use for a multitude of $500 or more solutions.
McNeel gets my admiration everytime. They actually monitor and answer questions on their forums where Autodesk up front states they do not. Autodesk and I are not on good terms with their products and support. $85K for subscriptions and they completely ignored the outstanding gripes with their last 3 implementations of AutoCAD and its verticals. For awhile they kept giving me the same support a single license user has until I blasted them for a day with phone calls and emails. Even then they tried to hide from me on programming questions saying I had to buy a developers subscription, after $85K they can pretty much take a hike with that nonsense, I'll hack their license server instead of spending the money and hours hacking their software to make it work right since their support was really non-existent. That finally got their attention. 90% of the issues we had with maintaining the same production processes we have done for the last 5 years came from me and other programmers sharing the information freely on forums outside of Autodesk, not Autodesk.
-
Sorry, but I'm still having problems exporting models, I'm using 3DS Max 2008. Here is the information of the error:
>> MAXScript Rollout Handler Exception: -- Unknown property: "radius" in $Editable_Mesh:Frigate @ [-0.026966,12.810505,0.009341] <<
-- Error occurred in anonymous codeblock; filename: C:\Program Files\Autodesk\3ds Max 2008\scripts\fsmax_suite\POF_IO.ms; position: 55469
-- No ""get"" function for undefined
Any suggestions?
-
Do all of your parts have names ?
-
Well, if you refer to name the turrets and all other stuff according the name conventions( turret01, turret01-arm, $engines....), yes, I did it. But I'm confused about the firepoints, what name should I write for them, "Firepoint_01" or there is other designation?
-
I dont think the error was caused by the names. If it was, then there will be some other thing wrong than "Radius", the most strange think is that I can't import too. Is there a poltergeist on my pc or there is some other explanation?
-
To be honest, I abandoned gmax and went with Rhino export to 3ds, textures with lithunwrap, then convert to cob using 3D Explorer. then open the cob with PCS2. These other exporters drove me nuts.
-
some on can pull a working link for the script i try to import model but for a unknown reason truspace make unusable 3ds :(