Hard Light Productions Forums
Community Projects => The FreeSpace Upgrade Project => Topic started by: Galemp on June 23, 2008, 07:59:04 am
-
Calling all coders! The Freespace artists community has all pitched in, and we're willing to hire a coder to help us!
As you all know, current support for POF files is full of bugs. Everyone except Max and Truespace users have to use third-party applications to convert their model to a POF, sometimes with more than four steps. This means loss of data and geometry errors. Even the 3DS Max exporter has its own problems.
All these problems would be rendered moot with Collada (http://www.collada.org/) support. As a universal standard to be supported by all modeling packages, it would mean we can convert our models to POF with no geometry errors, no loss of UV mapping, no loss of hierarchy or smooth groups-- in short, set up all the data in our preferred program and then convert it to POF flawlessly.
We have established a bounty fund, to be delivered to the programmer or programmers who can implement a reliable, stable, functional, full-featured and documented Collada import-export system, either as a standalone converter or implemented into an existing POF editor. There's US$250 to be paid! (We expect that if there's significant collaboration, we'll all be mature enough to handle the distribution.)
If you're capable, or if you know of any resources that can help, post here!
-
Don't know if this would be of any use, but FCollada (http://www.feelingsoftware.com/content/view/62/76/lang,en/) is a free collada import/export library. If nothing else, it would save you the trouble of having to write a parser by hand ;)
-
So you want the FSO engine to support Collada files? OR you want to modify the .POF filetype in some way?
-
So you want the FSO engine to support Collada files? OR you want to modify the .POF filetype in some way?
No, we want the ability to import Collada files into PCS2. Or some other way to get Collada files into the POF format. Collada support in the engine would be a ridiculous request :rolleyes:
-
The only problem I've noticed with this, and it took me a while to even think about it, is the quality of the various apps' Collada exporters. We all know that different apps handle different formats better or worse, so what if every app turns out to have massive collada issues? Sure it's an XML format, but not all the plugins themselves are available for modification. So, has anyone tested the Collada exporters yet? Perhaps a test case could be created, pass a model through all the different applications strictly via collada, and see if the end result is close enough to the start. And, if enough data can be created and saved in each app, so that most of the POF data could be autogenerated from helpers/etc.
-
The good news is that Collada exporters for Max, Blender, Wings3D, or what have you are all maintained by their own individual authors, and we don't have to worry about them. They'll be steadily improved over time, without any additional help from us. :)
-
But improved with our interests in mind is what we have no control over. And that's my point, if there's some crippling issue with one of the exporters, who's to say we can get it fixed? Blender would be one of the most likely I would imagine, but as for the rest, most of which are built with proprietary SDKs and closed code bases, we'd be pretty much at the whim of the author. I'm not saying they're going to be assholes to us, just that with it out of our control, we would have no way of ensuring continued support for us. I would at least like to know where the exporters currently stand though, so I still think a test of them as they are now is a good idea, if it hasn't already been performed.
-
Hmm, guys, IDK if this is of any help at all, but D2X-XL has support for OOF models, as well as ASE scene and model formats of 3D Studio Max. Forgive me if this doesn't apply or won't help, but D2X-XL is open source, and is based off of Descent 1 / 2, which FreeSpace shares code with, right? So would it be easy to patch in support using Diedel's work? Or wouldn't that help at all?
-
But improved with our interests in mind is what we have no control over. And that's my point, if there's some crippling issue with one of the exporters, who's to say we can get it fixed? Blender would be one of the most likely I would imagine, but as for the rest, most of which are built with proprietary SDKs and closed code bases, we'd be pretty much at the whim of the author. I'm not saying they're going to be assholes to us, just that with it out of our control, we would have no way of ensuring continued support for us. I would at least like to know where the exporters currently stand though, so I still think a test of them as they are now is a good idea, if it hasn't already been performed.
The 3ds MAX and the Maya Collada plugin are open source now(!)
http://sourceforge.net/project/showfiles.php?group_id=136478
-
Well, that covers 3DS Max, Maya, and Blender. That's the bulk of it right there I'd imagine. Anything we need changed, hopefully we can manage. I'm sold then I suppose.
-
Hmm, guys, IDK if this is of any help at all, but D2X-XL has support for OOF models, as well as ASE scene and model formats of 3D Studio Max. Forgive me if this doesn't apply or won't help, but D2X-XL is open source, and is based off of Descent 1 / 2, which FreeSpace shares code with, right? So would it be easy to patch in support using Diedel's work? Or wouldn't that help at all?
No, I don't think Freespace and Descent 1/2 code are similar in any significant way. Descent 3, maybe, but I doubt it still.
-
i personally think that pcs2 should support as many formats as possible. collada might be better than cob but then again it might be worse. i like the idea of using an open source format, but if i cant do all the modeling, uv mapping, smoothing, and so on in one program, then export once then run it through pcs2 then im for it. i dont want to have to shuttle data between 3 or 4 programs to convert a model. and frankly as it stands id just rather use the max exporter than to do it that way.
-
Max supports Collada export. As do a lot of other things. It also looks Collada supports many of the features we need, including smoothing.
-
That's true, and has already been agreed. My only concern was the quality and openness of the exporters, which seems to be acceptable. That just leaves the point of this thread, getting support for collada into PCS2, or an interim app to convert it to PMF/POF.
-
i already installed a collada plugin for max. if it supports smoothing that would be awesome. what about heirarchy, naming, and special points (like dummies for autogen)?
-
Let it be known that with Collada
...we can convert our models to POF with no geometry errors, no loss of UV mapping, no loss of hierarchy or smooth groups-- in short, set up all the data in our preferred program and then convert it to POF flawlessly.
-
i already installed a collada plugin for max. if it supports smoothing that would be awesome. what about heirarchy, naming, and special points (like dummies for autogen)?
Dummies and special points are supported. Additionally lights can cameras can be saved too, as well as animations.
Heirachy and groups can also be saved. And materials/textures keep their complete paths.
And you can drag and drop collada files into MAX like a *.max file.
-
thats good. perhaps this is the format we should be using.
-
Galemp, like I told you on my PM, this seems like a wonderfull thing to have.
You have my support :)
-
thats good. perhaps this is the format we should be using.
Thank you, Captain Obvious. :rolleyes: You don't think we'd organize and fund something like this unless we knew it would be worth it, did you?
Anyway, I haven't heard from any coders yet... Kazan? Bobboau? Taylor? Anyone?
-
I dug around today to see what kind of information I could find that would be useful to have in advance of doing any coding. What I found was that I could not find the specifications for PMF, nor the source for PCS2. For some reason I thought Kaz was using the SVN on Sourceforge to store the code, but apparently I was mistaken. In any case, my belief was that even for a standalone converter, to go all the way from Collada to POF, it would be easier to do Collada to PMF and then use the PMF->POF routines already written for PCS2, as those seem to be stable enough, or at least already in active development on their own. But the lack of easy access to either the PCS2 code or the PMF specs makes that a bit difficult. Now maybe PMF isn't a very good option, and the converter should be written to go straight from Collada to POF with no in-between, but it seems like that would duplicate a lot of unnecessary work. If the PCS2 source or the PMF specs do exist somewhere, I think this would be a good place to reference them, possibly also link to any necessary Collada information and POF specs as well. That, or maybe a page dedicated to the development of this feature could be created. Nothing fancy, just a mention of this prize program and a list of pertinent information. Thoughts?
-
I could swear I saw the PCS2 source somewhere. Can't place it though. Maybe ask Kazan... :nervous:
-
http://alliance.cvs.sourceforge.net/alliance/pcs2/
-
Admittedly, I'm intrigued. It's not a wholly reasonable thing for me to do all by myself, but it would be a good learning experience, and the money involved would make it more of an informal part-time job...so hmm...
-
How much time and effort is this likely to take?
-
Well, what we want is a DAE importer for PCS2.
But it's not that simple.
I'd like to be able to store everything needed in the DAE file and just press "export" or "save" in PCS 2.
Subysystems, weapons, firing points, turrets, glowpoints, rotating parts.
The MAX exporter already set some standards for most of the stuff. There weren't many options for glowpoints though.
It does sound like quite a bit of work to me, but I'm not a coder, so the basic implementation might actually be harder than making PCS 2 interpret helper objects and additional infos in a DAE file into subsystems, glowpoints, ect.
-
Is anyone working on this?
-
I've given some thought to it but I lack both the modeling background and C++ experience necessary to do something like this. I think it would benefit from being a somewhat collaborative project though, getting constant input from modelers as it progresses. Why not just start fleshing it out right here? Maybe with a more narrowly defined concept someone might be more willing (and able) to start writing some code, or at least help kickstart more documentation of requirements. I think it would be useful if the converter were implemented in a dll, and for development purposes the dll could be accessed through a skeletal command line executable, that merely accepts DAE files as an argument. Now if I recall, the only real 'documentation' for the PMF spec currently is in the source code, which is available. The decision needs to be made as to whether it would be easier to go from DAE to PMF or straight to POF, and I'm guessing PMF will be easier, aside from the documentation being in source code format. So, with a DAE->PMF/PMF->DAE library, a full converter could be implemented either in PCS2, or by using the libraries for PMF->POF and POF->PMF in PCS2 in another application. If someone else has any better technical writing experience maybe this could start getting documented? I just created a page on the FS Wiki for this project. It could really benefit from some experience though.
Collada Importer on FSWiki (http://www.hard-light.net/wiki/index.php/Collada_Importer)
-
I can probably manage C++ without too much trouble, but a(n experienced) modeler would be rather helpful.
Doing it as a library sounds sensible enough. Are we trying for cross-platform with this?
POF/PMF shouldn't really matter much if this is intended for use in conjunction with PCS2. I'd just go with whichever is easiest. Is the POF specification around somewhere?
I think we should have the interface, the file format, who's involved etc. all set by perhaps this weekend.
-
I think crossplatform would make the most sense. The POF spec is around, yes, but I was having a bit of difficulty finding it earlier. It's probably on the wiki somewhere already though. And if it is made to be used with PCS2, then PMF makes the most sense in that it was designed to be used with PCS2, and to be easier to work directly with than POF. It's just whether there's enough documentation, since Kaz seems to not be around to ask about it lately.
-
IIRC the only real specification for the POF format is the FS2 source and the PCS2 source. There is no official, up to date documentation available anywhere. I found the FS2 source to be very helpful. I'll get you started though. A POF file starts with the four bytes 'PSPO', followed by a four byte integer which is the version. Beyond that, it is divided up into chunks. A chunk starts with a four byte identifyer (eg. 'TXTR' for the texture chunk), and then another four byte int which tells you the chunk's length, not including the header. I'm pretty sure all numbers are stored as little-endian.
-
Is PCS2 cross platform?
What I think we'll want are some models, ideally making use of as many chunks as possible, in both DAE and POF/PMF formats.
-
PCS2 is not cross platform, but the fact that it is written in WXWidgets means that it could be ported very easily.
A DAE -> POF/PMF converter is fine for testing purposes, but in the end, we probably want native support in PCS2...
-
If that's the goal, we'll definitely want to do DAE <-> PMF.
-
Let's try getting this organised:
Anyone who wants to participate in coding for this, please let me know by say Sunday.
Galemp, how do you feel about representing the "artists community"? I guess this would involve finding some test models too.
-
I think there's a few people who would be very useful here. If you go through the PCS2 beta threads, there were a few who were always the first to test it with some crazy models. VA, Water, etc would all be useful I imagine. I hope to be able to participate to some extent myself, but my C++ is very rusty.
-
I'd be happy to help in terms of test models. :)
-
COLLADA support in Cinema4D is up to par too, and this, if possible to do properly, would be a bloody lifesaver for all mod makers.
I fully support this endeavour and if it isnt done by the end of the year, many heads will roll :p
-
I'm a little too busy these days to be able to provide you with as much data as you need, but I can spit out a Max DAE or two. VA should be able to help with Blender DAEs, and I'm sure you'll find others with Cinema 4D, Wings 3D, SketchUp, or anything else to help you.
-
*raises hand for cinema4D test*
-
I think Brand-X will be willing to help with some of his recent Star Wars models as well, using ColladaMax.
-
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.
-
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 (http://swc.fs2downloads.com/files/pcs2_source_20080711.tgz)
-
Hmm. PMF isn't bad, but a native DAE support in PCS2 would be best.
-
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.
-
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.
-
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?
-
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.
-
About replacing POF in the code - it's possible, however, it's not worth the effort ATM, and isn't going to happen.
-
kk, thats all i wanted to know :)
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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 (http://www.cse.unsw.edu.au/~smcn929/cube.pof) with quite a few hardcoded things...
-
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..
-
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.
-
- 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?
-
Hideous on so many levels. ;)
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/TestShipOne.jpg)
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. :)
-
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]
-
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.
-
Wow that was mighty quick. Lovely work! :D
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. :D
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:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/TestShipOne-HelpfulHelpers.jpg)
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. :)
-
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]
-
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. :D 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. :)
-
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...
-
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. :)
-
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 .
-
Yeah that way would work fine as well and would probably be less hackish I think. :)
-
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.
-
Chief and Spicious just got a PM with max collada files from me. Is anybody else working on this?
-
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.
-
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> ;)
-
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.
-
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.
-
It's planned. I might have a look into it sometime this week.
Just for fun, I've put the latest version here (http://the158th.hard-light.net/spicious/pcs2.rar). May break things, may not work as intended etc.
-
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.
-
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.
-
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 (http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en) 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.
-
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
-
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.
-
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. ;)
-
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
-
It sort of expects uv mapping for everything except shields, but I've uploaded a version that'll survive that.
-
ROFL @ "UV not found. How very boring." :D
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. :D
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
-
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.
-
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.
-
The smoothed and autofaceted files seem to be identical apart from the times. What is the autofaceted one supposed to do/be?
-
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.
-
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...
-
Unfortunately the 'autofacet' setting in blender I think is just a rendertime flag rather a trigger to actually perform autofaceting. :\
-
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.
-
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.
(http://img390.imageshack.us/img390/740/c4dgr5.th.jpg) (http://img390.imageshack.us/my.php?image=c4dgr5.jpg)(http://img243.imageshack.us/img243/7992/ts751en6.th.jpg) (http://img243.imageshack.us/my.php?image=ts751en6.jpg)
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?)
-
3ds Max smoothing test DAE.
(POF from the max export plugin also included.)
Download (http://game-warden.com/starfox/Non_SF_related_stuff/DaBrainStuff/max_smoothing_test.7z)
Should look like this in the end:
(http://i38.tinypic.com/k1e1is.jpg)
@VA
Your smoothing scene looks like this for me:
http://i33.tinypic.com/1zzruyw.jpg
-
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]
-
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]
-
Oh wow. I am very impressed. :D
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! :D
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. ;)
-
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.
-
I'd also like to request that the converter works both ways. Ideally I ought to be able to convert a POF (or PMF) into a DAE, then feed it right back into the converter and come out with the same model without any data loss.
The main problem with that is having to rename all the objects during DAE export to maintain the convention required for POF export. It could cause minor problems in the ships.tbl subsystems entry.
-
I'd also like to request that the converter works both ways. Ideally I ought to be able to convert a POF (or PMF) into a DAE, then feed it right back into the converter and come out with the same model without any data loss.
Umm...
Feel free to try exporting with the latest version now.
It managed to convert the 6000 poly new Aten to DAE, and then reimported it first time.
Or are you being more specific when you say 'work'?
-
"Helpers with numbers in the form XX-YY typically refer to the YYth item in the XXth grouping. E.g. engine01-02 would be the second glow of the first thruster."
That doesn't really make much sense to me.
Actually it would be a lot easier to just have the (in this example) thrusters being children of the parent engine object.
At least glowpoints should work like this(!)
Because that was the one big advantage of the MAX exporter. I simply set up a helper as glowpoint group (with the texture defined) and all helpers linked to hit (child of) work as glowpoint, regardless of their names, while their radius was used for the size of each glowpoint.
-
I'm curious how involved it is to build an import/export plug-in.
I use Rhino and the file formats it currently supports:
Index of Import/Export File Types
.3ds (3dstudio max)
.ai (Adobe Illustrator)
.asc (points)
.csv (points)
.csv (properties)
.dgn (MicroStation)
.dwg (AutoCAD)
.dxf (AutoCAD)
.fbx (Autodesk)
.gdf (WAMIT)
.gf (GHS - General Hydrostatics Geometry)
.gft (GHS - General Hydrostatics Geometry)
GHS (General Hydrostatics Geometry)
.gts (GNU Triangulated Surface)
.kml (Google Earth)
.lwo (LightWave 3D)
.obj (Wavefront)
.off (Geomview)
.pdf (Portable Document File)
.pm (GHS - General Hydrostatics Geometry)
.pov (Persistence of Vision Raytracer)
.ps (PostScript)
.raw (Raw Triangle)
.rib (RenderMan)
.sat (ACIS)
.skp (SketchUp)
.slc (Slice)
.step (Standard for the Exchange of Product Model Data)
.stl (Stereolithography)
.txt (points)
.udo (Moray)
.vda (Verband der Automobileindustrie)
.vrml (Virtual Reality Model Language)
.x (DirectX)
.x_t (Parasolid)
.xgl (Solaris)
.txt (points)
I can get the SDK for Rhino without any trouble.
My overall C++ skills are enough to make small apps, but I've never tried writing a file conversion.
Is this more or less a find and replace tag interpreter?
The concept fascinates me a bit.
-
It's quite a bit more complicated than that. Every model format stores its chunks differently, some are binary files, some are text, etc. Each has it's own quirks, some implement features completely differently from others. For every converter you probably end up coding in quite a few kludges to make different features convert properly, so each one is going to be unique.
-
Essentially it would be a conversion from OpenNURBS with Rhino.
I just downloaded the SDK's for .NET & C++.
I appreciate the patience with me.
I am not concerned with investing the time to learn about it.
If I learn it once it may prove more invaluable to me any way to have a better ubderstanding of it.
Whether going to COB/POF/Collada etc... is the best approach...
There are tons of compatibility issues involved with any cross platform applications.
I just want to find a better format than 3ds to export into PCS2 or 3D Explorer.
So far OBJ has not been very stable. 3DS loses geometry with any size to it.
-
I understand, I was just trying to explain that it's more work than a find and replace interpreter. It's not like converting BBCode to HTML.
-
Umm...
I'm actually more concerned about converting POF->DAE->POF than I am DAE->POF->DAE. The real test would be if Volition's BSPgen models convert, since they're pretty unique in that the names don't correspond to the hierarchy.
-
"Helpers with numbers in the form XX-YY typically refer to the YYth item in the XXth grouping. E.g. engine01-02 would be the second glow of the first thruster."
That doesn't really make much sense to me.
Actually it would be a lot easier to just have the (in this example) thrusters being children of the parent engine object.
At least glowpoints should work like this(!)
Because that was the one big advantage of the MAX exporter. I simply set up a helper as glowpoint group (with the texture defined) and all helpers linked to hit (child of) work as glowpoint, regardless of their names, while their radius was used for the size of each glowpoint.
You'd prefer that for engines? It could probably be managed.
Fine, I'll look at glowpoints :p
I'm actually more concerned about converting POF->DAE->POF than I am DAE->POF->DAE. The real test would be if Volition's BSPgen models convert, since they're pretty unique in that the names don't correspond to the hierarchy.
That's where I'm working from. The current limitation is that no properties fields are saved, at all. Turrets should be find (other than the properties fields) as long as the barrels are subobjects of the base, which seems to be the case with :v: models. Paths have issues if path numbers are missing and they all lose their parents. Subobjects suffer from the properties issue and lose rotations too. Subsystems shouldn't be a problem. Engines lose their linked subsystems. Dockpoints lose their paths.
For the most part this is due to no decisions being made on where to store all this stuff.
Anyway, try it and tell me what you don't like about it.
-
Did you try importing into another program?
At that point no - didn't have the time. Now that I have, unfortunately it doesn't work.
Here's a pack contining the POF, the DAE produced from it, the error log that blender produces when importing it, and the blender DAE import/export scripts for reference. Hopefully something in that will help?
http://game-warden.com/starfox/Non_SF_related_stuff/MVP3610BETA/ColladaStuff.zip
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.
Yeah that sounds fine for the firepoints of turrets. :)
For multiparts, hmm....
Maybe look for an object with "<subobject name>-arm" to recognise them?
Actually it would be a lot easier to just have the (in this example) thrusters being children of the parent engine object.
At least glowpoints should work like this(!)
Because that was the one big advantage of the MAX exporter. I simply set up a helper as glowpoint group (with the texture defined) and all helpers linked to hit (child of) work as glowpoint, regardless of their names, while their radius was used for the size of each glowpoint.
That doesn't sound half bad. :)
It would be much more organised and hence easier to modify.
One thing about thruster glowpoints is that they can be the children of either an Engine subsystem or an engine subobject model. When the parent subsystem/subobject is destroyed, the children glowpoints dissappear. To accommodate for that, I recommend the points be set up as follows:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/BlenderTutorialStuff/Collada_Thruster_Helper_Setup.jpg)
In the top half of the pic the parent is a subobject, while in the bottom it's an engine subsystem. In both cases I have all the actual thruster glowpoint helpers set up as children of a generic "Glowpoints#" parent helper (the number is nessecary to avoid having two objects with the same name in the scene). I thought doing it this way would be best because it would allow you to have other helpers as children of the subobject to define other things such as properties.
In fact, maybe something similar could be done with the subobject properties field:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/BlenderTutorialStuff/Collada_Properties_Helper_Setup.jpg)
This way you would be able to 'write' multiple lines of subobject properties through the names of the children helpers (Again the ## on the end of "Properties" would just be a discarded unique identifier). The "Vectors" helper would be the one that defined both the u and f vecs with its orientation.
The full list of properties that it would need to recognise according to PCS2 is:
$special=subsystem
$name=x
$fov=180
$rotate=x
$detail_sphere:1,x
$detail_box:1
$box_min: x,x,x
$box_max: x,x,x
$triggered:
$stepped
$steps=4
$t_paused=2
$t_transit=6
$look_at:0
$uvec:0,1,0
$fvec:0,0,1
-
You'd prefer that for engines? It could probably be managed.
Fine, I'll look at glowpoints :p
Great! :)
The full list of properties that it would need to recognise according to PCS2 is:
$special=subsystem
$name=x
$fov=180
$rotate=x
$detail_sphere:1,x
$detail_box:1
$box_min: x,x,x
$box_max: x,x,x
$triggered:
$stepped
$steps=4
$t_paused=2
$t_transit=6
$look_at:0
$uvec:0,1,0
$fvec:0,0,1
I think PCS2 doesn't have anything to do with this. It simply has to put it into the custom properties of a subobject.
The FSO exe has to "understand" it.
-
Oh I know - but PCS2's list of what the engine will recognise covers everything nicely. ;)
-
I have nothing at all productive to contribute, but I just wanted to say that, after reading the thread, I'm really impressed by the rapid, efficient progress being made here. It's not often we non-coders get a chance to see even a glimpse of what goes on behind the scenes.
Considerable admiration!
-
At that point no - didn't have the time. Now that I have, unfortunately it doesn't work.
Here's a pack contining the POF, the DAE produced from it, the error log that blender produces when importing it, and the blender DAE import/export scripts for reference. Hopefully something in that will help?
http://game-warden.com/starfox/Non_SF_related_stuff/MVP3610BETA/ColladaStuff.zip
Interesting; it died because of a timezone thingo which I copied directly from the Collada DOM wiki...
If you look at any exported dae files, you'll notice that the time and date are always the same.
Try a new build. It should omit the timezone.
Maybe look for an object with "<subobject name>-arm" to recognise them?
I've got it assuming any subobject of a turret is probably serving as turret arms. This could do weird stuff if anyone has subobjects of turret bases. Is anyone likely to do that?
On engine glows and glowpoints, that's pretty much what I wanted to do with turret firepoints. Would there be a problem with grouping all the helpers for a subobject under one single node?
Something like
name
-subobject
-geometry
-helper
--firepoints
---firepoint
---...
--thrusters
---thruster
---...
--glowpoints
---...
--properties
---...
-
Nope - that sounds great, and I'll try and test the new build later tonight. :)
-
Ok, I've tried opening the pof in the latest build, and it does now work, but with the following problems:
1) Due to the FS co-ordinate system being a bit weird, the model is rotated 90°, pointing straight up. (In FS +X is port, +Y is upwards and +Z is forwards. In most other apps, +X is starboard, +Y is forwards and +Z is upwards.)
2) All the turrets, turret arms and other subobjects of anything are in very wrong places. The guns on top are moved below the ship and way forwards, the arms shift a little bit etc. It looks to me like it's just that some of the position axes are switched around or back to front. If you can't identify which is what yourself I'll see if I can make a simple test model.
3) No materials/textures are found on the model, though to be honest I'm not sure if that's an import script shortcoming or an exporter fault. :\
-
Thruster glows and turret firepoints have been switched over. Properties, glowpoints and paths might tomorrow.
Your glowpoint picture doesn't actually specify all the glowpoint properties.
No materials at all?
Hmm, I'm going to blame the axes thing on things not working like they seem they should. Everything is probably still mirrored on the X axis though. Try it now.
-
Paths and properties should be working now. One slight issue with properties is that it's splitting properties on spaces as well as new lines.
I've changed the textures to expect .tgas for now on export and things show up with ColladaLoader (http://sourceforge.net/projects/colladaloader/) now. Try it.
-
Nice, yeah all the geometries are now appearing in their correct locations, it's seeing materials and the properties are converting. :D
There are a couple of other problems though:
1) The model appears to be mirrored along the X axis (left-right) during the POF->DAE conversion.
2) There are now way too many materials: ;)
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/BlenderTutorialStuff/Collada_LotsOfMats.jpg)
Not sure if there's a way around this though. It could well be the import script interpreting the same material as lots of different ones, as the numbers resemble the way blender adds default numeration to duplicate objects.
3) Engine glows still don't appear in their correct locations - they appear way further back in the modeller, but oddly get put back in their right places during the DAE->POF conversion. In Blender when I resize the engine subsystem they're attached to down to 1x1x1 dimensions they're put back in their correct places.
4) I think the $special=subsystem property is being added by default during DAE->POF from before the new changes, because subsystems are now getting "$special=subsystem$special=subsystem" as their properties. Also as you said, the properties are getting split by spaces as well, which is resulting in:
$name=main
dock
5) For the thrusters properties, they seem to have acquired an extra $, resulting in: "$engine_subsystem=$$engine"
Oh - and would it be possible to have a question box pop up during DAE export asking if you want to export paths or not? Or maybe just one asking if you want all or no helpers converted with the model? I ask because there are times you only need/want the geometry and materials. :)
-
Heh, thruster glow positions are getting scaled. I'll take care of that a bit later.
1, 2 and 5 should be fixed though. However, Collada doesn't seem to like spaces in names...
Export without helpers should be possible.
-
Yes indeed 1,2, the first part of 4 and 5 are all working fine now :D
Maybe replace the spaces in names with % or something unusual?
-
% it is.
-
This rocks.
I've been waiting for a better art conversion process for a long, long time, I'm glad to see I'm not the only one! Taking a model through 4 different packages (by different developers, no less) just doesn't cut the mustard.
I'm available and eager to pitch in with conversion tests for Maya 8.5 and 3DS max 9.
Let me know if I can help - I will be eagerly awaiting release at any rate!
Great work guys,
Mahak.
-
At this point, the most useful thing would be to try it. Find out what doesn't work the way it should. The only problem right now is the info on the wiki is out of date. You can use exported files to figure it out though.
-
I've loaded a POF (Exported from the old Max plugin) to re-export it as DAE and take a look at the helpers.
Well, it didn't work. :(
I got this message:
"Oh my GOD ut's so HORABLE!!!"
-----------------------------------------
*ERROR*:Array out of bounds!
That's BAD!
30k polygons though... ;)
Edit: Same happens with the Nahema (Shivan Bomber 02). With or without exporting helpers.
However, the turrets seem to work.
Looks like this when imported in Max:
http://i35.tinypic.com/iqv9z8.gif
I hope that doesn't mean I'll have to set up dummies for each property...
There is an extra tab in Max for properties for each model and helper.
<extra>
<technique profile="FCOLLADA">
<user_properties>This is where I put in the Object Properties in Max.</user_properties>
</technique>
</extra>
</node>
<extra>
-
Hmm, I'm going to say that untextured polygons are bad. So are thrusters not attached to any subsystem.
I can get it to interpret the contents of extra fields, but there is the question of compatibility with other programs.
-
Well, I think it would be best if both options worked.
PCS should look for the extra field first, if it's empty, it should look for the property helper, or whatever Blender exports the properties into, which should be children under the object.
Yeah, you're right, the models with thrusters don't seem to work.
-
A slightly newer version should be able to cope with subsystemless thrusters. The importer will completely ignore them though...
Looking at extra fields on import shouldn't be a problem. The question is whether to use them as well/instead on export.
-
Try for 'as well' first I think. After a lot of searching and testing I never found any sort of user properties field in blender except for linking the object to an inbuilt script that was just text. Nothing of that script survived the DAE export though. :(
-
A slightly newer version should be able to cope with subsystemless thrusters. The importer will completely ignore them though...
Looking at extra fields on import shouldn't be a problem. The question is whether to use them as well/instead on export.
If Blender interpretes the properties as helpers, I'd go for the extra tab. I'll prepare a DAE for VA to test.
[attachment deleted by admin]
-
Nah, I'm converting properties into helpers on export.
And it should play nice with subsystemless thrusters now.
-
:(
Ok, I'll try to write a Maxscript that puts the data back into the right place again, so the DAE files stay interchangeable between the programs.
Somebody should do the same for Maya, which should use the <extra> stuff as well.
-
I can probably make it an option on export as to which format it uses.
-
Hey, that's a great idea. :yes:
-
It should now offer to export in either way. At some point this should be moving into the options instead of asking each time.
The thruster and path offset scaling should be fixed, and as an added bonus subobject scaling should be fixed too. So the turret barrels on test ship one are the right size and position now. (Why did no one complain about this?)
-
I was used to it from the COB exporter I think. ;)
Speaking of COB exporter hangovers - I just noticed now - the DAE->POF conversion puts the ship back-to-front, because testshipone was back-to-front as per the COB exporter requirements. :\
Totally my bad sorry.
As for export options, might we be able to eventually pick what aspects we do and don't want to preserve from a list? I know I'll never want path and probably not subsystem data either, but exporting firepoints, eyepoints, glowpoints and thrusters I would use much more often. And it's already a bit of a pain to hunt down and delete all the individual path helpers while leaving the rest.
Finally, did you implement that glass separation technique Galemp described? If so I'll give it a test. :)
-
I was used to it from the COB exporter I think. ;)
Speaking of COB exporter hangovers - I just noticed now - the DAE->POF conversion puts the ship back-to-front, because testshipone was back-to-front as per the COB exporter requirements. :\
Totally my bad sorry.
:lol: It should be fixed now.
As for export options, might we be able to eventually pick what aspects we do and don't want to preserve from a list? I know I'll never want path and probably not subsystem data either, but exporting firepoints, eyepoints, glowpoints and thrusters I would use much more often. And it's already a bit of a pain to hunt down and delete all the individual path helpers while leaving the rest.
Yes, but it'll have to wait until I start fiddling with the options, unless you want to answer a heap of "do you want to export...?" questions every time.
Finally, did you implement that glass separation technique Galemp described? If so I'll give it a test. :)
Not yet...
-
Yep, right way round now, thanks. :)
-
It should treat nodes containing "-trans" specially now.
-
It does treat them specially now in that it recognises the texture, and doesn't create a subobject, but it doesn't put the glass back either. ;)
I've attached good old test ship one again with the cockpit glass separated from the model and called "Cockpit-trans".
[attachment deleted by admin]
-
I thought you wanted <name>-trans to be the transparent parts of the subobject <name>.
-
...oh. Yeah I totally missed that. Well having just retested it, it looks like it works perfectly. Awesome! :D
-
Cool. Let me know when a complete format for glowpoint helpers has been decided or if you find any problems. I'll try to get the documentation updated sometime soonish.
Is there anything else that needs doing apart from updating the options and probably adding support for matrices for rotations and translations?
-
What do you mean by the matricies? Where would that happen/what would it do?
Anyway, in a day or so I'll be ready to give the converter a poly-monster test. I'll let you know how it goes. :)
-
Matrices are just another way to specify rotations, translations and reflections. I believe it was used somewhere in one of the 3ds samples. It wouldn't add anything new, just possibly wider support. For some reason it was decided that lots of options for specifying rotations/translations/reflections would be a good idea.
-
I mean I understand matricies and matrix operations, but I can't see what they would do in a DAE -> POF situation. You might be seeing the way DAE supports storing animations/physics.
-
It's one of the "transformation_elements" like rotate, translate and scale. The blender exporter doesn't seem to use it and so I haven't implemented interpretation of it.
-
There might be something wrong with the UV mapping...
Bomber04 (MVP version) seems to have broken UVs.
I've exported it as DAE from PCS2 and imported it in MAX.
That's the right version, the one on the left is from Lith, which can open POFs and export them as OBJs. (Kills lods hand helpers though...)
(http://i38.tinypic.com/2ro74h5.jpg)
And this is the difference in the UV layout:
(http://i37.tinypic.com/2zzhrat.gif)
-
It's getting vertically flipped?
Is this happening when opening with other programs and is it happening on import?
A new version should flip the V part on import and export now.
-
PCS2 seems to load the DAE, it exported before, fine.
It's only flipped in MAX.
-
PCS2 seems to load the DAE, it exported before, fine.
Of course it does, I've tested that. :p
-
Well, everything works fine with the new version.
It's correct in MAX and the exported DAE from MAX looks correct in PCS2 too. :)
However, I just noticed the object properties are missing...
I either get the helpers, or nothing.
-
Hmm, try changing the profile attribute in one of the extra fields from "" to "FCOLLADA".
-
Hmm, doesn't seem to help.
Here are the two examples.
PCS2:
<node id="helper" name="helper">
<node id="properties" name="properties">
<extra>
<technique profile="FCOLLADA">
<user_properties>$special=subsystem
$fov=180
$name=laser turret</user_properties>
</technique>
</extra>
</node>
MAX
<node id="helper6" name="helper" type="NODE">
<translate>0.027228 -0.158232 2.31009</translate>
<rotate>0 -0.000545 1 -180</rotate>
<extra>
<technique profile="MAX3D">
<helper>
<bounding_min>-0.01 -0.01 -0.01</bounding_min>
<bounding_max>0.01 0.01 0.01</bounding_max>
</helper>
</technique>
<technique profile="FCOLLADA">
<user_properties>$special=subsystem
$fov=180
$name=laser turret</user_properties>
</technique>
</extra>
</node>
Edit: Btw, does the POF format allow a second UV set?
-
Try it now, I've moved the extra bit to be a direct child of the node. And helper normals should be pointing the right way again...
Edit: Btw, does the POF format allow a second UV set?
I have no idea, but no seems more likely.
-
Well, it looks like it works now.
At least somewhat. Max doesn't seem to interpret the breaks correct.
(http://i33.tinypic.com/6te1s3.gif)
Btw the smoothing groups seem to work perfectly now :)
There is one thing I noticed abou the hierarchy though. I don't know how this looks for the Blender guys here, but for me it's pretty scary, considernig that this is just a bomber...
(http://i35.tinypic.com/jjagqe.gif)
Edit: Well, actually a bit different.
[missilebank01]
-[firepoint01]
-[firepoint02]
-[firepoint03]
-
At least somewhat. Max doesn't seem to interpret the breaks correct.
Blame inconsistent ends of lines of different operating systems.
Btw the smoothing groups seem to work perfectly now :)
Is this different to before?
Edit: Well, actually a bit different.
[missilebank01]
-[firepoint01]
-[firepoint02]
-[firepoint03]
That's the sort of approach I would have gone with for everything. Thrusters and paths have sort of migrated over to that way. I guess gunpoints and dockpoints probably will when I get time.
-
The last time I really tested for smoothing groups, it didn't work, but that has already been a quite a while ago... some days... don't ask... I don't realyl remember how many... ;)
-
Spicious, perhaps you could run the file through a replace on \r\n to just \n, or vice versa, so it's always in a consistent state? From the looks of that screenshot, Max needs a carriage return and a new line, and there's probably just a new line.
-
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.
(http://img390.imageshack.us/img390/740/c4dgr5.th.jpg) (http://img390.imageshack.us/my.php?image=c4dgr5.jpg)(http://img243.imageshack.us/img243/7992/ts751en6.th.jpg) (http://img243.imageshack.us/my.php?image=ts751en6.jpg)
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?)
I'm getting my full version of Rhino 4.0 this week and it does save to fbx, 3ds, 3dm, well many formats but not collada.
I'll have to take a look at the Autodesk fbx converter and see if that works.
If I can have a ready conversion from Rhino into PCS2 I'm going to be really happy if it is just fbx I need to use.
I just want anything except MAX to work with files. I'm surprised more modelers arent using Rhino, especially the Students?
-
Rhino is built around NURBS modeling, not polymeshes, and it doesn't support UV mapping. I used to model in Rhino; had to draw each polygon individually, vertex by vertex.
-
Honestly I'm not quite sure what differences the meshes have when I export into different file formats the models look the same? The texture mapping is pretty good now in 4.0, can actually view the rendered model without any speed hits while I work with it too. I do find some advantages working with nurbs solids then meshing the results if that is what you mean?
I just find it infinately faster and easier to get my desired shapes and models. Of course game model design is still new to me. My only previous experience with game modeling was Abacus and Combat Flight Simulator 1 & 2.
So far this has proven more difficult to make happen, but I'm enjoying the hobby and I like modeling with this platform.
If I absolutley have to I can use MAX 4 but I'll be frakked if I'll pay the same price for a 13 month limited student version of MAX for my hobby needs.
-
You don't have to.
If you can get a copy of Gmax, you can use the export script to export directly to POF.
http://www.hard-light.net/forums/index.php/topic,55007.0.html
-
The odd thing is that the lines are already ending with \r\n. The \r turns into "" on export though.
Support for other formats is really unlikely to happen, given that the whole point of Collada was to negate the need for directly supporting anything else.
-
The same thing fbx is supposed to accomplish?
-
You don't have to.
If you can get a copy of Gmax, you can use the export script to export directly to POF.
http://www.hard-light.net/forums/index.php/topic,55007.0.html
Is that specifically for GMAX?
I do have the POF export tool installed for MAX 4.
Although, Max 4 is like Max in general, fairly obtuse and steep to figure out.
I'll work my Rhino and check it out with MAX, but 4 is so limited with textures it isn't funny. Also it is impossible to find the 4.2 service pack that fixes most of it. I have a valid license for MAX 4 but of course none of the supporting systems with it and the commercial upgrade is again beyond worth spending the time or money on for a hobby.
-
No, it's the script that was just written for GMax and Max4+.
-
Dockpoints and gunbanks should be grouped now.
-
Ok, I'll run some tests on that. :)
-
In case anyone cares (does anyone care?), partial glowpoint support is in.
Positions, radii and textures are working. Times default to 0; LOD defaults to 0; type defaults to 0; normals default to (0,0,0). I doubt anyone would care about any of those apart from times.
-
How close are you to the prize? I am following the rapid progress of this program with some degree of astonished admiration.
-
Not sure, but it is testable, and it looks like the input requirements are up to date on the Collada Importer Wiki page (http://www.hard-light.net/wiki/index.php/Collada_Importer). Give it a whirl and see how it fares.
-
In case anyone cares (does anyone care?), partial glowpoint support is in.
Positions, radii and textures are working. Times default to 0; LOD defaults to 0; type defaults to 0; normals default to (0,0,0). I doubt anyone would care about any of those apart from times.
I care! (A lot!)
I simply was a bit too busy. Don't worry. I consider this to be one of the most important developments for FSO atm. ;)
-
How close are you to the prize? I am following the rapid progress of this program with some degree of astonished admiration.
Oh, without a doubt Spicious has won it. It's just a matter of time until he--and the testers--get the rest of the POF features and documentation done. :)
Spiky, I've been thinking about this problem with no text fields available to put in model data. Is it too late, or not possible, to have the app parse the necessary data from a separate plaintext file? (such as a model.ini in the same directory as the .DAE)
-
Any word why the fbx converted to DAE by the Autodesk converter doesn't work properly?
-
Spiky, I've been thinking about this problem with no text fields available to put in model data. Is it too late, or not possible, to have the app parse the necessary data from a separate plaintext file? (such as a model.ini in the same directory as the .DAE)
It's definitely possible. The question is whether it would be an improvement over the existing options.
Any word why the fbx converted to DAE by the Autodesk converter doesn't work properly?
No idea. Send it over and I'll tell you.
-
what does this program do? convert dae into pmf? or dae into pof?
-
I'll take a look with one of the example models when I get home.
I just saw a previous post about it not functioning, but havent had time to test.
I'll try to have some evidence before wasting anyones time again. My apologies :D
-
what does this program do? convert dae into pmf? or dae into pof?
It converts DAE<->PMF. The PMF<->POF routines are all built into PCS.
-
Is there a link for the converter? I've read through this entire thing and seemed to have missed it *rubs eyes*
-
Is there a link for the converter? I've read through this entire thing and seemed to have missed it *rubs eyes*
It's in Spicious's sig.
-
Thanks found it, but can't run it, "The application has failed to start its side-by-side configuration is incorrect. Please....."
Which build of pcs should I use with it?
-
I just used the PCS2.0.3 installer, and then swapped the executables. Seemed to work fine.
-
Ok I was running 2.0.2, but even with 2.0.3 it still complains about this.
Let me try googling it.
Edit: ok only tow results, and one was from me. What VC runtime are you using?
-
2008 (http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en)
-
2008 (http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en)
Thanks :) I had the same problem as Scooby, and that seems to have fixed it.
-
Yup that solved that problem, on to the next one.
I can't seem to get pcs2 to actually import a single object. It'll convert it, and even give the textures but no mesh data.
The object should be called detail01 right? (i've tried detail0, detail01 and detail1)
Also are the export settings correct? no bake matrices, do use relative paths, use normals, triangulate, and xrefs but no tangents/binomals and export animation?
-
Should be detail0.
Try checking that the node actually has an id of "detail0". I think the 3ds samples had "-node" added to all the nodes. Hmm, maybe it needs a warning if it doesn't find LOD 0.
As for settings: no idea, but I think normals sound sensible.
-
I do see detail0-mesh in the dae file.
-
That's good, anything else with detail0?
It expects to find a visual scene containing everything.
I'd suggest exporting a pof and basing things off that.
-
Ok i've renamed it to XML so notepad++ can collapse the layers so I can read them better.
I think the <library_geometries> is where the actual object/vertex data is stored in correct?
The exported max file is <geometry id="detail0-mesh" name="detail0">
while the exported pof is <geometry id="detail0-geometry" name="detail0-geometry">
I've renamed every occurance of -mesh and still nothing.
edit: is there a working demo model I could use?
-
The Language option in the menu allows you to override the detected language without needing to rename the file :)
VA and others posted some testing models earlier in this thread, some of them import ok currently, others don't meet the new input requirements.
-
Hmm ... no matter how much fiddling I do with the file, I have not been able to get the importer to open any of SketchUp's DAE files correctly. It opens them, seems to load the textures, but refuses to load any of the geometry :mad:. Not sure if you want to take a look at this, since SketchUp is kind of a fringe application in the world of FS modding, but if you want I can provide a couple of SU-exported DAEs...
-
Hmm ... no matter how much fiddling I do with the file, I have not been able to get the importer to open any of SketchUp's DAE files correctly. It opens them, seems to load the textures, but refuses to load any of the geometry :mad:. Not sure if you want to take a look at this, since SketchUp is kind of a fringe application in the world of FS modding, but if you want I can provide a couple of SU-exported DAEs...
Thats what I'm getting too.
-
The geometry naming doesn't matter. The important things are in <library_visual_scenes>.
-
Thanks for the explanation Spicious :D
That explains quite a bit with many of the formats I have tried as well with other 3D applications.
That would seem a fundamental key with the compatibility of platforms in terms of all the geometry showing up.
Makes it one hell of a lot easier trying to figure out what went wrong with the platform conversion process.
Many thanks for your work and guidance!!!!
It explains the inherent need for UVW mapping in the platforms as well based on my limited knowledge.
-
Ok I'm seeing this:
<library_visual_scenes>
<visual_scene id="epee19.max" name="epee19_max">
<node id="detail0-node" name="detail0" type="NODE">
<translate>-0.000011 -121.371 5.26339</translate>
<node id="detail0-node_PIVOT" name="detail0_PIVOT" type="NODE">
<node id="Object03-node" name="Object03" type="NODE">
<node id="Box09-node" name="Box09" type="NODE">
</node>
<extra>
<extra>
</visual_scene>
</library_visual_scenes>
Group detail0 contains Object03 and Box09. The node's name attribute seems correct.
-
The id is the important one though. Each subobject node should have an <instance_geometry> linking to its geometry too.
-
<node id="Object03-node" name="Object03" type="NODE">
<translate>0.000021 -102.244 37.7643</translate>
<instance_geometry url="#Object03-mesh">
<bind_material>
<technique_common>
<instance_material symbol="orig_Standard_2" target="#orig_Standard_2">
<bind_vertex_input semantic="CHANNEL1" input_semantic="TEXCOORD" input_set="1"/>
</instance_material>
</technique_common>
</bind_material>
</instance_geometry>
</node>
and in the instance_geometries:
<geometry id="Object03-mesh" name="Object03">
</geometry>
It appears it's prefixing the url attribute in instance_geometry with a "#" sign.
-
That should be fine if you want a subobject named Object03 or possibly Object03-node.
A find and replace of "-node" with nothing should fix the -node problem.
-
Ok the <library_visual_scenes> node id value points to the geometry id/name value and still notta.
edit: here's the sample dae file right out of Max.. http://scoobydoo.freespacemods.net/Problems/epee.DAE (http://scoobydoo.freespacemods.net/Problems/epee.DAE)
-
Have you got a node with id detail0 linked to some geometry?
-
Now are you linking or using groups?
-
It needs a node with id detail0 containing, as a direct child, an <instance_geometry>.
I have no idea what that corresponds to though.
-
Ok I'm getting somewheres now... although I absolutely hate linking instead of grouping.
But it comes up with this error "Unsupported rotation found. Go have a cry :P" LOL
It's the second child object that seems to be causing it
node info:
<node id="Box09" name="Box09" type="NODE">
<translate>66.3911 36.0552 -57.3595</translate>
<rotate>0.694746 0.694747 -0.186157 -158.909</rotate>
<scale>0.464667 0.46467 0.464667</scale>
<instance_geometry url="#Box09-mesh">
<bind_material>
<technique_common>
<instance_material symbol="Standard_3" target="#Standard_3">
<bind_vertex_input semantic="CHANNEL1" input_semantic="TEXCOORD" input_set="1"/>
</instance_material>
</technique_common>
</bind_material>
</instance_geometry>
</node>
Edit: i think i see where the problem with grouping and this importer is, a group node doesn't have a geometry entry.
-
Well, look at the rotation axis. It's just nasty. This was on the "ignore it until someone notices" list.
Is the model showing up at all now?
-
Yes, btw is that a quadrion angle set?
edit: btw the angle for it in Max is (-150, 0, 90), the scaling looks good (46.468) and i dunno about the translation.
-
Dunno. It's rotation axis followed by the rotation angle.
-
how do you set this up for export? I can't figure it out.
I am using blender.
-
Grab a POF and export it to DAE (for starters maybe do it without helpers). Import that into blender and have a look at the naming conventions there.
If that's not what you're after, what are you currently trying? I'll try and guide you through it from the blender side of things. :)
-
ok, I got it now. thanks.
but why are the path empties so HUGE? do they need to be so gigantic?
-
Their dimensions represent each path points radius, so yeah they do. ;)
-
What's the status on insignia polies?
-
Pretty much waiting for someone to suggest a format (or ask about them).
-
Ah. Well, the way it's been done in the past is to have an object consisting of the planes the insignia is to appear on (properly UV'd, of course) named 'insignia'. I can't help you any more than that. I don't know what POF chunk it's in, or any of that stuff.
-
The issue regarding insignia is about storing the LOD. The rest is just a triangulated mesh with uv. It should save and load insignia now but it assumes it's for LOD 0. I didn't think anyone else bothered with them anyway...
It should be able to cope with all rotations now and the other rotation issue that no one brought up should be fixed too.
-
I bother with them, I just don't do fighters very often.
-
I've decided to write a little app that'll give you easier/shorter naming conventions. All you'll need to do is run it through it then open the result with PCS2.
-
just an update on the Cinema4D front, release 11 is coming out in september, with full collada support, so around that time i'll be able to contribute to the testing part.
-
Scooby, perhaps that could be integrated into the Collada support, making the extra step unnecessary?
-
Hmm ... just had a thought. Will the import import an object that has no rotation, scale, or translation defined?
-
Scooby, perhaps that could be integrated into the Collada support, making the extra step unnecessary?
Well the first one i'm doing is more for personal dislike for extra typing numbers
The layout will be something like this:
-lod0
+turret1
- <base mesh>
+arm
-<arm mesh>
-fp0
-fp1
+destroyed
-<destroyed mesh>
-lod1
It's just a matter of reading the xml file and renaming and moving somethings around. It'll convert this variation back to the one PCS2 uses.
The next tool I might need to do is one that automatically removed the "-node" so the PCS can read the info correctly. -Done
And possibly the third tool is to allow you to use groups instead of linking.
Right now I'm working on the first one only.
-
just something I was wondering, does this keep blender smoothing?
-
Yes - but not autofaceting. So it will correctly read whether a face is set to solid or smooth. :)
Also something I need to look into is the idea of splitting (Y key) selected faces and smoothing them separately - because it behaves quite differently and looks far better, but it means the base hull is going to have a lot of holes and coincident verts. :\
-
autofaceting?
-
Above right of the Set Smooth and Set Solid buttons in the mesh pane you should see a blue "Auto Smooth" & <Degr> button. The idea of that is that any angles between face normals below that amount are smoothed (set smooth), and any above are faceted (set solid) hence it's usually called auto facet. :)
In blender to set it up, you set your whole model to smooth, and toggle on that button with an appropriate angle though you'll only see the effect in renders. Overall Blenders support for smoothing is not a pretty setup, only partially converts to POF and not nearly as awesome as Max's smoothgroup arrangment, but it is there.
-
I've just noticed something...
I've got a model setup as is in xml:
<library_visual_scenes>
detail0
+chair
+pilot
+box1
+box5
+......
Box5 being the wings
(http://img.photobucket.com/albums/v356/Shodan_AI/Extras/bug.jpg)
Is this just a for-loop glitch?
-
That's because of how you build your models rather than a glitch in the conversion I'm afraid. With COB conversions those separate objects under one object group would be automatically merged into one FS subobject with the object groups name. The DAE converter treats those separate objects correctly - and converts them all to FS subobjects.
I'm not sure where you're creating DAEs from here (Max or TS?) but you should be able to fix it by just attaching all the parts that would be part of the one FS subobject in Max, so one max object = one FS subobject.
-
Yuck, well that definetely complicates things a bit.
-
I got a problem. I have a single poly object mesh, I call it detail0. I use the Collada exporter plug in I downloaded for Maya and export it as a .dae file. When I open the .dae file with PCS2, I don't see anything. Under subobjects there's a green circle with "detail0" but I can't actually see the mesh in shaded or wireframe mode.
I've exported from PCS2 some other models, including that same mesh converted through a crappy means earlier. And one of Strattcom's cruisers. I can load them up in Maya just fine (and if I do the helpers for the cruiser I enter locator hell, but anyway).
So does anyone know what's going on??? I've tried both exporting all, and exporting the object proper. I've got the object basically centered on the 0.0.0 co-ordinates, or at least I have it such that 000 is where I'd want the pivot to be. But I don't see anything in PCS2. I don't know if anyone else has had this problem, I checked back a few pages but didn't see anything. But it's nearly 4am so I'm not going to check back any further right now :sigh:
EDIT - As an experiment, I took one of the files exported to .dae from .pof. And basically in Maya re-exported as .dae that same detail0 polygon object. I load it up in PCS2 and it says "normals not found wheeee" and then proceeds to show me nothing again. I dunno what's going on. When I did "export all" with all the locators for the gunpoints and stuff, it said the same then also said "rotate" about 15 times (or probably as many times as I have locators).
Here's the export options for the Collada ".dae". Maybe I've got it set up incorrectly????
[attachment deleted by admin]
-
You'd probably need to upload the problem DAE. When you say 'a single poly object' do you mean it has one polygon in it or you're just talking about the hull of a ship and nothing else? I'm assuming the latter.
My guess is that the Maya DAE exporter simply stores its models in a different way again from Blender and Max, so if you provide some sample maya DAE outputs maybe Spicious will be able to adjust the converter to accept Maya created stuff as well. :)
-
You'd probably need to upload the problem DAE. When you say 'a single poly object' do you mean it has one polygon in it or you're just talking about the hull of a ship and nothing else? I'm assuming the latter.
Yeah, what I meant is that it's just one object. One object that's a couple thousand polygons or so.
Anyway, here's the .dae export:
This export btw is an "export selection" style one with only the fighter mesh selected. (named detail0)
[attachment deleted by admin]
-
Oh, heh, I don't think it's anything you did/didn't do actually. I updated to the latest version from Spicious' sig link just now and nothing imports anymore. I saved an Orion to DAE, opened in blender, deleted everything but LOD0 hierarchy wise and resaved as DAE. Upon import into PCS2, it presents me with a blank screen. Polycount is there, bounding box is there but ridiculusly huge, but there's no actual polys visible.
This is the same with all other test models including testshipone, but I should point out that it seems able to convert models that it itself has saved. (Ie, POF->DAE->POF)
Spicious! Something borked! ;)
-
Division by zero is fun!
It should also fix the axes for models with their up axis set to y.
Normals still won't show up since they're stored in a slightly different place compared to everything else so far.
-
Yeah, it works again now, but I'm encountering an almost identical error when attempting to convert the barebones Hades, which I need to be untriangulated for conversion. (More efficient for collision detection, though the HTL engine will auto triangulate the model for display purposes)
Is there anything in the current code that might cause that with untriangulated (but no more than 4 sided) polygons? I can probably provide test models if you need them.
-
Sweet, yeah it works for me now. Or at least, the ship shows up in PCS2.
So, is it possible to set up all the gunpoints, dockpoints, etcetera in Maya (or software of choice?). Like can a person throw down a bunch of locators and have PCS2 interpret the data as whatever it needs to be? I still haven't gotten a good video card so PCS2 is prone to crashing on my computer when I add firepoints/gunpoints.
Another problem I noticed. My texture name seemed to become garbled when I exported it from Maya. Well, I had a pof, I used PCS2 to export it to Dae, then I loaded it up in Maya, resized the ship, and exported it again as a Dae and opened it with PS2 again. My texture name, currently outUV had the o and u replaced with ascii characters for some reason. I just renamed it in the pof editor.
-
Anyway, it seems to be working pretty damn good so far. Let me know when I have to pony up some cash. In the interim I'll try to actually try to finish a model and get 'er released for public consumption.
Oh wait, one thing weird I noticed. After I took my model to dae format, into maya, and then exported it out back again and back to pof the textures look wierd. Whereas originally it was bright with glow and shine maps, after taking it back to maya to resize the glow and shine maps don't seem to be on in PCS2 and the ship appears very dark. Or sometimes the glow maps work but not the shine maps??? I dunno.
-
Question.... does the converter see things like "turret01-fp-1" the same as "turret01-fp-01"?
-
So, is it possible to set up all the gunpoints, dockpoints, etcetera in Maya (or software of choice?). Like can a person throw down a bunch of locators and have PCS2 interpret the data as whatever it needs to be? I still haven't gotten a good video card so PCS2 is prone to crashing on my computer when I add firepoints/gunpoints.
Yes, the wiki page (http://www.hard-light.net/wiki/index.php/Collada_Importer) has the expected naming and organisation.
Oh wait, one thing weird I noticed. After I took my model to dae format, into maya, and then exported it out back again and back to pof the textures look wierd. Whereas originally it was bright with glow and shine maps, after taking it back to maya to resize the glow and shine maps don't seem to be on in PCS2 and the ship appears very dark. Or sometimes the glow maps work but not the shine maps??? I dunno.
That would be the problem with normals. Since it doesn't find them where it expects to, they default to (0,0,0).
Question.... does the converter see things like "turret01-fp-1" the same as "turret01-fp-01"?
Typically no, but for grouped helpers the names of the individual child helpers don't matter, only the parent. In the case of turret firepoints, the parent name only has to start with "firepoints" since they're children of the turret submodel.
Is there anything in the current code that might cause that with untriangulated (but no more than 4 sided) polygons? I can probably provide test models if you need them.
It should be fine for everything but shields and insignia. Tests are always good.
-
Ohh your doing things differently then... good.
How does the turret hierarchy show as?
in the original it was
+detailX
+turretX
+turretX-arm
+turretX-fp-Y
+turretX-destroyed
-
It should be something like
+detailX
+turretX
+turretX-arm
+helpers
+firepoints
+firepoint
+firepoint
+etc.
+turretX-destroyed
-
Does each firepoint needs to be numbered?
-
No.
Incidentally, the normals issue with Maya should be fixed.
-
BTW, you know you can grab the turret-arm value from the
<node id="turret0X-arm" name="turret0X-arm">
<instance_geometry url="#turret0X-arm-mesh">
The URL contains the proper lookup value in <geometry_instance>.
if you just use "arm" for the turret-arm name and have more than one turret it'll still work. it'll look like this:
<instance_geometry url="#arm-mesh">
<instance_geometry url="#arm-mesh1">
those are the proper id's in <library_geometries><geometry>
-
You can call the turret and its arms whatever you want, but all naming comes from the node id/name. I'm not sure what might happen if FS sees two subobjects with the same name though.
-
I was refering to the hierarchy setup. That's what I'm doing with my own modifier program.
Instead of having in your case:
turret01
+turret01-arm
+firepoints
+firepoint
have:
turret01
+arm
+firepoints
+firepoint
no need for duplicate turret0X entries (this will allow making clones of the turrets fast and easy)
-
No.
Incidentally, the normals issue with Maya should be fixed.
Yeah it works beautifully now.
Though having more troubles of perhaps a different nature . . . I made a shield mesh, but when I open the .dae export in PSC2 the shield is translated backward a little, exposing part of the fighter. Despite the fact that in Maya I have the shield and fighter in the same place, with all translates and rotates at zero?? This may be a different sort of error, I don't know. I'm only trying to get my first ship into the game. Of course I could also just adjust the shield, such that when it goes to POF it's in the right place despite starting off in Maya in the wrong place :)
Also, I noticed that if I export to dae from PCS with the helpers + locators (gunpoints), and then if I re-export that stuff from maya to .dae, the PCS2 will crash when I try to load up that same .dae again. Instead I have to global import the values. I don't know if this is because of the helpers or what. Maybe if I just did locators for firepoints it would work just fine???
EDIT - despite the shield seemingly appearing in the wrong place, it doesnt seem to work as such in the game (the nose of the ship is not infact sticking through the shield?). Though using a a weapon with 0.0 shield factor, I found a bunch of holes in the shield for my ship. Probably some error on my part, and I intend to run it past another modeller to see what I've all done wrong.
-
Also, I noticed that if I export to dae from PCS with the helpers + locators (gunpoints), and then if I re-export that stuff from maya to .dae, the PCS2 will crash when I try to load up that same .dae again. Instead I have to global import the values. I don't know if this is because of the helpers or what. Maybe if I just did locators for firepoints it would work just fine???
Can you try importing and exporting something with Maya and upload it?
-
Also, I noticed that if I export to dae from PCS with the helpers + locators (gunpoints), and then if I re-export that stuff from maya to .dae, the PCS2 will crash when I try to load up that same .dae again. Instead I have to global import the values. I don't know if this is because of the helpers or what. Maybe if I just did locators for firepoints it would work just fine???
Can you try importing and exporting something with Maya and upload it?
Hmmn, I gave it another go and it seemed to work fine this time around. Tried with both a custom fighter and the mediavps Serapis. Not sure what the problem was before but will let you know if it happens again. May have been a lack of memory since sometimes I have way too many things open.
-
Is there a diagram view of the all the entries with proper naming? Also what's the exquivalant of EngGlow01-01 and EngGlow02-01?
-
Wait, no I got some wierdness going on.
Ok first of all, I figured out why it was crashing PCS2. For some reason I had a node called "shield" that seemed to be the cause of the crashes. I don't know why this was there, it doesn't seem to be necessary. (note, it was a node shield, not the geo shield or shield0 whatever).
So anyway, few days ago, I have a custom model. PCS2 doesn't really work for me because it crashes when I try to add gunpoints because my video card is crap. So I use Modelview to add subsystems and gunpoints to my model. It works, though for some reason I export to .dae and into maya and back again. Later on, in model view, the gunpoints are all still there, but they're in the wrong place. (they're translated down and backwards of where I placed them) In Maya, they're in the right place. But in modelview or PCS1 they appear in the wrong place. In game, they originate from the proper place as well (ie they work despite how they look in modelview)
So then, I want some more things on my fighter. Specifically a dockpoint and thrusters. I export the Anubis .pof to .dae, and take its dockpoint node. Then position it below my fighter. I export the Tauret .pof to .dae, take its thruster node, and duplicate the thruster locator a few times (for more thrusters) and position it in Maya. I also add an eyepoint named eyepoint01. So then I export this from maya to .dae, and then bring it into PCS2 and convert to pof. No crashes. Then I check out the model in modelview, now, all of the gun normals are both in the wrong place and facinng 90's downward instead of straight ahead. Also the Anubis dockpoints, which are on the bottom, now face both fore and aft (it had two for some reason?? or two lines anyway). I load FSOpen, and load my test mission. It loads fine, the guns and missiles still fire forward. The thrusters are there. But I forgot that the texture name gets buggered, so there's no texture. I open up ModelView (and later PCS2) to change the texture name to the proper one. I do so. But when I open up my test mission in FSOpen again it crashes again and again. (despite having played the game with textures earlier).
I also pull the Serapis from the mediavps. Save from pcs2 to .dae, import into maya, export to .dae, load into PSC2 and save as pof. I load in ModelView, the gun and missile normals on this are also all facing straight down instead of straight ahead. I'm not sure what's going on.
Anyway, attached is a zip with both the Serapis export from Maya. And the custom fighter export (with full thrusters, dockpoints and eyepoint -ie the one that crashes FSOpen).
[attachment deleted by ninja]
-
I had some issues where I had to split a mesh,
delete the side that kept getting wierd,
mirror the good side,
cull degenerete faces,
unify normals,
then join the two sides and repeat the unify normals and cull degenerate faces.
The mesh finally worked to actually get it to come up right.
Really strange because I had already built the mesh that way to begin with and it wasn't a complicated poly at all.
Only about 2000 faces in the total model.
Still trying to get the TrueView heirarchy into TrueSpace 7.6.
Is there a link telling me how to get that working you guys know of?
Also where do I get PCS with Collada support?
I'm having to go through a few extra steps though since I'm using Rhino 4 and then bringing the file into TrueSpace to make a dae file.
I tried the Autodesk fbx format converter also and had similiar missing faces results. I haven't tested the Autodesk fbx conversion since I fixed the mesh though. I'll get back to let you know the results.
-
basically, you have to use the vrml 1.0 format for importing into TS. i'll make a post regarding that later tomorow
-
Thank you sir, I remembered some mention of vrml before,
but I wasn't sure if that was a diagnostic check or actual conversion considerations :D
-
You can get PCS2-Collada from Spicious' sig, it's all over this thread.
-
Thank you sir, I remembered some mention of vrml before,
but I wasn't sure if that was a diagnostic check or actual conversion considerations :D
that is my method of exporting while keeping the hierarchy setup intact.
its in this thread somewhere around the first few pages (my post with a bit more... elaborate explanation)
-
Perhaps put that on the wiki for now. Any tips, tricks, hierarchy setup, etc should go there for ease of reference.
-
So anyway, few days ago, I have a custom model. PCS2 doesn't really work for me because it crashes when I try to add gunpoints because my video card is crap. So I use Modelview to add subsystems and gunpoints to my model. It works, though for some reason I export to .dae and into maya and back again. Later on, in model view, the gunpoints are all still there, but they're in the wrong place. (they're translated down and backwards of where I placed them) In Maya, they're in the right place. But in modelview or PCS1 they appear in the wrong place. In game, they originate from the proper place as well (ie they work despite how they look in modelview)
I've fixed the gunpoints, dockpoints etc. facing the wrong way for the most part. Thrusters seem to have their rotations in the wrong order in the files for some reason. As for position, in your model detail0 is offset from 0,0,0 causing the weapon points to not line up correctly.
-
I've fixed the gunpoints, dockpoints etc. facing the wrong way for the most part. Thrusters seem to have their rotations in the wrong order in the files for some reason. As for position, in your model detail0 is offset from 0,0,0 causing the weapon points to not line up correctly.
Sweet, thanks a bundle. I've got most everything working except for the dockpoints. I can't get the ships to dock to the underside of the craft, they keep crashing through and docking ontop. I don't get it. But I'll ask in the modding forum. The thrusters were wierd, but I just grabbed new ones from the Seth and duplicated those instead. They seem to work now.
I'll let you know if I have any more problems. Hopefully that's the last of 'em.
-
okay, here is the whole tutorial on using the vrml technique.
http://www.hard-light.net/forums/index.php/topic,56047.0.html
-
Sweeet! Thanks man you Rock!
-
Hmmm I think this latest build broke something... I remove the "-node" entries and get this: "instance_geometry not found for subobject detail0".
<node id="detail0" name="detail0" type="NODE">
<instance_geometry url="#detail0-mesh">
and <geometry id="detail0-mesh" name="detail0"> exist
-
Have you tried some pov file comparisons?
-
Found the problem... The model wasn't centered exactly at (0,0,0) so I moved it.
You need to reset x-form even just for that.
Ok, back to where I was confused before. What is the naming convention for gun/missile points? It exports them as gunbank0X and gunbank0X-0Y. The importer will read them and create them, but give them a position of (0,0,0) and a normal (0,1,0) straight up. X-form resetting didn't help.
-
With PCS on engines I kept finding the normal for setting them on a model would adjust to a line extending straight behind at 90,0,-1. I havent figured out if the numbers were in radians or degrees.
I havent spent much time with them but on three model imports I found those numbers worked. But I have yet to put one in game because of my texture/uv experience lacking. I would have to defer to the PCS guys that actually have done a full model though. It could just be the fact I consider +z - up, -y - front, & +x - port side.
If you need radian to degrees conversion I have the formula somewhere in my CAD lisps, I cant remember it off the top of my head right now.
-
err ... normals are vectors, not angles. It is the x, y, and z axes respectively. So if you wanted a normal facing forward, it would be 0,0,1. Backward would be 0,0,-1, up would be 0,1,0, right would be 1,0,0, and so on. And, of course, you can combine numbers to get things other than straight angles.
-
Ok, back to where I was confused before. What is the naming convention for gun/missile points? It exports them as gunbank0X and gunbank0X-0Y. The importer will read them and create them, but give them a position of (0,0,0) and a normal (0,1,0) straight up. X-form resetting didn't help.
The gunbankXXs are important, the gunbankXX-YYs don't matter.
Have you got some <matrix> or <skew> fields under the individual gunpoint nodes?
They aren't yet supported since no one has used them and I have no idea what skew is meant to do.
-
Yup, looks like some soft of transformation matrix. Although the values don't seem to represent object locations.
Heres the entire chunk:
<node id="gunbank01" name="gunbank01" type="NODE">
<matrix>1 0 0 217.005 0 1 0 70.7379 0 0 1 -43.1849 0 0 0 1</matrix>
<node id="gunbank01-01" name="gunbank01-01" type="NODE">
<matrix>1 0 0 -193.593 0 1 0 -171.384 0 0 1 -40.0538 0 0 0 1</matrix>
<extra>
<technique profile="MAX3D">
<helper>
<bounding_min>-4.60205 -4.60205 -4.60205</bounding_min>
<bounding_max>4.60205 4.60205 4.60205</bounding_max>
</helper>
</technique>
</extra>
</node>
<node id="gunbank01-02" name="gunbank01-02" type="NODE">
<matrix>1 0 0 -240.43 0 1 0 -171.384 0 0 1 -40.0538 0 0 0 1</matrix>
<extra>
<technique profile="MAX3D">
<helper>
<bounding_min>-4.60205 -4.60205 -4.60205</bounding_min>
<bounding_max>4.60205 4.60205 4.60205</bounding_max>
</helper>
</technique>
</extra>
</node>
<extra>
<technique profile="MAX3D">
<helper>
<bounding_min>-10.4952 -10.4952 -10.4952</bounding_min>
<bounding_max>10.4952 10.4952 10.4952</bounding_max>
</helper>
</technique>
</extra>
</node>
-
It looks like the grouping helper "gunbank01" has a position offset going on. If you add the individual gunpoint offsets (the non-zero and non-one entries) to the gunbank offset, you should get the right positions.
I'll look at adding matrix support when windows stops spontaneously rebooting.
-
It looks like the grouping helper "gunbank01" has a position offset going on. If you add the individual gunpoint offsets (the non-zero and non-one entries) to the gunbank offset, you should get the right positions.
I'll look at adding matrix support when windows stops spontaneously rebooting.
You got that screen saver installed? :p
-
What is the minimum requirement for a mesh to convert?
I've got a mesh here, just "detail0", no nodes and I can't get it to convert to POF.
There us no error message, it loads the model. The texture names are correct, just the mesh isn't there. (Nothing visible, size 0,0,0 mass 0)
Edit: Something is also going wrong with the smoothing, when I import a DAE from PCS2 in 3ds.
The smoothing is there, I can see it, but in the "edit mesh" tab, there isn't any smoothing group used.
When I convert it to "editable poly" to work with it, the smoothing is gone. :(
-
Are you exporting from Max?
edit: if so, check the dae file for "-node" entries. Delete those (or simply replace [-node"] with ["])
-
It looks like the grouping helper "gunbank01" has a position offset going on. If you add the individual gunpoint offsets (the non-zero and non-one entries) to the gunbank offset, you should get the right positions.
I'll look at adding matrix support when windows stops spontaneously rebooting.
Any luck? The one in your profile still is the older version.
-
Sorry I took so long to get around to the insignia test model - as usual, I'd forgotten all about it because PCS2 can't edit them at all. Anyway, I've attached a test DAE that includes insignia implemented based on how PCS1 expected insignia in the COB.
There are a couple of small issues to note:
1) The insignia are basically just the usual poly objects with a single texture applied
2) Each individual insignia logo must be a separate object
3) Whatever texture (if any) is applied to the insignia polys MUST NOT be added to the main texture list
4) The poly models themselves MUST NOT be added to the subobject list as PCS1 does
5) In the test file I have set it up with a total of four insignia, not attached to anything, since I figure you'll want to get the guts of it working before deciding how best the input should be provided. The naming convention is: "insigLOD00-01" for the first insignia on LOD 0, and "insigLOD01-01" for the first on LOD 1.
When you're ready, let me know how you want to see them grouped in the scene if you have a preference and I'll upload a test model for that case too. :)
[attachment deleted by ninja]
-
1) The insignia are basically just the usual poly objects with a single texture applied
That's fine and should work.
2) Each individual insignia logo must be a separate object
That should work too.
3) Whatever texture (if any) is applied to the insignia polys MUST NOT be added to the main texture list
Can't really help you there since the texture list is generated based on the Collada library_images section.
4) The poly models themselves MUST NOT be added to the subobject list as PCS1 does
That should work.
5) In the test file I have set it up with a total of four insignia, not attached to anything, since I figure you'll want to get the guts of it working before deciding how best the input should be provided. The naming convention is: "insigLOD00-01" for the first insignia on LOD 0, and "insigLOD01-01" for the first on LOD 1.
That could work. Currently it'll assume anything beginning with "insignia" is an insignia but it doesn't do anything about LODs yet.
Any luck? The one in your profile still is the older version.
I've been busy recently but I should have some time soonish.
-
That's fine and should work.
Oh, you mean insignia generation is already in? If so, great! And I'll give it a test as soon as I can. :)
3) Whatever texture (if any) is applied to the insignia polys MUST NOT be added to the main texture list
Can't really help you there since the texture list is generated based on the Collada library_images section.
Hmm, so currently if we leave the insignia polys as untextured it should still work?
Also, since we need to apply a texture to the polys beforehand anyway to align them correctly, could we perhaps have a specially recognised texture name like "Insignia" or whatever that if encountered in the library_images section, would not be added to the PMFs texture list?
I ask because this is one of those things that would easily go unnoticed during conversion and would probably result in having one texture too many in the list. You usually do not want to touch the texture chunk in PCS2, because deleting or adding anything there invariably causes problems. As such, you'd need to reconvert the model again.
-
It's been in for a while now.
Also, since we need to apply a texture to the polys beforehand anyway to align them correctly, could we perhaps have a specially recognised texture name like "Insignia" or whatever that if encountered in the library_images section, would not be added to the PMFs texture list?
Sure.
Edit: Try now. It looks for insigLODXX-YY, starting with 01 for both. It also will ignore any textures beginning with "insignia", case insensitive. Finally, it might deal with matrices properly too.
-
Are you exporting from Max?
edit: if so, check the dae file for "-node" entries. Delete those (or simply replace [-node"] with ["])
Looks like that worked. At least it's loading something now. It just takes a while. 50k polies...
@Spicious
What is the maximum number of faces or verticies for a model, PCS2 can handle when importing DAE files?
Edit: No. :(
I still can't import the model. It's stuck on "processing subobjects" at 1/10 of the bar I'd say.
Edit2: Weird. I used 3ds to convert it, that worked fine.
Then I opend the POF in PCS2, also no problem, but when I try to save that as DAE I get: "Error Array ran out of bounds"
-
It shouldn't have any limits other than those imposed by memory or time. 50k shouldn't take too long.
-
a better question, how many polys and vertices per subobject before bspgen chokes up? i'm having various differing problems getting a 120k poly model to convert...
-
a better question, how many polys and vertices per subobject before bspgen chokes up? i'm having various differing problems getting a 120k poly model to convert...
BSP has nothing to do with the collada importer. The BSP tree is compiled when the POF is saved.
-
its not related to collada, just the general limit
[edit] from my findings, it still crap out at 35k per subobject, time to cut it up some more.
also from what VA said, it can go on with around... 18 to 24-5 k poly's without crapping out
[edit#2] craps out at 15928 polys on a single subobject... cutting out more should help but i'm too tired to do more at the moment... will get back tommorow
-
What happens if you weld vertices?
-
What happens if you weld vertices?
If theres no triangle-polygons between the two vertices (or more) then nothing happens (just vertex reduction). If there is triangle-polys then those will get deleted. Provided something didn't get mucked up.
-
No real changes today, but it's switched from statically linked ColladaDOM to dynamic. Basically, smaller executable size, but you'll need this dll (http://the158th.hard-light.net/spicious/libcollada14dom21.7z).
Edit: No. :(
I still can't import the model. It's stuck on "processing subobjects" at 1/10 of the bar I'd say.
Edit2: Weird. I used 3ds to convert it, that worked fine.
Then I opend the POF in PCS2, also no problem, but when I try to save that as DAE I get: "Error Array ran out of bounds"
Care to provide the model?
-
PCS2 usually hangs when there are some wierd objects generated inside the model part it hangs on or else the name structure has a -0 or -# that doesn't have another component to complete it. i.e. You have a group named Hull-0 and a component named Hull-1.
-
No real changes today, but it's switched from statically linked ColladaDOM to dynamic. Basically, smaller executable size, but you'll need this dll (http://the158th.hard-light.net/spicious/libcollada14dom21.7z).
Edit: No. :(
I still can't import the model. It's stuck on "processing subobjects" at 1/10 of the bar I'd say.
Edit2: Weird. I used 3ds to convert it, that worked fine.
Then I opend the POF in PCS2, also no problem, but when I try to save that as DAE I get: "Error Array ran out of bounds"
Care to provide the model?
PM sent. :)
-
It finished importing eventually, but I've changed it to do things in a less woefully inefficient way.
Edit: And similarly for exporting too.
-
Is the new build already in your signature?
Sounds like a great improvement. :)
-
Yes.
-
Hmm, now I need "libcollada14dom21.dll".
-
you'll need this dll (http://the158th.hard-light.net/spicious/libcollada14dom21.7z).
-
Can you link that in your sig too? I think it's going to be missed by a lot of people since that's where everyone currently looks for the link to the latest PCS2 build.
-
Wow, the importing of DAE files got a lot faster. :yes:
-
I tried loading the SoL city POF and saving it as DAE, but wasn't able to open it in 3ds.
Any idea what this could mean?
(http://i37.tinypic.com/u0qdi.png)
Did I send you a copy of the city already? I can't remember if I gave it to Kazan, or to you...
And there is still the problem that the smoothing can not be imported correctly ind 3ds.
-
I believe I have a DAE of it. It does seem to infinitely loop the bsp code, at least when I tried it. It'd be easier to send over the POF you're working from anyway.
I'm not sure what I can do about smoothing. Do other DAE files maintain smoothing?
-
I'll pack up the POF and load it up.
Yeah, other DAE files maintain the smoothing. When I import DAE files from PCS2, they do also look like they have the correct smoothing, but none of the 32 supported smoothing groups is beeing used by any polygon of the model.
When I change it from "Mesh" to "Poly" it looses the smoothing completely.
My guess is, that the smoothing groups used by PCS somehow are over the number 1-32. Which would explain why I can't edit them.
-
Been away for a long while - great to see so much progress on this!
Question for maya users - what are you using for helper objects? (gunbanks, glow points etc etc) Locators don't seem to keep their transforms on export - resets everything to 0,0,0.
This may have been answered somewhere on this thread, I couldn't seem to find it though.
M.
-
Been away for a long while - great to see so much progress on this!
Question for maya users - what are you using for helper objects? (gunbanks, glow points etc etc) Locators don't seem to keep their transforms on export - resets everything to 0,0,0.
This may have been answered somewhere on this thread, I couldn't seem to find it though.
Well the gunpoints are just locators.
I'm not entirely sure what the helpers are though, I just tended to take values from other ships, bring them onto my own via PCS2 and then edit it in Maya. But I usually just edit the points themselves rather than the helpers.
-
Been away for a long while - great to see so much progress on this!
Question for maya users - what are you using for helper objects? (gunbanks, glow points etc etc) Locators don't seem to keep their transforms on export - resets everything to 0,0,0.
This may have been answered somewhere on this thread, I couldn't seem to find it though.
M.
My suggestion: Take similar ship, that already is stored in a POF, open it in PCS2 and save it as DAE file.
Open this file in Maya and you can get a pretty good overview how the setup for ships works in Maya. ;)
@Spicious
Maybe there is something wrong with the model itself. I'll take a very close look at it tomorrow before I load it up.
-
Two questions. First did the misplaced helpers get fixed yet? I noticed that they still are misplaced. Second whats the scaling conversion from max, 1 meter = 1 FS meter?
-
Yes, if your unit setup in Max is set to meters, 1m in Max is 1m in FS2.
-
Hmm, it seems that something's wrong with exporting DAE files with helpers. In short, it doesn't - even if you say yes to "Export Helpers?".
-
It seems to work for me. Did this start happening recently?
-
I'm not sure - usually I export ships without helpers because I'm just after their scale or something. I'll retry it now with your latest sig build, though I think I'm already using it.
Which ships did you test it on BTW?
-
The high poly Ares, the Evanglist from 158th and a handful of probably secret models from MT.
-
Crap, figured it out. The new blender version (2.4.7) seems to have stopped reading helpers and interpreting them as blender empties. Now, while that means one solution is to copy the old script stuff from blender 2.4.5, that's not a very newbie friendly method. :\
I've attached the python script files (both sets) blender uses for collada related things in the hope that you can maybe spot what's going on there? I just have no idea what I'm looking for exactly - but I think it will be somewhere in translator.py, as that seems to be what deals with exporting.
If they've for whatever reason ripped out helper import support that will be a PITA. :\
[attachment deleted by ninja]
-
The biggest difference I can see is that a bunch of semicolons seem to vanished. Is it exporting blender empties as anything?
-
Yeah, it seems to be - it's just not importing them back in. The empties get converted to whatever they're supposed to be in the POF just fine.
-
Yes, if your unit setup in Max is set to meters, 1m in Max is 1m in FS2.
Actually I don't think it's quite like that...
I've just managed to get my first pof created with Collada, and ummmmm it's kinda HUGE :lol:
The tape measure shows 18m when I'm in metric, however when I'm in regular max units it's 700. It looks like it's using the 700 units = 1 fs meter.
-
Yeah, it seems to be - it's just not importing them back in. The empties get converted to whatever they're supposed to be in the POF just fine.
In that case it's probably unintentional and should get fixed at some point.
-
Alright tough guys. I have here the mother of all messed up models.
It works as a PMF and can export to DAE.
It will not, however, export to a POF (hangs) or import as a DAE (crashes.)
VA's already tried his hand at it, and it even uncovered a PCS2 bug. But I want to see this model as a POF with a minimum of changes, as it's set up just the way I like it, and it's fully backwards compatible.
Have at it. (http://pjfoliver.googlepages.com/karnakdae.zip)
-
Running it with the debugger seems to reveal heap corruption, but I think that might be fixed now and it seems to import.
It also seems to export to pof from the input dae. Try it (http://the158th.hard-light.net/spicious/karnak.7z).
Edit: There have been some other changes. I'll let you find them for yourselves.
-
from the cinema 4D front here, now that r11 is out. all the helpers seem to be out of sync with the scale of the model itself... (one scale used for the model, one, 10 or so times larger used for the helpers...)
tested with karnak, the model was extracted from the pof to dae, will test with some others...
if anyone can point me to some in-game ready (with helpers included... ie, at least subsystem and firepoints...)
also, for some reason the dae's i create with c4d usually punt out detail0 not found. (i just exported via pcs to dae, imported to cinema, exported to dae again witnessed the failure.
might be a problem with c4d's export tho, since my engine helpers dissapeared...
attached in the zip file
hg af.dae is pcs2(just downloaded the executable and the dll from your sig) exported dae
hg afe.dae is cinema 4d exported dae.
[attachment deleted by ninja]
-
It will not, however, export to a POF (hangs) or import as a DAE (crashes.)
Opened detail 0 mesh - selected the major mesh chunks and deleted but left the greebles in place - saved ok to pof.
Run out of time - is there a link to the textures - will take another look this evening.
-
The textures are in the Karnak release thread in the FS Port Upgrade forum. Click me! (http://pjfoliver.googlepages.com/karnak.zip)
I noticed the glowpoints have been messed up, and all the paths too, but those are rescued easily enough. Thanks SO MUCH Spicious. :D
-
Question: How are lod levels suppose to be setup? I've got them attached to as:
But in pcs it shows up as:
- detail0
- detail1
- detail2
- detail3
The lower lods are there twice, once under detail0 the other seperate.
-
It should be:
- detail0
- detail1
- detail2
- detail3
The subobject hierarchies should pretty much transfer straight across.
I noticed the glowpoints have been messed up, and all the paths too, but those are rescued easily enough. Thanks SO MUCH Spicious. :D
The paths don't seem to be present in the dae and no one has made any suggestions on a complete format for glowpoints.
-
Strange, I tried that before but didn't work. Worked this time though.
Oh oh another minor issue.... the front and back are flipped. The model shows up correctly in max, but in pcs2 your looking at it backwards.
-
I'm going to blame that on inconsistent input, unless your "up_axis" is "X_UP". It's easy enough to change but I think someone else's model would end up facing the wrong way. I guess this should go on the to be decided list too.
-
Y is up, z is forward, x is port/star.
Edit: I wonder if this is a Max issue.
-
I know what Y_UP should be. It's just that the only sample I'd received that used Y_UP had z as backwards. But, pec's sample from cinema 4d is rotated 180 degrees around the left/right axis (upside down and backwards) compared to what it should be. That seems to be using y as the down axis.
Nothing seems to agree with what the Collada spec says about axes which is ever so slightly annoying. Let me know which axes you think need to be flipped. Maybe there could be axis flipping tickboxes in the options, but an odd number of flips turns things inside out.
-
I take that back, the axis changed :confused:
X is still port but y is front/back and z is up/down. If I rotate the model 180 z degrees then it's correct
Ohhh I think I see where you're coming up with Y_UP, it's in the xml file.
<up_axis>Z_UP</up_axis>
-
That's odd, Z_UP is the most often used and I don't think anyone's reported any problems with it recently.
-
Any one else use Max?
-
I believe DaBrain does.
-
i'm afraid that that particular problem with the axes is related to dae export, since i know for a fact that when i was pofing the model, everything was correct, and the model has been tested ingame quite a lot by me and 2 or three others....
-
It works as a PMF and can export to DAE.
It will not, however, export to a POF (hangs) or import as a DAE (crashes.)
The dae file - was it exported from the PMF or from modeling software?
The dae - I can import and save to pof. http://files.filefront.com/dae+pof7z/;11943126;/fileinfo.html (http://files.filefront.com/dae+pof7z/;11943126;/fileinfo.html)
The pmf - was able to export to dae and load that dae. Then save to pof. Although I don't fully trust files that have been stored as pmf. http://files.filefront.com/pmf+dae+pof7z/;11943229;/fileinfo.html (http://files.filefront.com/pmf+dae+pof7z/;11943229;/fileinfo.html)
Both files - only looked at in pcs2 (ver 21 Sept)- not checked in fs.
Clicking on subobjects - the blue bounding box? is offset. The one in port 304 seems to have that problem as well.
Edit: turret 38 is missing barrel in pofs (its in the pmf)
-
The DAE I included is a straight export from the PMF that I included, so you could open it up and take a look. The PMF got to where it is now via Max and a lot of work with PCS.
-
i'm afraid that that particular problem with the axes is related to dae export, since i know for a fact that when i was pofing the model, everything was correct, and the model has been tested ingame quite a lot by me and 2 or three others....
In that case, Spicious, you're probably better off with a flip axis dialog, since who knows what gets flipped with which version.
-
The DAE I included is a straight export from the PMF that I included, so you could open it up and take a look. The PMF got to where it is now via Max and a lot of work with PCS.
Ok - try this http://files.filefront.com/karnak+3+oct7z/;11952704;/fileinfo.html (http://files.filefront.com/karnak+3+oct7z/;11952704;/fileinfo.html)
-
How about we try this:
Everyone who cares makes a rectangular prism such that:
- One corner is at (0,0,0)
- One face is x units to the left
- One face is 2x units up
- One face is 4x units forward
where x is arbitrary.
-
Here you go: http://scoobydoo.freespacemods.net/Problems/rectangle.dae (http://scoobydoo.freespacemods.net/Problems/rectangle.dae)
-
If I've interpreted what you're after correctly, here's Blenders output. This is currently being correctly interpreted by PCS2.
[attachment deleted by Tolwyn]
-
I think thats about right. x in my case was 100.
it does not import into pcs2 however. pcs2 states that detail0 cant be found.
[attachment deleted by Tolwyn]
-
Well, it looks like the max and blender rectangles conflict. Can you try opening each other's rectangles and checking if they import facing the right way.
-
On import into blender the max rectangle is rotated 180° about the Z axis, so for whichever you pick as the default, all that the importer needs to do for the other type is mirror the scene by X and Y. :)
-
On import into blender the max rectangle is rotated 180° about the Z axis, so for whichever you pick as the default, all that the importer needs to do for the other type is mirror the scene by X and Y. :)
Ditto.
-
In that case, I think mirror axis tickboxes are going in.
Edit: Axis mirroring on import is in.
-
Also I've notice that exporting to dae files causes it to crash. Sometimes with array out of bounds.
-
Exporting what? It shouldn't be doing that. Post the offending POF.
-
I was just trying to figure out how turrets work... but is this how their suppose to be laid out?
(http://img.photobucket.com/albums/v356/Shodan_AI/Extras/turretlayout.jpg)
PCS2 completely crashes when trying to import that, right about when it says loading textures. If I remove the helpers node, it complains that it can't find the geometry for the firepoints.
If I detach the turret01 object itself and rename it to detail0 and export it, it compiles correctly, so the mesh should be ok.
-
That looks correct.
-
Wait... the "helpers" node is either new, or that's what crashing PCS2.
Never used or needed it so far. My firepoints are all directly connected to detail0.
-
They've been around for a while now.
Never used or needed it so far. My firepoints are all directly connected to detail0.
Have they worked and when did you last update?
-
Wait... the "helpers" node is either new, or that's what crashing PCS2.
Never used or needed it so far. My firepoints are all directly connected to detail0.
Could you please send me a sample model containing a turret please?
-
Actually this problem occurs not with just this turret mesh, but any old test turret causes it to crash. :sigh:
-
They've been around for a while now.
Never used or needed it so far. My firepoints are all directly connected to detail0.
Have they worked and when did you last update?
I didn't try it yet. I'll do so and report what happened.
Edit:
I just imported a DAE from PCS2 in MAX.
It creates helper nodes for every mesh with a property now, which is useless, since the info is stored in the custom properties of the mesh.
Edit2: Ok, I get "Instance geometry not found for firepoint(*some number*)"
Then PCS2 crashes.
-
Buggy bombardment I'm afraid :nervous: - the axis mirroring checkbox seems to invert all face normals all over the model.
-
They've been around for a while now.
Never used or needed it so far. My firepoints are all directly connected to detail0.
Have they worked and when did you last update?
I didn't try it yet. I'll do so and report what happened.
Edit:
I just imported a DAE from PCS2 in MAX.
It creates helper nodes for every mesh with a property now, which is useless, since the info is stored in the custom properties of the mesh.
Edit2: Ok, I get "Instance geometry not found for firepoint(*some number*)"
Then PCS2 crashes.
Yup thats what's happening here. Does it crash about the time "Load Textures" occurs?
-
No, I don't get an error message, just a crash.
-
No, I don't get an error message, just a crash.
Same here...
Starting Load....
Loading Textures...
CRASH
-
Buggy bombardment I'm afraid :nervous: - the axis mirroring checkbox seems to invert all face normals all over the model.
You're meant to use an even number of them at a time. :p
-
lol, ah righto then. Makes sense when you think about it. :D
-
Ya, the latest build works! Although I still have to have the model rotated 180 degrees front/back, the turret issue is gone.
Edit: Opps i see the axis flipping now. ;)
Double Edit: Question, how are turret fire point rotation origins handled? I hope your not assuming the turret barrels are in the center of the base.
-
Ok another problem...
I create a simple box, apply textures to it, reset the x-form, collapse and attach this as a subobject to the main hull. Tell pcs that it's a subsystem. Load the model in the game, no collision detection occurs, you can fly right through it.
Edit: more test, similar result. Last one I could hit part of the box, but the rest would pass through.
-
Short sidenote about X-Form Reset:
Any rotation or scaling applied to the obect (not the polygons!) will be reset to 0° or 100%.
So you only need to use it, when you've edited the object. Changes within the editable poly do not require it.
Also, you can only it for meshes that are not withing a heirachy(!).
-
Also if you move the object you need to reset, otherwise pcs2 will complain about unable to find mesh instance.
Edit: oh ya, and it's often wise to collapse the stack first, sometimes it messes things up bigtime and theres no undo.
Still have no clue why hit detection is wonky.
double Edit: Some more info, if I put the subsystem at (0,0,0), the center of the detail0 the hit detection works perfectly. When I start moving the object away from the detail0 it starts becoming more and more problematic. It looks like the subobjects isn't extending the main hitbox collision. :confused:
-
AFAIK, the detail0 bounding box is not extended to encompass subobjects in POFs - and the collision detection is often skipped altogether when the centre of those subobjects is outside or nearly outside that bounding box. You can manually expand the bounding box by strategically placed teeny tiny triangles that have almost no area. (Map them to a black part of the main texture, or they may flare up in game once in a while).
This problem was causing the new Iceni's big turret subobjects to ghost, as they were above the bounding box.
-
Are bounding boxes supposed to extend around child geometry?
-
spicious, was there something wonky with my dae exports since i cant get em to import into pcs2, since i always get the "detail0 not found" error?
-
Your exporter seems to use its own system for labelling node ids. I've changed the importer so it will use node names to decide things for everything except transparent bits of subobjects. This should make 3ds users happier too.
-
Are bounding boxes supposed to extend around child geometry?
Not automatically, no - it's up to the modeller to ensure the main bounding box encompasses all the subobjects. Large bounding boxes without the geometry to back them up is kinda asking for trouble. ;)
-
kk, thanks spicious.
-
AFAIK, the detail0 bounding box is not extended to encompass subobjects in POFs - and the collision detection is often skipped altogether when the centre of those subobjects is outside or nearly outside that bounding box. You can manually expand the bounding box by strategically placed teeny tiny triangles that have almost no area. (Map them to a black part of the main texture, or they may flare up in game once in a while).
This problem was causing the new Iceni's big turret subobjects to ghost, as they were above the bounding box.
Ya, thanks VA, I spent a couple of days trying to figure this out. Would never have realized it was the engines fault.
-
How exactly are lod levels done? I've got detail00, detail01, detail02. When I load the model into pcs detail01 appears to be the default one (i.e. no cockpit is showing up), only when I click on detail00 do i get it. In game, only one lod is ever displayed.
Same with glowpoints, I've got glowbank01 and glowbank02. Each have glowbank01-01.... children.
Also the -glow/-normal/-shine maps are loaded as part of the texture. They don't need to be included.
-
The lod naming scheme for some reason is detail0, detail1 etc.
For glowpoints it looks like they should be linked to subobjects.
Any texture names in the texture list are carried over when importing.
-
The lod naming scheme for some reason is detail0, detail1 etc.
For glowpoints it looks like they should be linked to subobjects.
Any texture names in the texture list are carried over when importing.
Ohhhh 0, 1, 2.....
So the glowpoints should be childed to detail0?
The textures isn't an issue, just delete them in pcs :)
-
The lod naming scheme for some reason is detail0, detail1 etc.
Heh I get the impression that it picks a lod or debris and switches it at random.
-
So the glowpoints should be childed to detail0?
Yes, attach the glowbanks to its helper child.
Heh I get the impression that it picks a lod or debris and switches it at random.
If lods and debris are ending up pointing to the wrong subobjects, let me know. The system for matching them up changed recently and probably hasn't been thoroughly tested.
Also if you move the object you need to reset, otherwise pcs2 will complain about unable to find mesh instance.
I can probably fix this at some point.
-
If lods and debris are ending up pointing to the wrong subobjects, let me know. The system for matching them up changed recently and probably hasn't been thoroughly tested.
PCS2 - Standard and collada
1 detail0
2 detail3
3 detail1
4 detail2
1 debris03
2 debris02
3 debris01
4 debris04
Edit: Sorry that was for cob. For collada only the debris is out of order, a non issue.
-
Is it alright that all objects have helpers attached to them?
It really blows up the hierarchy.
-
Edit: Sorry that was for cob. For collada only the debris is out of order, a non issue.
Oh, that's sort of intentional. The ordering of quite a few things is undefined with the change to name based recognition. Notable exceptions that I can think of now are lods, gunbanks and eyepoints.
Is it alright that all objects have helpers attached to them?
It really blows up the hierarchy.
What?
-
Also on the numbering, how is glowpoints done?
I've done glowbank01, glowbank02 and glowbank1, glowbank2 but it'll only read glowbank2.
-
It should process any node with a name that starts with glowbank.
-
Ok that helps, but is there a way to have glow groups? (more than just one)
-
Aren't glowbanks groups?
-
You can have more than one group. For example group A displays when group B is dark and alternating.
-
Yes, I call them glowbanks. Glowbanks contain glowpoints. There shouldn't be any problems with multiple glowbanks.
-
Yes, I call them glowbanks. Glowbanks contain glowpoints. There shouldn't be any problems with multiple glowbanks.
How should they be setup?
- detail0
- helper
- glowbank
- glowbank01-01
- glowbank01-02
- glowbank02-01
-
It should be something like
- detail0
- helper
- glowbank
- glowbank01-01
- glowbank01-02
- glowbank
- glowbank
- glowpoint
- glowpoint
- glowpoint
- anything here the name doesn't matter
-
Cool, not sure what I was doing wrong but it works.
BTW these layout charts should be included on the wiki page.
-
How should they be setup?
- detail0
- helper
- glowbank
- glowpoint01-01
- glowpoint01-02
- glowpoint02-01
^like that IIRC. :)
-
"Great Flameing Graphics error of DOOM!!!"
"Warning OGL reported "invalid value" at .\pcs_file.cpp (1724)
please report this issue to Bobbau
...or else..."
I am getting this. I am reporting it.
-
I've added all the links to the required files to the Wiki page for Collada Importer, and I recommend using the newer VC2008 SP1 Runtimes (http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en) instead of those earlier ones.
-
using VBO and the other geometry something triggers those errors Turambar.
-
how do i not use those things?
-
options on pcs2 and untick the two checkboxes, namely use VBO Objects (if able) and the other one. forgot how its called, but its right next to it
-
You get me Collada support and I'll get you Bullet.
-
Wha? :wtf:
-
Ok possible problematic issue. It looks like side mounted turrets need to be x-reset in order for them to be rotated to the right position. However when I do that, I'll lose the angles needed for PCS subsystem vector.
-
What happens if you don't x-reset?
-
Turrets show up at wrong angles. It seems to be that they were at 0 and 180 (straight up or down), but don't quote me. A workaround solution, is to copy the x,y,z angles into the turrets properties. At least that way they'll be saved and far easier than copying them into notepad.
Also it seems that you have to x-reset not only the turrets, but their firepoints as well... ugh this is going to take a while.
Edit: oh oh, when you reset the firepoint (s), which you need otherwise they won't be placed correctly, their normals go (0,1,0) (straight up). How do I get around this?
Double edit: ehhh somethings not working right at all.
-
If you reset any helper object, it will have a 0,0,0 orientation, so you can't/may now reset firepoints.
If you reset them and keep their orientation, you forgot to unlink them. Child objects can't be reset.
-
Hmmmm
I started with a simple GTC Cube. Created a turret, moved it to cube ship. Rotated it 45 on the Y axis. Did not x-reset. When I imported it into pcs2 the turret is in the correct spot, but it seems to be rotated 45 on the Z axis. Are the axises (sp?) getting mixed up?
-
They might be.
-
Here's the test model:
http://scoobydoo.freespacemods.net/Problems/test.dae (http://scoobydoo.freespacemods.net/Problems/test.dae)
-
Thanks. It turns out I was applying the change to FS2 axes before the rotation instead of after. Build updated!
-
Thanks. It turns out I was applying the change to FS2 axes before the rotation instead of after. Build updated!
Sweet... actually this might solve my earlier turret rotation/x-form issues :yes:
Question, does it ignore numbers after things like helpers and firepoints? i.e. helper01, helper02 becomes helper, helper. I ask this because max will append a number if you clone an object (or increment the existing number)
Edit: More importantly, how are subsystem lods handled? I know the subsystem would need to be attached to detail1, but how should it be named?
-
Sweet... actually this might solve my earlier turret rotation/x-form issues :yes:
If something is acting weirdly, let me know.
Question, does it ignore numbers after things like helpers and firepoints? i.e. helper01, helper02 becomes helper, helper. I ask this because max will append a number if you clone an object (or increment the existing number)
Unless it's something where the numbering matters (LODs, eyepoints, maybe something else), any trailing numbers/letters should be ignored.
Edit: More importantly, how are subsystem lods handled? I know the subsystem would need to be attached to detail1, but how should it be named?
I believe it's just subsystema for lod0, subsystemb for lod1 etc. The importer doesn't do anything explicitly with subsystem lods.
-
One more question... how are multiple thruster banks named? I've got: thrusters->thruster01-01 but that doesn't seem to work.
-
That should work. The names of the individual glows don't matter; only the thrusters name matters. I've changed the export naming to better reflect this but since this is non-critical, it can wait until a bigger reason for a new build.
-
So should it be thrusters->thruster, thrusters->thruster? When dealing with more than one thruster group (i.e. different engines)
-
If you've got several thruster groups, each group corresponds to one "thrusters" (this could really use a better name). If you want these thruster groups linked to engine subsystems, they should be children of the subsystem's helper node.
So something like
- thrusters
- thrusters
- subsystemEngine01
- subsystemEngine02
- detail0
-
Hmmmm having: detail0->subsystem->helper->thrusters->thruster gives me a "uv not found. How very boring"
edit: actually i think it might be something else that crept into it.
-
Is your subsystem a physical subsystem?
-
Is your subsystem a physical subsystem?
Tore apart the entire heirarchy structure and rebuilt it, the problem seemed to go away.
-
Okay I'm noticing a problem. I took a cargo pod, added basically a box around it made out of 6 distinct walls. I gave these walls their own texture. In Maya, I have the walls with their texture, parented to the cargo box with its FS2 texture. I export as .dae, but when I load it up in PCS2 the walls no longer have thier own texture, instead they have the same texture as the cargo box.
[attachment deleted by necromancer]
-
Why couldn't maya play nice and use the same naming everywhere? It was actually defaulting to the first texture in the texture list for everything. It should be fixed now.
-
Question for those with experience in Max linking and hierarchy...
I've got detail0 pivot point centered at (0,0,0) it's been x-reseted and collapsed.
I've got helper and glowbank centered at (0,0,0) and it's also been x-reseted and collapsed.
Finally I've got many glowbank0X-0X positioned in the correct spot, x-reseted and collapsed.
Everythings linked correct. Detail0->helper->glowbank->glowbank0x-0x. Everything looks good in max, but in PCS2 the glowpoints are not in the correct position anymore. :confused:
-
Why couldn't maya play nice and use the same naming everywhere? It was actually defaulting to the first texture in the texture list for everything. It should be fixed now.
Sweet, works now thanks
-
Fixed it... the glowbanks moved on me without me realizing it.
BTW is there any chance of numberized glowpoints? It's kinda hard to make things like landing/take off lights when it's basically a game of "guess which ones".
-
Fixed it... the glowbanks moved on me without me realizing it.
Try a new build and tell me if they're still in the right places.
BTW is there any chance of numberized glowpoints? It's kinda hard to make things like landing/take off lights when it's basically a game of "guess which ones".
It shouldn't be a problem, but we still have to decide on a format for storing on/off times and the like for glowbanks. So far no one seems to have had much interest.
-
Also I just learned something... don't delete those -normal/-glow/-shine textures from the texture list otherwise your entire model will get messed up.
-
Is PCS2 cross platform?
99% - just need to get it to compile under linux - should just be a few tweaks EXCEPT all the major distros install the unicode wxwidgets and i've been compiling for non-unicode under windows
i'll probably go through the effort to move to unicode when i make the effort to allow compiling for 32 and 64 bit targets.
-
If that's the goal, we'll definitely want to do DAE <-> PMF.
got DAE format specs?
as you've seen by now from the source it's fairly easy to integrate new file formats (which is why i created PMF - to be an internal format easy to convert to, then only have to PMF->POF and not worry about the PO shiat ever again)
-
Where have you been? Check his signature for the build and this wiki page (http://www.hard-light.net/wiki/index.php/Collada_Importer) for all the other resources.
-
I just went over that in another thread, that's how he ended up here. But yeah, I forgot to mention the latest build is in Spicious' sig.
-
Code diff is attached. Enjoy the mess.
[attachment deleted by admin]
-
You mention a linux build, any chance of a OSX build aswell?
That'd be pretty sweet
-
Once a Linux build is working, OSX shouldn't be much trouble, but you'd be on your own for compiling it.
-
Bah, I'll try and figure it out if they can get linux working maybe.
-
Spicious, your PCS2 with Collada file is missing the VC90 support files to get PCS2 to properly work. It's saying it can't find Microsoft.blah-blah.VC90.crt, which as I understand is part of the deployment package for Visual C++ version 9 (?) packages? Since I apparently haven't installed any software that was based off of Visual C++ 9, I can't get PCS2 to work. I have found VC80.crt files on my system, but it isn't using those.
Can you suggest anything to help?
-
I'm pretty sure the necessary file is linked on the wiki...
-
I'm pretty sure the necessary file is linked on the wiki...
Do you have a link to the area it is in?
EDIT: Nevermind. Found it at wiki. Thanks for the help! :D
-
I'm pretty sure the necessary file is linked on the wiki...
Do you have a link to the area it is in?
Just search for "collada": http://www.hard-light.net/wiki/index.php/Collada_Importer (http://www.hard-light.net/wiki/index.php/Collada_Importer). I think the file you're looking for is near the bottom but I don't know what exactly you need.
-
Yep, I found it. Thanks a lot for the help. I can only hope it works...
-
Spicious, hate to tell you this but your Alpha release of PCS2 in your signature doesn't open or save .pof files at all. A huge dilemma that I have about Maya and converting could be fixed once this is fixed. Just thought that I would inform you of that. :)
-
Just updated to the latest version (didn't realise I'd fallen behind), and yeah - I'm getting crashes upon loading any POF. It seems to fully load and display the model before it crashes though.
I presume the 4 'wx' dlls go in the root PCS2 folder with the exe?
-
Probably not my fault. I just updated to the latest CVS code. I'll try to have a look this weekend though. Work during the week is surprisingly time consuming.
Yes, the dlls should go with the exe.
-
Ah...Kazan did say he was going to start doing some more work on it. I'd have stuck with the stable code for now though. Oh well.
-
Errm, any chance it could be rolled back to the previous version if you can't spot the fix, or does anyone have the older version lying around? I overwrote the previous DAE conversion exe with this latest one, so now I can't convert DAEs at all. :\
-
Maybe this will help. After PCS2 was loaded I clicked on "Use Orthographic Projection" and then went to "file" and clicked on "open". I opened a .pof file from my FreeSpace folder and this error came up. This happens to any .pof file I load when I click on "Use Orthographic Projection." Maybe it's related to the problem of not being able to open any .pof file? Hope it helps. :)
[attachment stolen by Slimey Goober]
-
Errm, any chance it could be rolled back to the previous version if you can't spot the fix, or does anyone have the older version lying around? I overwrote the previous DAE conversion exe with this latest one, so now I can't convert DAEs at all. :\
http://files.filefront.com/pcs2+13oct+collada7z/;12575099;/fileinfo.html (http://files.filefront.com/pcs2+13oct+collada7z/;12575099;/fileinfo.html)
-
Woo! Thanks. :D
-
I've updated to the latest CVS code and it seems to be less unstable now. Feel free to try it out.
-
I've updated to the latest CVS code and it seems to be less unstable now. Feel free to try it out.
Is it the one in your signature?
-
Sorry... I see now it's a different build, but I'm still having the same problems and the same errors.
Would you happen to have a debug version of PCS2 that would provide some level of verbosity (in a text file or something?) to what it's doing that might help you trace the error to a specific location / function in your code?
Is it possible the problem is somehow related to the wx* .dll files you have included? It seems as though every version of PCS2 that has had these wx files has produced these problems. Just trying to help... Thanks.
-
Yeah still crashing when it finishes loading here too.
-
Wow, I had no idea this was such a huge thread. I ought to split it and make it a sticky in FS Modding or FS Upgrade.
Where should I split it? I think when the Collada exporter was finished is a good place, but I don't know when that happened.
-
Wow, I had no idea this was such a huge thread. I ought to split it and make it a sticky in FS Modding or FS Upgrade.
Where should I split it? I think when the Collada exporter was finished is a good place, but I don't know when that happened.
Speaking of "finished", if it is, when does the dude get his prize because no one's asked me for any pledged money.
-
It's finished when no one else runs into any problems on his end of it, and the documentation is finalized so people know just how to use it.
-
It's finished when no one else runs into any problems on his end of it, and the documentation is finalized so people know just how to use it.
Ok cool, sounds good.
-
Actually I'm not the final authority on that but if it was my money that'd be my criteria.
-
Also, I don't know about you guys still having problems, but I'm using a build labeled PCS 2.1 Alpha Release November 16 2008 20:21:36, and I opened the MediaVP Aquitane, saved as DAE, and reloaded from that DAE, and had no crash at all. At first glance everything looked pretty good. I'm impressed with how far this feature has managed to come. I'm not sure where you can get this build but I may upload it somewhere if everyone is having a hard time finding a stable one.
Edit: Of course, I didn't have any trouble doing this with the latest one from his signature, so I'm not sure what's up.
-
Found some issues. After saving to dae and reimporting as pof, I noticed a few things missing. The glowpoint normals were reset to 0, the MOI was lost, and the overall scale seemed to have been changed ever so slightly. The last part may not matter much as long as everything lines but, going between dae and pof over and over and over is likely to create problems if that has to remain the case. But losing data completely I hope could be avoided. Of course, this may not really be the intent anyway, since it still seems the model and the bulk of its data were retained, which is fantastic. The scale problem could also be due to the changes to the POF export side of things now too as the starting pof was made with PCS 2.0.3 and this using the changes that have brought it up to 2.1 Alpha.
Also, when I open the file as a DAE, its size values are drastically different from those of even the output POF, which are much closer to the starting POF. I just found this bizarre, as long as the end result is fine it's not a problem. For example, the original POF had HWD of 79.46, 66.87, and 65.15. When I saved as DAE and opened the DAE, those values were 49.74, 54.80, and 61.24. When I saved that as a POF and opened that, the values were back to the original numbers.
-
It's finished when no one else runs into any problems on his end of it, and the documentation is finalized so people know just how to use it.
I have to say that just screams loophole. :p
Glowpoints are still rather lacking in completeness, mainly because no one has expressed interest in their Collada format. Similarly MOI isn't stored due to lack of interest. I'd blame small discrepancies in numbers on rounding errors.
Weird dimensions are probably due to a small issue with subobjects - the big differences, at least. It should be fixed now. Again, lack of interest is not very motivating. ;)
-
glowpoints... okay. here's my take on it, similar to the eff's for animated texture.
when setting them up, this would go under the main glowbank.
$Texture_name: <insert_tex_name>-xxx-gp.<insert_ext_here>
$FPS: <rate at which the glowpoint changes, as with eff, in case of animated gp's>
this would go under the glowpoints themselves
$On_time: <insert time for the gp to be on in miliseconds>
$Off_time: <insert time for the gp to be off in miliseconds>
$Blink: <insert condition for blink, as in yes, no, permanently on>
$Blink_delay: <insert delay between blinks, ms only>
$Blink_transition: <insert transition time between full on and full off>
i am thinking of this as in the subsys and subob properties, manual entering of these details either via helpers or literally in the editor in PCS.
more to come when i refine the idea a bit, but tell me what do you think of the general idea.
-
It's hard but I can guarantee you that there's no shortage of interest in this support. Glowpoints probably just need to be some meta property that can be edited. I also forgot to mention that the paths were absent as well (for the turrets), which I'm also guessing was due to lack of interest. I don't do much in the modeling apps myself so I hope someone who would be using these features can pose some suggestions for how they should be stored so Spicious can implement it. Any takers?
-
Uhm, I don't believe there's anything in glowpoints about FPS and the on/off times would do essentially the same thing as your blink fields.
Correctly associated paths should be preserved.
-
The paths in the defense satellite (nb_ds) (http://pjfoliver.googlepages.com/satellites.zip) are not present when this file is saved as a DAE, nor in the subsequent re-save to POF. Is there something wrong with them then? Used the build I just downloaded from your sig. The DAE file's dimensions are also still off by a large factor. The Height value went up from 49.74 to 66.62, but the other two values are still the same. You can experiment with it yourself and see what I mean. If you do see any peculiarities in the model please let me know.
-
i didnt exactly think the whole deal through, just a 5 minute quibble out of my brainfart... XD
the fps thing might help if someone uses an animated glowpoint. then again, animations speed should be in the eff.. meh. basically, just keep the on-off thing. + enter something for more intuitive control
-
I would make the way it's stored as close to the storage method in POF so it's easy to translate, it's just how to put it in the DAE so most modeling apps can set it reliably.
-
The importer expects path to be all lowercase.
The two other values seem to be correct. The global X and Z bounds are identical to those of LOD0.
-
Can the path casing requirement be changed then? Because it's never been a requirement before and would hurt functionality with existing POF files. If not I suppose it can be worked around.
-
It's finished when no one else runs into any problems on his end of it, and the documentation is finalized so people know just how to use it.
I have to say that just screams loophole. :p
Glowpoints are still rather lacking in completeness, mainly because no one has expressed interest in their Collada format. Similarly MOI isn't stored due to lack of interest. I'd blame small discrepancies in numbers on rounding errors.
Weird dimensions are probably due to a small issue with subobjects - the big differences, at least. It should be fixed now. Again, lack of interest is not very motivating. ;)
I'd say a cash prize indicates the counter to a lack of interest, we just may have a lack of qualified people (or those people have a lack of available time) to effectively and constantly test as needed. If I knew more about modeling than I do and about model structure, I can assure you, I would be doing a post a day. :)
-
Can the path casing requirement be changed then? Because it's never been a requirement before and would hurt functionality with existing POF files. If not I suppose it can be worked around.
Thanks to some refactoring from a while back, yes I can and have made all node names (except -trans ones) case insensitive. Now VC just whines about strnicmp quite a lot when compiling.
-
I've been starting to wonder if a lot of my problems I'm having came from using a case sensitive mac filesystem, instead of the insensitive one.
-
I'm probably going to next look at this around boxing day or the weekend after it. If anyone cares about sensible storage of glowpoint timing, types etc. do post your suggestions before then. I would prefer to avoid rewriting things a few times this time around.
-
Hey, I exported a POF from PCS2 to DAE, and I can't open it in Blender... Possible bug, it happened with the Mihos, and I think earlier with the Aeolus (not positive on which ship it was earlier). The import script (v1.4) crashes, and the python console says the error was opening some geometry mesh.
On a slightly less grave note... I have no idea how to create a DAE :( I mean, I opened the model I made in Blender and it can export to DAE, but I have no idea where or how to input any info (nor do I know for sure how to name things or create a hierarchy)
-
(nor do I know for sure how to name things or create a hierarchy)
Select an object in Blender, press n, edit the name.
To parent something. select all the children objects then the parent object last and press ctrl-p
-
Since nobody bothered to tell me where I should split the thread, I'm moving the entire thing wholesale to the FSUpgrade forum. :p If you want it split, you can do it yourself and then move the "announcement" part back into the Announcements forum.
-
Hey, I exported a POF from PCS2 to DAE, and I can't open it in Blender... Possible bug, it happened with the Mihos, and I think earlier with the Aeolus (not positive on which ship it was earlier). The import script (v1.4) crashes, and the python console says the error was opening some geometry mesh.
That's not very descriptive.
-
Maybe next weekend...
-
a new build?
frankly, i still have the newest one from your sig crashing on the finish of loading the pof, but the older one (12th october or so) completely wipes the UV's of everything(when exporting to dae that is).
-
I'm having a slight issue with glowpoints. In pcs2 and max they show up in their correct position, but in-game they are offsetted by a considerable amount. The model itself is centered at 0,0,0. The glowpoint,glowpoints and helper are all x-formed (glowpoint and helper are at 0,0,0). Whats going wrong?
-
Do they have a parent subobject set? (This may or may not have anything to do with the actual problem)
-
Setup is:
detail0
helper
glowbank
glowpoint
PCS2 confirms the parent subobject is detail0. Also it seems to be off on only one axis at a time (on one model it's x, on another it's y) Oh and it's not just the glowpoints, thrusters and eye points are included.
edit: also I dunno if this could be an issue, but detail0 offset is (-0.000013:0.000000:-0.000000), while in max it's at (0,0,0). .000013 is kinda small compared to the offsets.
-
That's just a rounding error.
Are they still in the right place in PCS if you reopen the pof? Can you make a simple setup where this happens?
-
I think I got it fixed... but don't be surpised if i have this problem latter. detail0 turns out wasn't exactly at (0,0,0). I ended up taking apart the heirarchy, resetting detail0's pivet point, then moving everything to match the offset. Ugh, but at least it works.
-
Based on statistics and some creative rounding, I'm going to conclude all future problems as user error. :p
Any thoughts on storing glowpoint data in a way useful to modellers?
-
Wouldn't a simple "$attribute: value" work?
Another idea I'd like to see done is for turret angles. I assume you read the x,y,z rotation when you read the dae file?
-
It would, but I'm trying to avoid someone coming up with a much better way of doing it and me having to do another rewrite of something a bit later.
Do you mean the stuff for multipart turrets with non-regular rotation axes?
-
Correct, I'm always seeming to have problems with them, ask poor Keldor :lol: I'd assume you'd have to assume some standard default position, like the turret must start faced up pointing forward, then rotated to where it's suppose to be in-game.
As for the glowpoints, theres one thing even more important for me than the attributes, it's numbering and group numbering. Making landing/launching bay lights that blink in sequence is rather difficult when none of the glow groups are in order.
-
What do you want done with turrets?
Glowpoint properties and MOI should save and load now.
-
Is the link in your sig being updated?
Also, did Kazan ever do anything about the geosphere things crashing?
-
Yes and I doubt it.
-
I have just found a rather retarded idiocy of C4D's importer. Basically, if the model has a texture attached to it, C4D doesnt import the UV map, but imports the texture.
however, if the texture is removed from the list, the UV imports nicely, and the texture can just be drag'n'dropped casually... for the example i used GVF Toth
<node id="detail0" name="detail0">
<translate>0 0 0</translate>
<instance_geometry url="#detail0-geometry">
<bind_material>
<technique_common>
<instance_material symbol="Fighter09-01-mat" target="#Fighter09-01-mat">
<bind_vertex_input semantic="CHANNEL1" input_semantic="TEXCOORD" input_set="1"/>
</instance_material>
</technique_common>
</bind_material>
</instance_geometry>
</node>
idiotic, and the reason is something related to semantics proper. i'll provide a proper example once i gather all the details
-
The current version can't load or import most models anymore. It constantly crashes for me, even when I try to load a vanilla standard model (i.e. bomber10.pof)
It crashes right after the model appears in the viewport for POF files and before that for DAE files.
AppName: pcs2.exe AppVer: 0.0.0.0 ModName: wxmsw28_core_vc_custom.dll
ModVer: 2.8.9.0 Offset: 000de499
-
I meant omnipoints. Someone summon Bobboau, Kazan mentioned he might know more about them.
-
I think I got it to work again, after some re-installing.
Anyway, it scaling down my UVs. I'm trying to use tile textures, so I'm using a lot more then the center tile, but PCS2 ends up scaling it back down into it.
Edit: Oh, and it inverts the bounding box. The detail0,1,2 models are all at 0,0,0 and the pivots are centered. So there isn't much more I could do myself to avoid getting an inverted bounding box.
-
Try following... Open the model with inverted bounding box, select 'Purge BSP Info' (or some such option) and then save the model again.
-
Have you got any of the invert axes options on? I don't think there's any reason why bounding boxes should be getting inverted.
No idea about the UVs. What happens if you export and reimport?
-
the problem with uv's is in the export scheme itself. C4D has a bit different interpreter obviously. i'll post the thoth dae straight from PCS and the one that i managed to import to C4D then export it out so you can see for yourself
-
Try following... Open the model with inverted bounding box, select 'Purge BSP Info' (or some such option) and then save the model again.
I tried that, I still get negative bouding box values.
Have you got any of the invert axes options on? I don't think there's any reason why bounding boxes should be getting inverted.
No idea about the UVs. What happens if you export and reimport?
When I export them from 3ds and reimport them, they're exactly like before.
I also tried loading it into MeshLab, save a DAE from there and reimport it in 3ds again.
Even though it's for some strange reason semi-transparent, flipped 90° and the smoothing is gone, the UV mapping is still as it was before.
I'll load the DAE up and send you the link via PM.
-
I think the bounding box bug has been fixed, but PCS2 may also have a display error. Try it in ModelView. Or, if you don't have the hi-poly ModelView build, load it in a debug build of FSO and see if it complains about inverted bounding boxes.
-
I was wondering if anyone could tell me why the DAE-importing version of pcs isn't reading my turret subobjects?
The hierarchy is something on the lines of
detail0
turret01
turret01-fp01
turret02
turret02-fp01
and etc...
note that turret01-fp01 and similar objects are all lamps, intended to be substituted as points as is done in TrueSpace.
The turrets do not appear in the imported pmf, and it is becoming really aggravating. This hierarchy is probably extremely bonked as it's meant for cob->pof conversion. Checking on the wiki you are using a new hierarchy. I think it might be a faulty hierarchy setup, but doing even simpler ships has yielded the exact same results. If it is a turret naming/hierarchy issue, could someone please tell me what to do to make this work. If it is a much more serious issue, any help is greatly appreciated.
Thanks
P.S. If this is the wrong place to ask, please let me know and I'll start something in the support forum.
-
Turret firing points should be empties (not lamps) and should be set up as children of another empty with a name starting with 'firepoints'. That empty should then be set up as a child of the turret base object.
So it'd be:
detail0 (Object)
turret01 (Object)
firepoints01 (Empty)
imafirepoint (Empty, name doesn't matter)
turret02 (Object)
firepoints02 (Empty)
imanotherfirepoint (Empty, name doesn't matter)
-
I think the bounding box bug has been fixed, but PCS2 may also have a display error. Try it in ModelView. Or, if you don't have the hi-poly ModelView build, load it in a debug build of FSO and see if it complains about inverted bounding boxes.
Hmm, the Lab still doesn't work with debug builds in SoL. No idea why.
Anyway, Modelview doesn't complain and gives me a positve bounding box.
So I guess that's fine.
The issue of loading tilemapped models into PCS2 via DAE is still a big problem. I really need to convert two models, but the only way I can keep my mapping is by going the COB way or use the MAX exporter (and I don't have MAX8 atm...).
-
I have no idea why this would happen just with tile maps. Has anyone else tried using it with tiled maps? Alternatively, can someone create a simple sample model using tiled mapping with this problem?
-
I've converted plenty of models that use tiled texturing via DAE, and I've had no problems...
-
Tile mapping should work, it's just a way of applying textures the actual cords should be the same as with UV mapping. I would hope so.
-
I got it converted properly now.
I simply exported it as OBJ and reimported it into 3ds. Then it worked fine in PCS2
My guess is that it might be related to the second UV channel in the model.
I was using a viewport shader to get a preview of the model with normal, specular maps and AO maps.
Just a guess. Since neither PCS2 nor FSO can use the second mapping channel, they should probably ignore it until they can.
-
spicious when are you going to get me a patch of your codebase updated against current trunk so i can integrate it into the core codebase?
-
Is the CVS stuff working again? the last builds he made were of recent trunk checkouts and some of the pof exporting stuff was crashing again, where it worked fine in 2.0.3.
-
current trunk is unstable... builds should be done against 2.0-fixes branch
i still need that patch so i can merge it into trunk going forward
-
Ah...that would explain quite a bit then. Hear that Spicious? I hope he's around, I haven't seen much from him these days. Maybe PM/email/IM.
-
I've run into an interesting problem. When I import a large model into pcs2, I'm losing the entire uvmap (it's resetting itself to uvtiled planar with a large repeating value). The dae file seems to be ok, when I reimport it back to max, the mapping still exists correctly.
(http://i74.photobucket.com/albums/i270/Skaarj_Saga/dreaderrors.jpg)
-
Does the exported model look wrong in game, or have you not tried yet?
-
Ingame looks pretty much like this. I've torn it down to one subobject and it still produces this.
I tried using the old boolean intersection trick that used to work with Cob formats, but didn't help here.
Second test: I added a simple box to the scene, gave it a simple texture. Attached it to the hull, so both are one piece. Converted it and even it lost it's uvmap.
-
it might be using a way of recoding the uvmap that the PCS2 DAE support doesn't understand
-
Found the culprit, I had to re-export the object to 3ds then reimport to clear up the uvmap, not sure exactly what went wrong.
But I do have another possible bug, when I try to import anything into an existing model, the model completely disappears or the program crashes :confused:
This is with Alpha Jan 4 09 release, the Nov 7 08 release was a lot more stable.
-
Yeah the Alpha was probably never supposed to have been used, Kazan started working on the trunk code without Spicious knowing that Kazan was breaking stuff. So really any build that's the 2.1 Alpha probably won't export very well to pof. This should be getting taken care of soon though.
-
build labeled "alpha" are exactly that
-
Oh dear... the fred crashing problem is back.
Heres what I did:
1.) Attached (via edit poly->attach) object
2.) export to dae
3.) import to pcs2 & save
4.) load in fred
5.) if stable goto #1
6.) if not stable, go back to max, undo last attach, hide the "Bad piece" and continue on.
I got to a point where no matter what I added on it'll crash fred.
So I took all those "bad pieces" and merged them into one object. Attached that object via hierarchy link, not poly attach, to the main hull. Export and converted to pof. Vola it works in fred.
Am I hitting some sort of limit and with which collada importer or fred? Detail0 is 16,701 triangles (738 vert).
-
Am I hitting some sort of limit and with which collada importer or fred? Detail0 is 16,701 triangles (738 vert).
The numbers sound wrong. An average of 22 faces per vextex seems too high.
-
Opps I was looking at something completely different
Polys: 7,367
Tri: 16,701
Vertex: 10,185
-
Opps I was looking at something completely different
Polys: 7,367
Tri: 16,701
Vertex: 10,185
cob format - 20k mesh loaded ok in pcs 2.0.3. Failed as dae. Didn't crash, just wasn't there when it had finished. (oct12-08 build)
-
I'm using the nov 7, 08 build. Dunno if there were any stable builds after that. It works most of the time, which is good enough for me, for now.
I need a suggestion, I'm about to do two launch bays that combined is a mile long, that parts done. I need to do glowpoints, 2 every 15 meters, which is about 67 glow groups. What would be the best way to organize them so that I don't have to hunt down each successive group (The callada importer doesn't seem keep them in order)?
-
Scooby, the newest 2.0.3-based DAE build I have is Oct 6, 2008. Can I get the Nov one from you?
-
Unforunately, I don't have the orignial zip file, but I can zip up what's currently in the folder, (theres some DLL's from the newer broken build.)
-
The exe is all I need, if you could zip that and email it to me that would work. It should just be a drop in replacement for the exe I already have.
-
Here you go: http://scoobydoo.freespacemods.net/Completed/Misc/pcs2.exe (http://scoobydoo.freespacemods.net/Completed/Misc/pcs2.exe)
-
Gracias :)
-
Could you make a zipped/installer version of it? Or does someone still have the installer for it?
-
The current installation process is described on the Collada Importer (http://www.hard-light.net/wiki/index.php/Collada_Importer) wiki page. Get the regular 2.0.3 installer that Kazan released, the libColladaDOM dll, the VC2008 redist files, and the exe you just posted, and you're set. If that file will be there a while I might add a link to it to the wiki page, it's the latest 2.0.3 based DAE build I'm aware of.
-
A suggest for future development: accomadate other units of measure besides the default pixel one. For example, 1 FS2 meter equals to 1 default unit. How about adding the ability to use 1 meter instead? I know the dae file includes which unit of measure is used. <COLLADA>.<asset>.<unit meter = "x" name = "unit">
It's extermely hard to do small stuff (fighter scale). I've noticed rendering rounding errors when dealing with it.
-
Query: where can the latest builds be found?
-
The latest stable build I know of is in the wiki article now. Which is linked to in my sig. And other places around this thread.
-
Should I post collada-related problems here, or in Mantis?
It looks like the turrets break when I export a DAE from a POF. At least in 3ds one firepoint is missing, the names are wrong and I think the pivots might be wrong as well.
Also there is still the problem with 3ds and the "-node" importing. I really can't open the DAE file from 3ds with a texteditor and look which objects need it, every time I want to convert a model.
Converting a simple ship with a few turrets is currently a pain...
-
So I got this up and running and it's all very nice. But I'm running into the same problem with one model that I had with the max exporter: Submodels that are outside the bounding box of detail0 are ghosting (shoot-though, fly-through).
Is that a problem with PCS2 or engine-related? I suspect PCS2, because we have some old TBP models that were created with PCS1.X and are working fine, but also have submodels outside the detail0 bounding box, so it was possible at one point.
I know the problem can be circumvented by some cleverly placed polys attached to detail0, but that's kinda the non-elegant solution :blah:
-
VA was discussing that issue a long time ago. This is I think an engine problem that needs to be solved much more gracefully than it can be now. Even if PCS2 could try and guess all possible subobject locations including rotations and expand the bounding box to include those, things like subobject translation (which I believe are only determinable when they happen) still make that fail I believe.
-
So any idea what PCS1.X did different with the bounding boxes so that it didn't suffer from this problem?
-
Maybe it did something that's technically 'wrong' but seemed to work ok? Or maybe PCS2 isn't doing something that it would be fine if it did, I don't know.
-
Yeah I don't get this thing. I open a .dae file in PCS2 that was exported out of Maya and all of my weapon points are in the wrong place and facing the wrong direction and so on and so forth. Oh and it's not reading the textures for some reason. Even though a previous build DOES read the textures (I downloaded what I take to be the newest one from the Wiki).
In either case the model enters at an odd angle, and half of the components seem shifted. So the actual fighter model for example seems shifted forward which results in the shield and all weapon/dock/subsystem points being in the wrong place (further back than they should be and/or at a wrong elevation relative to the model).
What the heck.
EDIT - oh I downloaded a different file off the Wiki (Jan 4 2009 build??) and it loads the textures but the ship is still out of sync with all of the relevant information. Including the shield and all points. Meanwhile in Maya, the shield mesh and the fighter mesh for example both have translates of 0,0,0. So why when imported are they different????
-
So I got this up and running and it's all very nice. But I'm running into the same problem with one model that I had with the max exporter: Submodels that are outside the bounding box of detail0 are ghosting (shoot-though, fly-through).
Is that a problem with PCS2 or engine-related? I suspect PCS2, because we have some old TBP models that were created with PCS1.X and are working fine, but also have submodels outside the detail0 bounding box, so it was possible at one point.
I know the problem can be circumvented by some cleverly placed polys attached to detail0, but that's kinda the non-elegant solution :blah:
Try setting all subobject centers to 0,0,0 in your modeling program. Convert the model then move them back in PCS2. Usually solves that issue.
-
Hmmn, so somewhat inspired by fubar's message I reset transformations on my model and that seemed to get everything more/less where it's supposed to be. Or more accurately the guns are in the right place. Then however, I discover my fighter is upside down and backwards for some odd reason. So I rotate it around. But NOW, my docking points and my thrusters are in the wrong places, while everything else remains the same. I parented everything to a locator in maya when I rotated it to get it rightside up so I don't know why these would be in teh wrong place why everything else is in the right place. I am however reminded of why I lost interest in modding.
Maybe I'll just have to shift/re-do this stuff in PCS2 since for whatever reason it's clearly not translating properly.
-
There are options to rotate/flip everything in PCS 2 for Collada importing.
-
There are options to rotate/flip everything in PCS 2 for Collada importing.
Oh is there? Okay maybe I'll have to look into that next time. I just fixed the stuff more/less manually this time. Should be good enough.
Thanks
-
A question for anyone still working with this, how does the importer behave when there are things as lights in the null hierarchies?
As i have a rather retarded situation with Cinema4D's collada exporter...
-
I can still work on this but I have no idea how it would behave.
-
well, perhaps just make it completely drop any data from lights found and then to parse the helper tree structure?
-
What do lights turn into? Anything that doesn't have a special name and doesn't have any associated geometry should get ignored.
What exactly is the importer doing that isn't what you'd like?
-
sometimes the transforms that were on the lights get applied to the nulls which shouldnt have said transforms. resetting transforms multiple times on the whole tree structure didnt help a lot unfortunately, and sometimes it completely scrapped a perfectly good pof otherwise.
note, i do not edit pofs in PCS2 much, i mostly edit them in C4D then re-export.
-
Are these lights parents of the nulls? Small examples always help.
-
UGH I wrote up a long response for the opencollada issue and the forum spit it back at me :ick:
In short:
Look in <library_geometries><geometry><mesh><triangles> material attribute. It points to a modified version of <library_materials><material>name attribute instead of id attribute. The solution we've found so far is remove the appended _1 and append "-material".
The attachment contains a simple detail0 box. It has two textures assigned to it, "Details 1" (confed_details_1.psd) and "Details 2" (confed_details_2.psd).
Here's some of the source for my little hack fix:
private void LoadGeometry(XmlNode node)
{
Debug.Assert(node != null, "param <node> is null");
foreach (XmlNode geometry in node.ChildNodes)
{
// Make sure we're dealing with a geometry entry
if (geometry.Name == "geometry")
{
// Ignore shields, they don't need textures
if (IsShieldGeometry(geometry))
continue;
// Go through all of the geometry entry's children
foreach (XmlNode mesh in geometry)
{
// Make sure we're dealing with a <mesh> There shouldn't be anything but <mesh> but just in case.
if (mesh.Name == "mesh")
{
// Go through each of it's children. We're looking for just <triangles> entries.
foreach (XmlNode triangles in mesh)
{
if (triangles.Name == "triangles")
{
for (int loop = 0; loop < triangles.Attributes.Count; loop++)
{
XmlAttribute material = triangles.Attributes[loop];
// We're only interested in the material attribute
if (material.Name == "material")
{
int foundAt = FindMaterial(material.Value);
if (foundAt == -1)
{
Debug.Assert(false, "<Geometry<<Triangles material=> not found in <library_Geometries>");
}
// At this point simply append "-material" to the name.
// We've already gotten rid of any excess "_1" or such from the string
material.Value = materialNames[foundAt] + "-material";
}
}
}
}
}
}
}
}
}
private int FindMaterial(String value)
{
Debug.Assert(value != null, "param <value> is null");
bool done = false;
while (!done)
{
// Attempt to find the material's value in a list containing all the materials <library_materials>
int loc = materialNames.IndexOf(value);
if (value.Length != 0)
{
// Couldn't find it. Probably as an extension appended to it. Simply remove one char at a time till we find it or run of out chars
if (loc == -1)
{
value = value.Substring(0, value.Length - 1);
}
else
{
return loc;
}
}
else
{
return -1;
}
}
return -1;
}
[attachment deleted by admin]
-
I still need a changeset to get this integrated into the trunk (not 2_0-fixes) branch. once that is integrated i'm goin to try to stabilize trunk and switch to SVN and then open up the repository to more contributors
i'm also going to be doing some significant code refactoring of the main program to clean up poor coding techniques i used in the past
-
:yes:
-
Try the attached.
Is there a problem with using a more modern VCS?
[attachment deleted by admin]
-
Last I heard we plan to get it moved to SVN at some point. And also to open up access to more SCP members.
-
Try the attached.
Is there a problem with using a more modern VCS?
Is that diff against trunk or 2_0-fixes?
i plan to move it to SVN after collada is merged into head and i get head running stable - was in the middle of re-factoring some inter-thread communication and I destabilized the program.
-
Trunk from some time ago.
Mercurial or git!
-
Mercurial or git!
no
-
He wouldn't do that at least since Sourceforge doesn't support it yet, although I would love to just see it all on github or repo.or.cz. But I'm not gonna push it as long as I get commit access to it :)
-
Mercurial or git!
no
change to "maybe"
it appears that Git's user tools at least are getting more robust and actually workable.
-
I think I can live with SVN after all; Mercurial and git both seem to have decent looking SVN wrappers.
-
you find a decent hosting service for Git and I might use it. my problem with them to date has been lack of toolchain maturity (combined with bandwagonism in the early adopters)
-
git might be more future proof, as you said there seems to be quite the bandwagon, but I'm quite happy with SVN, hell if the tools worked better for me I'd be happy with CVS still. but whatever we do we need to do it, and get it done, development is going to remain stalled until we get a maintained repository other than CVS.
-
github or repo.or.cz both seem like good options, they're very social-oriented coding repositories.
Git's SVN wrapper is more capable than Mercurial's from what I heard, but I'm not a fan of the wrappers themselves anyway.
Git's windows tools have come leaps and bounds forward in just the last year. TortoiseGit is very stable now and msysgit even comes with its own gui tools. I've been using Git on OS X and Windows now, and it obviously works fine on Linux. Git 1.7.0 especially seems to have taken care of a lot of little nitpicks in the tools.
-
you find a decent hosting service for Git and I might use it. my problem with them to date has been lack of toolchain maturity (combined with bandwagonism in the early adopters)
I realize that I have nothing of value to say on the topic of the thread, but I would like to add my two cents about the VCS:
Code Hosting
Code wants to be free. Host your code on our free and public, warm and cozy SVN, Git, Mercurial, Bazaar, or CVS servers.
The SourceForge Features Page (http://sourceforge.net/register-project/features.php) says that SF supports both Git and Mercurial, so there is no need to move from SF.
Yes, Git has quite the bandwagon going for it but that is mostly because of who started it. That being said I don't think there is much concern about the future of either Git or Mercurial if only because of the current projects that are now using it. Git has the Linux Kernel Team and Mercurial has CPython Development Team.
-
yeah, that's what I was talking about with the 'future proof' comment, GIT seems to be the way stuff is moving, so it might be a good idea to go with them so we don't have to worry about SVN losing support in two years, but the state of technology as it is, SVN is fine.
GIT also has the 'oh, shiny' factor going for it.
-
SF says they have GIT, but i haven't seen it.
-
gotta enable it. under project admin, feature settings, under the availible features tab. (if you are an admin of a project)
Also, might wanna read this a bit, just in case (https://sourceforge.net/apps/trac/sourceforge/wiki/Git)
-
So is this project still running? What kind of state is it in?
I've been using a version of Collada PCS2 for quite some time now, I don't know about everyone else, but being able to use any up-to-date 3d modelling software instead of going through old, unsupported programs is a dream.
I've noticed there hasn't been any mention or new posts for a while...
M.
-
Well, can't say anything about Spicious' plans in this regard, but PCS2 and ModelView development has been forked here: http://www.hard-light.net/forums/index.php?topic=69360.0
Sooner or later, we're going to be looking at the bugs that are currently known, and try to fix them.
-
forking out of my repo = bad idea
-
Kaz, we've been hobbling along with a set of somewhat unstable PCS2 builds for some time. We've asked several times for a move to a more modern VCS, of which you hadn't seem opposed to but have yet to do. The code for Collada support has been published several times in whole on the forums in the new PCS 2.1 format, and now you've only recently asked Spicious to commit it himself instead of doing this at some point in the last six months or more. I'm not mad or anything, but there are many modders who have grown tired of waiting for this tool to get to a usable state, and The_E has picked up work on ModelView, as apparently the interface is more desirable than that found in PCS2 to many modders. Since there is a lot of good code in PCS2's core, The_E has decided to utilize some of that to replace the ModelView core, starting with texture processing. I suggested that perhaps the core could be modified in such a way that both ModelView and PCS2 could be built against it, since I don't see ModelView ever being a cross platform interface, and any enhancements made to the PCS2 core through that project could then immediately be available to PCS2 as well. Keeping it in one repository would allow for a checkout that could build either ModelView or PCS2, from a common backend model handling library. The Windows modders would have ModelView, or PCS2, and PCS2 could still be developed into a cross platform tool, all while maintaining a common core. But with this much new interest in the project, we need to get it out of CVS right meow and into something newer.
Now don't get me wrong, I'm not chewing you, I'm just pointing out that there's been a lot of frustration as of late and these are observations that have been made by most of the community. I'm personally against any forking but we need a little help and cooperation from you to avoid that I think.
-
lol things change fast.
Collada support was integrated into PCS2's CVS yesterday, today i migrated PCS2 to SF.net git is now in PCS2's
read-only access git://alliance.git.sourceforge.net/gitroot/alliance/PCS2
developers use ssh, same url (but remember your username)
-
If you're a dev you can use the url ssh://[email protected]/gitroot/alliance/PCS2 and it'll just ask for your password. Or upload your SSH key to Sourceforge and you won't ever need to authenticate.
-
Build updated. The inconsistent crashes on load and save should be fixed (or at least greatly reduced).
-
Is this now a build straight from PCS2's repo?
-
all builds from the repo contain collada now.
-
Yes.
-
Build updated. The inconsistent crashes on load and save should be fixed (or at least greatly reduced).
Thank you so much. However, it still crashes when I try to save some models to COLLADA format, for example, the UEFg Karuna from BP:AoA and the Longbow from the WCSaga Prologue.
-
The bug causing the problem with the Karuna should be fixed now.
-
PCS2 can save X and Z-axis rotation, but not Y-axis rotation. Here's a little VP for your perusal (http://www.ciinet.org/kevin/myimages/rottest.vp).
-
...And another thing: trying to import a shield mesh from a DAE gives me this error:
(http://www.ciinet.org/kevin/myimages/PCS2Shlderror.PNG)
-
I didn't think the Collada stuff did anything with rotations. I don't remember anyone coming up with a preferred representation.
Did you try importing from another file format? ;)
It should be fixed now.
-
I didn't think the Collada stuff did anything with rotations. I don't remember anyone coming up with a preferred representation.
I never said the Collada stuff has anything to do with submodel rotations... In fact, that bug has been there for a long time.
-
I didn't think the Collada stuff did anything with rotations. I don't remember anyone coming up with a preferred representation.
I never said the Collada stuff has anything to do with submodel rotations... In fact, that bug has been there for a long time.
May I direct you to this thread: http://www.hard-light.net/forums/index.php?topic=69598.0
Looks like a UI bug to me...(seeing as the z is actually x or whatever IIRC)
-
I don't know why, but something is causing Spicious's PCS2 build to crash whenever I try to open a POF or DAE. It just started happening recently, so it may be a problem with my system/OS configuration.
AppName: pcs2.exe
AppVer: 0.0.0.0
ModName: msvcr90.dll
ModVer: 9.0.30729.4148
Offset: 0006ccb5Other PCS2 builds, such as this (http://scoobydoo.freespacemods.net/Completed/Misc/pcs2.exe) one, do not crash when I open a POF or DAE.
EDIT: I performed a clean install of PCS2 and installed Spicious' latest build over it. It seems to be working properly now.
-
PCS2 can save X and Z-axis rotation, but not Y-axis rotation. Here's a little VP for your perusal (http://www.ciinet.org/kevin/myimages/rottest.vp).
Should be fixed now.
-
Not certain the "<parent-object-name>-trans" trick is working anymore - has anything changed with that?
On a conversion last night the glass section converted correctly in terms of geometry (ie, it merged with the hull rather than stayed as a seprate object) but was left with no texture cos the 'glass' texture that had been applied to it didn't survive the conversion. Testing it with the 2.0.3 DAE version it worked fine.
I'll find a sample model if needed. :)
-
It doesn't look like there's anything special going on that would be causing this problem. A sample would be really helpful.
-
Yeah sure - just tested with the Uly on 2.0.3 and the latest build from your sig and the problem is still present only in the new build, so hopefully that will be enough?
[attachment deleted by admin]
-
Ah, found and fixed. It was getting lost because of the change to only include textures used by actual geometry.
-
Confirmed fixed; thanks man. :)
-
And one more little change to import top level subobjects in a sensible order. Redownload!