[Spicious]

- The object names rather than the mesh names should be the ones assigned to the POF-style subobjects once converted.

Yes, I thought it would end up being like this, given the per geometry thingo materials.

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

Sound sensible; I'll probably do it the same way it's done for cob conversion.

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

I can live with that.

Thanks for the sample. Would it be possible to get a picture of what it's supposed to look like?

[Vasudan Admiral]

Hideous on so many levels.



It's just meant to have a few features to test with that can be interpreted as objects filling the roles they're meant to rather than a hard to figure out collection of cubes.

[Spicious]

I've got the geometry converting over well enough. LODs, debris and subobjects are working. Both turret bases are inside out though. Just the turret bases. The turrets are partially in; subsystem properties aren't in yet. Engine glows are working, but I didn't see anything about the radii or normals of engine glows. Textures seem to be referenced in the most roundabout way possible so everything still uses one texture only.

For subsystem radii and the like, would it be possible to store that as a sub-helper(?) of each subsystem helper?

The current output is attached.

[attachment deleted by admin]

[chief1983]

Do you happen to have your code stored anywhere public?  Also, if you're just converting to PMF, you might as well not finish the conversion to POF, we should all have PCS2 I believe.  Or maybe attach both.

[Vasudan Admiral]

Wow that was mighty quick. Lovely work!

Heh, the inverted turret meshes look to be my fault sorry. Muddled that bit up when making them and forgot to check before export. It's a good sign they converted that way though. I'd be more worried if they hadn't.

Unfortunately I found absolutely no way to write any sort of text based data anywhere that would export to collada beyond the names of the objects and meshes themselves. As such, subobject properties is probably not going to be possible via Blender DAE export.

Normals and radii might be possible though. Can you interpret the 'orientation' and 'scale' of the empties? In Blender we can change how they appear, including a 'single arrow', 'circle' and 'sphere'. The single arrows are perfect for data that consists of a location and a normal (gunpoints, eyepoints, dockpoints), the circles are ok for data that consists of a location, radius and normal (engine glows) and the spheres are perfect for data that consists of just a location and a radius (subsystems).

Here's what the new version looks like in terms of empties:


Same URL as before: http://game-warden.com/starfox/Non_SF_related_stuff/MVP3610BETA/ColladaTestShipOne.zip

All the helpers in the object now posess correct normals and radii where appropriate.

[Spicious]

Also, if you're just converting to PMF, you might as well not finish the conversion to POF, we should all have PCS2 I believe.  Or maybe attach both.

That was mainly because pof is the default save format in pcs2.

The scale and rotation thing seems to work fine; the multi-part turret firepoints don't seem to line up with the barrels though; the rotations might do strange things if weird rotations are attempted (bloody 3d trig)...

I guess we'll have to work something out for glowpoints.

I've attached what should contain the changed/added code files and the model in pof and pmf.

[attachment deleted by admin]

[Vasudan Admiral]

That's odd. I didn't notice it in the first model because the turret polys were inverted, but it looks like the offset of both turrets arm subobjects has been lost - the centre of the arms has shifted down to the centre of the turret base. The firepoint placement is fine, but the arms fell out from under them.

Anyway - it's looking great. I suspect smoothing will be the biggest problem for the Blender DAE output since Blender doesn't really support smoothing too well. That's my next area of investigation.

Also, I have two feature requests that would make conversions a lot easier:
1) A little bit of a hack, but would it be possible to have the convertor take polys textured with a texture named 'glass' and place them last in the poly list?
This would allow glass canopies to be done really easily, since we would no longer have to manually detatch those polys and re-add them just before conversion to ensure they're last on the list. Currently if we don't do that, the render order in-game is all whacky, as can be seen with this model if you look through the glass in PCS2.

2) An additional 'turret info' helper that would be the child of the multi-part turret it was referring to.
There would be 3 aspects to it:
- The helpers name would define the Movement Type, Axis and the FOV.
- It's orientation would be converted to a fvec and uvec, for off-axis rotation stuff.

So, a helper named maybe "Rotate:Z,FOV:160" with it's would assign the following properties to it's parent object:
Movement Type: Rotate
Axis: Z
Properties:
$special=subsystem  (this would be automatic)
$name=turret   (as would this)
$fov=160

The direction of the helpers Y axis would be converted into the fvec for the object, and the Z would be the uvec, which would be added to the Properties field with the format:
$uvec:0,1,0
$fvec:0,0,1


If you're willing to give that a go, I'll get you a sample model file as soon as I can.

[Spicious]

1 should be easy enough on a per-subobject level. Would there be likely to be more than one polygroup using glass per subobject?

2 I think could be expanded. I think there should be some sort of prefix to indicate that it isn't a subobject. The rotation axis could be done as a special case; the fov would most likely be better off being done as part of the properties field, which could include things like custom names and rotation times.

Perhaps something like "Fake:Axis:Z,Properties:FOV:160" with the possibility of things like "Fake:Axis:Z,Properties:Rotate:10.0,Name:Spinning Thingo". This may of course be subject to change...

Hmm, what do you think of doing turret firepoints as children of the turret itself?

I'm happy to look at the uvec and fvec stuff too.

And I have no idea what's supposed to happen with the smoothing at all.

I would like to see some non-blender made models too...

[Vasudan Admiral]

Glass polys:
If by polygroup, you mean a group of polys all connected to each other, then yeah there definitely would be cases where there are more than one of them per subobject - like for separate sections of a canopy.


Subobject properties:
It gets tricky there because we only have 21 characters to play with in the name of the helper. The main two ingame model features this helper would....uh,....help with would be rotating subobjects and multipart turrets - both of which should be off-axis rotation compatible as well.

