[Spicious]

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

I have no idea what might be causing that but a google search would suggest that it might have something to do with this or something similar.

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.

Does the input file follow the naming scheme in the wiki page?
It should be saving a log file where the input is of all the bits it finds.

[Vasudan Admiral]

Hey, yeah it starts up now, thanks.

Now I'm getting the same thing chief reports - it appears to get halfway through the load and give up on the helpers version of the test ship. Here's the log output:

/I:/Blender/TestShipOne_Helpers.dae
/I:/Blender/TestShipOne_Helpers.dae#Shield-Geometry

[Spicious]

That's probably because it expects lowercase for most of the helper names. It looks like it did the shields though. If it doesn't find a detail0, the output's going to be pretty boring.

[Vasudan Admiral]

Ah ok - yeah that's what it wanted.
Would it be possible to make it all case independent though? I hate to think how many times I'd forget that little tidbit in future.

[Vasudan Admiral]

I'm trying to look into smoothing stuff now, but have hit a bit of a snag. Upon trying to convert the smoothing test model, it crashes with an array out of bounds error. The log shows:

/I:/Blender/SmoothingTest.dae
/I:/Blender/SmoothingTest.dae#detail0
/I:/Blender/SmoothingTest.dae#Cube

(Cube is the name of the mesh, detail0 the name of the object)

The model is here:
http://game-warden.com/starfox/Non_SF_related_stuff/MVP3610BETA/SmoothingTest.zip

[Spicious]

It sort of expects uv mapping for everything except shields, but I've uploaded a version that'll survive that.

[Vasudan Admiral]

ROFL @ "UV not found. How very boring."

Anyway, from this test it looks like there's no smoothing of any kind being applied to models. I really need to look into how to use blenders systems for smoothing properly before I continue though.

Edit: No wait, I speak too soon - it looks like it actually supports different types of smoothing within the same mesh already. Whether that's something you've implemented or just how the models are stored with regards to smoothing, this is awesome.

It doesn't seem to support autofaceted stuff though - they just come out as smoothed. Here are three cylinder input files with the different smoothing types applied:
http://game-warden.com/starfox/Non_SF_related_stuff/MVP3610BETA/SmoothingTypes.zip

[Spicious]

Currently it isn't looking for any smoothing at all and I think I've got it using the default value that the cob converter uses.

[chief1983]

It's going to be much desired for better support than that.  Max has some amazing smoothing features, and it seems Blender has some nice stuff too.  Modelers are going to take the time to get them just right, so this converter would be much more useful if it could understand the smoothing information.

[Spicious]

The smoothed and autofaceted files seem to be identical apart from the times. What is the autofaceted one supposed to do/be?

[Vasudan Admiral]

Yeah I was afraid that would be the case. Just confirmed it now with word's compare document thingie.

Autofacet is supposed to be where any angles between two connected polygon's normals that are below a specified angle (45° in this case) are smoothed, and any above are faceted. The idea is that autofacet with a good angle will smooth parts that are supposed to be smooth and facet parts that are supposed to be faceted.

[Spicious]

It seems that smoothing is dependent on the vertex normals, given that that's the difference between the faceted and smoothed versions. Since the importer sticks with whatever the input file has, it should preserve any smoothing present in the source file, unless of course it's stored in other ways too...

[Vasudan Admiral]

Unfortunately the 'autofacet' setting in blender I think is just a rendertime flag rather a trigger to actually perform autofaceting. :\

[Spicious]

Well that's a bugger. I have started working on the dae saver though. Again the most annoying parts are probably the textures and rotations.

[pecenipicek]

as a meantime "fix", TrueSpace 7.51 supports collada, however, i'm stilly trying to make it work.

i am experimenting on how to get the hierarchy through from cinema 4D to truespace, and no fish for now.

neways, i've tried exporting fbx from cinema then importing back in, the hierarchy sticks correctly, but truespace doesnt do fbx. okay. so find a fbx to dae converter (autodesks fbx converter is the one i'm using) and it converts the fbx to dae with no hierarchy loss, tested with a viewer app, however, getting it back to fbx doesnt work for some reason. will do some more research why truespace doesnt read the collada file made by the converter.

[edit#1]aaand for some silly reason, 7.51 apparently only exports dae, doesnt import it... yayness... will get back to this as soon as i find another solution.
[edit#2] ts 7.51 doesnt import collada file generated by itself either.... hmmm... perhaps the old vrml file format might be of use XD
will test.
[edit#3]tried exporting to wrl, it conserves the hierarchy, but smoothing seems... a bit odd. probably doesnt conserve it really well...

however, for anyone having woes with hierarchy exporting, the wrl format seems the most... well, usable one. ts 3.2 should be able to open it no problem too, so use it till we get proper collada into pcs2




aaaand my woes with the hell that is truespaces hierarchy are oooooveeeeer XD

hierarchy comparison from the two proggies.


minor differences, the names are preserved and the ordering is a bit different, but it works.

(those noticing me using the ts 3.2 trueview plugin with ts7.51 are getting shot in the balls. truespace lacks good native hierarchy editors.)

also, should i post this under freespace modding forum? the temporary solution for hierarchy transfer?)

[DaBrain]

3ds Max smoothing test DAE.
(POF from the max export plugin also included.)
Download

Should look like this in the end:



@VA

Your smoothing scene looks like this for me:
http://i33.tinypic.com/1zzruyw.jpg

[Spicious]

The dae importer seems to end up with a mirror imaged version. Oddly enough, the bounding box of the provided pof is also mirror imaged.

[attachment deleted by admin]

[Spicious]

Feel free to try exporting with the latest version now. The effects section is probably still a bit lacking but I've attached what testshipone produced anyway.

[attachment deleted by admin]

[Vasudan Admiral]

Oh wow. I am very impressed.
It managed to convert the 6000 poly new Aten to DAE, and then reimported it first time. Not only was smoothing preserved (which nothing else thus far has ever been able to do), but ALL the data of the original that the importer can interpret was there too. Awesome!

Also, I suspect the mis-shapen turret arms in testshipone is due to the way blender handles resizing of children objects when you resize the parent, meaning it's easy to avoid.

So, aside from more sample input files from other programs, I think that leaves the main two things to be done in terms of features as:
1) Galemps technique for making glass last on the render list
2) The turret/subobject data helpers.

Oh, and I'd really appreciate it if the object naming convention wasn't case sensitive. I just know that will cause minor headaches for new modders down the track.

[Spicious]

Did you try importing into another program?

I've had an idea about the turret helpers, given that turrets tend to be named all sorts of things. Instead of doing turretXX-YY, it would do <subobject name>-YY. That way it's clearer which subobjects are meant to be turrets and it's less restrictive on turret names. It's pretty much how the saver works currently. It doesn't create an entirely foolproof way to detect multipart turrets though.

It doesn't do paths, glowpoints or auto-centring yet. Paths just need somewhere to store the parent; auto-centring needs a name; glowpoints probably need quite a bit.

As much as I would like to help you with case insensitivity, I can't really do anything about it.

Edit: Paths are in, but parents have to be set manually.

Turret changes are in too.