Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Tools => Topic started by: Asteroth on March 15, 2022, 01:35:15 am
-
Pof Tools is a program for Windows and Linux which let's you edit properties of Freespace's model format .pof as well as convert them to and from .dae that is meant as a successor to PCS2. If you're familiar with PCS2, this program will feel largely similar.
Download here (https://github.com/Baezon/pof-tools/releases/tag/v1.5.3)
The github is here (https://github.com/Baezon/pof-tools). I'm more than willing to accept any code contributions, and if you have any bugs or feature proposals you can post an issue on the github, post here in the thread, PM me, or @ me on the discord.
This is still a work in progress and including some of the features I've posted to the github, this is a brief list of features I intend to eventually implement that are not yet done:
Importing subobjects from other .pofs Done in version 1.5!Importing/Exporting only geometry from/to a pof Done in version 1.5!Displaying Textures (basic stuff only, use the lab for something visually representative) Done in version 1.2!- Blender-like movement/rotation handles on 'lollipops'
Display of turret fovs and adding the additional turret fov parameters in .pof- Adding several other table-only data structures to .pof (contrails, maneuvering thrusters, etc)
(https://i.imgur.com/rIuYWdh.png)
Wait, What's Wrong With PCS2?
Not all that much really, it's still fundamentally capable of 99% of what modders need as is. However there are 3 main advantages to starting again:
1. PCS2 will totally let you enter all sorts of invalid states, and put in bad data all over the place, which makes for a lot of nasty surprises when used in FSO. There are a lot of avenues for aiding the user, presenting data in more intuitive ways, and warning them about potential issues, which are primary goals of Pof Tools.
2. The .pof format has been basically frozen since our only .pof authoring tool has not been maintained, preventing new features from being added and any that are added basically require hex-editing in order to do. This has also resulted in a lot of features that should have been in the .pof get put in the table instead, and nobody likes tweaking positional or directional vectors in text form.
3. There is still that 1% you can't do, like the new features added that PCS2 doesn't support, and the various bugs it has accrued over the years.
-
Wait, you want to move things from the tables to the pof data? I thought we were trying to get away from that so it can be more easily modified.
My experience building a mod is that as much data as possible should be in a table and not the POF because otherwise I can't change it downstream without carrying a brand new version of that POF. Unless we get modular POFs somehow.
-
Not as a replacement, as an optional way to provide the same data. As you said, there are still times when you want to override things on a ship-by-ship basis (the table data would take precedence), but certain things like maneuvering thrusters are a nightmare to make when you only have text and can't actually see what you're doing. Most things involving positional vectors or normals should have a graphical interface to show you them directly instead of guessing and checking in FSO.
-
Not as a replacement, as an optional way to provide the same data. As you said, there are still times when you want to override things on a ship-by-ship basis (the table data would take precedence), but certain things like maneuvering thrusters are a nightmare to make when you only have text and can't actually see what you're doing. Most things involving positional vectors or normals should have a graphical interface to show you them directly instead of guessing and checking in FSO.
Aha, ok then. In that case I propose passive lightning as well.
-
Oooh, I'll give this a solid look when next I get the chance
-
Version 1.1 released. Includes replacing the opaque 'docking points' interface with a much more clear 'docking orientation' interface, allows you to see the pof version of a file and change it, and visually displays radius, bounding box and offset when the relevant fields are hovered over or clicked.
-
Awesome, these are some very handy features! The hover over tooltip for various POF versions is an extra useful bonus!
-
If Bromios (https://www.hard-light.net/forums/index.php?topic=97850.0) is loaded into Pof Tools, it shows The header's bounding box does not encompass all of its geometry, but recalculate does nothing.
Intersting thing, if older Bromios (https://www.hard-light.net/forums/index.php?topic=84700.msg1691636#msg1691636) is loaded, Pof Tools don't show this warning, but after recalculating header's bounding box, there is this warning.
-
Thanks for the heads-up :yes:, it has been fixed and will be in the next version (which should be within the next few days).
-
Version 1.2 released, which has some basic texture support, allows for moving just the center of a subobject and better properties handling.
-
Awesome! Thanks for the quick updates.
-
This looks amazing! but for some reason my PC refuses to run it. It opens a window for a fraction of a second then closes. The log only has the date and time and nothing else. Do I need something else to run this?
-
What OS are you running on? And can you tell whether it's a command prompt that shows up briefly, or what looks to be the main screen?
-
Windows 7 64bit, and looks like the Main screen.
-
Can you try this .exe and tell me if it's any different?
https://anonfiles.com/ZcIbifW1x7/pof-tools_zip
-
No luck, still closes itself almost instantly.
-
Use this https://anonfiles.com/z8Pfk1Wdxc/pof-tools_zip
But this time, actually extract it somewhere (if you weren't), and in that folder ctrl + right click and you should see "open command prompt here". Do that, and then use these commands:
set RUST_BACKTRACE=1
pof-tools.exe
It will still probably go away, but it should print out any crash data into the prompt, which you can then post here, which will hopefully point towards the problem.
-
Here it is.
pof-tools.exe glium has triggered an OpenGL error during initialization. Please report this error: https://github.com/glium/glium/issues
thread 'main' panicked at 'called 'Result::unwrap()' on an 'Err' value: CompilationError( "WARNING: 0:18: 'inverse' : function not available in current GLSL version – trying implict argument conversion \nERROR: 0:18: 'inverse' : no matching overloaded function found (using implicit conversion) \nERROR: 0:18: 'transpose' : no matching overloaded function found using implicit conversion \n\n", Vertex)'. src\main.rs:607:131
-
Ok, cool. Fixed version hopefully: https://anonfiles.com/P8Eeu6Wdx1/pof-tools_zip
You can just run it normally, if there is still a crash it should also be in the log now.
-
It works! Thank you. What was the issue?
-
Excellent, it appears you have an older gpu, which doesn't support certain functions I use in the shaders, luckily it was just some matrix math I could easily do outside the shader.
This is the PR that fixes it (https://github.com/Baezon/pof-tools/pull/56), if you or anyone is interested.
-
Hey there, is there a way to assign textures through POF? I've imported a ship from Blender that uses the Principled Shader, but none of the linked textures are showing up at all in POF. It just shows a empty menu.(https://files.catbox.moe/u3ogot.PNG)
-
Pof Tools can't use complicated materials, all the .pof has a single reference to a texture name, which it gets from the name of your material, in this case Pelta_Hull_Mat (which you can rename by selecting the entry). Pof Tools will search for a texture with this name in the same folder or a sibling folder called "maps" in order to display at least the base color texture, which is optional.
If you just want it to work in-game, you just need to make sure the name is the same as the eventual texture name of the diffuse texture.
-
^ Ah okay, so basically if I'm exporting from Blender, I just need to rename the material to share the name of the texture linked to it, and it should show up in POF. Awesome :)
-
Yep! Note that the image code I use can't display all kinds of .dds, if that's what you're using, so don't be too concerned if still doesn't show in Pof Tools.
-
Version 1.3.0 released! With two big features:
Comes with support for pof version 2300 with increased vertex/normal counts (65k -> 4 billion) (with thanks to DahBlount in assistance with implementing that in engine) . No more need to cut large models up into many subobjects!
Supports .gltf/.glb import/export, which (at least for blender) finally allows for lossless round-tripping. No more do you need to remake the .pof from scratch if you need to make a tiny change to the model! A lack of proper round-tripping has always been a major annoyance for me with PCS2 and a lossless round-trip was always a big goal for me, so I'm very glad to finally be there.
Note that .gltf models are unavoidably split by every polygon into separate vertex groups, so be aware of this when importing into your modeling software of choice. Blender can re-merge the mesh back together and maintain smoothing by ensuring 'sharp edges' is checked when using 'merge by distance' (Pof Tools does not require this step if you are re-importing back into .pof).
-
There've been many models over the years that have been split into submodels to get around the index limits. It is my opinion, one which I have very lightly but not rigorously tested with actual performance profiling, that this makes collision detection slower than if there was a single submodel with all that geometry. When 22.2 comes around I think it would do the general performance of the game good if people, particular the FSU, went in and merged all such models back together, something that the GLTF import/export and blender makes a piece of cake.
Note, I'm not talking about detailboxing. If you have detail boxes that is likely good and you should keep them.
Also, merging everything together should make using the collision LOD options in the ships table easier, and performance would be helped by that too.