Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Tools => Topic started by: Hades on July 04, 2011, 04:49:56 am
-
Didn't see one already, and I have some features I'd love to see so I figured I could kill two stones with one bird
1) The ability to see how glow-points and thrusters will actually look in PCS2, which makes it easier to glow-point and set thrusters, as there's a lot of going in-game to check. This should, ideally, be toggleable at any time, as it's easier to get positioning right with the little ball in PCS2 now, and it's better to determine what size it needs to be if its the actual glow-point, as the ball we have now is terrible for knowing how big the glow-point will actually be.
2) Normal mapping in PCS 2. Nuff said. Not really a big deal but it'd be nice to have.
3) Slightly more transparent bubbles, including the thruster, primary, secondary, and glow-point bubbles (or what I called balls earlier). This is for both a selected and non-selected bubble, which means its also easier to get placement right because you'd be able to see the surface it's placed on easier.
-
:yes: to hades
also
Please can he have this (http://www.hard-light.net/forums/index.php?topic=75620.0) looking into, multi-parts are still a pita.
another thing while I am thinking about turrets please can we have an option/button to generate the following in the properties of sub objects starting with turret in the name when the properties is empty.
$special=subsystem
$fov=180
$name=GunTurret
lastly can we have an option in turrets to generate a "turret" and a fire point for each sub object in detail0 beginning with turret
-
My wish for PCS2 is to support more Model formats, especially 3DS and Blend.
-
3ds and blend support is pointless though?
Max and Blender both export to DAE...
+1 for normal mapping.
I'm pretty happy with PCS2 though, it does pretty much everything I want it to <3
-
Have you ever actually USED the built in Max DAE exporter? Suffice it to say, it sucks. (Luckily there's OpenCollada.) Other model formats would be nice. What would be cool is the ability to hide subobjects in a model, so if there's something in the way, you can temporarily hide it to just see what you're doing.
-
Especially more transparent "bubbles" for squad insignia placement. As it is, the selected vertex bubble is totally opaque white, so you need to deselect it to see where the point is.
-
3ds and blend support is pointless though?
Max and Blender both export to DAE...
The DAE Export in the newest Blender has been broken.
-
:/
I have nothing to say except that it's blender's fault.
And that they should fix it.
-
I dunno if this needs to be on the list, as maybe I'm just missing something. But bounding boxes on objects (when the object is at a "tilted" aspect of the main body) still run parallel to the models center line.
Example of this: The new Charybdis. We have children sub-objects in Radar Dish domes. They successfully rotate independently even with the dish itself rotating. But because the bounding box for them is parallel to the main body, the rotation is not to their plane but the models center line plane. Which means they then warble up/down through their respective domes when rotating.
Feel free to split this post for further discussion of it if it doesn't fit with this topic, but I'd really like to know how I could go about fixing this.
-
Uh, I think the fact that the objects x-forms are reset (thus all the boxes being "upright" is a good thing (cause otherwise stuff gets really screwed up).
The rotating subdish thing should be more of a SCP thing, to allow off-axis rotation (ie, defining a normal vector along which the object rotates instead of just X/Y/Z), but what do I know?
-
Here's my wish... $uvec and $fvec automatically punted in from the orientation of the turrets base.
-
Here's my wish... $uvec and $fvec automatically punted in from the orientation of the turrets base.
That would be great, but in case you didn't know, there's something almost as good already in Spicious' builds: in the modelling app, link a helper object to the turret base (and center the dummy on that; I don't know if the positioning matters), and to that helper link another object called "vec". When imported to PCS2, the $fvec and $uvec props for the turret should then be automatically derived from the orientation of the "vec" object (so don't reset its xform or anything).
-
Uh, I think the fact that the objects x-forms are reset (thus all the boxes being "upright" is a good thing (cause otherwise stuff gets really screwed up).
Right, but upright relative to what? It would make more sense for tilted geometry to have a box that binds to the objects orientation rather than a flat plane orientation that surrounds it.
The rotating subdish thing should be more of a SCP thing, to allow off-axis rotation (ie, defining a normal vector along which the object rotates instead of just X/Y/Z), but what do I know?
The objects rotate nicely, so that isn't really a problem. And while yes, setting the models xform for the sub objects to be centered relative to their center point vs model center point would be the better way to go. But if I can rotate, move and flip turrets and firing points, being able to adjust for a "mistake" like that (especially if it just auto-happens during conversion) would be nice.
Maybe I'll post a YouTube of what the issue is specifically to shed some light on it.
-
Here's my wish... $uvec and $fvec automatically punted in from the orientation of the turrets base.
That would be great, but in case you didn't know, there's something almost as good already in Spicious' builds: in the modelling app, link a helper object to the turret base (and center the dummy on that; I don't know if the positioning matters), and to that helper link another object called "vec". When imported to PCS2, the $fvec and $uvec props for the turret should then be automatically derived from the orientation of the "vec" object (so don't reset its xform or anything).
didnt know that indeed. Thanks, i'll give it a try.
-
Have you ever actually USED the built in Max DAE exporter? Suffice it to say, it sucks.
QFT. Nothing I've found will export from Max, so I still generate pofs via TS. It's literally the only way I have.
-
Have you ever actually USED the built in Max DAE exporter? Suffice it to say, it sucks.
QFT. Nothing I've found will export from Max, so I still generate pofs via TS. It's literally the only way I have.
Huh? You can export to .dae just fine with the OpenCollada exporter plugin, with the only problem being that it doesn't (yet) work with Max 2012.
-
I'm of the persuasion max's built in "AutoDesk DAE" is a different format altogether using the same three letters for the filetype >.>
-
Have you ever actually USED the built in Max DAE exporter? Suffice it to say, it sucks.
QFT. Nothing I've found will export from Max, so I still generate pofs via TS. It's literally the only way I have.
Huh? You can export to .dae just fine with the OpenCollada exporter plugin, with the only problem being that it doesn't (yet) work with Max 2012.
No, I can't. I've tried. I get errors.
-
You using 2012? then yeah, nothing works.
You using something else? then :wtf: you may possibly be doing it very very wrong.
besides, 2012 can go -> fbx -> max2009 -> OpenCollada -> POF
-
I also want to add my support for PCS to either import DAE files from a wider variety of Collada exporters or accept some additional formats such as OBJ and/or 3DS.
-
Which additional Collada formats do you want supported?
You're welcome to implement support for other formats. I'm not going to do it though.
-
The one generated by Blender 2.6 please, see attachment.
[attachment deleted by a basterd]
-
i think they mean the COLLADA 1.5 format.
-
What FSF said. Thanks. :)
-
What I would have liked to see is a more versatile means to add support for formats to PCS2. A dynamic format library loading ability would be great, then people could add support for formats without modifying or having access to the core PCS2 code at all. All that would be needed is to define a set of functions that PCS2 would use to read the model through the library, and perhaps a way of getting what file extensions the library supports so it could be added to the file open dialogs.
-
The one generated by Blender 2.6 please, see attachment.
Nice; IDs but not names and polylist for triangles. You seem to be missing textures for everything apart from DAMAGE too. Try the attached build (which has since been updated to actually render untextured areas with VBOs enabled).
Can anyone spot today's lesson?
What I would have liked to see is a more versatile means to add support for formats to PCS2. A dynamic format library loading ability would be great, then people could add support for formats without modifying or having access to the core PCS2 code at all. All that would be needed is to define a set of functions that PCS2 would use to read the model through the library, and perhaps a way of getting what file extensions the library supports so it could be added to the file open dialogs.
It's a nice idea in theory, but would anyone actually write plugins?
[attachment deleted by a basterd]
-
Right, my findings. This build correctly imports DAEs exported by Blender 2.6, and at first sight there don't seem to be any issues with it. It also still opens the older DAE version. Good job, Spicious :):yes:
However, the Blender COLLADA exporter is still WIP (at least, I hope it is). Modifiers are completely ignored (as opposed to the 2.49b exporter, where you can choose to apply them), only objects in visible layers are exported (not so much an inconvenience, but something to keep in mind anyway) and textures now seem to be handled via materials instead of directly from the UV editor. From 5 minutes of messing around, it appears you need to have one material for each texture, and have UV coordinates selected for the material texture mapping.
If this is true (not quite certain yet) and will remain so, that would suck, since it significantly increases the workload of UV-unwrapping (you now need to assign not only a texture to each face, but also a material, and AFAIK that can't be done in any convenient way). For fully UVed models with just one texture this would be no big deal, but as soon as you want two textures on one object you'd have to assign materials face by face.
In conclusion, I recommend sticking to the 2.49b exporter for now, it's really much more convenient for POFfing purposes.
-
I think it's more likely down the line that someone would write a plugin rather than sort through the entire PCS2 codebase to add support for a file type, but perhaps only marginally more likely.
-
Just an FYI, face by face is not necessary. You can just assign the image in the UV editor like normal, then in poly select mode press ****f G and click image, then assign the material.
-
Just an FYI, face by face is not necessary. You can just assign the image in the UV editor like normal, then in poly select mode press ****f G and click image, then assign the material.
Ah, I could have known there'd be a better way. Thanks :)
-
My model loaded from Blender 2.6 Collada output as well. Thank you Spicious!
-
I'm sure this would be extremely low priority, and I have no idea how difficult it would be, but the lack of text DPI scaling compatibility is kind of annoying, since I either have to copy-paste things into notepad to read them or switch user accounts to one running at 96 DPI.
-
Ever since the BSP version (in fact, any PCS2 build post Feb 19 2011) the Radius for stored glowpoints get's eaten (reset to zero) even after being altered and saved, they go back to zero and they don't display in-game.
-
Good catch.
[attachment deleted by a basterd]
-
Danke. Works perfectly.
-
So is this a new-BSP build, an old-BSP build, or has new-BSP become the standard?
-
It's the standard now. Is it causing problems?
As an aside: any engine glows without normals would also have had their radii set to 0.
-
It's the standard now. Is it causing problems?
Not that I know of, just trying to keep track of the different versions :)
-
Why is this new build of PCS2 saving as COB by default (when you don't give a file extension) when the newer builds can't even open COB? Shouldn't it be saving as POF or DAE instead?
-
Oh, and one last thing... Can we please have a move up/move down button so that we can exchange the weapon point positions in the weapon banks without having to do a lot of copydeleting?
Ex. Moving bank 1 down would make bank 2 become bank 1 and bank 1 would become bank 2 and so on...
-
Oh, and one last thing... Can we please have a move up/move down button so that we can exchange the weapon point positions in the weapon banks without having to do a lot of copydeleting?
Ex. Moving bank 1 down would make bank 2 become bank 1 and bank 1 would become bank 2 and so on...
click-drag doesnt work?
-
Oh, and one last thing... Can we please have a move up/move down button so that we can exchange the weapon point positions in the weapon banks without having to do a lot of copydeleting?
Ex. Moving bank 1 down would make bank 2 become bank 1 and bank 1 would become bank 2 and so on...
click-drag doesnt work?
It works for me but it is a bit of a bind manually moving 8 firepoints, and its worse when dealing with large missile banks
-
I'd very much like a bounding box override in some shape or form. My top choice would probably be a way to import it the same way you can import vecs: that is, if you have an object named "bbox" linked to a submodel, then PCS2 calculates the bbox (for that submodel) based on that object's dimensions.
-
I want it to look me in the eye when it shakes my hand.
-
I'd very much like a bounding box override in some shape or form. My top choice would probably be a way to import it the same way you can import vecs: that is, if you have an object named "bbox" linked to a submodel, then PCS2 calculates the bbox (for that submodel) based on that object's dimensions.
It's not that simple. Bounding boxes get recalculated whenever they might have changed. Doing an override like with radii seems fairly straightforward though.
-
I'd very much like a bounding box override in some shape or form. My top choice would probably be a way to import it the same way you can import vecs: that is, if you have an object named "bbox" linked to a submodel, then PCS2 calculates the bbox (for that submodel) based on that object's dimensions.
It's not that simple. Bounding boxes get recalculated whenever they might have changed. Doing an override like with radii seems fairly straightforward though.
Fair enough, whichever is easier. However, wouldn't it then be easy to make it so that if a submodel has a "bbox" child, its bounding box is calculated and used to pre-fill the override values for the parent's box?
-
Fair enough, whichever is easier. However, wouldn't it then be easy to make it so that if a submodel has a "bbox" child, its bounding box is calculated and used to pre-fill the override values for the parent's box?
Sure, if everything else was done (and I hope you mean a child of the helpers for a submodel). Please provide an example of that and for custom radius as well.
Global bounding box overrides and the new UI for radius overrides are done.
-
Fair enough, whichever is easier. However, wouldn't it then be easy to make it so that if a submodel has a "bbox" child, its bounding box is calculated and used to pre-fill the override values for the parent's box?
Sure, if everything else was done (and I hope you mean a child of the helpers for a submodel). Please provide an example of that and for custom radius as well.
Global bounding box overrides and the new UI for radius overrides are done.
Ah, cool. Here's a testcase for the submodel-specific bbox and radius overrides (the size of the radius helper is fairly random, though). It has the following hierarchy:
Detail-0
|- WingLeft (both wings go outside Detail-0's bbox, hence the need to override it)
|- WingRight
|- helper
|- bbox (this is actually a mesh object, not a helper)
|- radius
[attachment deleted by a ninja]
-
Chequered texture view :3 ?
Some sort of Troll face generator?
-
Now with subobject and PMF support. DAE support later.
[attachment deleted by a basterd]
-
I also want to add my support for PCS to either import DAE files from a wider variety of Collada exporters or accept some additional formats such as OBJ and/or 3DS.
i m in for OBJ format.
-
I want to be able to import NON hierarchy defined geometry and define the hierarchy in PCS2
-
Now with support for importing custom bounding boxes for subobjects from DAE. (The sample radius doesn't actually seem to have a size)
I also want to add my support for PCS to either import DAE files from a wider variety of Collada exporters or accept some additional formats such as OBJ and/or 3DS.
i m in for OBJ format.
You're volunteering to add support for OBJ?
I want to be able to import NON hierarchy defined geometry and define the hierarchy in PCS2
I have no idea what you're asking for.
[attachment deleted by a basterd]
-
I want to be able to import NON hierarchy defined geometry and define the hierarchy in PCS2
I have no idea what you're asking for.
He wants to be able to link objects in PCS2 rather than in a modelling program.. The reasoning for that is beyond me.
-
I want to be able to import NON hierarchy defined geometry and define the hierarchy in PCS2
I have no idea what you're asking for.
What i think assasing123 is asking for is to be able to import a model file into PCS2 where the objects are all on the same level and then move them around to place the child objects on the detail levels rather than having to do it in the modelling program, as a blender user this is of no interest to me as hierarchies are easy but i am not sure if some programs can be tricky to set them up.
As it is when PCS2 imports a model file any root level objects that dont start with something like detail or lod (i think lod works) is ignored.
-
People can do awesome modeling in Wings3D or Sketchup... and then they get to this step, and they go "What is an 'helper object' :confused: I speak polygon."
It should be possible to do it like this:
- Using the program of your choice...
- Model something awesome
- Export OBJ
- Using PCS2
- Import OBJ
- Tell PCS2 how to use each of the objects in that OBJ
- Set up additional data
-
I want to be able to import NON hierarchy defined geometry and define the hierarchy in PCS2
I have no idea what you're asking for.
What i think assasing123 is asking for is to be able to import a model file into PCS2 where the objects are all on the same level and then move them around to place the child objects on the detail levels rather than having to do it in the modelling program, as a blender user this is of no interest to me as hierarchies are easy but i am not sure if some programs can be tricky to set them up.
As it is when PCS2 imports a model file any root level objects that dont start with something like detail or lod (i think lod works) is ignored.
exactly this! is true blender users dont have any problem at all, but some programs are pretty good at modelling easily but dont have support for nodes. not to mention i find PCS2 much more easier to use to define hieararchy than blender or anything else.
-
You CAN shuffle around hierarchy in PCS2.
Just drag and drop the subobjects around.
To get it to import you just need to parent everything to say, detail0...
You can set up all the other hierarchy later, assuming everything is split into separate objects already.
WARNING: Droid803 is not responsible if PCS2 crashes on you or screws up your model. Just saying that I've rearranged hierarchy in PCS2 before, and its entirely doable. Feature already exists. :rolleyes:
-
Now with support for importing custom bounding boxes for subobjects from DAE. (The sample radius doesn't actually seem to have a size)
There's some kind of an offsetting problem with the imported bboxes. This should illustrate what's happening:
EDIT: Naturally, in both cases detail-0 itself is at 0,0,0 as it should be.
[attachment deleted by a ninja]
-
Transformations on "helpers" nodes aren't supported.
-
Transformations on "helpers" nodes aren't supported.
But it doesn't have any transformations. It's just a helper, placed at 0,0,0 which is where detail-0 and its pivot point is.
EDIT: Erm... I fiddled with it some more and now the bbox appeared correctly when imported. I don't know what's going on. I'll let you know if I encounter the problem again.
-
You CAN shuffle around hierarchy in PCS2.
Just drag and drop the subobjects around.
To get it to import you just need to parent everything to say, detail0...
You can set up all the other hierarchy later, assuming everything is split into separate objects already.
WARNING: Droid803 is not responsible if PCS2 crashes on you or screws up your model. Just saying that I've rearranged hierarchy in PCS2 before, and its entirely doable. Feature already exists. :rolleyes:
As it is when PCS2 imports a model file any root level objects that dont start with something like detail or lod (i think lod works) is ignored.
-
You CAN shuffle around hierarchy in PCS2.
Just drag and drop the subobjects around.
To get it to import you just need to parent everything to say, detail0...
You can set up all the other hierarchy later, assuming everything is split into separate objects already.
WARNING: Droid803 is not responsible if PCS2 crashes on you or screws up your model. Just saying that I've rearranged hierarchy in PCS2 before, and its entirely doable. Feature already exists. :rolleyes:
As it is when PCS2 imports a model file any root level objects that dont start with something like detail or lod (i think lod works) is ignored.
Just name them all detailX, fix up the header later.
If you absolutely insist on not doing ANY hierarchy AT ALL...
Was that so hard?
-
or maybe the tools i use for modelling just cannot define hierarchies at all?
and yes you will say something like" get real tools, or get blender or, something like that, this is a wishlist, i m just saying what i wish for.
for me blender albeit really powerfull, is way overly complex and way too hard to use. on some of the apps i use, to make a good model in 15 minutes with textures and all, takes half hour, on blender i m still trying to find out how i can select vertex that are hidden from view using box selection and how to select faces instead of vertex D:
-
Maybe it's because you consider a 'good model' something you made in 30 minutes. Unless you're talking about a cargo container, I'm not sure what kind of quality work you can do in any app in that amount of time. Unless you're The Flash. If so can I have your autograph?
-
Blender is rather quick. Most of the Sobek was modelled in about 45 minutes.
...then I scrapped everything but the neck and started over.
-
Im not getting into the which 3D prog is the best etc debate because thats a discussion for another thread but to the rest of the post
or maybe the tools i use for modelling just cannot define hierarchies at all?
presumably you can still name the objects otherwise you cant set the names to detail# which means that PCS2 will ignore all your objects anyway.
what droid is saying is to stick detail in front of everything, import to PCS2 move the turrets and other objects into the correct place in the hierarchy and rename as appropriate
-
Im not getting into the which 3D prog is the best etc debate because thats a discussion for another thread but to the rest of the post
or maybe the tools i use for modelling just cannot define hierarchies at all?
presumably you can still name the objects otherwise you cant set the names to detail# which means that PCS2 will ignore all your objects anyway.
what droid is saying is to stick detail in front of everything, import to PCS2 move the turrets and other objects into the correct place in the hierarchy and rename as appropriate
O_O! i love you headie! (IN THE NOT GAY WAY) i though naming on the program i used wouldnt work at all, but it does and i can export straigh to collada from it and it works on PCS2 O_O
THANKS A LOT MAN seriously! O_O
-
One of my few remaining wishes would be to be able to replace submodels by importing a replacement from another file. For example, if I find that a single submodel happens to be missing a poly, I could fix that more easily if I could just replace that submodel by importing a replacement from another file. Currently there's currently no simple and practical way to do it (I think the submodel load feature is supposed to allow it, but it seems broken), so I have to re-convert the whole thing (which isn't a lot of work, but always leaves a bit of room for error).
Also, it'd be nice if the submodel numbers were re-generated every time the hierarchy changes.
-
Maybe it's because you consider a 'good model' something you made in 30 minutes. Unless you're talking about a cargo container, I'm not sure what kind of quality work you can do in any app in that amount of time. Unless you're The Flash. If so can I have your autograph?
the fastest ship i ever did took 2 days, one day mesh, 1 day texture. im not sure what it was (may have been the original vulture), but these were the pre-htl days so it was only like 400 polies.
-
Im not getting into the which 3D prog is the best etc debate because thats a discussion for another thread but to the rest of the post
or maybe the tools i use for modelling just cannot define hierarchies at all?
presumably you can still name the objects otherwise you cant set the names to detail# which means that PCS2 will ignore all your objects anyway.
what droid is saying is to stick detail in front of everything, import to PCS2 move the turrets and other objects into the correct place in the hierarchy and rename as appropriate
Well it's still kind of silly, but at least there's a known workaround. But what about being able to import an .obj?
-
One of my few remaining wishes would be to be able to replace submodels by importing a replacement from another file. For example, if I find that a single submodel happens to be missing a poly, I could fix that more easily if I could just replace that submodel by importing a replacement from another file. Currently there's currently no simple and practical way to do it (I think the submodel load feature is supposed to allow it, but it seems broken), so I have to re-convert the whole thing (which isn't a lot of work, but always leaves a bit of room for error).
How is it broken? (It adds rather than replaces)
Also, it'd be nice if the submodel numbers were re-generated every time the hierarchy changes.
I'm sure automatically reordering submodels would annoy plenty of people.
But what about being able to import an .obj?
What about it?
-
One of my few remaining wishes would be to be able to replace submodels by importing a replacement from another file. For example, if I find that a single submodel happens to be missing a poly, I could fix that more easily if I could just replace that submodel by importing a replacement from another file. Currently there's currently no simple and practical way to do it (I think the submodel load feature is supposed to allow it, but it seems broken), so I have to re-convert the whole thing (which isn't a lot of work, but always leaves a bit of room for error).
How is it broken? (It adds rather than replaces)
Exactly; it only adds, and cannot replace. Although frankly half of the reason why that's a problem is because the delete function doesn't work: when I attempt to delete a submodel, it asks whether I want to delete all its children as well, yet even when I say "yes" it doesn't delete the children as well. If the delete function would be fixed then I suppose I could always add the new replacement submodel(s) and delete the old, but that'd still leave me with a broken-looking (probably has no functional difference, though) hierarchy because the new submodel(s) appear at the end of the submodel list, instead of the list getting re-sorted alphabetically. When importing a fresh file, submodels get sorted alphabetically.
-
Delete with children worked for me.
You're probably better off reimporting and doing a global import if you want to preserve order.
-
How hard would it be to get PCS2 to open FS1/ST Retail POFs?
Currently, it just essentially opens to a 'blank' instance of PCS2.
If you need some retail models to work with, I have them all.
-
My simple request for new version of PCS2:
I need a tool for clearing main model from subobjects [turrets etc.]. I was thinking about as a button that switch on a small window with list of subobjects of model. You could tick submodels you want to delete on list and than remove them with one click on proper button. I need it for returreting ships. Removing subobjects one by one, turret after turret is a bit frustrating especialy when I have something like 50 turrets [+ maybe destroyed versions]. PCS2 also sometimes crashing when I remove something. Is this possible to do?
-
these days all i want are vs2010 project files.
-
Delete with children worked for me.
You're probably better off reimporting and doing a global import if you want to preserve order.
It doesn't always work, especially if you have a lot of children. They usually get distributed to a higher level in hierarchy.
-
One small question, I'm kinda out of the loop (i'm still using Nov 7,08 build), but has anything been done with glowpoints? What I'm looking for is a way to import the on/off/displacement timings in max. That way I can create a script or something that will let me quickly build christmas-light landing lights (blinking in sequence)
-
One small question, I'm kinda out of the loop (i'm still using Nov 7,08 build), but has anything been done with glowpoints? What I'm looking for is a way to import the on/off/displacement timings in max. That way I can create a script or something that will let me quickly build christmas-light landing lights (blinking in sequence)
For what it's worth, I haven't heard of anything of the like having been done.
-
Think I asked about this years ago, but there were other things more important at the time. I tried doing it for Saga, but it became nearly impossible with pcs2/collada not keeping the order.
-
Wish: instead of displaying the poly/tricount, display the vertcount. That's what really matters, and it's easy to accidentally go over the current vertex limit of 65536 (*) while all you see is the poly/tricount which presumably doesn't really matter anyway (or at least tends to matter less often than the vertex limit).
(*) At least I believe that's what the limit is. PCS2 can save more than that, but it cannot open the resulting .pof anymore. FS2O can load and use those models, but the normals of vertices which went over the limit are garbled. There might be other issues too, but those are the ones I'm familiar with.
-
Wish: instead of displaying the poly/tricount, display the vertcount. That's what really matters, and it's easy to accidentally go over the current vertex limit of 65536 (*) while all you see is the poly/tricount which presumably doesn't really matter anyway (or at least tends to matter less often than the vertex limit).
Good idea. Done.
As far as I can remember, it's a POF format limitation.
-
Wish: instead of displaying the poly/tricount, display the vertcount. That's what really matters, and it's easy to accidentally go over the current vertex limit of 65536 (*) while all you see is the poly/tricount which presumably doesn't really matter anyway (or at least tends to matter less often than the vertex limit).
Good idea. Done.
As far as I can remember, it's a POF format limitation.
Not a POF format limitation specifically, but more of a general limitation (which should be implemented by the engine), since your POF files better damn well not be near 2GB anyway (the "number of vertices" variable stored in the file is a signed int32, according to http://www.hard-light.net/wiki/index.php/Bsp_data_structure).
-
Good idea. Done.
Cool, thanks.
However... looking at what the vertex count field says, it seems I really don't understand what the limits are, after all. The (PCS2) code is difficult enough for me to read that I can't find anything in there; can you give any kind of pointers as to where the low-level mesh data read/write operations are? For one, the displayed vertcount implies that vertices aren't getting split the way I thought they were (http://www.hard-light.net/forums/index.php?topic=81005), and I can get models with corrupted normals even when neither polycount nor vertcount exceeds 30k, let alone 65k.
I'm starting to think that it's more along the lines of vertcount+polycount+normalcount having to remain below a limit (of 65536?) or some other combination like that, instead of there being too many of any single thing.
-
Out of curiosity, is the source on Sourceforge (http://sourceforge.net/p/alliance/pcs2/ci/master/tree/#) still the latest source? It looks like the last commit was sometime in March.
-
Not a POF format limitation specifically, but more of a general limitation (which should be implemented by the engine), since your POF files better damn well not be near 2GB anyway (the "number of vertices" variable stored in the file is a signed int32, according to http://www.hard-light.net/wiki/index.php/Bsp_data_structure).
The limitation here is on the indexing, not the total:
ushort vertnum[i]
ushort normnum[i]
However... looking at what the vertex count field says, it seems I really don't understand what the limits are, after all. The (PCS2) code is difficult enough for me to read that I can't find anything in there; can you give any kind of pointers as to where the low-level mesh data read/write operations are? For one, the displayed vertcount implies that vertices aren't getting split the way I thought they were (http://www.hard-light.net/forums/index.php?topic=81005), and I can get models with corrupted normals even when neither polycount nor vertcount exceeds 30k, let alone 65k.
I'm starting to think that it's more along the lines of vertcount+polycount+normalcount having to remain below a limit (of 65536?) or some other combination like that, instead of there being too many of any single thing.
Vertices don't have to be split, but for each vertex we need to store all of its normals, which is somewhere between 1 and the number of polygons containing that vertex, depending on smoothing. There's no sharing of normals, so a normal used by two vertices is stored twice. Unless your model is completely smooth (one normal per vertex), you're going to overflow normal indexing long before you hit the vertex limit.
Out of curiosity, is the source on Sourceforge (http://sourceforge.net/p/alliance/pcs2/ci/master/tree/#) still the latest source? It looks like the last commit was sometime in March.
Pushed.
-
Vertices don't have to be split, but for each vertex we need to store all of its normals, which is somewhere between 1 and the number of polygons containing that vertex, depending on smoothing. There's no sharing of normals, so a normal used by two vertices is stored twice. Unless your model is completely smooth (one normal per vertex), you're going to overflow normal indexing long before you hit the vertex limit.
A-ha, thanks, I think I finally get it now. That explains why normals of vertices past a given point are made of seemingly garbage data; it can't index all the normals it wants to, so the indexing wraps back to 0?
So, in theory (and I'm not saying this would be a good idea, just that it'd be possible), one could sort of fix the issue like this: for all normal index numbers which would not fit in an ushort, find the closest matching existing normal and point to that one instead. Right?
-
I would want to use a set (http://en.wikipedia.org/wiki/Set_%28data_structure%29) to store each unique normal, and then, convert that set to a list, and index all of the normals by finding the index of the normal in the list.
-
It seems
+offset vertex_data // Each vertex n is a point followed by norm_counts[n] normals.
is misleading and normals don't actually need to be stored with their positions. Without that constraint, the limit is now 64k total normals per submodel. Please give it a try: pcs2_2014-01-04.7z (https://googledrive.com/host/0B_qLK7VGhoIydUY1RFlzOVNMdGc/pcs2_2014-01-04.7z). As an added bonus, this build includes some performance fixes for POF load and save and Collada imports. It will most likely require the x86 Visual C++ 2013 redistributable (http://www.microsoft.com/en-au/download/details.aspx?id=40784).
So, in theory (and I'm not saying this would be a good idea, just that it'd be possible), one could sort of fix the issue like this: for all normal index numbers which would not fit in an ushort, find the closest matching existing normal and point to that one instead. Right?
Yes. I think we could choose which normals to keep a bit better with clustering though.
-
It seems
+offset vertex_data // Each vertex n is a point followed by norm_counts[n] normals.
is misleading and normals don't actually need to be stored with their positions. Without that constraint, the limit is now 64k total normals per submodel. Please give it a try: pcs2_2014-01-03.7z (https://googledrive.com/host/0B_qLK7VGhoIydUY1RFlzOVNMdGc/pcs2_2014-01-03.7z). As an added bonus, this build includes some performance fixes for POF load and save and Collada imports. It will most likely require the x86 Visual C++ 2013 redistributable (http://www.microsoft.com/en-au/download/details.aspx?id=40784).
Seems to work! :yes: Super awesome, thanks a lot. I'll do more testing on it and tell if I find anything amiss.
-
This build seems to have a bug where subobject normals are concerned. Opening the Solaris pof (http://blueplanet.fsmods.net/E/UEDSolaris.7z) yields these results:
(http://blueplanet.fsmods.net/E/brokennormals.png)
-
I have the same problem with some hi-poly model I converted. Half of the ship looks the same as the Solaris from The E's screenshot. It causes both PCS2 and a game to crash, while PCS is sometimes able to open the model.
-
And that's why you scope variables as tightly as possible. New build is at pcs2_2014-01-04.7z (https://googledrive.com/host/0B_qLK7VGhoIydUY1RFlzOVNMdGc/pcs2_2014-01-04.7z).
-
This build shows textures with UV flipped on the V axis.
-
Overwrite your old dlls with the ones in the archive.
-
And that's why you scope variables as tightly as possible. New build is at pcs2_2014-01-04.7z (https://googledrive.com/host/0B_qLK7VGhoIydUY1RFlzOVNMdGc/pcs2_2014-01-04.7z).
Hello. I downloaded the file, but I can't run because the required DLL file, MSVCP120.dll is missing from my computer. I downloaded that DLL file, and put it inside the same directory as the new PCS build, but it won't start correctly (0xc000007b). I am currently running Windows 7.
-
It will most likely require the x86 Visual C++ 2013 redistributable (http://www.microsoft.com/en-au/download/details.aspx?id=40784).
-
I managed to get it running. Thanks a lot, Spicious :)
-
Hey Spicious, could you please take a look at the file attached? (Collada, Blender exported) As far as I can tell, the texturing is stored correctly in the DAE, but it's not being imported in PCS2...
[attachment deleted by an evil time traveler]
-
The polylist elements should have an attribute material="Material-material".
-
Ah, gotcha - turns out you have to actually assign the material to the object faces. Thanks!
-
Wish: refresh the main view after model loading is complete. I often open a model, maximize the window and then wait around or do something else while the model is loading. After it's done, the rendering canvas is still the size it was when the program started (that is, tiny) and I have to de-maximize and re-maximize for the canvas to be resized and redrawn.
-
Wish: refresh the main view after model loading is complete. I often open a model, maximize the window and then wait around or do something else while the model is loading. After it's done, the rendering canvas is still the size it was when the program started (that is, tiny) and I have to de-maximize and re-maximize for the canvas to be resized and redrawn.
There is actually a similar feature in it at the moment to what your wish sounds like; if you check the top menu bar for "view" and go to 'reset' at the bottom of the drop-down it should make the ship view the correct size for you screen. Discovered while running into the same problem myself.
-
Ability to modify the center of objects in PCS2 and their true orientation.
the option to just import any 3d object and position it in PCS2 and easily alter the hierarchy.
this because sometimes models get their matrixes messed up for some unknown reason to me when importing and fixing them in blender/3dmax dosnt seem to work, so I often end just making each object apart and them importing them individually.
-
Ability to modify the center of objects in PCS2 and their true orientation.
the option to just import any 3d object and position it in PCS2 and easily alter the hierarchy.
this because sometimes models get their matrixes messed up for some unknown reason to me when importing and fixing them in blender/3dmax dosnt seem to work, so I often end just making each object apart and them importing them individually.
the best way to avoid this in blender is to make sure your normals/faces are all oriented to the outside and that scale / rotation is applied prior to export
-
I'm kinda out of the loop with the newest pcs features, but can you set glowpoint information in your source files and import them into pof? Like glow_texture?
I want to set them up in importable files, that I can quickly drag and drop onto the models and do minimal maintenance?
-
I know this is a huge feature request and it might not be something you're interested in, but could you add support for exporting ships into Vegastrike engine format to PCS2? It would be really great if we had a graphical tool for hardpoint/shield editing.
-
Also I'd like to request migrating from WXWindows 2.8 to 3.0. The GL Canvas code that exists has been deprecated and the application no longer builds on Debian 8.1
-
Another question for another year....
There is a COB scaling factor, but is there a way to scale DAE files? I'm kinda tired of having to edit in such a small scale and then have to export into other engines with a 100X factor. (Things like symmetry, welding, chamfering, etc... don't really like being used on such a small scale. I could just rescale before export, but that can cause all sorts of problems with animations (not that engine supports animation yet...)
-
And there's another question: Portability, being able to use PCS 2 from a flash drive, which makes it independent of %APPDATA% and registries.
-
And there's another question: Portability, being able to use PCS 2 from a flash drive, which makes it independent of %APPDATA% and registries.
It's not already portable?
-
I think it's portable. Or isn't it?