So, the data that they take is as follows: (this is a little long winded - I'm sorting it out in my brain as I go here. )

Rotating subsystem (call it a radar, whose submodel is facing forwards)
Movement Type: Rotate     [we need a trigger to turn this feature on in the model file]
Axis: Z                                [we need a way to define the axis in the model file]
Properties:
$special=subsystem           [this can be auto-added to the properties if the movement type is rotate]
$name=Radar Dish             [this field can be auto-gened from the parent subobjects name. No need to specify]
$rotate=5                           [we need a way to define the rotation speed in the model file]
$uvec:0,1,0                        [we can get this from the helpers Z axis]
$fvec:0,0,1                         [we can get this from the helpers Y axis]

Multipart Turret (pretend it's an off axis one as well and the subobject faces forwards)
Movement Type: Rotate     [same]
Axis: Z                                [same]
Properties:
$special=subsystem           [same]
$fov=180                            [we need a way to define this in the model file]
$name=main turret             [either just grab this from the parent subobject model - it's not used ingame by default anyway]
$uvec:0,1,0                        [same]
$fvec:0,0,1                         [same]

Of these, it means that the two typical sets of 'flags' we'd need to set in the helpers name would be:
Rotating subobjects: -> Rotate flag, Axis & Rotate speed -> Eg: "Rotate:Z,RotVel:5"
Multipart turrets: -> Rotate flag, Axis & FOV -> Eg: "Rotate:Z,FOV:180"

And I think that'd be about all it'd need to do. There aren't a lot of options that go in the subobject properties field anyway - and most of those extra ones that are there aren't the sort of thing that you'd do in a pre-conversion model anyway, including:
"$triggered:", "$look_at:#", "$detail_sphere:1,#", "$detail_box:1", "$box_min: #,#,#", "$box_max: #,#,#", "$stepped", $steps=#", "$t_paused=#", "$t_transit=#"


Firepoints:
They could be children of the turrets, but I think that should be more for organisational purposes than a requirement. I think as long as the firepoint helpers are correctly named, their location in the hierarchy should be irrelevant.

[Galemp]

Per the glass issue, I'd like to point out that ANY transparent textures need to be at then end of the list, not just the glass-- for example, open girders.
Perhaps subobjects with a transparent texture should be detached and named (subobjname-trans) and then the converter can attach them to the parent object .

[Vasudan Admiral]

Yeah that way would work fine as well and would probably be less hackish I think.

[Spicious]

Ah, the joys of arbitrary limits.

How about using one character to signify it? Semicolon probably could work since it tends to be used for comments in FS.
I think it might be worth trying to keep the possibility of a name field, if perhaps only of a sensible length.

So, if this helper is found, the subobject gets the $special=subsystem by default with a default name based on the parent or "turret" or whatever. Rotation and its axis could be done in two characters, say 'R' and one for the axis. Then perhaps straight into the rotation time or fov depending on the context and then use the rest of the space for a name.

Per the glass issue, I'd like to point out that ANY transparent textures need to be at then end of the list, not just the glass-- for example, open girders.
Perhaps subobjects with a transparent texture should be detached and named (subobjname-trans) and then the converter can attach them to the parent object .

I believe I could live with that.

[DaBrain]

Chief and Spicious just got a PM with max collada files from me. Is anybody else working on this?

[Spicious]

Ah, some variety. But with variety comes a different naming scheme. For some reason all the scene nodes all have -node appended to their ids. It looks like the $ got turned into _ too and the subsystems don't seem to have retained anything about their size.

We have to decide on the complete naming scheme for helpers. dashes or no dashes? Capitalisation?

One thing I would like is to have all numbers that are expected to be recognised be padded to two digits (or three if you want support for more than 99 of anything).

For some reason the blender sample faces the opposite way to these samples. If I fix it so the blender one faces forwards, these face backwards, but the subsystems end up matching up...

Edit: I've put up a draft naming scheme on the wiki page.

[Vasudan Admiral]

Ah, some variety. But with variety comes a different naming scheme. For some reason all the scene nodes all have -node appended to their ids. It looks like the $ got turned into _ too and the subsystems don't seem to have retained anything about their size.

Yeah, I was afraid of that sort of thing being the case. Do you think you would be able to automatically tell the difference between the file outputs from the different programs, and adjust the interpretations accordingly? It'd really suck in any program if you had to point all your gunpoints, dockpoints, engine points etc backwards. :\

Edit: I've put up a draft naming scheme on the wiki page.

Nice - it looks fine.
The one suggestion I have there is:
Turret Firepoints
turretXX-YY

The COB/SCN light naming convention here is turretXX-FPYY. It's just a teeny tiny nitpick though>

[Spicious]

It can as long as the authoring_tool field has the right name.
It turns out that I had a 180 degree rotation for all the helper points too.
So if it sees Blender, everything gets rotated by 180 degrees. Otherwise it doesn't. That seems to fix it.

There is the possibility that everything's getting mirror imaged though, at least for the max samples.

[DaBrain]

Btw, do you think it would be possible to make PCS export DAE files?

So load and old FS2 POF, export it as DAE, edit/upgrade it and convert it to POF again using PCS2.

[Spicious]

It's planned. I might have a look into it sometime this week.

Just for fun, I've put the latest version here. May break things, may not work as intended etc.

[Vasudan Admiral]

Won't start up for me; gives an error saying 'This application has failed to start because the application configuration is incorrect.'

This is running it from the PCS2 install folder.

[chief1983]

Strange, I got it to open just fine.  However, upon opening (or importing) a DAE file, it seems to terminate the load and leave me with a blank render window.