[chief1983]

I think Brand-X will be willing to help with some of his recent Star Wars models as well, using ColladaMax.

[Spicious]

Good, the sooner I get some sample inputs, the sooner I can look at getting things started.

At this point it's very tempting to just go straight for integration into pcs2 given the existing data structures and pmf saving code. Is there an easy way to get all the pcs2 source files? CVS seems rather clunky in this regard.

[chief1983]

Well I was able to get them pretty easily myself, I supposed I could archive a snapshot of the source.  I don't think it's been changing much unless Kaz has been working on it in secret.

CVS Checkout Here

[DaBrain]

Hmm. PMF isn't bad, but a native DAE support in PCS2 would be best.

[chief1983]

Essentially, that's what it would allow.  If implemented as a DLL, PCS2 could just use that, since it imports to PMF internally anyway.  We could just use a skeletal app for testing that would take the conversion from the dll and dump it to a PMF file, but file output wouldn't have to be part of the dll.  Just getting to PMF data is all we need.

[pecenipicek]

somewhat silly question, i know, but is it even possible to replace pof as the model file type in the freespace engine or is it thoroughly hardcoded?

also... apparently i've misread some parts and unfortunately, cinema4d does not support collada yet, however some projects have been started on adding that support and supposedly, the company that made c4d is going to include collada support in either the next update or the next release. we shall see. for now, i'll be trying to figure out my way around the code.

[chief1983]

For one, they'd never replace it as that would break retail.  Adding support or expanding on the format would be more likely.  What did you have in mind?

[pecenipicek]

as for pof... i dont know, i was just wondering if it would be possible or thoroughly not worth the effort


as for the collada->pcs2...
to be honest, i have no idea... the whole code is... well, inhuman to say the least and i really have no idea where should i start, sooo... yeah. still, up for testing stuff, once we get to that point.

[blowfish]

About replacing POF in the code - it's possible, however, it's not worth the effort ATM, and isn't going to happen.

[pecenipicek]

kk, thats all i wanted to know

[WMCoolmon]

The POF code is some of the most straightforward, if somewhat disorganized, code in the FS2_Open codebase. In fact I'm surprised that nobody has added IBX chunk support yet, other than there being a lack of a program to generate or integrate it with.

Then again it wouldn't be all that hard to code that either.

Unless PMF stores geometry in a fundamentally different format, all you'd need to do would be to set up the parse function to work on PMF rather than POF. But it would violate the idea of PMF as an intermediate format, which could impose design headaches later on.

Now I'd imagine that if you wanted to make Lightwave or something directly import into FS2, you'd have one hell of a time because you'd have to extract all the values somehow, and you'd have to convert the internal model geometry from the format Lightwave uses to BSP stuff.

[Flaser]

IMHO at the moment implementing support for a new model format just for the sake of importing models from modeling programs  is kinda redundant.

If the model code is to be tweaked priority should go toward making it more efficient at collision detection instead and workarounds of the subobject limitations so the engine could handle proper damage modeling (more destroyable subobjects) and animations (a more flexible BSP code that not only speeds up collision detection but is designed with moving parts from the get-go).

Of course this isn't a gospel, merely the impression of a SCP affectionate with a bit of programing background. I think so because this part of the code is one of the parts that needs an immense amount of work to upgrade and a lot of features as well as design issues are connected to it, so renovating it might go to waste when it's time for a real overhaul.

[DaBrain]

Btw, I just wanted to offer my help to any coder picking this up too.

If you need any models, with whatever kind of helper object setup, I'll gladly help you out.
Just write me a PM and I'll give you my IM and mail adress.

[Spicious]

Good to hear/read. The coders involved at this point are chief1983, WMCoolmon and I.

Given that I'm not a modeler, I would be happy for the input organisation of helpers to be anything really, as long as it's sensible, consistent and hopefully relatively simple. It'll be up to the modelers interested in using this to shout their ideas and actual example input will likely have the most influence. Maybe this should be mentioned in FS modding to get more complete views.

As for the coding side, I see no reason not to make use of the PMF code in PCS2; we need to decide on things like whether to use FCollada, Collada DOM or something else, and we probably need to get in contact about organising this.

[chief1983]

If so I would recommend using the Wiki page I set up, it should be a pretty easy place to document things like test cases and desired functionality.

[DaBrain]

Well about how the data is interpreted:
http://www.hard-light.net/wiki/index.php/Styxx%27s_POF_Conversion_plugin_for_3D_Studio_Max

The model setup for the MAX exporter is pretty good.
And DAE supports all helper objects needed for a similar setup.


So imho, that should be the way to go.

[chief1983]

That sounds like a good idea.  Since the converter will need test models we could already go ahead and set up some test cases based on those conventions, and modify them where necessary.  We could also create a modified copy of the conventions that are less app specific, or maybe include help for how to accomplish certain tasks in more than just Max.  I would imagine that having a couple of models that use as much as possible, and a bunch that use as few things as possible would be helpful.  So we can kind of cover both a full on test as well as simple test cases.  I don't think there's any rush for that, although I am curious how much people have tested using DAE as a portable type, going between Blender and Max, etc and making sure nothing goofy happened.

[Spicious]

Sounds good.

I've been looking at the Collada DOM and it seems to do what we need. If I can get my hands on a sample input, I can probably make a start on this. Simple would be nice first.

It can do a cube with quite a few hardcoded things...

[jr2]

If this helps you coder guys at all, use pastebin:

http://scp.indiegames.us.pastebin.com
or
http://www.hard-light.net.pastebin.com

You can select Syntax highlighting for most programming languages, and basically do cooperative coding etc..

[Vasudan Admiral]

Ok, here's a...well not terribly simple sample of the Blender DAE exporter output: TestShipOne.

http://game-warden.com/starfox/Non_SF_related_stuff/MVP3610BETA/ColladaTestShipOne.zip

It should take the two textures - ShipHullTexture and Glass. I've also set up lots of empties (helpers) also to represent sample data such as engine glows, dockpoints, subsystem centres and gunpoints. The model has shields (which are the only bits of geometry without a texture or a UV map), a LOD and debris objects all named appropriately.

A few other notes:
- The object names rather than the mesh names should be the ones assigned to the POF-style subobjects once converted.
- There are two versions of the DAE, one with hierarchy and one without.
- I couldn't find anywhere in Blender to insert the subobject properties other than scripts attached to objects - you can see these in the .blend, but them and all references to them didn't survive the export, so it might be a good idea to make it recognise a turret object in the input (ie, every object with "turret" in the name UNLESS it also has "arm") and add some default turret data itself (and rotation axes for multipart).
- Not sure what the best method for defining radii for subsystems. Probably just a "-R=20" tag on the end of the name of the empty representing the subsystems centre, so for example: "SubsystemEngine-R=30" for a subsystem called $Engine with a radius of 30 meters.