Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Kazan on August 14, 2006, 02:33:03 pm
-
Ok... post your feature requests here.. I'll add them to my lists here
(approved features are added to the roadmaps - additional revision goals will be added as needed)
PCS 2.0 Roadmap
- Completely rewritten POF BSP compiler
- New internal model format [PMF]
- PMF saving to disk
- POF Load from/saving to disk
- gunpoint convergence calcuator
- .cob import
- .cob Autogen features
- BSP Debug (ala show sortnorms/bboxes from PCS1)
- Functional import features (PMF->PMF data copy)
- ALL data editable in sections (HDR2, TXTR, OBJ2, SPCL, DOCK, FUEL, PATH, GPNT/MPNT, TGUN/TMIS, GLOW) Dev: Bobboau
- autopath Dev: Bobboau
- universal copy+paste Dev: Bobboau
- POF Smoothing Data->faceted/autofacet/smooth reverse engineer Dev: Kazan
- .cob save (requires editors to be done first) Dev: Kazan
- new POF Chunk SLDC for Shield Collision Trees Dev: Kazan (ref: http://www.hard-light.net/forums/index.php/topic,47751.new.html )
- Glow/shine/env mapping Dev: Bobboau
- Moment of Inertia calculator (math involved (http://www.hard-light.net/forums/index.php/topic,39723.msg808065.html))Dev: Bobboau
2.0 Notes/Caveats: adding new file formats is orders of magnitude less difficult in PCS2.0 - this is because of the new internal model format "PCS Model Format" - BSP compilation (the hard part of generating a .pof) is ONLY done when generating a .pof (whenever you save to new POF or one which's geometry has been altered - opening a POF caches the BSP).
PCS 2.1 Roadmap
- Geometry Import (IE add additional geometry to existing file)Dev: Kazan
- Collada XML Format support (Max, Maya, Lightwave, Blender, etc) Dev: Spicious
- AutoTurret upgrade to new Keldor's new side-facing compatible turret code Dev: Kazan
- New and Improved UI Dev: The_E
- Refactoring all pointers not passed to wxWidgets to use boost (std::tr1/C++11 std:: ) smart pointers to eliminate memory leaks.Dev: Kazan
- PMF metadata export to text Dev: Kazan
-
.ASE File Format support (Maya, 3DS Max and others support this format) Dev: Kazan Format Found to be Unrelaible
-
.OBJ file format support Dev: Bobboau
- geometry/UV editing capabilities + Geometry error detection
- BSP Geometry Error checker (will do a precompile and check for any polygons that will be dropped due to errors - dropped polygons will be shaded red, others green)
- Render with VBOs Dev: Bobboau
- PMF upgrade to indexed vertex array. (more time spent in COB/ASE/OBJ -> PMF, less time PMF->POF) -- Strike, maybe? Could make geometry editing more difficult
- .eff support (MAYBE)
- Normal Mapping support (MAYBE)
- Model rescaling
PCS 2.2 Roadmap
- Add (FS2) table data to PMF
- ship tbm export for .pof
------------------
Tentatively Accepted Features (not yet roadmapped)
Pending Features (not yet accepted or rejected)
Tentatively Rejected Features
Permanantly rejected features
- .3ds Support (format replaced by more useful one)
-
.ASE File Format support (Maya, 3DS Max and others support this format) Dev: Kazan Format Found to be Unrelaible
-
.OBJ file format support Dev: Bobboau
(please sticky this)
-
Maybe not really a request, but just to make sure, the only thing I find Modelview superior to old PCS is the render window, with it's sharp lines and the possibilites to switch into wireframe and untextured mode, automatic sideview and so on. I'm sure you have it in, but If not, consider doing it :)
Besides that, aurora's autopathing-function was very handy and save a lot of time, but should be upgraded to place at least 4 paths per fighterbay.
-
latest screenshot i can find (2006-04-16) and PCS2's render window doesn't suck CPU like a blackhole :D
(http://ferrium.org/media/PCS-20060416.jpg)
-
MoI calculator/estimator?
-
teach me the math so i can understand it and it's there (i think bobboau knows how to do it.. maybe he can describe the algorithm) (does the FS2 engine even USE the MOI?)
-
Well... according to this thread (http://www.hard-light.net/forums/index.php/topic,39723.msg808065.html) FS does use MoIs...
-
ok.. a quick skimming of the linked thread apparently has the information in a format that I can understand and work with - just requires me to grab every LOD1 bounding box for all submodels and use them to calculate... should be acceptable... moving to tentatively approved until I get a chance to look closer at the math
-
Yes it does, and while a MOI calculator might be too much work, make at the very least an edit box for the values, like ModelView has. That way we can copy/paste values from :v: ships
- Make a ship radius edit box, so we can fix POFs which were created with older versions of the MAX exporter.
- Ability to read DDS textures. (JPG, BMP would be useful too)
- Any option to read model formats that support proper smooth grouping data would be awesome.
- A 3D cursor thing would be useful. I mean something like a point defined by 3 crossing lines (each parallel to an axis), that could be moved around. Together with a text readout of the coordinates, it could be used to determine x/y/z coords for gunpoints, thusters, etc. directly in PCS
I'll add more requests when I remember them.
-
Yes it does, and while a MOI calculator might be too much work, make at the very least an edit box for the values, like ModelView has. That way we can copy/paste values from :v: ships
already editable
- Make a ship radius edit box, so we can fix POFs which were created with older versions of the MAX exporter.
already editable
- Ability to read DDS textures. (JPG, BMP would be useful too)
already there.. i had to custom compile the image library i use
- Any option to read model formats that support proper smooth grouping data would be awesome.
such as?
- A 3D cursor thing would be useful. I mean something like a point defined by 3 crossing lines (each parallel to an axis), that could be moved around. Together with a text readout of the coordinates, it could be used to determine x/y/z coords for gunpoints, thusters, etc. directly in PCS
probably doable
-
Support for Glow/shine/env mapping? (In the said various formats?)
-
Support for Glow/shine/env mapping? (In the said various formats?)
if taylor shows me how to do those, or codes them himself (PCS uses OpenGL to render)
-
The ability to see, and possibly edit, axes would be nice. :)
-
- Any option to read model formats that support proper smooth grouping data would be awesome.
such as?
Ideally MAX, but that's probably not doable. Could you parse model data from the Max ASCII format ? That would be very kickass too. See the attachement for an example (note the "*MESH_SMOOTHING number" in the face list)
3ds exporting in Max allows sort-of smooth grouping, it creates non-welded vertices betweeen non-smoothed polys. That would require PCS2 to detect those, extract the smooth grouping data and then weld the vertices. Probably too much hassle.
OBJ supports smooth groups, IIRC, but I'm not sure if one can find proper format descriptions.
Another way of doing things (and the most flexible one) would be to include an option to edit smooth grouping data in PCS. I don't know how you're handling the smooth shading properties of polygons internally in PCS, but ideally you would create an option to select multiple faces with the mouse and then assign a smooth group number to them, à la Max.
That way we could import any model and then edit smooth groups on the go. It would be also the easiest way to fix the smoothing on old POFs.
[attachment deleted by admin]
-
now that we have gunpoint convergance what about a normal calculator. it would operate on selected gunpoints and maybe thrusters as well, and determine the normal for each point based on a convergance coordinate.
i like axem's idea of a coordinate tweaker, so you gan swap axes and invert them as well, so as to help orient models that may be out of whack.
when converting cob files, use something other than lights to terminate geometry. on some of the newer versions of truespace, especially when working on capships, rendering all those lights can slow down the program considerably. it would be nice if autogen worked on single, one sided polys instead, like the freelancer model converter does. for points with a radius you can use the size of the polygon to calculate that. normals could be calculated off the way the polygons are facing calculated to a length of 1. converter should remove the geometry from the model while keeping the data.
import/export of all non-geometry pof data to an easy-to-edit text file.
animation code simulator, allows you to test animatons based on the table parameters. perhaps even a point and click editor that allows you to specify how the subobjects will animate and generate animation code which may be directly pasted into the table.
i think pretty much everything else has been mentioned already
-
now that we have gunpoint convergance what about a normal calculator. it would operate on selected gunpoints and maybe thrusters as well, and determine the normal for each point based on a convergance coordinate.
that should be doable (slating for 2.1)
i like axem's idea of a coordinate tweaker, so you gan swap axes and invert them as well, so as to help orient models that may be out of whack.
ok.. coordinate cursor sounds good to me.. but wtf does it have to do with axis :D (slating for 2.1)
when converting cob files, use something other than lights to terminate geometry.
no changes to the cob format. Set the lights luminosity to zero
import/export of all non-geometry pof data to an easy-to-edit text file.
i can probably do that :D especially since PCS2 internally is using PMF (slating for 2.1)
animation code simulator, allows you to test animatons based on the table parameters. perhaps even a point and click editor that allows you to specify how the subobjects will animate and generate animation code which may be directly pasted into the table.
if someone else wants to code it i'll add it to the roadmap, but i'm not touching that with a 10-foot pole
-
...
already filed under new model formats
-
ok.. coordinate cursor sounds good to me.. but wtf does it have to do with axis :D (slating for 2.1)
this is just to support modeling programs that have a totally wierd axis order *cough* truespace *cough* and others as well. so you can get your ship pointing straight with just a few mouse clicks.
one more, cut and paste for all 3 coords in an xyz field array, rather than doing it one number at a time.
-
Not to get off-topic but where did you get that Waterloo?
-
...
already filed under new model formats
Which one of my suggestions ?
If you could make a documentation for your PMF format available, I might be tempted to write a Max ASCII -> PMF converter.
-
The ability to auto-generate paths would be nice Kazan. Setting up docking paths and attack paths is mind numbingly dull and I'm not sure why PCS can't at least have a guess. If you don't like the path it comes up with you can either modify it or delete it and make your own so what's to lose? Maybe add auto-generate path buttons to the dock, turret, and subsystem screens?
Support for >100 subobjects as well please. PCS1 actually would do it but it messed up one of your list boxes :).
-
Not to get off-topic but where did you get that Waterloo?
it's a WCS model
-
If you could make a documentation for your PMF format available, I might be tempted to write a Max ASCII -> PMF converter.
i could do that once 2.0 comes out so PMF is finished
-
Support for >100 subobjects as well please. PCS1 actually would do it but it messed up one of your list boxes :).
ha.. that must be a windows API problem :D - other thing added to 2.1 roadmap
-
one more, cut and paste for all 3 coords in an xyz field array, rather than doing it one number at a time.
added
-
ha.. that must be a windows API problem
Your numbers just needed padding with 0s to 3 digits. 999 sub-objs should be enough ;).
-
If you could make a documentation for your PMF format available, I might be tempted to write a Max ASCII -> PMF converter.
i could do that once 2.0 comes out so PMF is finished
of.. if you're curious
(if you're curios what a kaz_vector/kaz_vector is.. it's my temporary replacement to std::vector/std::vector so i can debug inside the ****ing things - and they're almost certainly faster and less memory-consuming than the dailywtf-deserving MSVC6 implementation)
http://alliance.cvs.sourceforge.net/alliance/pcs2/
pcs_file.h/.cpp
pcs_file_dstructs.h/.cpp
read/write functions right at the top - don't let the preprocessor defines bite you in the ass though
if you're any good at coding i'll give you repository write access and you can write me readers/writers for the formats you want
-
It's been quite a while since I've done anything with C.
I was more thinking along the lines of writing a converter that tranlates Max ASE files to PMF files in ASCII, and then read the created PMF with PCS2. If that's not doable and I can muster the will, I might try adding it directly to PCS.
I'd like to take a look at a PMF file containing some simple geometry, once you've done.
-
the entire PMF format is documented in code... you could do the Max ASCII->PMF but i'd prefer to keep everything inside, anyway any code do to that would be doing the same thing as the code you'd be writing for internal support - you wouldn't have to write any of the hooks just the PMF::read_max and PMF::write_max functions, i'd take care of everything else
-
I'm glad someone else brought up Axes (or is it Axi?). I have a hell of a time with them... :D If it would be easier in program, then my dream of quickly switching out old turrets for new (more detailed ones) on certain ships would be a snap! :nervous:
-
you mean subobject import? that would be nice.
-
no he didn't mean that.. but that's a feature i could consider vaughly.. but why the hell don't you just do it in your stinking modelling program for ****'s sake
-
i think he wants to import new turrets into existing freespace ships
-
i think he wants to import new turrets into existing freespace ships
I'd love to see that added :nod:
One of the homeworld editors (i forgot the name ages ago) had that. You could import a turret, position it, then make an array of clones, flip them around...
At least allow some "predefined templates". I do this with cob files but its quiet annoying having go to in an rename each turret's number (the turret, the turret arm, the turret's firepoint(s), the destroyed turret...etc)
-
perhapse make a turret prefab. a turret only, complete with data in pof format, with the base on the 0'0'0 plane. import those into pcs2, enter position and orientation info, and boom, pcs 2 does the rest.
-
Because Kazaan-san, you have the power in you to build the greatest ship-editing program in-the-world! (ok, that's maybe a little over the top :D)
I like that term, "sub-object import". Sorta like how DOGA is all drag and drop and rescale. I can already imagine the hijinks ,er, serious research projects I could start with such a feature... ;7
Changed my siggy.
-
I'll try to see if I can help any this weekend.
a feature you absolutely must have, and make sure it's there from the begining, COPY! new, delete, COPY. I cannot stress how much easier this one little feature makes editing, and it's so simple to implement if you make sure you do it as you go along (rather than going back and doing it later).
-
are you talking about the x/y/z coordinate copy? or what? copy what exactly?
-
I think he means that you should be able to copy any details that aren't added by autogen (And some that are). For instance if I add a weapons subsystem on one side a ship in PCS I should be able to click copy, add a minus in front of the X value and rename it to create a navigation subsystem on the other side of the ship.
That's something PCS can't do at the moment and it's miles quicker than having enter all the details for every subsystem by hand.
-
ok.. that's going to be a lot of code
-
Scalable outputs been considered i take it?
Glowpoint manipulation and Lod/Debris positioning?
-
Scalable outputs been considered i take it?
wha?? you mean scaling the conversion? um.. that's already present in 1.0
Glowpoint manipulation and Lod/Debris positioning?
glow point manipulation is already present in the 1.0 tree, and look at the first post in this thread under 2.0 roadmap
-
Well what about adding some sort of point click/drag interface to it then?
-
Actually PCS2 is going to be driven by a text command line interface.
-
Well what about adding some sort of point click/drag interface to it then?
not going to happen - this isn't a modelling program, it's primarily a conversion program
-
Fair enough, if i dont ask i won't know these things. :)
-
if i dont ask i won't know these things. :)
Except for the thing that was in the first post that you didn't need to ask about.
-
I still want .lwo support, it would make my life so much easier, problem is, apart from Omni, I think I'm the only Lightwaver left, specially since Mikhael doesn't seem to come here any more :(
Now, if you could combine PCS2.0 with some kind of table-file generator, so you can edit each subobject, assign it a hull percentage, apply a rotation script, or firing points and rotation details if it is a turret, and then generate the .POF and the basic table files at the same time (especially if you could watch the animation effects in PCS2 first), that'd be very useful....
Problem is, that sounds more like something that would need work from all the coders who did each feature rather than samething it would be reasonable to ask a lone member for :(
-
yeah.. all those advanced features (multitexturing, animations, etc) will require each appropriate coder to help me
as for the extra values for a table.. maybe for the 2.3 roadmap i could add in all those other values and then POF export would be POF/.tbm
-
I still want .lwo support, it would make my life so much easier, problem is, apart from Omni, I think I'm the only Lightwaver left, specially since Mikhael doesn't seem to come here any more :(
I'm a 'waver too, so you are not alone :)
And omni uses max for modelling, even though he knows his way around in LW.
-
I think he means that you should be able to copy any details that aren't added by autogen (And some that are). For instance if I add a weapons subsystem on one side a ship in PCS I should be able to click copy, add a minus in front of the X value and rename it to create a navigation subsystem on the other side of the ship.
That's something PCS can't do at the moment and it's miles quicker than having enter all the details for every subsystem by hand.
Something similar on this note, although a lot easier to code would be something like this. My fighters are symetrical i put a gun at say (10,5,2) there is always a gun on the other side, mirror it so its (-10,5,2). It'll involve copying the existing gun data node, alter the specific axis and add it to the gun list... I could even code that for you :)
-
wonder how you have things coded that would make that dificult, it should be
add_new_thing();
copy_currently_selected_thinngs_data_to_new_thing();
set_new_thing_as_selected_thing();
-
wonder how you have things coded that would make that dificult, it should be
add_new_thing();
copy_currently_selected_thinngs_data_to_new_thing();
set_new_thing_as_selected_thing();
for ONE thing it is that easy - but you have to setup a copy and paste function for EACH object you want to be able to copy paste
-
If you can automate the copy and paste then doing it for multiple objects shouldn't be a problem. a simple foreach loop...
btw are we talking about mesh objects or simple point objects like engine glows and gun mounts?
-
If you can automate the copy and paste then doing it for multiple objects shouldn't be a problem. a simple foreach loop...
i was talking about types of objects, not instances of objects
-
do you have the editors set up yet? if not (or if you felt like rewriteing everything) you could make some universal array template editor class and code it once.
-
Something similar on this note, although a lot easier to code would be something like this. My fighters are symetrical i put a gun at say (10,5,2) there is always a gun on the other side, mirror it so its (-10,5,2). It'll involve copying the existing gun data node, alter the specific axis and add it to the gun list... I could even code that for you :)
I just used subsystems as an example. Bob was saying that anything that has data should work that way (so including gunpoints :D )
-
do you have the editors set up yet? if not (or if you felt like rewriteing everything) you could make some universal array template editor class and code it once.
i already have the editors templated out, only header works though, but this would be data duplication not really stuff in the UI other than the hooks to trigger the copy and pasting
-
Another feature, although you've already got it added. I see there is a rotate by axis, but is there a view front/back,left/right,top/bottom? It would make editing points much easier.
-
that would be cool. but im not a big fan of multiple views. just a number of view angle buttons to toggle between them.
-
Thats what I was referring too... view angle buttons, sorta like whats in Modelview..
As I'm working on pathing right now, I thought of another minor nice feature, change the color of the path your current selected, like yellow. That way I know which one i'm working on.
-
i find that 4 pane view sucks unless you have a really big monitor right in your face. a 19" 3 feet away it really sucls.
with all the modeling ive done i still dont fully understand pathing. i dont know the procedure the code goes through when docking, dont know when to use a short path and a longpat. i dont understand the attack paths. all i really know is how to put in a path that works to the degree of not crashing the game.
also code in a way that makes future upgrades to the model format easyer. like if you want to add a new chunk or add an extra field to an existi9ng chunk. and so on.
-
Keyboard shortcuts. Alt to open and close the menus, Ctrl-X/Ctrl-C/Ctrl-V for cut/copy/paste, and TAB to move between text boxes on a dialog.
-
Definetely tabbing, I wouldn't be surprised if that would speed up creating a working pof model faster.
-
hey bob, if you need write access to the PCS2 source (and don't already have access to my repo) give me a shout... I got a PM about you working on the ASE file format or somesuch.. i'm too tired to really read closely.. i'll go through and update the other requests tommorow
-
Sorry to keep this list growing but....
When your in gun/missile mode it shows you where the hard points are and their orientation, please have this for eyes/engines too. I'm also assuming you've got eye/gun/glow points importable like EngGlow?
-
Glowpoint manipulation and Lod/Debris positioning?
glow point manipulation is already present in the 1.0 tree, and look at the first post in this thread under 2.0 roadmap
In PCS1, it just displays a block to represent the glowpoints. Could PCS2 be made to actually display the glowpoint effect indicated? The idea is to see what it will look like in-game, without having to boot up the game itself.
-
perhaps even have the glowpoints blink according to their setting too. it would really save me alot of work.
-
In PCS1, it just displays a block to represent the glowpoints. Could PCS2 be made to actually display the glowpoint effect indicated? The idea is to see what it will look like in-game, without having to boot up the game itself.
possibly... yet again with the help of the gfx genii
-
I assume your using Opengl correct?
Could you draw a rectangle centered where the glowpoint is located in the model space? Given the right dimensions and apply the glowpoint texture to it?
-
Nothing like bumping an old thread but... :nervous:
right now I'm trying to path the turrets, and released something that might be useful and hopefully shouldn't be that hard to create, just a little vector math. Take the turret base point on the parent draw a vector through it and the firing point. This can be the near path point. Then move the line out to about 100 or so units and have this the other path point. It won't be ideal in all situations but a.) it gives paths and b.) it gives something to start working with.
-
Don't worry, I've bugged Kazan for this a hundred times ;).
-
perhaps a system where i select an object and hit a 'path object' button, a line pops up from the center of that object to a point in space. you can rotate this line around the object with the arrows and shorten/lengthen the path with pgup/pgdn keys. maybe you can make the mouse do it too, scroll wheel handeling the length. space creates a new point and you can then edit that line, enter completes the path. maybe it can be smart, and enter all the other infor for you depending on the object type you pathed. say you pathed a turret, it would fill in all the turret specific path info. if you path a subsystem named fighterbay it creates a fiterbay path and sets that up for you. if you path the hull it sets up a dock point as well (baced on the normal of the nearest polygon). this aproach would et you set up a path fairly quickly. you could path a whole juggernaught in only a few minutes.
perhaps make it so you could use the fast pathing controls to edit normals (for anything) as well.
-
bumping this thread is good.... hopefully i'll be able to start working sometime soon.. just busy w/ work, school, wedding and tae kwon do right now. next semester i return to school full time and quitting my programming-sucking-job
-
One thing I'd like is the ability to update models or submodels without starting a file from scratch--like how you can copy other features from other ships, you should be able to copy the model from another ship or from a .cob file and keep the rest of the data. Also, it'd be nice if it could tell you which of the two types of "cocentric triangle" errors you have: either your model being too small or your model having serious geometry errors.
Edit: wedding?
-
Edit: wedding?
yeah
-
Congrats Kazan :)
that is I think congrats or sympathy :p
-
first they chop off the end of his dick
now they want to take his balls.
poor kazan :D
-
she does want to "take" my balls.... note the distinct lack of the word "off" :D
-
Just remember "to death till us part" is a goal :p
-
I just thought of something useful yesterday while I was trying to convert my cruiser and I couldn't post :-(
before i forget, would it be possible to convert lods seperately, i.e. one at a time (this could be like turret prefabs)
Edit: I just foud out my turrets are messed up... so I had to go through each of them (major pain in truespace) to find i didn't renumber some of the arms/firepoints...
How about this instead of :
Turret01
cube
turret01-arm
cylinder1
cylinder2
turret01-fp-01
turret01-fp-02
Turret01-destroyed
cube
light
how about this:
turret01
cube
ARM
cylinder1
cylinder2
FP01
FP02
DESTROYED
cube
light
That way you only need to specify which turret number it is only once. Now I don't know if COB files are setup as nicely (it might require some preprocessing to create that hierachy from the cob hierarchy) Plus another major bonus is you can copy and paste turrets very nicely, only having to renumber the main group instead of having to rename 4+ objects
-
Not sure if someone has already said this, but...
I think there should be more either built in subobject orientation detection tools, or easy tools to let the user determine the orientation of the subobjects. Like, you should be able to assign a normal vector to something by selecting a face with the same normal vector. And you should be able to select either a polygon or submodel to center the point on or in. The two might or might not have to be the same (if you select a polygon as the location).
Edit: and some easy way to flip points across planes parallel to but not identical to the three coordinate planes (i.e. the plane x = 2 instead of the yz plane, or any numerical entry); this would be particularly useful if you could do multiple points at a time.
Also, how about an "advanced clipboard" feature, where you can copy any number of points, subobjects, or what-have-you into the clipboard, and paste or remove them from the clipboard at any time. Also useful with this feature, you should be able to save clipboards, either inside their respective PMFs or as their own files.
-
The clipboard feature has already been requested, and I'm backing it. Ideal for duplicating turrets. :)
Ohhh following my suggestion about using Turret01 number just once (prev post) that should make making the clipboard easier. Unless these some funking stuff going on in the PCS internal model/pof hierarchy i'm not aware of.
-
Heres another feature requestion.... Kazaan already looking at me with the look of death LOL..
How about rescaling an existing model? I could bring all my fighters to scale with Saga models without having to rebuild them and relocate the points (gun, paths, eye..etc)
-
with PCS2 that would probably be a trivial amount of coding
-
Is the wishlist still open ? :)
Not sure if it has already mentioned here (sorry, to lazy to read everything), but a really important function that we are missing for years
is a pof-resizer. It sucks to have to re-convert the model everytime I scaled it wrong.
AFAIK there was something like segeltuch in the past, but I never get this program to run like it should.
Would that be possible Kazan ?
-
yes the wishlist is still open, i just haven't added things to the schedule for a while.. been to busy to try to think out on the road map... i think someone already requested that and with the new internal model format that wouldn't be very difficult.
conversion from COB will be 1:1 no longer 1:20 by default as well
-
Is the factor still selectable ? I found it always quite handy that it converts 1:20. When I have to make the cob file 1:1 then I have to work on a giant model in truespace which makes it a little more difficult IMO, not to mention that navigation in truespace is a pain in the arse
-
That would have been my request about 5 messages up :)
Ok would a model thats 1km would an imported X x 3.6 x Z, switched down to X/3.6 x 1 x Z/3.6 sized up to 1000X x 10000 x 1000Z/3.6
That would be impossible to edit in truespace?!!! :nervous:
-
its better to model fighters at 1:1, but capships i oten model at around 50:1
-
Hmmm I never thought of it for fighters.... I'm so used to using X/3.6 x 1 x Z/3.6.
Heres a dumb thought.... would it be possible to export the model data through a function call? You could then write a plugin that would receive all the model data, perform it's operations and return the result back. I'm not sure if this would work well for it or not, but it would make life in the long run easier for the wish list. Instead of having to write everything including the kitchen sink into the program, you could write plugins that do the job.
-
it would be cool to have some form of integration with the max plugin.
-
no need to export the data like that... the plugin (if i write a plugin interface) could just have direct access to the internal PMF
-
Well thats even better then :-)
I was thinking something like this:
ModifiedData = RunPlugin (OutgoingData) ;
-
that would be terribly ineffecient.. making copies of the central data store.. oui
the plugin would simply have access to the PMF object in memory
-
Agreed.... just pass it a reference or pointer
-
it'll be a reference if i make the interface
-
This might sound like a stupid suggestiong, but I just discovered I've been making a mistake for my subsystem special names...
Would it be possible (with people's suggestions/warnings) about possible errors in your pof model data. For example in my case....
It'll warn you that you forgot to put a '$' in front of the specials name.
-
My request is that it get made!
-
My request is that it get made!
ditto
-
MOI!! Moment of inertia?
Have read up on this, from different threads. There isn`t an easy fix for this, is there?
I mean, leaving the file in pof format, while fixing it isn`t possible, correct?
-
You can edit the MOI in Modview. To prevent weird actions due to improperly set MOI, you can either import the values from a tried and true ship, like one from FS2, or you can edit the values to make them all equal zero... which is what all existing TBP models are set to.
-
since people posted: i'm back in school now and i may get some work in on pcs2 between cs309 project ****e and playing vanguard
-
massive thread necromancy
anyone who's requests i haven't integrated into the plan, pls repost
-
table generator and a "finalize" button?
(decides tables based on gunpoints and other crap, then creates a .tbm file when you select "finalize" along with, of course "which primary/secondary weapons would you like it to use" text boxes.)
-
Instead is needlessly complicating additional features (like the above), how about a tentative release date of a version that can save to file (in case I missed it) understanding it could be months or more down the road.
-
Instead is needlessly complicating additional features (like the above), how about a tentative release date of a version that can save to file (in case I missed it) understanding it could be months or more down the road.
right now it can open POF files, and resave them - just most of the editor UIs are not active yet- and COB loading isn't coded yet - see the feature list at the beggining, greened ones are completed
-
I do have to admit, some way of generating a ships table entry might be nice, but I could see that being a whole other program of itself, looking at how complicated those table entries can be. But having it generate a very basic template, with just the right amount of turrets, subsystems, and blank openings based on the pof data, might be within the scope of this program.
EDIT: For grammar
-
I think that a table generator etc would be a lot of work to put on one persons shoulders though. I suppose the best bet is to get something workable up and running, and then that will hopefully add impetus to improve and expand on the base converter :)
-
Well, he is planning the roadmap, so I figured this could be something for 2.2 or beyond if nothing else. On top of that, I don't think it's all that complicated of a request. It just needs to generate a template with all possible fields for a ship, and blanks wherever it can't generate the data from the pof directly. The data's already all there, it just basically has to dump it to a pre-formatted file. I might actually try and sit down and write something like that over spring break if I get a chance.
EDIT: Grammar again...tonight's not my night.
-
Oh, I agree, I'd love to see a table generator (in truth, I suggested one on page 2).
I think the problem is things like ship-flags. There will probably be a pretty final list of flags by 3.7, so stuff won't keep having to be added to PCS 2, but I agree, generating the text file for a ship isn't complicated from a coding point of view :)
-
Say wasn't someone working on a table editor a while ago?
-
Yeah, that's why I was saying that a real generator/editor could be a full blown program, but just spitting out a template with a few things filled in already and the rest empty isn't, that's all I meant.
-
I'm on the fence about tbl generation - because initial design specs for PCS2 were engine-abstract because i had planned it to be capable of dealing with both POF for FS2 Open and FOF for ferrium, but ferrium is dead - so i have to decide whether or not i want to put in a bunch of FS2 specific stuff
-
It would be soooo awesome if it let you move subobjects around.
-
Heres another feature requestion.... Kazaan already looking at me with the look of death LOL..
How about rescaling an existing model? I could bring all my fighters to scale with Saga models without having to rebuild them and relocate the points (gun, paths, eye..etc)
What he said :nod:
Also... dont forget insignias!!! :P
-
rescalling is not difficult in the PMF format
-
Where does any one actually need table entry generator? As it aint difficult to write the entries on your own and you pretty much have to do that anyway. Subsystem/subobject name list is just about all that can be used.
-
This is the thing, a simplistic table generator may be of little use, but how about one that automatically works out the vectors on your turret, so that its simplicity to use Bob's angled-turret code when it gets included etc. The potential is there, even if it takes a few generations to appear :)
-
and setting detail distances is hard....and so are subsystems, ect. ship table entrys are by far the most annoying to do.
-
scheduling including table data in the long-term plans
i am, at this very moment, working on COB support
-
This is the thing, a simplistic table generator may be of little use, but how about one that automatically works out the vectors on your turret, so that its simplicity to use Bob's angled-turret code when it gets included etc. The potential is there, even if it takes a few generations to appear :)
Kinda bad example as - IIRC - Bobs angled-turret related stuff goes all into submodel or subsystem properties (in the POF file) and has no relevance what so ever to table files and does not need anything special from the table files...
-
I wondered that myself. Even simplistic stuff like auto-setting turrets to face forward et al is useful though. Someone who can't make a basic FS2 table should really be learning how to do so, I'll admit that, but certainly for some of the more long winded stuff, and particuarly for the fact that non-FS2 mods may have ships with hundreds of turrets/subsystems etc, I would guess that any labour saving would be an advantage :)
-
takashi, I'm not sure a lot of the stuff you want done could be feasibly implemented by an automatic generated. Most of the stuff you want sounds like it needs to be decided by the user, not generated from POF data. How can it know what distance you want it to switch LODs? For stuff like that, a full blown table editing program could be nice, but like I said, that's beyond the scope of what I was hoping to see here.
Anyway, here's kind of the output I figured it could give.
; for descriptions of fields, see the wiki for help at http://www.hard-light.net/wiki/index.php/Ships.tbl
; delete or comment with a semi-colon lines you don't want to define
; only required fields are $Name, $POF File, and $Flags
; most other fields are included to help generate a production table entry
$Name: Name Here
$Short name: Short name here
$Species: Species here
+Type: XSTR("", -1)
+Maneuverability: XSTR("", -1)
+Armor: XSTR("", -1)
+Manufacturer: XSTR("", -1)
+Description: XSTR( "", -1)
$end_multi_text
+Tech Description:
XSTR("Tech room description here", -1)
$end_multi_text
+Length: (Determined by PCS) m ; generated by PCS
+Gun Mounts: (Determined by PCS) ; generated by PCS
+Missile Banks: (Determined by PCS) ; generated by PCS
$POF file: filename.pof ; generated by PCS
$Detail distance: (#1, #2, #3, #4 ) ; #1 <= #2 <= #3 <= #4
$Show damage: YES ; YES or NO
$Density: 1
$Damp: #
$Rotdamp: #
$Max Velocity: #X, #Y, #Z
$Rotation time: #X, #Y, #Z
$Rear Velocity: 0.0
$Forward accel: #
$Forward decel: #
$Slide accel: 0.0
$Slide decel: 0.0
$Expl inner rad: #
$Expl outer rad: #
$Expl damage: #
$Expl blast: #
$Expl Propagates: YES ; YES or NO
$Shockwave Speed: #
$Shockwave Count: 1 ; probably not good to go too high, especially with mediavp shockwaves
$Allowed PBanks: ( "Name1" "Name2" )
$Allowed Dogfight PBanks: ( "Name1" "Name2" )
$Default PBanks: ( "Name1" "Name2" ) ; number of fields generated by PCS to match pof file
$Allowed SBanks: ( "Name1" "Name2" )
$Allowed Dogfight SBanks: ( "Name1" "Name2" )
$Default SBanks: ( "Name1" "Name2" ) ; number of fields generated by PCS
$SBank Capacity: ( # )
$Shields: #
$Shield Color: # # # ; RGB, 0-255
$Power Output: #
$Max Oclk Speed: # ; speed at full engine power
$Max Weapon Eng: #
$Hitpoints: #
$Flags: ( "flag1" "flag2" "flag3" )
$AI Class: class from ai.tbl
$Afterburner: NO ; YES or NO
$Countermeasures: #
$Scan time: # ; in ms
$EngineSnd: # ; from sounds.tbl
$Closeup_pos: #X, #Y, #Z
$Closeup_zoom: #
$Shield_icon: shield animation name
$Score: #
$Subsystem: turret01a, #, # ; generated by PCS
$Default PBanks: ( "Name" )
$Subsystem: turret02a, #, # ; generated by PCS
$Default PBanks: ( "Name" )
$Subsystem: turret03a, #, # ; generated by PCS
$Default SBanks: ( "Name" )
$Subsystem: Radardish01a, #, # ; generated by PCS
$Subsystem: communications, #, # ; generated by PCS
$Subsystem: weapons, #, # ; generated by PCS
$Subsystem: Navigation, #, # ; generated by PCS
$Subsystem: Engines, #, # ; generated by PCS
$Subsystem: Main-Reactor, #, # ; generated by PCS
Yes, for many subs and turrets, having all the names in place would definitely help.
-
much of the data wouldn't be autogenerated, it would be new data fields in the PCS2 that you can edit.
Just found why AutoInsigia corrupted models in PCS1.x
-
well if were gonna be running some table generation, any chance of an animation and turret simulator/editor. then you can tweak animations in pcs2, generate the table data for them, and they will be pretty much ready to use. the turret side would let you modify the turret rotation axes (bobs turret features) and simulate the movements to check for any unwanted clipping and whatnot.
another thing i want is user editable ascii based data sheets to store non obj2 chunk data in. so stuff like gunports can be entered in a text file and auto loaded into their proper fields in the editor.
-
don't bring up any details related to that stuff until we're about to implement it
-
I mentioned a few weeks ago in SCP section about ship/weapon table generation checker etc...
A normal table would be out of the question: how does PCS2 know the diff between a fighter/bomber, a cap ship of any class, or other ships/objects? It doesn't all that data would have to be edited so at best the most vaguest of tables could be generated via what it finds in the .cob.
Again such features (while nice) are definitely a distraction to the core program.
I'm glad to hear .cob importation is the priority!
oh and:
Are there stages in teh conversion process? So if your progress bar stops at say stage 3 it can also display an error message on fail or if hung up past like 5 mins (arbitrary time limit I'm throwing out there) and say, "PCS2 failed @stage 3"
So if different processes occur during conversion you know which one has the problem. (which greatly clarifies individual mesh issues that can later be looked at).
-
It may be a distraction, but a very short distraction time wise. Read the data from the file, and output what is mostly a static file with a couple loops dependent on the number of subsystems and turrets. I'm going to try to write it myself, so no one has to bother with anything other than feeding it the right data in the program. I still think having the basic layout dumped to a file with the right number would be useful on complicated ships. The SWC is going to be pushing the limits of turrets, and it would be much easier than doing all the subs by hand.
Edit: Anyway I'll stop talking about this because it's starting to overshadow all the other more important suggestions made so far. Keep up the good work, I'm sure it's going to be excellent when it's done!
-
maybe an auotgen of sorts for the fighter/bomber/other diff? like naming the hull object in the hiearchy a specific word....
-
[03:22.28 AM] Hans Kazan: sandwich - please post in the PCS2 discussion threads in modding that i had a 5-alarm family emergency and will be out of contact
-
i'm back... but my stress level is high enough that i became sick, so if i'm short with someone please forgive me
[edit]
oh.. cob import is done, but untested (it expects data in the cob to be sublty different than PCS1 does - mostly because i have it coded for 1-1 scaling)
-
how about more comon formats, like .3ds?
-
how about you STFU and RTFT
-
And if that wasn't therapeutic, I dunno what is! :lol:
Seriously Kazan, take as much time as you need dude!
We appreciate what you put into these type of things, but everyone needs to remember it's just a hobby.
-
it's not working on PCS2 that is the problem, and taking a break from PCS2 won't help
-
well give me a build and i got about 20 different truespace models to throw at it.
-
alpha executable for your mashing pleasure: http://www.ferrium.org/media/pcs2-alpha-20070325.zip
-
alpha executable for your mashing pleasure: http://www.ferrium.org/media/pcs2-alpha-20070325.zip
Crashes whenever I try to open a pof.
-
alpha executable for your mashing pleasure: http://www.ferrium.org/media/pcs2-alpha-20070325.zip
Crashes whenever I try to open a pof.
that's new...
[edit]
and i cannot replicate it
-
heh, just extracted it and tried to run in own folder,
"application failed to start cause incorrect configuration"
It has all it's dll's that came with it so I wonder what's going on? :confused:
-
Crashes whenever I try to open a pof.
that's new...
[edit]
and i cannot replicate it
I can't get it to open a thing. Retail models, my own models, BtRL models... nothing.
It just closes when I select the file and hit "Open"
-
It works fine for me.
-
I can't get it to open a thing. Retail models, my own models, BtRL models... nothing.
It just closes when I select the file and hit "Open"
sys info?
[edit]
i just noticed i forgot to disable the "COB Loader Not Implemented, piss off" message (that's not what it really says :D)
-
:lol: It would be great if it did though ;)
-
Wow....
(http://s5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/th_PCS2vsSB1.jpg) (http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/PCS2vsSB1.jpg)
Ok, I've now tested it on a lot of the pofs I have, and as you can see, ^ some work quite well. :D (Incidentally, one such working model was an experiment that was converted to pof directly from blender's cob export. ;) )
With the ships that don't load, I'm noticing two distinct types of failure.
It loads most media-VP ships perfectly, with the notable exceptions I spotted being mainly terran fighters and bombers. The failure the fighters and bombers experience - both retail and mediaVP, is that PCS2 will lock up and have to be terminated.
My wild guess would be something to do with insignia maybe?
The second type of failure occurs rarely - with ships like the mediaVP orion and hecate. In these cases, PCS2 will hang for a second before exiting completely. (No errors) Haven't the foggiest as to what could cause these.
=====
It's looking very promising with the ones that do load up properly though. :D
That ship in the screenie above is comprised of 63 000 polys. It works in game, but neither PCS1 nor modelview were able to load it up properly (PCS with the viewer on just crashed, and a special build of modview I made for it leaked memory like a sieve and still didn't display it properly.)
PCS2 loads it in seconds and renders it with no performance drain that I can see. :yes:
I've not tested the cob import properly yet, mainly because all my conversions have been via .SCNs and I don't have any complex convertable cobs lying around.
Oh, and a couple of other little things I'll bring up here before I forget:
1) The controls - would it be possible to rig it so that right-click will zoom, and shift+left-click will pan? It just feels more natural and more in keeping with most other 3d viewer proggies. :)
2) (sorta related to 1) I can see you've implemented a rotation system that allows you to rotate through all 3 axes - that's awesome, but in practice I've found that having the rotation controls split over two buttons is really difficult to use effectively. :\
Perhaps the best thing would be a toggle button between a 3 axes system and the 2 axes system that the left click currently controls. Basically have the 3rd axis controlled in the same way it is in the ship lab. I would describe it, but....I can't really figure out what the input for the third axis is in there. It just works nicely. :s
3) Really-little-thing-1; might it be possible to have an isometric/perspective view toggle? That'd be quite helpful for positioning stuff.
4) Really-little-thing-2; PCS2 seems to load up the models in completely random orientations every time, and loads them up as wireframe despite what the display buttons up the top say. Not sure if the first one's a bug, but I figure I'll point them both out just in case.
Anyways, awesome work. :)
-
give me the exact names of models that cause the hard-lock
give me the exact names of models that cause the momentary lockup
.scn/.cob loading code is the same, i just need to make PCS2 recognize .scn as a .cob - doing that now
-
here is a build where you can actually open .COB/.SCN
http://www.ferrium.org/media/pcs2-alpha-20070325b.zip
just be warned.. i will be SHOCKED if cob loading works right - it is still untested
[edit]
run for your lives! it's kazan in a suit! http://derekmeek.com/Pictures/Kaz-Suit-20070325.jpg
(this moment of levity brought to you by Kazan-prepairing-to-put-his-money-where-his-mouth-is)
just need to get my hair cut now...
-
well so far it loaded all nukemod pofs and actually uncovered a geometry bug on one of my models (by showing missing lines) that i was having problems with. it did have some trouble showing small models such as small rockets, mines, ect. and vwep gatling guns (probably cause the parent object didn't have any geometry).
now that last build you put up that supposedly could convert scn didn't have a scn option in the load model dialog box. assuming that was a minor oversight, i manually entered the filename and hit open. at this point i got a happy little read error. il assume for the moment that it cant handle scns and try some cob files instead.
are dds textures supported yet? that would be a really useful feature to have you know :D
-
DDS should be covered, and i'll add .scn to the box
Code
tex_ctrl.cpp:107
char *extensions[] = { ".pcx", ".dds", ".jpg", ".png", ".tga", ".gif", ".bmp" };
-
"application failed to start cause incorrect configuration"
Same here :(
-
for those of you it won't run for - get msvcm80.dll, msvcp80.dll and msvcr80.dll from the net and put them in the same folder, tell me if that fixes it
if it does, i need to murder some MSCV8
-
Sweet it runs really fast and smooth.
Btw are textured model currently operational? You mentioned DDS, how's the folder setup for textures suppose to be, in the same folder as the model?
-
it tells me i have to reinstall becauseits not configured properly. im running windozes XP.
-
for those of you it won't run for - get msvcm80.dll, msvcp80.dll and msvcr80.dll from the net and put them in the same folder, tell me if that fixes it
if it does, i need to murder some MSCV8
Done, but still no joy.
-
OPs I deleted it and used the newest -b build and it opens.
OPens new pof's for me no problem (untextured so it's lookign in the defualt vp right? Not the folder the pof is in)
no joy with custom .cobs yet.
gonna try a higher poly pof in a few..
[EDIT]: The max size models I usually use is around 8k and so far I opened every Gundam pof I made no problems.
Three observations though: 1 - The status bar does not indiacate progress yet? It does have text status clues next to it.
2 - When I want to open a new pof I just do as the NEW option does not seem to clear the old session...
3 - You type too damn fast! :D
-
fsck file wouldn't attach
here are the DLLs http://www.ferrium.org/media/stupid_mscv8_dlls.zip - put them in the same folder as PCS2
- PS the search path for textures is as follows
there is a list of directories in the Options->Preferences menu (default entry of c:\games\freespace2)
Search order is
VPs in the folders in that list
raw files in those folders + "\data\maps"
ie if your list is
c:\games\freespace2\
c:\games\the babylon project\
c:\games\wing commander saga\
it'll look for VPS in
c:\games\freespace2\
c:\games\the babylon project\
c:\games\wing commander saga\
and raw files in
c:\games\freespace2\data\maps\
c:\games\the babylon project\data\maps\
c:\games\wing commander saga\data\maps\
-
Hey Nuke so far I tried to open a few NM pof's like the asgard and Jotun and they were invisible, not even wireframe was possible.
Only the Rumrunner had any textures at all (cause all the rest are dds)
I did add a few custom ships to your mod like aldo's EOS with PCX textures and they did not show up. (I have it configured right)
C:\games\freespace2\Nukemod\data\maps
l8tr!
-
C:\games\freespace2\Nukemod\data\maps
that is an incorrect configuration
the correct configuration would be
C:\games\freespace2\Nukemod\
-
Ahhh DUH *Slap forehead*
I saw texture paths and automatically thought it was for game paths, like modelview.
Nope textures still won't show. BTW theres a small bug with the rendering options, it selects the textured one while showing the wireframe model. Could this be the cause of the texture problem?
Fixed, btw you might want to allow to put enter the exact location of the textures (or at least do a recursive search). For example, while I'm working on a model, I stuff everything absolutely necessary for it into a folder "modeldata", "modeldata\maps", "modeldata\model"...etc when I'm done i just do a simple vpmage and vola.
-
apparently it does search the direct path as well - just doublechecked my code
-
Awesome - whatever you changed with this latest one, you seem to have caught and killed the pause-then-close bug. As such the media VP Orion, Hecate, Medusa, Ursa and Zeus now load up no worries. :D
The lockup type of failure is still happening with: (going through all retail-version fighters - straight out of the sparky_fs2 VP)
Mara, Pegasus, Herc 2, Perseus, Erinyes, Myrm, Serapis, Bakha, Ptah, Dragon, Herc 1, Seth, Horus, Thoth, Baslisk, Manticore and Loki
Some notable exceptions are that it works with the Asteroth, Ashema and Tauret. Also of note is that it works perfectly with the HTL versions of the Mara, Pegasus, Herc 2, Perseus, Erinyes, Myrm, Serapis and Herc 1. (Basically all the fighters that have been HTLed so far)
As to the cob conversions - just tried it with a model I know works and then a cube glued to a light named detail0. PCS2 crashed on both of them.
-
[edit]nevermind[/edit]
-
please posts some COBs and their textures for me to play with
-
Here's the cube that fails (uses AWACTile1). Do you want the Lucifer COB as well? (most complex one I have handy)
I would attach it straight off, but I'm hesitant because the latest version of PCS1 stack-overflows on pretty much every complex SCN or COB I have. Even though the autofacet build converts them all without problems and try as I might I can't find anything wrong with the ones it's produced, I can't rule out that _something_ might still be wrong and PCS 1.3.6 (build 73) is just being more picky than the autofacet one.
[attachment deleted by admin]
-
Awww CRAP!
I read your post wrong... Since NUKEMOD dont have a vp I saw the word raw and figured it needed to be shown WHERE to search for the maps like ususal. DUH...
Nevermind, me iz stupid tonight (more than ususal)...
:lol:
Works fine can see the non-dds textures now...
-
I'm still unable to open any models. For instance, the retail Comm Node doesn't work for me.
-
fsck file wouldn't attach
here are the DLLs http://www.ferrium.org/media/stupid_mscv8_dlls.zip - put them in the same folder as PCS2
- PS the search path for textures is as follows
there is a list of directories in the Options->Preferences menu (default entry of c:\games\freespace2)
Search order is
VPs in the folders in that list
raw files in those folders + "\data\maps"
ie if your list is
c:\games\freespace2\
c:\games\the babylon project\
c:\games\wing commander saga\
it'll look for VPS in
c:\games\freespace2\
c:\games\the babylon project\
c:\games\wing commander saga\
and raw files in
c:\games\freespace2\data\maps\
c:\games\the babylon project\data\maps\
c:\games\wing commander saga\data\maps\
ok, i got it to display textures now. i was sorta confused about how the texture paths works. initially thought it wanted me to point to the directory with the textures rather than the mod directory.
i did find a problem when loading the dante. it had loaded once before i figured out the texture paths. but now that their configured properly it hangs when it tries to load the animated texture. so i swapped the animated texture with a pcx and it worked. rather than hanging it should just draw those surfaces as flat shaded.
found a minor bug in your render window projection code where the render window stops working when its w/h < 1. there also apears to be some minor warping too.
i didnt have the problem with the dll cause i have vc++ 6 installed. but having version 6 dlls, will that cause any problems?
il throw some nukemod cobs in a zip for you and post it in abit.
-
it shouldn't hang... when it encounters a texture it cannot read it should simply just not load it and move on
-
hmmmm will it only read from something\data\maps?
I've got the paths setup as is:
path0=c:\\games\\freespace2\\
path1=D:\\Program Files\\FreeSpace2\\scooby
path2=D:\\Program Files\\Wing Commander Saga Prologue
path3=D:\\Program Files\\FreeSpace2\\scooby\\modeldata\\maps
numpaths=4
The turrets which are located in path1 (d:\program files\freespace2\scooby\data\maps) load, however the ship texture in path3 don't.
btw should the escaped slashed \\ be outputted as it is instead of the correct "\" outside of C?
-
ok, i put up 3 models, with cobs, scns, converted pofs, and textures. the apis, the dante and the chimera. they all have alot of subobjects, both dante and apis have turrets. the chimera doesn't have turrets but it does have subobjects for submodel animation and a cockpit. the apis is the model i mentioned earlyer that has a few geometry problems which you can see in wireframe mode. its never given me any conversion problems and runs ingame pretty stable, so it could just as easily be a bug in the code.
models (http://www.game-warden.com/nukemod-cos/nukemod models.zip)
-
Anyone notice when you load a model and it's already onteh show textures option it shows up wireframe first?
Once you click another box and then back again the textures show up?
or is it just me? :D
-
Anyone notice when you load a model and it's already onteh show textures option it shows up wireframe first?
Once you click another box and then back again the textures show up?
or is it just me? :D
Nope textures still won't show. BTW theres a small bug with the rendering options, it selects the textured one while showing the wireframe model. Could this be the cause of the texture problem?
:D
-
texture/wireframe bug long time known, just haven't bothered to **** with it
thanks for the test data
yes it is correct for the slashes to be doubled in the .ini - it's something about wxFileConfig - don't ask me i didn't write it, i just use it.
i'm effecting a code change to make the search path be the following:
[path] (raw files)
[path]\data\maps (raw files)
[path] (VPs)
[path]\data\maps (VPs)
(the last one just makes the code change easier)
-
it's something about wxFileConfig - don't ask me i didn't write it, i just use it.
Good enough for me :D
i'm effecting a code change to make the search path be the following:
[path] (raw files)
[path]\data\maps (raw files)
[path] (VPs)
[path]\data\maps (VPs)
(the last one just makes the code change easier)
That should fix my complaint then :)
-
I tried on a different PC with Win XP SP2 and now it works. My PC at home on which it won't run, is SP1. So there seems to be something missing apart from those 3 DLLs.
-
cobra is using XP SP2 and can't run it - i know i've seen this error (or more correctly: one akin to it) before on systems i just don't remember how i ever fixed it
-
really sounds like some sort of missing dll error... but that's obvius.
-
maybe an XP bug? i get the same error as cobra on this and many of bob's programs. but PCS1 works like a charm, minus the lagging and hanging.
-
Well if there's lagging and hanging then I don't think it works as a charm, does it?
-
Actually, that info might be useful, as if it's happening with multiple programs, find out what's needed in common between all of them, and that might lead to the culprit. Takashi, which of Bobboau's programs are crashing?
-
I've got another idea.... again...
First off, question. the lastest pcs 1 build that supports gun normals, I can't get the pcs view window to have the normals actually move, their always pointing (0,0,1) even if i change the values. Is this normal?
Now the idea... Allow you create a dummy object (call it target point), a box will do, allow you to move it around, closer or further away from the model. Select a gun or guns, and have them autovector to that target. This will allow you to quickly setup auto convergence.
Heres a pic (Black is the ship, blue is the dummy target, green is the gun barrels, red are the vectored lines)
(http://img.photobucket.com/albums/v356/Shodan_AI/autoaim.jpg)
-
i think that ones on the todo list. its really just a matter of some really simple trig.
-
Actually, that info might be useful, as if it's happening with multiple programs, find out what's needed in common between all of them, and that might lead to the culprit. Takashi, which of Bobboau's programs are crashing?
aura, prox 1, prox 2. all are unzipped and consist of one .exe and several .dll's.
-
i'm currently busy with school.... i should have time to dedicate to dev again in a few weeks
-
In the meantime, was there a newer build of PCS1, that fixed certain things like the 100 turret handling limit?
-
umm... what ****ing 100 turret limit? that's not a pcs limit
-
Wait, I thought someone said it was limited in the gui not going past 100 objects or something. I swear someone else just mentioned that.
-
it's possible that it is.. i don't generally think of GUI limitations....
hmm..... it's definantly possible
just wait until PCS2
-
I know, I just thought someone had made a couple fixes to pcs1 that might hold some people over until pcs2 is ready.
-
umm... what ****ing 100 turret limit? that's not a pcs limit
I have noticed something with PCS with many multipart turrets (more than 30 some).
After PCS you'll get something like:
turret01
turret36-arm
turret02
turret02-arm
turret03
turret03-arm
....
turret36
radar
I don't know if the turret fire points are messed up, I didn't go beyond this point.
-
possibly an autoturret bug... but i'm not worried with PCS1 anymore - no major servicing will happen to it
-
Ya i don't expect that to get fixed, I'm sure it'll involve quite a bit of recoding.
-
Please put that manual object sorting feature in.
It would make my modder life a lot easier. ;)
-
what about auto-placement? its the sole reason i choose pcs over modelview.
-
Wait, you mean besides the fact that modelview is unstable as hell and eats memory like nobody's business? And that there are several other features that are simply not available in modeview?
-
or to sum it all up in a single phrase:
modelview sucks
-
no, it's prety good as a model viewer.
-
you forget were talking about the actual data editing capeabilities
-
Takashi, you said there was only one reason you use pcs instead of it, which makes it sound like you like the app. Then you turn right around and state that it's awful, as soon as someone points out the other problems with it. I wasn't talking about anything specific really, even as a model viewer it crashes on me, but your general statement about it sucking was not directed toward any specific abilities, but the program as a whole. Once again, speaking without thinking. Slow down, and think.
-
what happened to PCS2? is it already gone?
-
No... But if you searched for similar threads you'd see this has been quite long in the planning, initial stages. It's been close to 2 years now right? :p
Give it at least another year...
See unfortunately at some point Kazan went and got himself a life before checking with us... :lol:
-
NOOOOOOOOOOOOOOOO- wait; thats good right?
-
I remember hearing about Kazaan thinking about making PCS2 before I joined the board, so 2 sounds about right.
-
No... But if you searched for similar threads you'd see this has been quite long in the planning, initial stages. It's been close to 2 years now right? :p
Give it at least another year...
See unfortunately at some point Kazan went and got himself a life before checking with us... :lol:
What's a Life? ;7 :lol:
-
something which isn't always a good thing
i've been busy with coding for business software practices (puke) class
-
I'm in a similar situation.
-
Yeah, me too. Only my situation involves long naps and no coding to speak of.
-
Now THATS a life :D
-
im in an even better situation, in which im desperately tring to get my stupid handmade robot to do more than blink and thrash around. (science fair is harder than you think)
-
Well, if your robot making skills are equal to your current 3d skills... good luck on that task :P
-
toss cobs at this version http://ferrium.org/media/pcs2-alpha-20070507.zip (already tried all three the models that nuke posted)
-
it seems the converter multiplied my sobj positions. see pic.
note that this model converts perfectly under pcs1.
i seem to be getting the same effect on other models as well.
[attachment deleted by admin]
-
Same thing with the Loki SCN too - the cockpit was flung forwards in the same way about the same distance.
Looking good though. :)
-
that problem is solved in code now... right now i'm fretting over the long time it takes to calculate the smoothing data... it's... unacceptably long and it's do to having to repeat operations.... but there may be no easy way to avoid that
[edit]
i sped it up a bit with some result caching... let's see if i can improve further
-
second build for the day http://ferrium.org/media/pcs2-alpha-20070507b.zip
-
A Sketchup -->POF importer would be nice...
EDIT: Just tried it. It loads a .COB ok I guess (missing large chunks of the model), but the .SCN crashes it instantly.
-
wtf.. and no
[edit]
got a model from someone via pm - textureless polygons and models make PCS2 cry :D - just fixed it... but generally it should be avoided because textureless polygons have poorly defined behavior
-
Having a zoom all button would be good
-
Being able to zoom in/out with the mouse wheel would be even better.
-
Being able to zoom in/out with the mouse wheel would be even better.
Zoom all is a bit different. 1m object vs 5km+. A lot of zooming even with a mouse wheel (unless it goes logarithmic)
-
Well, a 'fit to viewscreen' option might be better, that way, regardless of the size of the object, you'll be able to get the best possible zoom for it?
-
it's already supposed to make a fair guess at that when the model is loaded
-
Am I to take it that I'm not getting bug reports about the COB loader because it's working right?
-
Or not many people are following this thread still. Maybe make a new one requesting testers.
-
Am I to take it that I'm not getting bug reports about the COB loader because it's working right?
well everything apears to work. thats a whole different thing from actually working. i havent tested the autogen features though, are they exactly the same as from pcs1?
-
yeah.. i copy pasted the code and just adapted it in.
with bugfixes :P
-
Quick question, what are the odds of PCS2 working on non-Windows platforms?
-
very good considering that was a design goal
-
:P
-
i have a problem.
PMF to COB conversion and materials - the problem is smoothing data. the PMF data stores the facet_angle defined by COB, so COB->PMF then right back again in that reguard isn't a problem.
POF->PMF->COB is... POF doesn't store the facet angle, it stores the normals. I either have to do a (VERY CPU INTENSIVE) guestimation routine on POF load and guess the angle..... or I have to output everything as either faceted or smoothed from a POF load...
thoughts?
-
export the angles too another file. IE: before you do COB --> PMF ask the user if he wants to export the facet data to a file. then when you ant to go PMF --> COB, ask the user for the file. if he doesn't have one, make everything faceted.
-
PMF stores it... POF doesn't.. there are POFs we don't have the COBs for (technically .3ds files.... since that's what V used)
-
What does that have to do w\ what I said? :wtf:
-
your suggestion doesn't address the problem :wtf:
-
OKAY, everywere I said PMF change it to POF.
-
i'm still kinda leaning against making them save another file - while it's CPU intensive, from the user standpoint it's still simplier (though potentially less accurate) for it to figure the facet angles by reverse-engineering
-
Why not have both? ask the user what he wants, let him decide. (yes I know thats alot more coding, I know.)
-
Why not have both? ask the user what he wants, let him decide. (yes I know thats alot more coding, I know.)
-
If the user has the facet-file to the POF, they must have had access to the original COB or PMF file. Why not provide an option to extract the angles from one of those, and if neither are available, guesstimate the normals?
It seems like if you're not going to implement autogeneration from the normals, you'll have trouble with all the old POF files that you don't have access to the faceting angle data for.
-
isn't that what I said? :wtf:
EDIT: never mind, I get it... use the models not the facet file...
-
if they have the original COB there is no point for them to load a POF in PCS2 and save it as a COB - if they have a PMF they don't need to...... looks like the only meaningful option is to perform the generation... but i think i'll make it an optional (checkbox) on POF loading
-
Any chance of a simplier turret naming layout? With less "turret0X" all over.
-
um, in POF's, is everything faceted or smooth or (smooth or faceted like in blender)?
-
in POFs there is no smoothing data at all, it's totally decomposed into surface normals.
in order for Kaz to find the angle he'd need to, for every polygon, find the angle between every normal on that polygon and the normals on every other polygon that shared that point, and then he'd only get a guess, a _range_ of values that _could_ have been used to generate those normals, he'd then probly have to do a **** ton of comparasons between polygons to try and find the fewest sets of angles that would fit into this range, it would probably be a good guess on very complex models, but I can almost garentee that you'd end up with totaly diferent groupings of polygons in the materials it generates.
now, we could cach the data in some extra chunck that would get ignored by FSO, or we could use a trick I've been itching to use for a while were we tack data to the end of a polygon, and just set the offset and size values of the subchuncks so this data exsists outside were FS would look, but still somewere easy to find.
but realisticly, the best option for now would probly be to check if a polygon is full-smooth, or flat, if it isn't either it's auto-faceted, and just use 32 as the angle (truespace's default) it'll probly be good enough most of the time.
oh, hey, kaz while you are tinkering with that code, there was something I wanted to try for a while, could you make it so that if the reflectance shader in the material used on a poly was 'translucency' then it would flip the lighting normals of that polygon? I think that could be used for some very neat efects.
-
oh, hey, kaz while you are tinkering with that code, there was something I wanted to try for a while, could you make it so that if the reflectance shader in the material used on a poly was 'translucency' then it would flip the lighting normals of that polygon? I think that could be used for some very neat efects.
lighting and collision normals are the same
-
but realisticly, the best option for now would probly be to check if a polygon is full-smooth, or flat, if it isn't either it's auto-faceted, and just use 32 as the angle (truespace's default) it'll probly be good enough most of the time.
so there are smooth polys in POF's? just full smooth and totally flat? (Like in blender?)
-
POFs have full shading - per-vertex normals so everything from faceted to full smooth and in between
-
you could just generate a normal map for models converted from pof to whatever. actually scratch that, it would just screw up on cap ships which use alot of tiling and thus shared uv space.
-
lighting and collision normals are the same
nope, the normal used for colision is the per poly normal, the vertex normals are used only for lighting.
-
but realisticly, the best option for now would probly be to check if a polygon is full-smooth, or flat, if it isn't either it's auto-faceted, and just use 32 as the angle (truespace's default) it'll probly be good enough most of the time.
so there are smooth polys in POF's? just full smooth and totally flat? (Like in blender?)
it would be easy to see if a poly was (past tense, ie in the cob) fullsmooth or full flat or somewere in between, it would not be easy to tell were in between it was cause polys do not have smoothing data.
if it was flat all vertex normals would be the same as the face normal, if it was full smooth the vertex normals would all be in the average kocation for the poly normals that use that vert, if some were the same as the poly and some were in the average locaton then that poly would be autofaceted.
-
some polies also have the capability to be neither - some vertices could be faceted while others are smoothed, but based upon the modeler's desire not an autoangle (atleast [V] models may be - i'm not sure of 3DS, or the [V] POF converter's, capabilities)
bob: i am thinking it may be time to define OBJ3
-
i know what i'll do - PCS2 nor FS2 needs to know the autosmooth data - both use the vertex normals for lighting.... when you go to save to .scn it'll do a full smoothing calculation and reverse engineer it - here is how I'll do it.
Make a list of all unique points present in the subobject mesh
Compile a list of all polygon normals for polygons sharing that point
iterate across all polygons and their verticies - check if all points no-smoothed, check if all points full-smoothed, calculate smoothing angle for all points - use smallest angle as autofacet angle (if a check succeeds, skip the rest).
Record result in PMF
write to SCN
that recording result in PMF is important - because then you can save the PMF and keep the smoothing data.
-
it might help things run a bit faster if (assumeing you simply didn't mention this cause it's sort of obvius) you worked on all polys that share a texture, and did one texture at a time, rather than all polies at once, it would reduce the complexity of the numerous comparisons.
-
it might help things run a bit faster if (assumeing you simply didn't mention this cause it's sort of obvius) you worked on all polys that share a texture, and did one texture at a time, rather than all polies at once, it would reduce the complexity of the numerous comparisons.
yeah.. but what if you want to smooth between those textures
-
well, the thing is, if they are diferent textures then you know they were diferent materials, and the auto-facet angles should be independent (though they will likely be the same, and they will also likely be 32)
-
true
-
I just thought of something, you could add into the options a check box for fast model loading, and if it's checked make sure the user know this means auto-faceting will be disabled. so if someone just want's to quickly import to screw around with a wip model, they can without haveing to wait through the blarg of auto-facet calculation.
-
Can I just throw in that an option import 3DSMax ASCII files would still be awesome. They have per-polygon smoothing groups stored in them and are relatively easy to parse.
Because all this work going into autofacet generation isn't really useful for models made in max.
Or alternatively, make a button that recalculates all the collision data for a loaded POF. That way we could fix those POFs that were generated with the Max exporter and now have holes in them.
-
Can I just throw in that an option import 3DSMax ASCII files would still be awesome. They have per-polygon smoothing groups stored in them and are relatively easy to parse.
format reference pls
Or alternatively, make a button that recalculates all the collision data for a loaded POF. That way we could fix those POFs that were generated with the Max exporter and now have holes in them.
the only reason that PCS2 doesn't already recreate the entire BSP tree already is it cache's the BSP - i can make a function to "Clear BSP cache" on a loaded model.
-
what did you use to edit main_panel.cpp?! it's line endings are corrupt!
[edit]
had to clean the file, remove it from CVS and readd it with a clean copy
-
I copied and pasted something that had some weird symbols (something from wikipedia, that's were I was doodleing with geodecics) but I removed all that, so I didn't think about it. that's all I could imagine would be the problem.
-
One thing I would definitely want is model rescale, where you can resize a model to a desired size and the program calculates the correct POF data by multiplying/dividing the original POF data by the scale factor.
-
if you change the geometry PCS will rebuild the affected subobject(s) completely not just hack the coordinates
-
if you change the geometry PCS will rebuild the affected subobject(s) completely not just hack the coordinates
Could you please elaborate for someone (me) who is not very familiar with modeling outside the features afforded by ModelView's editor?
-
if you change the geometry PCS will rebuild the affected subobject(s) completely not just hack the coordinates
Could you please elaborate for someone (me) who is not very familiar with modeling outside the features afforded by ModelView's editor?
well.. for starters modelview doesn't let you touch most of the data of a POF... PCS2 is a combination of PCS1's ability to edit EVERYTHING and modelview's ease of use (you should see a lot of influence from modelview in the interface i'd think).
PCS1 and Modelview when they load a file - it stays in POF-format in memory... this is not true for PCS2
all model files, once loaded into PCS2 are in a format known as PMF - PCS Model Format - it's PCS2's own personal format. So when you open a .cob/.scn it gets loaded by the COBHandler code, then converted to a PMF - when you load a POF the same is true.
PMF is flexible, easy to extend, easy to manipulate.
All of the data in a POF is easy to manipulate except one thing - the geometry - the geometry in a POF is stored in what is called a "Binary Space Partitioning Tree" - or BSP Tree. This is very useful for collision detection, and it used to be very useful for making rendering faster (pre-video cards having Hardware Transform Clipping and Lighting).
BSP trees are not easy, nor safe, to manipulate. It is not difficult however (in terms of CPU usage) to read the data out of this (As is done when converting the POF into a PMF) nor computationally very difficult to rebuild that tree.
When PCS2 loads a POF it cache's the BSP however - so if it doesn't have to make a new BSP tree for that geometry, it doesn't do so - (just to keep consistentcy.. don't need to recompile the BSP on [V] models.. their BSP compiler was even better than mine).
So it only rebuilds if you change the geomtry - and then only for the subobjects that the geometry changed on.
-
And how does this tie into my idea of changing a model's size and adjusting things like gunpoints and docking paths to fit?
-
And how does this tie into my idea of changing a model's size and adjusting things like gunpoints and docking paths to fit?
it requires rebuilding the BSP... PCS2 can easily do it... i was just saying it requires a BSP recompile (nothing major) when you write out the POF
-
OK, is the ability to rescale the geometry present in current builds of PCS2?
-
no, and it's a second phase feature, we haven't gotten all of the basic stuff done yet, that is geometry editing, that's a big huge feature on it's own.
-
so, any requests?
particularly any sort of feature that would automatically make some sort of data for you, or figure it out in some way.
-
did i make the subobject context rendering work (ala modelview style) or did you?
[edit]
oh.. i'm going to reintegrate BSP Sortnorm/boundbox debugging like was present in PCS1 (since it let me find so many errors)
here is how it works
when you load POF compiled with [V]'s BSPGEN, PCS1 of high enough version to have compiler 1.3.4, or a PCS2 build it "caches the bsp" - so it doesn't have to rebuild it unless you change the geometry.
when you save a file to POF it also cache's the results of the compilation (As of 20 seconds ago) - in either case "can_bsp_cache" is set to true.
in this case i need a button to become usable (a toggle button) "BSP Debug" and then i'll do a context render of the sortnorms and bound boxes
[edit]
I'd also like the UI To display the polycount of an object, and the polycount of all it's children summed, and the total of those two
-
I'll set a bool in the model to true, you can check that in the renderer, and either use the current active model or apply it to everything.
-
I'll set a bool in the model to true, you can check that in the renderer, and either use the current active model or apply it to everything.
kk - BSP debug will have the same context scoping as lods/models
oh... on that note - make child nodes of header for each LOD and we'll tie that into context rendering
-
oh, you mean like
header
+(LOD0-LOD4 and debris)
and we use that rather than the currently active model to determine which LOD to draw?
and PCS_Model::draw_bsp will be the flag for your BSP drawing, in addition there is an event BSP_RENDER_CHANGE which will get sent every time the check box is changed (use GetInt on the event for the value), although I doubt you'll need to use that.
-
Dragging one sub-object on to another seems to turn the target into a group heading. Instead of both being children of a new group.
What is the maximum poly count for sub-objects in pcs2? (when saving a pof) It seems the same as pcs1.
Once you get past the limit on a sub-object the file usually doesn't save past the 1 meg mark. If the offending sub-object is divided it saves fine.
Also would it be possible to have a drop box to set front, side, top etc view? Modelview has them down the side. ;)
-
What is the maximum poly count for sub-objects in pcs2? (when saving a pof) It seems the same as pcs1.
how much memory you have in your computer.
PCS1 and PCS2 do not have the same BSP compiler
PCS1 had a fixed destination buffer for the BSP data (4megs or so)
PCS2 builds a tree in memory and can calculate the buffer size from that.
PCS2's BSP compiler should also be more accurate... hence why it takes longer.
-
Go, go dynamic memory allocation.
-
Can I just throw in that an option import 3DSMax ASCII files would still be awesome. They have per-polygon smoothing groups stored in them and are relatively easy to parse.
format reference pls
I did send you a simple example file last time this was discussed. I can put it online when I get home later.
I don't think there's an official format reference document.
EDIT: Ok I've found something online. A reference for the ASE format on the UnrealWiki: http://www.unrealwiki.com/wiki/ASE_File_Format (http://www.unrealwiki.com/wiki/ASE_File_Format)
The interesting part with comments from the Unreal modders starts further down.
I may be repeating myself, but: If PCS2 would support ASE import it would be the ultimate modding tool, since ASE is an open format. Everbody could then write simple exporters for their favourite modeling tool.
-
hmmm ASE :D
i can get to that eventually..... if soemone wants to volunteer to code it now i'll add you to CVS repo :P
[edit]
oh bob.. if you need a fast and dirty draw a bounding box on the screen there is a function defined in pcs_pof_bspfuncs.h OpenGL_RenderBox(vector3d min, vector3d max) as of my next commit
-
hey bob.. can you change the checkboxes
split the "BSP debug" into "Sortnorms" and "Boundboxes" and add a checkbox for "Render children"
oh.. and i've discovered that PCS2 is outputting bad snorms and bboxes
-
well.. the BSP errors have been fixed.. curteousy for the BSP Debug tool (available when you load a POF, or after you save a file to POF)
(http://www.ferrium.org/media/pcs2_htlzeus_bspdebug.jpg)
oh.. and PCS2 can utilize multiple cores :D (POF Compilation on a Athlon 64 x2 AM2 4200+ using a debug build)
(http://www.ferrium.org/media/pcs2_htlzeus_cpuutil.jpg)
-
Hehehe, I'll have the fastest ship editor on the planet ;)
-
oh?
the reason why PCS2 can utilize multiple cores is because we use threads - the OS can then assign threads to whichever core they want.. if i wanted to be a masochist i could make it detect core count and concurrently compile multiple SOBJs independantly :D
[edit]new buil in buidls thread
-
Hehe, well, maybe not the fastest in the world but I'm still a little giddy from the Core2Duo ;)
Grabbed the new build, it was actually excellent timing, it saves me having to track down what CD the Descent Manager stuff is on :)
-
Am I not looking right or is there no left, right,top,bottom, front,back buttons for the view?
-
top hotbar
-
I see the rotates, but not those...
Also a more serious problem.... where are the subobjects X,Y,Z location values at? I need that value when making paths
-
to be displayed later
-
Ah ok... good. I'll have to copy and paste from PCS1 right now, but it's a lot easier to use than pcs1 is :cool:
-
the X axis is backwards in PCS1 (not in the resulting file... but in repsect to the standard directions it is)
-
In case you want to play around with ASE, here's a simple example. The standard Max teapot textured and with several smooth groups: Download (http://n.ethz.ch/student/ebuerli/download/teapot_ASE_example.rar)
(http://n.ethz.ch/student/ebuerli/download/teapot1.PNG)
-
the file specification would be most helpful.
also a file with a few cubes in a hierarchy would be nice.
-
I just remembered something that should be real easy to add to FSO if we had model support, the basic idea is we merge a submodel with it's parent, but we use a special BSP chunk to point to the geometry, this will allow detail boxes/spheres to work without incuring the multable subobject penalty.
the downside will be that the renderer in FSO will need to be modified considerably and use dynamic index buffers, and index data will need to be held in the poly data. might need to wait untill we define a new BSP spec. which will be much later.
-
OBJ3
-
Sorry if this has been suggested/implemented already, but will there be a direct .3DS or .LWO import? That'd be grand, if possible.
-
Sorry if this has been suggested/implemented already, but will there be a direct .3DS or .LWO import? That'd be grand, if possible.
no as those formats are superfluous with ASE support (and .3ds is pretty much undocumented)
-
the file specification would be most helpful.
also a file with a few cubes in a hierarchy would be nice.
See my post on the previous page for a link to the best format reference I could find.
I'll post another example with some hierarchy when I get home today.
EDIT: Ok here we go: A box with some boxes as children, which in turn have some children and so on. Also, some dummy helper points are attached to the smallest box.
Download here (http://n.ethz.ch/student/ebuerli/download/boxes_ASE.rar)
(http://n.ethz.ch/student/ebuerli/download/ASE_boxes.png)
-
if you do use .3ds, and i hate that format, keep in mind that there are so many bad implementations of that format used in other progs that a great deal of idiot proofing would need to be done to make it compatable with as many programs as possible.
-
I especially dislike the 8.3 filename format Max uses.
-
wee look at all that green!
-
I just realized that, while messing with a ship that had its center off to the side of the middle of the ship, that it would be really nice to change that. As in, change the actual coordinate center of the entire model, not just the center of mass. I realize that could be a very painful addition, as I imagine it would require recalculating every vertex coordinate, but, if it were possible, it would make it so much easier to add pof data, having it being symmetrical. Or, is the pof data based on the center of mass and not the center of the model?
-
I didn't read the thread to check if this had been requested, but is a grid possible? A labeled one?
-
I didn't read the thread to check if this had been requested, but is a grid possible? A labeled one?
Do you mean like which way X, Y and Z are?
If it is, then I've started work on some icons that should help - once i get a break from testing.
@Bobboau
Is it possible for Z lock to be greyed out when xy constrain button is active? So you will only be able to chose X or Y
And the same deal for the other constrain buttons. If so - I'll add greyed out icons.
-
Will these be suitable?
(http://homepages.paradise.net.nz/pcantwel/images/icons.gif)
-
well the movement constraint and projection options ones I like better, the axis lock ones look nice, but I think they are a bit confusing, for one thing the x,y, and z don't seem to be positioned in any particular way, and the little lock graphic sit's next to y all the time, as for texture controls... I'd just prefer sticking with cubes or other generic geometry.
-
I have officially adopted several of those BTW.
-
Here is another attempt at the axis locks - Since the grid is now in place the lock icons can be simpler.
(http://homepages.paradise.net.nz/pcantwel/images/icons2.gif)
And can the grid be set to grey ( the white may be too overpowering ) or just add another colour option setting?
-
I kinda like those texture control icons...the thing is it should be a FS ship, not some random one...like a Herc or perseus or Orion ;)
-
I kinda like those texture control icons...the thing is it should be a FS ship, not some random one...like a Herc or perseus or Orion ;)
Err.. you don't want to see my attempt at a Herc :ick:
@Bobboau
(pcs2.exe)
Using the 3 constrains and 2 locks is too much
Suggestion:
1: - get rid of the lock buttons. use left mouse for X, middle for Y and right for Z
or
2: - get rid of the lock buttons. left mouse for x, right for z and Y ends up being used on both.
or
3: - keep lock buttons. (eg - for xy constrain) clicking X will toggle Y off, clicking X again will unlock X and ungrey Y
The grid gets displayed for the model AND a smaller grid for the item you are editing. This makes finding the edited item (eye point etc) a bit hard since it is surrounded in grid. Maybe just keep the main grid. Part of the problem is that the default item placement is 0,0,0? so you need to switch to wireframe to find it. Any one using the grid may not find the item straight away. Or you could make the default normal 10 instead of 1. Maybe a fighter/capship toggle with cap ships set to 100 or something.
Also the texturless solid mode seems to use just black (no lighting), and on a black background... ;)
I think you will need to add three views for ortho mode - front view - side view - top view
Most people tend to switch to one of the ortho views for precision placement when modeling, and this would help a lot.
-
and another features turns green on the list (.cob save implemented)
-
Couple of requests and a question
1) A refresh or reload from file button on the toolbar.
2) (Reminder) A button to view/load the texture file (open in explorer default, custom PCS2 viewer, over the main 3d window, doesn't really matter)
3) A standard untextured view mesh colour (probably just grey). I can't tell how it decides on a colour currently, but on some models it's just way too dark to see.
Not quite sure if this is a bug, but currently there's no way to actually view the result of your texture changes without saving, and then reopening the model. Should there be an 'apply' button in the texture editor chunk maybe?
-
3) A standard untextured view mesh colour (probably just grey). I can't tell how it decides on a colour currently, but on some models it's just way too dark to see.
it's supposed to be grey.. i dunno wtf is going on but i have noticed the problem
-
I think it's using the texture map but no UV coords.
-
1) A refresh or reload from file button on the toolbar.
...button in the texture editor chunk maybe?
done, sig.
-
Texture reload works great, but I couldn't find a reload from file button on the toolbar?
Also, the reset view in the view drop down menu needs to trigger a redraw the window. :)
-
oh, I thought those were the same, you want a full model reload?
-
Yeah that'd be great thanks. It's not the kinda thing you'd think of as being particularly useful, but I quite often find myself using modviews one.
-
well the only reason I ever used modelview's reload model button was to reload textures or to check on changed I made to POF data, so it seemed a bit redundant here, but if you really want it I'll see what I can do.
-
I gave pcs2 to someone who hadn't done pof stuff before. Once he had the hang if it , he had no problems using it and getting models into the game. Four models pofed in two days. His only comment was about the views be settable to hot keys to make setup faster.
Nice work :yes:
If any of these are useful...
(http://homepages.paradise.net.nz/pcantwel/images/icons3.gif)
-
ok, I started messing around with an open-texture-externally button for textures, but I have hit a bit of a quandary, in terms of what I shall do when the texture loaded came from a VP.
Kazan, does PCS2's VP library have the capability to extract any given file from a VP into any given directory? that would be nice, I could extract to a temp directory and open from there, and I could add an extract to folder button in there too for any textures that are in a vp.
water, if you are feeling frisky, I could use a 'reload model' button a 'reload textures' button and a 'open texture externally' button the model button must be no more than 24x24 the other two can be slightly bigger or smaller, but must be the same size as each other.
-
Kazan, does PCS2's VP library have the capability to extract any given file from a VP into any given directory? that would be nice, I could extract to a temp directory and open from there, and I could add an extract to folder button in there too for any textures that are in a vp.
should be able to do whatever you want
it's util/VPReader.h
this function should do you
bool ReadFromVP(kaz_string vp, kaz_string filename, kaz_string destination)
{
VolitionPackfileReader VPR(vp);
int filenum = VPR.FindFile(filename);
if (filenum != -1)
{
char membuffer;
VPR.LoadFile(filenum, membuffer); // loadfile allocates the required size of memory
ofstream outfile(destination.c_str(), ios::out | ios::binary);
outfile.write(membuffer, VPR.FileSize(filenum));
outfile.close();
delete[] membuffer;
return true;
}
return false;
}
example call would be
ReadFromVP("c:\games\freespace2\sparky_fs2.vp", "bomber09.pof", "c:\games\freespace2\data\models\bomber09.pof")
[edit]
VolitionPackfileReader can also give you a handle to an open ifstream that is set to the right spot in the file to read the file - i can probably modify POF::LoadPOF() to be able to deal with this
-
excellent (http://warpstorm.com/community/Smileys/warpstorm/sid.gif)
-
just be aware that if you go to save a 400meg file that function will allocate 400megs.. so if you're going to be working with large files i'll need to make a function that reads in blocks
-
well... are there 400 meg files in any VPs? or do you mean 400 meg VPs?
-
individual files in a vp, and yes... movies can be that big
-
If any of these are useful...
(http://homepages.paradise.net.nz/pcantwel/images/icons3.gif)
did you make those?
-
I'm assuming he did.
are movies (MVE) in the VPs? or do you mean the ANIs.
which brings up a point, we need ANI/EFF support.
-
.mve's were unvp'ed on the disk
there is a vp floating around with all the movies in .ogg
-
oh, well I don't plan on using it for anything but extracting the <250k PCX and maybe a handful of larger ANI files.
-
hey bob.. i just notied the turret editor is lacking the ability to select gun or missile turret
-
well that's ok, cause there the same, they get filled into the same array in FSO, with no way of telling which they were originally, though I suppose I should make sure they get merged to support the V models that have them differentiated.
literaly
case ID_TMIS:
case ID_TGUN:
{
//add turrets here
}
-
did i forget to have it mark which type they were in the POF? oops
[edit]
oh.. no i didn't... just FS2 doesn't care anymore - a turret is a turret is a turret
-
it never did.
well maybe FS1, but that's not important now.
-
i could have sworn i once had problems with FS2 refusing to treat a turret as a missile turret for me because it was a gun turret
-
I was shocked when I first saw it, even though I knew it treated them the same, I figured it would have SOME difference, but nope they both go through the exact same code.
-
ok, I've been fighting with wxExecute and more specificaly wxFileType::GetOpenCommand for the last few hours, and I just give up, win32 solution done, we'll figure something else out later. in the texture editor, there is now another button for opening the file externally.
it only works for files not in VPs currently.
it's in my sig.
also make sure I didn't screw up anything when I migrated the new BSP compiler.
-
please commit top_level_selected.xpm to the respository
-
oops
should be fixed now.
I took a look at getting glow and shine mapping implemented, and we will need version 1.3 if we are to have a decent implementation.
-
i can import a library that will grab all openGL functions, not just the ones in the microsoft headers but it'll make SDL a dependancy
-
I think that will be acceptable.
though it would be nice if that wasn't necessary, but I guess it is...
it doesn't NEED to be 2.0, it would be nice though, I'm not planing on using any 2.0 features, though I might need something >1.3 at some point, and I might find a use for something from 2.0 later.
-
The PCS2 Doesn't Export to scn.Will it?
-
yes he's working on that as we speak
-
Also The Textures are like Grey.No color just Grey.Is that supposed to be like that?
-
sounds like it isn't finding the textures, make sure you have the texture paths set in the options, you might want to include the working directory .\
-
Nope its not that, because its at my Fs2 Directory as 1 and 2 is Maps.It does this on shivan ships mostly.
-
yes he's working on that as we speak
nah i gave up on .scn because it requires a bunch of useless extranious data that i don't know how to setup
-
did you make those?
yup - Those are the easy ones. The information icons I'm finding a lot harder.
It's only a very minor bug, but the tool tips for the icons struggle to display over the model render window.
-
we have that in mantis, it seems we can have them render properly of have the GL canvas refresh when they are gone but not both.
-
So maybe put a little extra toolbar grayspace between the buttons and the render window.
-
I could use a 'reload model' button a 'reload textures' button and a 'open texture externally' button the model button must be no more than 24x24 the other two can be slightly bigger or smaller, but must be the same size as each other.
Ok the model reload will be for the main bar (24x24)
The other two will be for the texture tab (bit larger)
I'll see what I can do.
-
yeah
-
i'm going to go ahead and add the SLDC chunk
[edit]
and.. it's been added
-
This is a small thing, but would it be possible to express MOI data in exponential notation? I worry that it's always 0 in the interface because of the values being so small that they don't make the least-significant digit.
-
it's always 0 in the interface because it's not being calculated
-
That doesn't mean it's not getting displayed. Currently the only way I can tell something nonzero is in there is because some of the entries are negative 0. It would be nice to be able to check whether a model has it or not by the display (and once it is calculated, this will be important). MoI values typically fall in to the 10^-11 to 10^-13 range of values, so it needs to be in exponential notation even if it's just there to look at.
-
How come when i Import something it doesnt show up?What i want tp Import-(http://img115.imageshack.us/img115/3786/bcvj5.th.jpg) (http://img115.imageshack.us/my.php?image=bcvj5.jpg)
-
are you following hierarchy rules?
-
What is that? :shaking:
-
i'll take that as a no.
http://underworld.fortunecity.com/pacman/106/fs2mods/shipcreationguide/creatingyourmodelusingts.html#groups
-
Well what are they? :blah:
-
i linked you one of the tutorials
-
I know I asked it before, but - any idea when .asc will be implemented? :) (That was the new format, right?)
-
for the 10th ****ing time it's a 2.1 feature (.ase)
-
How come when i Import something it doesnt show up?What i want tp Import-(http://img115.imageshack.us/img115/3786/bcvj5.th.jpg) (http://img115.imageshack.us/my.php?image=bcvj5.jpg)
are you making a starcraft mod?
-
No i just found that on Scifi-Meshes.com.I have to really lower it from 500k polys to 50-100k polys.300k polys as of now. :P
-
Everything for 2.0 is green now.. RC1 builds have started http://www.hard-light.net/forums/index.php/topic,50099.new.html
-
Couple things I'd like to see, both could be done once the bsp is constructed.
First since any angle turrets are now possible once again. How about optional (assume straight up or down otherwise) three light points for each turret, named: CENTER, TOP, FRONT. Have these attached to the base of the turret, actual location relative to the model is irreleveant. From those you should be able to generate a top and front vector, which needs to be added to the subobjects properties. I'm sure theres quite a few guys that'll love this feature, myself included.
Second, I mentioned this long time ago. But could it be possible to have a second style for turrets.
instead of:
turret01
base
turret01-arm
arms
turret01-fp-01
turret01-fp-02
turret01-fp-03
have something much simplier:
turret01
base
Barrel
arms
fp-01
fp-02
fp-03
that way when you need to place a dozen or so turrets of the same style (copy and duplicate), you don't have to go through the laborish task of renumbering everything.
-
probably don't need another light to generate those vectors, i can probably do it from the orientation of the subobject
-
If you know the math how to convert angles to vectors, I bow down to you then. LOL
-
it's stored in the model as vectors.. but angles to vectors is easy.. vectors to angles is hard
-
hopefully this will be handled transparently, given how I want to make a subobject chunk with the orientation matrix as an integrated data member. you'll probably never need to deal with this directly (that is the whole adding stuff to the subobject properties thing) once we get everything sorted out.
BTW I should become active again sometime in December, my classes and work seem to be working together to all jump me and kick my ass as a cohesive force, I'm in a lul for the next day or two, but by monday it'll all start up again, fortunately work seems to be giving me a slightly lighter load next week, but the week after is going to be ****ing ****.
-
The last ew things I converted with PCS2 has abysmal colision detection/bounding boxes.
The new Galaxy I just converted has no collision at all (expect for hangarbay01)..the Duat I converted before had the same problem. :hopping:
-
There is a severe bug with bounding boxes which causes models to crash or produce other errors. I've opened an issue in Mantis.
-
There is a severe bug with bounding boxes which causes models to crash or produce other errors. I've opened an issue in Mantis.
Maybe thats where my problems are coming from to.
-
Hooray! Let's hope it gets fix0red soon. I'm tired of re-converting the same ship 10 times in a row, hopeing it will turn out allright :(
-
the 12th is when my chunk of free time should start.
-
this week is dead week and next week is exams.. after that i should be able to dedicate some time to working on pcs2 and other projects around here
-
nasty BBOX bug fixed, new item (side-facing turrets) added to 2.1 roadmap
start filing requests for 2.1/2.2 features - soon as the current batch of issues in mantis are fixed i'm going RC2 which is mostly going to be concerned with multi-platform compatibility (linux, mac os/x if we can get taylor's help)
-
I am working on it right now, I am fiddling with some BSP stuff, and I think I got that old geometry filter working properly.
[edit]OH looks like someone found a UI bug!/*jumps on it*/[/edit]
-
ok, I think I fixed the subobject deletion bug, but I'd like confirmation on that.
also you might want to through really nasty geometry at my sig build and see how well it handles it, I have enabled the new geometry filter, it should be able to handle concave geometry now. though it's well within possibility there are certain cases I didn't cover. think of it as a game, just bool a bunch of stuff together that you know should not even attempt to be converted and see how well it does.
it only works during COB importation BTW.
-
Remember the old 'You forgot to group those objects!' message? Well it doesn't say anything now - it pretends it converted the model (ie, says it's open in the title bar), but shows nothing in the window.
Also, due to the large number of people who came onto the boards asking about that error over the years, it'd probably be a very good idea to make that error more descriptive - it'd save a lot of hassle for newbies. :)
Currently doing the stress test thing again with seriously screwed up models. No crashes thus far, so I'll be making them worse next. :D
Edit: Ok, I think I might switch to blender to manually make messy geometry - I keep killing truespace...... surprise surprise.....
-
Well that was good fun, but we'll have to call it a draw. I finally managed a mesh that fails to save as POF. It imported from cob ok, but seems to be in an infinite loop during POF save. (It *might* still be going - so I'll leave it running for a while longer)
I've made an 8277 poly monstrosity of an object - packed with many editions of every type of geometry error I can think of, along with some I can't.
This is the abomination in blender:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/PCS2/MonstrosityInBlender.jpg)
This is the abomination in PCS2:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/PCS2/MonstrosityInPCS2.jpg)
And this is the abomination in TS:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/PCS2/MonstrosityInTS6.jpg)
-
now that is one bad model :eek2:
-
well the thing I was testing was only active on the import, and so long as it seemed to render properly then I guess it worked.
-
by the way, I also made a minor tweak to the bbox code in the BSP tree to make them a little tighter, make sure I didn't make them too tight.
-
speaking of bboxes... one of us needs to make the engine support SLDC - i'll do it, but di you have any idea where i should look to get started
-
that's the shield collision stuff right?
once you have all the setup done, mc_check_shield would be were the fun would happen.
-
did you ever find the cause of that weird floating point math error
-
which one?
-
the only one i knew about was where several of the bounding variables for BSP split recursion because floating point error sentinel values
-
do you have some changes not in trunk, like a MOI calculator or something? because i'm seeing more and more models that spin waay easily under weapons fire.
-
are you talking about the "infinite recursion because the bbox gets so small in one direction that floating point rounding error becomes more significant than the actual box" bug?
because that's just floating error, it's just a matter of there only being so much space to describe how small of a number we are dealing with.
and I have a few fairly minor changes not related in the slightest to MOI, mostly bug fixes and BSP bbox tweaks. from my last confrontation with the MOI I determined that there probably was no way to calculate it like V did, because there seemed to be no strong relation with the V MOI settings and known MOI values for simple objects (i.e. I used the MOI for a cube on the one cargo container that is almost a featureless cube couldn't figure out how they came to there numbers)
-
maybe you should try to get ahold of daveb
i would, but he still refuses to talk to me
-
I actually doubt he'd know, he wasn't the one in charge of physics, I remember him talking about the guy who was, and he was described as a walking physics book, and this is a very specific bit of code, it would require looking directly at the pertenant section of the BSPGEN code, assuming it still exists is most likely on a CD or tape (not garenteed to be in good condition) in a storage building someware in the Champaign-Urbana area of Illinois.
-
This (http://web.archive.org/web/20040323080313/www.freespace-2.com/ddn/sources/cob2fs/) doesn't help any does it? I'm guessing you already have it, or know of it, but I just thought I would check. It's not BSPGEN, but it might still have something useful.
-
This (http://web.archive.org/web/20040323080313/www.freespace-2.com/ddn/sources/cob2fs/) doesn't help any does it? I'm guessing you already have it, or know of it, but I just thought I would check. It's not BSPGEN, but it might still have something useful.
in a word: no
in a sentance: PCS1's compiler is a descendant of a descendant of that very extremely ungodly buggy code
-
the point was we won't know how it was coded unless we look at the original V code, that is not V code.
BTW, testers, how is the whole colision hole issue in the most recent builds?
-
the point was we won't know how it was coded unless we look at the original V code, that is not V code.
Is the MOI different between FS1 and FS2?
-
god I hope not.
but what was posted wasn't based on V code, it was reverse engineered like most everything else POF related, Garry Knudson didn't have any better an idea how MOI worked than we did, and I think he just left all the fields 0 like PCS1 did, which is probably the worst thing to have done, given how MOI is an inverse tensor or something like that, which would indicate the best default would have been an identity matrix.
-
god I hope not.
but what was posted wasn't based on V code, it was reverse engineered like most everything else POF
So cob2fs - was reverse engineered?
Edit: Ah.. just seen the author name
-
On the topic of MOI, I think that spinny problem *might* be that PCS2 doesn't have enough precision for the data. Modview was previously our only other place to edit the MOI, and it had 20 decimal places for each value. PCS2 only goes to 6, and so almost no MOI values of canon ships show up on it at all.
Anyway, if you can't work out how to correctly calculate it, why not just give it a good approximation? I mean all we currently do is pick a canon ship that most closely matches our new one in size and copy its MOI data in modview. Could we have PCS2 do that for us with a little built in library of a couple of ship sizes?
For example:
A juggernought with a radius from 3000 up (Colossus - 5483m radius):
0.00000000000001973413 | 0.00000000000000000606 | -0.00000000000000001896
0.00000000000000000606 | 0.00000000000001984870 | 0.00000000000000000781
-0.00000000000000001896 | 0.00000000000000000781 | 0.00000000000002875930
A destroyer with a radius between 600 - 3000 (Orion - 1225m radius):
0.00000000000165083106 | -0.00000000000001438860 | -0.00000000000026603408
-0.00000000000001438860 | 0.00000000000165699637 | -0.00000000000022210571
-0.00000000000026603408 | -0.00000000000022210571 | 0.00000000001239813287
Corvette with a radius between 300 - 600 (Deimos - 407m radius)
0.00000000011426040669 | 0.00000000000002944536 | 0.00000000000061950223
0.00000000000002944536 | 0.00000000011964380875 | -0.00000000003169709981
0.00000000000061950223 | -0.00000000003169709981 | 0.00000000079098005923
Cruiser with a radius between 60 - 300 (Fenris- 134m radius)
0.00000000702210023462 | 0.00000000000789263706 | 0.00000000009395786232
0.00000000000789263793 | 0.00000000719166104446 | 0.00000000027791779988
0.00000000009395786232 | 0.00000000027791777213 | 0.00000004418388854788
Bomber with a radius between 20 - 60 (Ursa - 33m radius)
0.00000693813490215689 | 0.00000001177944142228 | 0.00000023917166913634
0.00000001177944142228 | 0.00000506669584865449 | -0.00000013753013661244
0.00000023917169755805 | -0.00000013753012240159 | 0.00001044297096086666
Fighter with a radius between 0 - 20 (Herc1- 14m radius)
0.00022375727712642401 | 0.00000118694310913270 | -0.00000074683151751742
0.00000118694310913270 | 0.00014142904547043145 | -0.00000104222328900505
-0.00000074683146067400 | -0.00000104222328900505 | 0.00019945905660279095
Then all PCS2 would need to do is pick which one was closest to the current model being converted, and copy the appropriate data in, because really only 2 things are important with MOI in the following order: 1) Not having ships go crazy spinning and 2) allowing small ships like fighters and bombers to rotate a bit when hit away from the centre. No-one is ever going to notice if such an approximation system is a bit out. :)
-
because MOI is determined by distribution of mass, not radius, you aren't suposed to just be picking one that is the same size, but also one that matches the shape
-
anyway I was in the process of posting this when I had to respond to that, this (http://en.wikipedia.org/wiki/List_of_moment_of_inertia_tensors) is a list of common MOI tensors, take note of the one for a cuboid. now open up cargo01.pof (make sure to use the 29 poly V original), note that asside from one of the corners being cliped, and some campering on the edges, it is roughly a cubiod so it's MOI should be reasonably close to that of a cubiod. (this is THE ONLY REAON this approximation works FOR THIS MODEL ONLY) now first off, going by the wikipedia reference the products of inertia (the three in the upper right and lower left) should all be zero, they are pretty small so it could be from that missing corner.
the moments though should be about
6705.95 (xx), 6656.01 (yy), and 4017.99 (zz)
when in reality they are
0.000168 (xx), 0.000160 (yy), 0.000286 (zz)
now I remember the first time I did this I noticed that if I divided 1 by each of the top numbers I'd get something very close to the bottom number (it's suposed to be an inverse, but this isn't how inverse matricies work, but what ever). I was thinking this was it, I'd just make a MOI and invert each of the elements, but when you examine other objects it doesn't work this way. even worse, if the products are suposed to be inverted then they should be humongous numbers, because they are suposed to be close to zero. acording to mathematica the proper inverse matrix for this MOI (inverse of an inverse, so it should match what wikipedia gives) it should be
{{5953.27, 74.4565, 1.30169}
, {74.4565, 6254.35, 109.342}
, {1.30169, 109.342, 3498.42}}
now the moments (the numbers along the diaganal line running from upper left to lower right) are sort of within reason, but the products are defenately not zero, I suppose in the grand scheme of things maybe they are close to it, but I'm still not sure if it's due to a small amount of error in my approximation or a major difference in the algorithm, it's also possible the V code was a loose approximation.
-
since I'm thinking about this again, in theory the MOI should be findable, for all closed meshes, by makeing a grid in the xz plane, then for each cell of the grid running a line through the middle, any colision with the model will have a multiple of two colisions, an entry and an exit, each of these should be considered a pair, for each pair you will now have enough information to define a volume that approximates the object's shape in that xz cell, that is you will have an x and z coordinate with some number of collision pairs wich will represent a cuboid volume that the object more or less occupies, so for each pair you will have a cuboid centered at an x/z position (X and Z) with a x/z width (xw and zw) and a y value between the two ends of each collision pair (Y==bottom dy==top-bottom). you can find the MOI tensor for this cuboid with the formula:
{
{4/3*dy*xw*zw*(3*dy*Y+dy^2+zw^2+3*Y^2+12*Z^2), -4*dy*xw*zw*X*(dy+2Y), -16*dy*xw*zw*X*Z}
,{-4*dy*xw*zw*X*(dy+2Y), 4/3*dy*xw*zw*(xw^2+zw^2+12*X^2+12*Z^2), -4*dy*xw*zw*Z*(dy+2Y)}
,{-16*dy*xw*zw*X*Z, -4*dy*xw*zw*Z*(dy+2Y), 4/3*dy*xw*zw*(3*dy*Y+dy^2+xw^2+12*X^2+3Y^2)}
}
add that up for all cells, multiply by the mass, done.
my best guess is you would then have to invert that to get the MOI FS wants
-
Well if that works and you think it'd be better overall, sure use that.
I know MOI is based on the distribution of mass, but the point I was making is that it barely has any effect on the gameplay, so a rough approximation is really all that's needed. I mean would you really notice even under calm conditions if the ship you shot rotated 10 degrees when mathematically it should have rotated 15? As neat as it would be to have an accurate MOI calculation, in a game engine like FSO I just can't see it being terribly important.
-
no but you might notice if you hit a flat wide object on the outside of it's wing it started spinning realy realy fast, which is what would happen if you took the MOI of say a Ulysses (wide and flat) and repllaced with the MOI of a Valkyrie (long and thin)
the distribution is key and makes a humangus difference, if you hit a ship in a place where the MOI was calculated with no mass existing there, it might cause the hit to impart more momentum than the shot had to begin with, which would cause the object to spin violently out of controle, which is the problem we are all familiar with.
-
Just tried putting an Erinyes MOI into an Ulysses - the two most different shapes in the same class I could think of, and hitting it with a morning star on the ends of the wings. I then tried with regular Uly MOI. I was watching quite carefully, and I couldn't see any difference between them. You would need radically different shapes and a gun with a powerful kinetic effect to be able to notice any significant difference, let alone problem.
I suspect the spinning that people have reported in capships recently is due to the less precise PCS2 MOI fields. If you look at the data I posted above, PCS2's editor is completely unable to display anything above cruiser level. So, if you even click on the MOI data of a canon capship, PCS2 will overwrite whatever values it couldn't display with 0. As such, if you open a canon ship and even just click in any of the MOI fields during your edit, you erase the lot. This is the kind of MOI problem that is going to be a lot more noticable than different shapes of ships. ;)
-
very well, scientific notation for you, should give you all the precision you need. uploading now.
-
Cool, thanks. :)
-
I don't think I got an answer in terms of the collision hole issue on current builds.
-
I checked it. Seems amazing. The BSP data is SO much nicer than it used to be, much cleaner looking. All fits within the proper boundaries, I can't have asked for more. I've been shooting and ramming ships, haven't found any holes yet. Seems good to me.
-
this is good does anyone else have good or bad news to report (keep in mind this is the biggest issue we need to resolve before we can get a 1.0 release)
-
Ok, here's an issue. I was going through the models and redoing the BSP data on all of them. First of all, the auto-detect and regenerate function doesn't seem to work very well. I was having to manually purge the BSP cache and then save the model again to get it to regenerate it. On top of that, any models initially imported with PCS2 weren't regenerating even after that. I had to delete the comment AND purge BSP to get them to successfully create BSP data. I'm not sure what it was about that which made it work, but I'm glad to say that every model I've tried this method with has successfully created a BSP, even known broken models. And the BSP isn't crazy ****tons of polies per node either.
-
ok, so I implemented my proposed MOI calculator, it isn't very good but it seems to be withing a few orders of magnitude of what V had, I'm not sure if this is because mine is more accurate than theres or if I totally missed some huge important obscure thing I have no hope in hell of guessing, I'll let people test it and see how well it does before having it on by default in COB import
-
Ok well that was way way faster than I'd been expecting. Well done crazy coder person. ;)
It does seem a fair way out from the [v] ones, but I doubt that's gonna be much of a problem considering how all over the place [v] ones are already. I mean, there are some fairly big diffs between the artimus and the artimus DH in terms of MOI, but model wise the difference is one fin.
In a while I'll test it on the uly with the morning star again and see if any problems arise. :)
-
please commit your changes to CVS bob... i didn't get commit emails and nothing on cvs update
chief1983: weird.. without BSP cache it should be forcing recompile as there is no BSP.. i'll check into the BSP caching related logic
oh.. builds released that are CVS up to date should be ignoring cached BSP from previous builds as I upped the compiler version number
-
ok, committed it, honestly I probably should have committed before I started tinkering with the MOI thing.
so reports on MOI behavior, make sure to test big ships as well as small.
-
ok, so I implemented my proposed MOI calculator, it isn't very good but it seems to be withing a few orders of magnitude of what V had, I'm not sure if this is because mine is more accurate than theres or if I totally missed some huge important obscure thing I have no hope in hell of guessing, I'll let people test it and see how well it does before having it on by default in COB import
Earlier you mentioned, that :v: could have used an inverse matrix for MOI, have you tried generating that yet?
(Last thing I recall, was an approximation using the inverse of the elements of your original MOI matrix).
I read up on a bit, and the method Gaussian elimination turned up, which if I recalled nominally is used to solve multi factor linear equations; and is so liked because it can be turned into a finite algorythm. (All I wrote so far is theory, I haven't tried any of this beside calculating some matrices on paper a year ago).
Hmm, this is from the Wikipedia article:
"Matrix inverses in real-time simulations
Matrix inversion plays a significant role in computer graphics, particularly in 3D graphics rendering and 3D simulations. Examples include screen-to-world ray casting, world-to-subspace-to-world object transformations, and physical simulations. The problem is usually the numerical complexity of calculating the inverses of 3×3 and 4×4 matrices. Compared to matrix multiplication or creation of rotation matrices, matrix inversion is several orders of magnitude slower. There are existing solutions which use hand-crafted assembly language routines and SIMD processor extensions (SSE, SSE2, Altivec) that address this problem and which achieve a performance improvement of as much as five times."
http://en.wikipedia.org/wiki/Inverse_matrix
-
yeah, like I said, I implemented the algorithm I described. calculate MOI tensor, invert it.
-
Well I don't know if this can considered a feature request, a needed tweak or just a nonsense ;)
Please check Mantis report 1556 (http://scp.indiegames.us/mantis/view.php?id=1556) about an issue with new MediaVps 3.6.10 beta Shivan comm node.
Basically, and comparing with retail one (from sparky_fs2.vp), it seems to be some kind of enter code between $special=subsystem and $name=Core in Special Points ($core) > Properties text box.
This enter code is invisible, (both models look just the same in PCS2 RC1), and I don't know how to insert it:
- If I press enter, focus goes to Position. Shift+Enter or Ctrl+Enter are the same. Alt+Enter doesn't do anything.
- If I copy the property from retail comm and paste it in mediavps one, only $special=subsystem is pasted
So:
- Would it be possible to convert Properties into a multi text box where that strange Enter code would be clearly visible and editable as a common line break?
- If that's not possible, could you add a [Enter] button or something like that which adds that code in the text?
-
properties are already a multiline isn't it?
if not it's trivial to make it multiline - and it's probably a standard two character windows \r\n carage return+new line
-
Either I'm really dumb, (never discard that possibility), or Properties is not multiline at all.
OK, I would really love your tech explanation about "windows \r\n carage return+new line" if I had understood it :wtf: :wtf: But, how do I insert that thing in the middle of the text?
-
you can't without a multiline edit box... it should be trivial enough to change
-
special point properties is not multi-line, and honestly I had never considered it, the only things I've ever seen in it was the subsystem thing and split, I didn't realize (and none of any of the other coders who have worked on POF editors for the last ten years have either) there could be anything else there.
I'll look into this and if your right I'll fix it.
-
wow, it is, heh... fix committed
-
Could you post a new RC build please?
-
Just a quick request - could one of you stick in a 'Length' 'Width' and 'Height' measure for the open pof in both the header and subobject pannels? (ie, for the model as a whole and the currently selected subobject) I know we get the bounding box min and max positions, and so can work it out through pre-school math, but it's just so much nicer to be able to get that info at a glance. :)
-
I guess I could do that, just as a read only display, though I try to minimise things like that so things don't get too cluttered.
-
uploading a new build that has a number of small improvements and one big one I redid the way subobjects are drawn to take advantage of vertex buffers as best I could (don't know what the hell kaz was thinking when he decided to define geometry as a bunch of vertex arrays, as opposed to a single vertex array with a bunch of index arrays but that's going to have to wait until post 1.0) so all the htl models should render smooth as silk now. this turned out to be a much bigger pain in the ass than I was expecting it to be, but I got it done in not too huge an amount of time.
I'm expecting some compatibility issues, so tell me if it doesn't work.
I might be tempted to implement some sort of real render of thruster/glow point effects, I'll need to figure out how that'll work with the current omnipoint code (probably just leave it to people to turn the colors down real dark)
-
what the hell i was doing was making it easily editable for future geometry/uv manipulation.
make sure you put a hook in to allow other parts of the code to force a rebuild of the VBO
and since we're making VBOs can you see if you can make it generate .ibx files to go with the POFs
[edit]
oh.. and not using VBO's = less coding work (it's only one model, we don't need the performance advantage of VBOs) + more compatible
-
Major display glitches with the changes Bob;
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/PCS2/ScrewedUVs1.jpg)
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/PCS2/ScrewedUVs2.jpg)
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/PCS2/ScrewedUVs3.jpg)
Small ships like the uly and dragon etc seem to be largely unaffected, so it's not a global thing. It might be something to do with subobjects?
-
well that is very very weird, because some of those ther the very models I spent a lot of time testing with.
looks like UV coordinates are getting borked in a very peculiar way, it's especaly weird how the glowmaps are working but the base map is messed up.
-
gees you make the tinniest of mistakes and OGL rips your guts out, found what was causing that, I made one extremely small mistake right before I compiled/uploaded, I am now uploading a new version. that should have that fixed, it was literally one line.
-
Awesome, yeah that fixed it. :) And wow - the renderer really is a lot faster. Sweet. :D
Also, one other thing - in PCS1 in the paths tab there was a 'Turret' section where you specified turrets and then the subobject number of that turret in the object list.
As far as I know it has absolutely no effect in-game, but any models that do have a turret defined cause a non-fatal 'Warning: Couldn't fix up turret indices in spline path.....' message upon load into fred.
This stuff wasn't included in the PCS2 path editor so I assume you are aware of it already, but would it be possible to get PCS2 to remove any data on existing pofs in that field upon save? So rather than going through all the problem [v] ships one by one in PCS1 manually removing any defined turrets, we could just open and save them in PCS2. :)
-
Well, with the newest build texture location is not shown. (The magenta triangle outlines are missing).
Also when you select a model, that piece isn't outlined either. I think you should revise general rendering...
-
OTOH, I think there's something wrong with PCS.
Because of the Shivan Comm Node Mantis report I've run FS debug three times. I've just started the game and gone to F3 lab, then I've selected Shivan Comm Node LOD0 and I've exited (actually the game crashes because of a unknown known bug which Taylor knows about). Then I've read fs2_open.log.
When I use retail (from sparky_fs2.vp) Comm2s-01.pof I get the following warnings:
Warning: Ignoring unrecognized subsystem piece1a, believed to be in ship Comm2S-01.pof
Warning: Ignoring unrecognized subsystem piece2a, believed to be in ship Comm2S-01.pof
Warning: Ignoring unrecognized subsystem piece3a, believed to be in ship Comm2S-01.pof
Warning: Ignoring unrecognized subsystem piece4a, believed to be in ship Comm2S-01.pof
Warning: Ignoring unrecognized subsystem piece5a, believed to be in ship Comm2S-01.pof
Warning: Ignoring unrecognized subsystem core, believed to be in ship Comm2S-01.pof
When I use new Mediavps 3.6.10. Comm2s-01.pof:
Warning: Ignoring unrecognized subsystem piece1a, believed to be in ship Comm2S-01.pof
Warning: Ignoring unrecognized subsystem piece2a, believed to be in ship Comm2S-01.pof
Warning: Ignoring unrecognized subsystem piece3a, believed to be in ship Comm2S-01.pof
Warning: Ignoring unrecognized subsystem piece4a, believed to be in ship Comm2S-01.pof
Warning: Ignoring unrecognized subsystem piece5a, believed to be in ship Comm2S-01.pof
See how subsystem core one is missing probably due to the Mantised issue, as core isn't likely a valid subsystem. The Mantised in-game warnings aren't shown when you just open the model in F3 Lab.
Then I open Mediavps 3.6.10. Comm2s-01.pof with PCS 2 (your latest build from 0112 at 22:50), I insert an Enter in the middle of the conflictive line and I save. Then I get:
WARNING: "Inverted bounding box on submodel 'debris01' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'debris02' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'debris07' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'debris03' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'debris04' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'debris05' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'debris06' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'shcomma' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'piece1a' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
Warning: Ignoring unrecognized subsystem piece1a, believed to be in ship Comm2S-01.pof
WARNING: "Inverted bounding box on submodel 'piece1a-destroyed' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'piece2a' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
Warning: Ignoring unrecognized subsystem piece2a, believed to be in ship Comm2S-01.pof
WARNING: "Inverted bounding box on submodel 'piece3a' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
Warning: Ignoring unrecognized subsystem piece3a, believed to be in ship Comm2S-01.pof
WARNING: "Inverted bounding box on submodel 'piece3a-destroyed' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'piece4a' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
Warning: Ignoring unrecognized subsystem piece4a, believed to be in ship Comm2S-01.pof
WARNING: "Inverted bounding box on submodel 'piece4a-destroyed' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'piece5a' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
Warning: Ignoring unrecognized subsystem piece5a, believed to be in ship Comm2S-01.pof
WARNING: "Inverted bounding box on submodel 'shcommb' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'piece1b' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'piece2b' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'piece3b' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'piece4b' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'piece5b' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'shcommc' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'piece1c' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'piece2c' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'piece3c' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'piece4c' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'piece5c' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
WARNING: "Inverted bounding box on submodel 'shcommd' of model 'Comm2S-01.pof'! Swapping values to compensate." at ModelRead.cpp:2404
Warning: Ignoring unrecognized subsystem core, believed to be in ship Comm2S-01.pofSee how subsystem core is present again as it should be but now there are a lot of Inverted bounding box warnings... :confused: :confused:
I upload an archive with the three models in case it can be useful. (Remember to fix the extension of the desired one)
[attachment deleted by ninja]
-
FS Open reports all subsystems with 0 hitpoints with the
Warning: Ignoring unrecognized subsystem piece1a, believed to be in ship Comm2S-01.pofSo it reports every and all subsystems etc stuff with that same warning even when there is absolutely no reason to do so
EDIT: OTOH it might just report any subsystem that is not navigation, engine, weapons etc system as unrecognized...
-
to fix inverted bounding boxes you need to recompile from source .cob
-
bob you didn't cvs add ogl_vertex_buffers.h ogl_vertex_buffers.cpp
-
to fix inverted bounding boxes you need to recompile from source .cob
But the problem is that:
- I have one existing pof which hasn't got any kind of inverted bounding boxes (whatever thing they are).
- I edit it in PCS2, I save it again, and then it has inverted bounding boxes
Are you sure there's nothing wrong with PCS?
-
what is the date of the version of PCS2 that you are using, i could not replicate such behavior
[edit]
there was a change in the way POF HDR2 bounding box is assigned in pcs_pmf_pof.cpp revision 1.21 - that was commited June 27, 2007 - so if your build is older than that i SMACK YOU for using a 7 month old PCS2 build
-
what is the date of the version of PCS2 that you are using, i could not replicate such behavior
[edit]
there was a change in the way POF HDR2 bounding box is assigned in pcs_pmf_pof.cpp revision 1.21 - that was commited June 27, 2007 - so if your build is older than that i SMACK YOU for using a 7 month old PCS2 build
Hey I didn't thought my English was so bad. :p From my previous post:
OTOH, I think there's something wrong with PCS.
BLA, BLA, BLA
Then I open Mediavps 3.6.10. Comm2s-01.pof with PCS 2 (your latest build from 0112 at 22:50), I insert an Enter in the middle of the conflictive line and I save. Then I get:
BLA, BLA, BLA
I'm using this build obtained through Bob's signature link. Remember that I needed the very latest build with the multiline enhancement in Special Points > Properties.
OTOH please also check the issue with the missing graphical info about where the used textures are UV mapped or which triangles are part of a selected subsystem. (I've already said this here (http://www.hard-light.net/forums/index.php/topic,41648.msg1041106.html#msg1041106))
-
bob you didn't cvs add ogl_vertex_buffers.h ogl_vertex_buffers.cpp
DOH!
sorry, fixed
-
uploading version that has wire frame/highlighting in HTL mode.
has anyone thus far gotten NOTHING in the HTL versions (i.e. nothing but black, or a crash or a combination of the two with maybe a "great flaming graphics error of doom"?)
-
uploading version that has wire frame/highlighting in HTL mode.
has anyone thus far gotten NOTHING in the HTL versions (i.e. nothing but black, or a crash or a combination of the two with maybe a "great flaming graphics error of doom"?)
I've just reopened the mediavps edited Comm2s-01.pof, click in "Textures" and:
Great Flameing Graphics error of DOOM!!!!
Warning OGL reported "valor no valido" at .\pcs_file.cpp (2103)
please report this issue to Bobboau
...or else...
And some more like this one
-
does "valor no valido" roughly translate to "invalid operation"?
or would "invalid value" be more accurate?
-
I just uploaded a new build with a few more error checks (and I made it so invisible textures don't draw as white anymore (so the com node won't show as a white box with spikes sticking out of either side)).
please run that and tell me the error OGL reported, the line number and file (for example ' "valor no valido" at .\pcs_file.cpp (2103) ') it'll probably be about the same but it will rule some things out and I'll be sure the line numbers match properly.
I'm assuming when you don't click on the textures or submodels everything is working fine.
-
has anyone thus far gotten NOTHING in the HTL versions (i.e. nothing but black, or a crash or a combination of the two with maybe a "great flaming graphics error of doom"?)
No crash so far, but the more POFs I open in succession the longer it takes to load them.
-
are you sure you aren't just loading successively more complex models?
-
anyway sence this is the request thread after all I think this is the best place to mention I've just looked over the OBJ file format and I think I'll be able to make an importer for it, it supports everything we need in terms of geometry, so thats good, the only downside is it does not support higherarchy, so I'll need to either make some hacked together solution or OBJ import will only be a bunch of sibling objects and you'll need to rebuild the geometry in PCS2 (which fortunately enough you can do)
-
what program is .obj?
PST: no new features! we're supposed to be in RC build feature freeze for 2.0 release
[edit]
flipped BBOXes just DON'T MAKE ANY BLOODY SENSE!
this is driving me up the wall.
i'm building the HDR2 bounding box off all the subobject bounding boxes on POF save, each subobject's bounding box is constructed off it's FS2-coordinate space polygon list _OR_ if BSP cached off it's PMF coordinate space list and then ran through POFTranslate(vector3d) so it's right in both cases.
[edit2]
bob.. make sure you're convering the MOI between the two coordinate spaces
[edit3]
just found a memory leak in POF loading
-
I'm really hoping he just meant for 2.1 or 2.2, I want a stable 2.0 soon!
-
anyway sence this is the request thread after all I think this is the best place to mention I've just looked over the OBJ file format and I think I'll be able to make an importer for it, it supports everything we need in terms of geometry, so thats good, the only downside is it does not support higherarchy, so I'll need to either make some hacked together solution or OBJ import will only be a bunch of sibling objects and you'll need to rebuild the geometry in PCS2 (which fortunately enough you can do)
Oh Bob, you've made me the happiest modder ever! OBJ is what I (and quite a few people I know) export to start the long and horrible POF conversion journey.
-
:) see what :yes: says, it's popular.
originally it was from wavefront, but it's a commonly supported file.
what all are we waiting for on the 1.0 (or 2.0 or what ever version number) release? aside from general settling. should we make some big huge push for developers to hunt for bugs?
I need something to work on while I wait for feedback from people. sitting here waiting hours between posts I get stir crazy.
MOI was done in the internal coordinate system, and more importantly is a function of an objects partial distance so it shouldn't have any problems, the numbers didn't seem like they were flipped any ware. but this is a perfect example of stuff I'm waiting for feedback on.
are bboxes still getting flipped?
-
the official version number we're on RC builds for is 2.0 - so yes big bughunting push. once we're confident all bugs are hunted down and destroyed we release 2.0 and start on 2.1
people tell me that they are getting flipped but neither goob nor i could find where this is happening - it did cause me to find a memory leak (probably what ASPR was talking about with "it gets slower as i load more models)
it was leaking the net size of all the BSP data for each file!
[edit]
oh.. and i revoked PCS1.x's recognition for BSP caching.
oh.. and isn't it nice having the internal PMF format instead of having to go straight to POF when it comes time to add new formats :P
[edit2]
using VBO's for rendering will interfere with some features in 2.1 possibly
-
Bob, couldn't you just add a new branch to CVS for 2.1 stuff?
-
Bob, couldn't you just add a new branch to CVS for 2.1 stuff?
:yes:
that would be a good idea - because then we could backport bugfixes to 2.0.x builds while working on 2.1 unstable
[edit]
wow.. i'm a retard - that was POF::OBJ2_Get_BSPDataPtr NOT POF::OBJ2_Get_BSPData
not a memory leak.. wee double free CRASH!
-
yes and no, it's nice to have an internal format not dependent on POFs, but the way geometry is organized is horrifically ineffecent. if you would have used a index based representation of the geometry rather than a pure vertex based representation (that is a list of vertexes and polygons represented as a list of indexes into this list of vertexes rather than polygons being simply a list of vertexes) it would have been several orders of magnitude better. most (all that I am aware of) file formats are arainged like this and it's the cause of 90% (this is an understatement) of the time BSP compiling takes (tree generation for extremely complex models only takes about less than half a second, converting from PCS2 internal geometry to indexed geometry takes 30 seconds or more). the first thing I want to do after release is change this, because it's the biggest limiting factor in the programs design.
-
did we ever figure out how to work branching, because I tried that once already with the experimental BSP stuff and it didn't work out so great.
-
.OBJ import would indeed be cool. The lack of a hierarchy might make it very tedious though. Might you be able to generate at least some initial hierarchy based on the object names? Ie, anything called 'turret01a' would be parented to 'detail0', while 'turret01b' would go to 'detail1' etc.
As for other stuff that could be done, well the save as cob function is still partially broken: http://ferrium.org/mantis/view.php?id=36
And it would also be really cool to be able to open VP files and look at any models in there. <insert begging emoticon here>
-
Yeah, I'm definitely getting a lot of crashing on the .cob export as well. I don't think I've saved a .cob successfully in a long time. It sometimes seemed like the export worked, but then crashed anyway, now it seems it's not creating anything near a complete file. I tried exporting a retail ship to cob (capital03 I think, the big Vasudan one), it crashed during export, and when opening the cob in pcs2, most of the geometry is gone. So yeah, cob export seems to need some work still. Might I suggest fixing that, and then making sure everything has been committed for a RC2 release, to squash any more remaining bugs?
-
"it would also be really cool to be able to open VP files and look at any models in there."
well if you have PCS2 associated with POFs you can use any existing VP extractor to open POFs by opening them from there.
we should probably make an installer.
"Might you be able to generate at least some initial hierarchy based on the object names?"
this is basically what I was thinking when I said "some hacked together solution".
basically looking at the last letter in the object name and if it's 'a' -> LOD0 'b' -> LOD1 ect... if it's name starts with "hull" or "detail" its the parent of that LOD, stuff like that.
-
As long as it's consistent and well-documented, hopefully within the app even, maybe even a one-time popup describing what's required when someone tries to do obj import. Or at least some included help files or something, so we don't have to rely on online stuff that always gets moved around.
-
Could it be possible to tell you exactly what subobject caused a bsp error?
-
yes and no, it's nice to have an internal format not dependent on POFs, but the way geometry is organized is horrifically ineffecent. if you would have used a index based representation of the geometry rather than a pure vertex based representation (that is a list of vertexes and polygons represented as a list of indexes into this list of vertexes rather than polygons being simply a list of vertexes) it would have been several orders of magnitude better. most (all that I am aware of) file formats are arainged like this and it's the cause of 90% (this is an understatement) of the time BSP compiling takes (tree generation for extremely complex models only takes about less than half a second, converting from PCS2 internal geometry to indexed geometry takes 30 seconds or more). the first thing I want to do after release is change this, because it's the biggest limiting factor in the programs design.
the format was NOT designed for speed of rendering - index based is not easily edited. it's designed for easy editing, not fast rendering. Making the change that you wish to make will limit our ability to implement promised features on the roadmap - such as geometry editing capabilities, etc.
Internal formats for games, and internal formats for editors have vastly different requirements - incompatible ones in fact. The differences between PMF (easily editable, not suitable for high performance) and POF (difficult to edit geometry, suitable for high performance in previous generations) highlight the differences well.
-
"it would also be really cool to be able to open VP files and look at any models in there."
well if you have PCS2 associated with POFs you can use any existing VP extractor to open POFs by opening them from there.
already covered by file associations
we should probably make an installer.
for 2.0 official release we will
"Might you be able to generate at least some initial hierarchy based on the object names?"
this is basically what I was thinking when I said "some hacked together solution".
basically looking at the last letter in the object name and if it's 'a' -> LOD0 'b' -> LOD1 ect... if it's name starts with "hull" or "detail" its the parent of that LOD, stuff like that.
not necessary - if your lods generate out of order it's easily corrected in the header editor, and "a" vs "b" stuff is already handled by being a child of it's lod
-
well if you have PCS2 associated with POFs you can use any existing VP extractor to open POFs by opening them from there.
Well I was more thinking along the lines of modviews VP browser thing, but that would probably not be much more useful overall.
this is basically what I was thinking when I said "some hacked together solution".
basically looking at the last letter in the object name and if it's 'a' -> LOD0 'b' -> LOD1 ect... if it's name starts with "hull" or "detail" its the parent of that LOD, stuff like that.
Cool then. Do you have any way in mind to do auto-gen info like firepoints?
not necessary - if your lods generate out of order it's easily corrected in the header editor, and "a" vs "b" stuff is already handled by being a child of it's lod
That's the problem though - .obj doesn't appear to support hierarchy, so any PMF convertor for that format would need to figure out some of it based on object names.
-
then we'll have to allow drag'n'drop on the hierarchy tree - though i would prefer NOT to support any object format which cannot store such information
what do you mean autogen info like firepoints? light's another thing .obj doen't support?
-
the format was NOT designed for speed of rendering - index based is not easily edited.
I don't think so, let me make a simple example, what if I have selected a point and I want to move that point, in an index based organization you need to know the index of the vertex and you move it, in the vertex based organization you need to know the index to all the polygons involved and the index of what that point is in each of those polygons and you need to move each of them separately. this is a vastly more complex and error prone undertaking than if it was index based.
models are not collections of unrelated polygons in space they are collections of points which make up polygons in space.
not to mention the difference in memory requirement or any algorithm that works on inter polygon relationships.
what factors were you considering when you decided this would make things easier? I came to my decision after trying to actually implement the geometry editor and not being able to implement the simplest of editing functions, and determining that our current method slows down virtually all polygon/vertex/normal operations by rediculus factors.
-
then we'll have to allow drag'n'drop on the hierarchy tree - though i would prefer NOT to support any object format which cannot store such information
ummm... drag and drop hierarchy editing is already in place...
but the thing with obj support is it's extremely common, and it supports everything POFs do other than the hierarchy, specifically smooth groups, I'm not sure how well supported in other file formats, but it's there.
I'm planning on obj to be a partial model (ie submodel) file format primaraly however. I'm expecting it's primary usage will be to import/export one subobject at a time, so if someone notices a glitch on a ship's hull they don't have to reimport the whole model, and all the old data from the old POF, just the damaged part. it would also allow people to make chunks of models, you could simply make the hull of a capship, import that, then make a turret, import that, setup the turret if nesisary, then copy it as many times as you need, this will bring the editing capabilities of PCS2 into more of a light. (and as you just demonstrated :) a lot of people who should know about PCS2s editing abilities don't)
-
i misunderstood you a bit on what you were talking about with the PMF format changes - you're just talking about a master list of vertexes and then each polygon contains a list of numeric references instead of individual copies of the vertex
i did it this way for two reasons
A) laziness
B) independant polygon editing
B can be done with your way, you just have to split the vertex into two when needed.
as for performance issues with the render window... i've seen none what so ever (Then again, look at the rig in my sig) though on my weakling laptop i see no problems either - so i don't know where this "dismal render performance complaint" is coming from: it's an editor, not a game. Your VBO code breaks a LOT of things at this point - including all context editors (they're wrapped in the else part of your if statement)
VBO rendering can be put off till 2.1 - when we'll be implementing the main features it may interfere with as well.
I'll add that and switching to vertex list PMF into the 2.1 roadmap
[edit]
oh.. and we need to SERIOUSLY write a tutorial and full help document.
-
If you don't already have PMF Version support in the PMF format, you might want to add it before PCS2.0 goes final. If you plan on making serious changes to the format, not only would future versions know which version they're dealing with easily, older version would have a reliable way to tell if they can or can't open the file based on that version alone, and then also know why they can't, and generate a usable error to the user.
-
what did you think I meant?
I have no problem putting it off for a while, it's mostly working at this point (I do have context working on my machine but there seems to be issues on other machines, the 'flaming' error I'm sure you got quick of seeing in a hurry). but I can assure you the performence levels were quite apparent on a 32 bit Athlon 3000+XP + Radeon 9800 128MB, I can only imagine how slow it is on some of our lower spec machines.
-
If you don't already have PMF Version support in the PMF format, you might want to add it before PCS2.0 goes final. If you plan on making serious changes to the format, not only would future versions know which version they're dealing with easily, older version would have a reliable way to tell if they can or can't open the file based on that version alone, and then also know why they can't, and generate a usable error to the user.
light years ahead of you - the very first version of the PMF format to save to file had a version tag
-
Kazan, do you or Bob have the very latest build? (who' link)
I ask cause the last two builds do not show textures (or even appear to load model except for the bar progress) PCS1 did though. Unfortunately I deleted the build I was previously using so I don't know the date but I know it showed them.
Also did Gary make that higher poly cob2pof .exe (the architect oriented version?) Could that have something useful in it for you?
-
are you trying the build in my sig, I just synchronized with CVS and everything looks fine here. do you see anything in non-textured/wireframe mode?
-
Also did Gary make that higher poly cob2pof .exe (the architect oriented version?) Could that have something useful in it for you?
no.. i used everything gary ever had to contribute in 1.x
-
Ok strange, here is the older model I converted no problem and DOES show up...(although I did this with pcs1 last year. (Destroyer)
Now second file is the newer Battlecruiser by same artist, no idea why model does not load right nor textures show. any ideas?
PCS1 loads it and pofs.
I hope this brings something to light for the program. If it's something on the model end np, just thought it was worth mentioning.
[attachment deleted by ninja]
-
I think this loading dialog box could be modified a bit to make it possible to see all the text during a file load (see attached). Also, I received an error about an unrecoverable geometry error, and thinking of children, dammit. Is that an error we're supposed to see, or does that mean it went somewhere it wasn't supposed to? :)
[attachment deleted by ninja]
-
was the message
"*ERROR*:uncorectable geometry encountered!
Truly this is the darkest of hours."
if so I must see this object which has defied my geometry filter.
if you get that message it means you have a polygon which is concave and my algorithm was unable to correct it. now you are no worse off than if the geometry filter did nothing, however there is a strong possibility that you will have rendering and collision issues, and perhaps BSP or smoothing errors (among many other possible nightmare scenarios) for that polygon.
now I thought that I had covered all my bases with that thing so I am very interested to see exactly what killed it, the only thing I can think about that could have done it is if it was both concave and severely non-planar.
-
Is there even a 3d modeler that lets you create non-planar polygons ? (without triangulating them internally, that is)
-
apparently there is
just added .eff and normal mapping to the 2.1 roadmap
-
I don't think that's what a concave polygon is. It's still 'planar'. See here (http://mathworld.wolfram.com/ConcavePolygon.html).
-
I don't think that's what a concave polygon is. It's still 'planar'. See here (http://mathworld.wolfram.com/ConcavePolygon.html).
Yeah I know, I was replying to Bobs last sentence. I think that when you have a polygon consisting of more than 3 vertices, and those vertices are not all in the same plane, the polygon hast to be triangulated for any renderer to make sense out of it.
-
My bad. Although I think for FS, don't they have to be triangulated even if they _are_ in the same plane? That's what I was confused on, how you can have a polygon that's not in just one plane.
-
My bad. Although I think for FS, don't they have to be triangulated even if they _are_ in the same plane? That's what I was confused on, how you can have a polygon that's not in just one plane.
nope a polygon in POF's BSP format has 3-20 vertexes - IIRC PCS2 is triangulating the mesh though (produces more stable meshes AFAIC)
-
Ok, they don't have to be triangulated, but I thought a polygon, by definition, was planar.
-
Ok, they don't have to be triangulated, but I thought a polygon, by definition, was planar.
normally... but some programs allow them to be curved
-
normally... but some programs allow them to be curved
That actually hurts my brain.
-
Didn't Nvidia's NV01 allow non-triangulated polygons too?
-
2.0 Final Release (http://www.hard-light.net/forums/index.php/topic,52098.0.html)
bob's and my hands are now untied and we can start working on 2.1 features
PS: Bob make sure to backport bugfixes to the stable_2_0_fixes branch
[edit]
Note: 2.1 Alpha builds will be bob and i only, maybe a hand select few
2.1 Beta builds will be CLOSED BETA - Only people accepted as beta testers [one of the criteron will be NOT using beta versions of PCS2 for production models :P]
2.1 RC builds will be limited forum release
2.1 final will be wide sf.net release like 2.0 final is
-
Awesome. Can't wait to test out the new PCS2.1
-
I can't believe how much you guys rock! ;7
Question: With PCS2.1 handling a direct export from Max, does this mean that we won't be restricted to v8, anymore? Not sure about how file specs change from version to version, but I know I like versions later than 8 more. ;)
On a side note, I wish I could help you guys, but I'm a pretty neophyte programmer and would probably just get in your way.
With 2.1, I'll no longer have an excuse not to finish my models... :(
Anyways, you guys still rock!
-
ASE Support (and OBJ support too), would mean almost direct export.
No Truespace anymore. ;)
It should also work with pretty much any MAX version. (I don't know about the really old ones though... ).
Actaully, it might even be possible to just re-export your files made for the MAX exporter, without changing anything, while you keep your complete POF setup (gunpoints, subsystems and stuff).
That way a lot of problematic POF files could be re-exported instantly in a minute, instead of hours or days.
-
New request: For the selected subobject, could we get a label telling us the subobject number as it the game would see it please? Things like the turret firing animation code want to know the subobject number of the turret doing the firing, and as is we kinda have to guess. ;)
-
mantis that VA
ASE is off the table.. the format is far too unrealiable
-
Back to obj then?
-
yeah.. which ha it's own problems... no hierarchy support so you have to import 1 obj at a time
-
You were still planning on getting implied hierarchy through a standard object naming convention right?
-
Maybe time to look at something else.
COLLADA 1.4
3ds Max, Blender, DAZ|Studio, Feeling Viewer, FX Composer, Google Earth, Houdini, Maya, Sketchup, and XSI
http://en.wikipedia.org/wiki/Collada (http://en.wikipedia.org/wiki/Collada)
http://www.khronos.org/collada/ (http://www.khronos.org/collada/)
-
How about a file chooser for selecting textures, with thumbnail view?
It would have to also allow you to just enter in a name (in case the file isn't yet where it will need to be, etc.)
-
W00t! I was wondering if there was a decent XML based open 3d format. Maybe Collada could be it.
-
XML was not originally meant for many of the uses it gets nowadays. I find it comical that people think it is so great how much stuff can be stored with it.
I'm not sure if this is a feature or a bug, but please make it so that the z-buffer is big enough to hold whatever ship is being viewed. Currently, for example, a 3 km warship (at least for me) shows up as a few polygons protruding from a sea of black (the z-buffer max depth)
-
XML was not originally meant for many of the uses it gets nowadays. I find it comical that people think it is so great how much stuff can be stored with it.
I'm not sure if this is a feature or a bug, but please make it so that the z-buffer is big enough to hold whatever ship is being viewed. Currently, for example, a 3 km warship (at least for me) shows up as a few polygons protruding from a sea of black (the z-buffer max depth)
ooh good call on the cause of that :D i was trying to track it down
-
I've used OpenGL before :)
-
XML was not originally meant for many of the uses it gets nowadays. I find it comical that people think it is so great how much stuff can be stored with it.
True, but I think it lends itself to 3d modeling quite well, a model is just a collection of a list of points, and heirarchy, etc, and XML lends itself to that quite handily doesn't it?
-
increasing far clip did nothing.. they're not actually out of place... just unlit
-
Are you sure you're doing it right?
If you are using OpenGL:
glFrustum(xmin, xmax, ymin, ymax, zmin, farclip);
don't make the mistake of doing this, like I did, it doesn't do squat for you:
glClearDepth(farclip);
glClearDepth should almost always be 1.0, so you can generally ignore it.
-
we're using gluPerspective
-
I don't know if it's related or not, but had an issue with one model where the main part was small and all the sub-objects were very large. PCS focused on the small part - so you couldn't really see anything.
-
hrm weird
-
i'm looking into adding support for Collada now using the Collada DOM library from sf.net
if that works then MAya and 3DS users can rejoice as there are plugins for both to export/import collada
[edit]
format appears to be viable
-
Not for Blender, or you just didn't look? Either way I'm doublechecking now.
Edit: Found it. http://colladablender.illusoft.com/cms/ (http://colladablender.illusoft.com/cms/)
Seems to have a good backing, as it's being made by a game studio for their own use, and they've decided to open it up to the public as well.
-
It's already part of Blender 2.45. Also Sketchup could potentially be used.
-
Strange... I am still having that can't find texture problem with .cobs. Also this model I've wanted in game for years finally converted with PCS1 while it freezes halfway through smoothing operation in PSC2.
Gets damaged and blows up fine in game so it appears stable.
1 welded object 5500 polys.
Atra's Yamato.
[attachment deleted by ninja]
-
Strange... I am still having that can't find texture problem with .cobs. Also this model I've wanted in game for years finally converted with PCS1 while it freezes halfway through smoothing operation in PSC2.
Gets damaged and blows up fine in game so it appears stable.
1 welded object 5500 polys.
Atra's Yamato.
Converted in PCS2 without problems. 27 turrets - just add firepoints. (and engines etc)
http://files.filefront.com/yamato2zip/;9641421;/fileinfo.html (http://files.filefront.com/yamato2zip/;9641421;/fileinfo.html)
-
You've had it all this time? :lol: I remember when Swamp thing converted it and never sent it to me after I first posted it like in 2003/04.
I was mainly curious as to what was causing the problem because this is a NEW computer and new video card
3gh dual core
1gb ddr2 mem
8500 gts Nvidia (my first NON-ati card)
****ing VISTA Home Premium (Slap the monkey who did this please!)
I just got SCP back over this weekend but broke my machine in with NWN2 2 weeks before that.
The thing is it did display the name in the upper left corner but no ship data on the right as if no model was actually loaded. If I opened the pof made it shows up no problem, this is only an issue with the .cob
Was the 2.0 "stable build" pointing the dir to the cob in the texture path in configuration was ineffective.
So I guess it can't be explained and is just one of those things with computers. IF this was more of an annoyance than a help about an issue then I won't mention them anymore (if it's just me having it).
BTW the rear turrets, shouldn't they be facing 180 degress rearward instead of forward? That was never addressed in any tut I've read and I didn't notice any problems when I did it that way first time (at least with the base part, I TOTALLY screwed barrel axel and placement though, that's why I am multi-shy now) :D
-
What you describe there sounds like you had some object that was not a part of an object group present somewhere in the scene. Remember the old 'you forgot to group those objects!' message? Well PCS2 doesn't give that message and just pretends to have loaded the cob (ie, the "model.cob" thing in the title bar), and displays nothing - exactly the problem you describe. As Water has demonstrated it converts just fine, so you can rest assured that it's not a model problem and just faulty hierarchy or something.
As for multiparts, AFAIK yeah - topside bases face forwards, underside face backwards. This does not apply to off-axis multi-part turrets since you specify where their front is yourself, but I think all barrels need to be pointing stright up relative to the base. You can rotate anything to point in any direction you like using the initial animation type. (Check the animation code in the Wiki for more detailed instructions there)
For the turret base you place the base axis at the centre of the point around which you want the base to rotate vertically, and make sure you're specifying the axis for the object GROUP rather than just the MESH of the base. For the turret barrels, you place the axis at the pivot point of the arms - typically this is inside the base model. Again be sure you're placing the axis for the object GROUP of the arms rather than the mesh, because PCS2 (or 1) pays no attention to the mesh centres.
-
and make sure you're specifying the axis for the object GROUP rather than just the MESH of the base.
Ooops, was in a rush and tried to preserve the group names in Truespace. Time to look at that export script again.
@Getter Robo G
It is possible your original cob file may be acceptable to PCS2 now. I did return a link to the fixed cob file, but hadn't named the turrets at that stage. I'll see if I can find a way to get the turrets up to pof standard - I just don't want to do it in Truespace.
-
No problem I was intending on eventually replacing the AA guns (like 11 turrets on each side) with better ones.
I noticed you didn;t start the rear side torpedo tubes , the 6 frontal ones, or teh main gun itself.
I FP'ed the main turrets for testing but even beam freed it jsut went in a circle non-firing with an orion table.
Enough of this. I did add a light and try in pcs2 again, it hangs up in smoothing operation halfway through and I have to use task manager to end the process lockup I waited once for over a half hour to make sure it wasn't just processing.
The main thing is it is in game regardless, I can go back later and worry about the rest in the future.
-
stop *****ing and give me the model already :hopping: :mad:
-
Enough of this. I did add a light and try in pcs2 again, it hangs up in smoothing operation halfway through and I have to use task manager to end the process lockup I waited once for over a half hour to make sure it wasn't just processing.
Which version of PCS2 are you using?, and was that with the cob or pof? in the zip posted above?
Both load fine in PCS2.0.1 for me
-
No, I meant I don't want to tangent Kazan's thread further with an issue of outside models and hierarchy since ATM it's Greek to me. ;)
I will try 2.01, but then after that won't sweat it since I am reinstalling almost everything (and I mean that both FS2 and non Fs2 related, this sucks) that's why I decided to go with the listed 2.0 stable build as I interprited 2.01 as beta still.
BTW is there any shield collision/bounding box issues remaining? I was going to hold off installing until those were basically ironed out.
I figured if there were any odd or unusual situations mesh-wise that could crop up it would be me posting them cause my sources are from all manner of meshers even though you would think they were stable initially. Any defects are inserted from the various formats being converted over (3ds, lwo, dfx, ms3d, gmax,and some less used ones).
It was kinda naive to just throw stuff at the PCS2 grinder and then point out when things get stuck inside especially when I don't have the 3d experience to describe it accurately, or know that I shouldn't have tried in the first place.
I appreciate Kazan and you guys patience in that. :D
But honestly if I didn't I wouldn't have 80-90% of the progress I've gotten over the last 6 or so years.
Oh I know that puts me in danger of sharing Takashi's cross of "Perpetual Noob", but results mean more to me than personal ego. heh.
-
2.0.x = 2.0 stable bugfixes
2.1 = unstable
-
PCS2 is supposed to be handling broken models gracefully, if you have a bad model that causes it to freeze, crash, or throw up some really strange error messages, they want to see it to improve the filters and checkers that keep it from crashing. So whether or not you have a perfect model going into PCS2 doesn't matter. I don't have hardly any experience with modeling but I've found 5 or 6 models that have broken it on import and always passed them on to help them improve the import process. So if he asks for the model, give it to him eh?
-
*was away for the weekend*
Why are you using gluPerspective, all it does is call glFrustum anyway...
-
Got an idea for a feature. Being able to do a batch resave. This way a great deal of models can be reconverted at one time. At least the ability to do POF->POF, but if import from other models and then export to POF ever becomes anywhere near hands free, that might be useful as well, but not as much I don't think.
-
I would like the ability to import only certain data from another POF. The other day I exported a model as COB, then imported it scaled by two (the only way to do this AFAIK). Much of the POF data is lost in that conversion. I want to get turret FOVs, turret subobject assignments, n' stuff, but I don't want to import things like subsystem positions which have changed. Of course, this problem would also be solved with the ability to scale, but I'm sure there are other uses for this feature.
EDIT: Oh, and on this topic, when a file contains two objects, turret01 and turret01-arm, even when the arm is a child of the other, it does not automatically assign turret01-arm to the turret (it does not make it a multipart turret). Not sure if this is a bug or something that was just never implemented, but it would save a lot of people a lot of time if it were changed.
EDIT2: And camera move and zoom would be useful.
-
I'm fairly sure there already is camera zoom and move. Shift + Left click moves the camera around (does not move the rotation point though), and middle wheel scroll zooms, as does Shift + Right click.
-
Three requests (first two are trivial)
1.) a simple plugin/ click button that automatically looks for a turret0X-arm and uses it, instead of having to manually set each and every turret.
2.) There is a normalize button, but how about an round up button, instead of having (0.1333, .915, 0.00001) it rounds to (0,1,0).
3.) Any chance of a resizing tool that resizes everything, mesh, firepoints, eye point...etc of existing models?
-
roadmap updated
Three requests (first two are trivial)
1.) a simple plugin/ click button that automatically looks for a turret0X-arm and uses it, instead of having to manually set each and every turret.
2.) There is a normalize button, but how about an round up button, instead of having (0.1333, .915, 0.00001) it rounds to (0,1,0).
3.) Any chance of a resizing tool that resizes everything, mesh, firepoints, eye point...etc of existing models?
those are possible
-
If I made a small file showing hotkeys and mouse modifiers - Would you be willing to create a help entry in the top menu to add it to?
It addresses - 0000072: Feature request: WYSIWYG point-dragging - implemented in PCS2 already.
-
you want to write a UI cheat sheet?
-
you want to write a UI cheat sheet?
Yes. A lot of users would find it helpful. Would it be possible for pictures (icons) as well as text? html?
-
I hope this has not been suggested before
Something that would be really useful for me:
An import funtion for COB, OBJ and DAE. "Importing" or "merging" into the currently loaded POF.
So if I want to add a detail to an old mesh, I could simply import it.
As for the options, I think there are a few needed, like "add" (as a new subobject) "attach to" (to an existing subobject, or a lod, so it's really part of that object after that), and "replace" (which simply replaces the geometry of a subobject).
It's not that important I guess, but it would sure help with making a quick HTL version of a ship for FS2, without much trouble.
-
you can import geometry into it, but it's an "add" operation at this point
-
However, isn't there also a subobject delete, essentially allowing replace but as a two-step process? And how is general collada support coming anyway? I think it would be great to backport that to 2.0.x instead of waiting for 2.1 and all its other features, unless some of those are needed for proper collada support.
-
I do believe there is a subobject delete. Click a subobject and press delete :P
-
And how is general collada support coming anyway?
still waiting for me to get time/motiviation to do it
I think it would be great to backport that to 2.0.x instead of waiting for 2.1 and all its other features,
that violates the entire purpose of separate stable and dev
-
Well then, I hope there would be a developer preview of 2.1 alpha or something with collada support before we have to wait for the bulk of the other features. I just think it would prove very useful and a lot of modders would probably like to see it sooner rather than later.
-
out of all the 2.1 features it will probably be the most time consuming to implement
-
:eek2: Its a frakking XML file. Unless there is a lot of infrastructure that needs to be implemented before DAE import can be done, than I fail to see why it should take so much longer than everything else.
Note that I'm not saying that this should be easy to implement, I'm just surprised that it is the most time-consuming of all of the features (there is some stuff that I would have thought would be much harder).
-
:eek2: Its a frakking XML file. Unless there is a lot of infrastructure that needs to be implemented before DAE import can be done, than I fail to see why it should take so much longer than everything else.
Note that I'm not saying that this should be easy to implement, I'm just surprised that it is the most time-consuming of all of the features (there is some stuff that I would have thought would be much harder).
because obviously XML is easy as hell to implement and parse, which explains why it's such an ancient standard and has been in use for 30 years.. yup
writing xml may be simple, handling it's parsed DOM tree contents is not
-
you want to write a UI cheat sheet?
Yes. A lot of users would find it helpful. Would it be possible for pictures (icons) as well as text? html?
yeah, I actually think there is a prebuilt HTML viewer in wxwidgets, but short of that if it wasn't too long I could recreate just about anything you could want in some sort of help window. and there is always the option of simply having the documentation in HTML and having the OS handle it (ie have it show up in firefox or (ugh) internet explorer)
also on the subject of XML, there is a saying:
there comes a time in every coders life when they have a problem and think "Ah! I know I'll use XML", now they have two problems.
not saying it's a bad idea, I just always thought that was funny.
-
also on the subject of XML, there is a saying:
there comes a time in every coders life when they have a problem and think "Ah! I know I'll use XML", now they have two problems.
That's made of win. I'll have to share that some of the other coders I know.
-
Maybe I'm just too used to Apple's automated parse APIs...
-
yeah, I actually think there is a prebuilt HTML viewer in wxwidgets, but short of that if it wasn't too long I could recreate just about anything you could want in some sort of help window. and there is always the option of simply having the documentation in HTML and having the OS handle it (ie have it show up in firefox or (ugh) internet explorer)
Ok - I'll see how minimal I can get it.
-
Minimal Help Text
------------------------
View:
L Mouse
R Mouse - Rotate view along Z (long) axis
Shift + L Mouse - Pan view
Zoom:
Shift + R Mouse - Zoom Fast
Mouse Wheel - Zoom Slow
Move:
Ctrl + L Mouse - Move item around in blue plain (dual axis)
Ctrl + R Mouse - Move item along red axis (single axis)
(http://i229.photobucket.com/albums/ee67/waternz/mesh/icons5a.gif)
-------------------------------------------------------------------------------
Using these icons to replace the existing ones makes the help file easier to explain, and allows you to drop the X, Y and Z axis lock icons. So instead of 3x3 button variations. Just three are all that is needed for both dual and single axis use.
-
ok, had a free moment to work on this, and CVS got unbroken, so I was able to get this half way implemented, if you want anything about it changed tell me, I'm thinking about implementing a transparency slider on the bottom and makeing the window always on top, not sure if that would be worth the effort though. it's currently modless so it can be up while you use pcs2, but it will be pushed to the background while you use the graphics window. I expect you will want to make changes to the help file as I only made a minimal html file for it, no frills at all.
-
I expect you will want to make changes to the help file as I only made a minimal html file for it, no frills at all.
I though the adding special points, paths etc seemed to not need any sort of help section so any alterations would depend on feedback from others.
-
Any chance of having a turrets automatically setup their up and forward angles?
-
Has this already been mentioned? It would be nice if you could use autogen for specific paths. Sometimes I have new paths I need to generate but I don't want to destroy the old ones.
-
just import those paths.. selective autogen would not make you happy.. trust me
-
just import those paths.. selective autogen would not make you happy.. trust me
Why not? (If there is a good reason, I'd like to know)
-
just import those paths.. selective autogen would not make you happy.. trust me
Why not? (If there is a good reason, I'd like to know)
do you want 20 million prompts when loading a model?
-
:wtf:
I don't get it.
-
:bump:
I'd just like to make a useful feature request: Transferring data from one file to another.
This could be very useful because... Let's say you import a model once with PCS2, you have it hardpointed, glowpointed, subsystems, the etc. and then you decide you aren't happy with the mesh the way it is. So you decide to go back into your modelling program and add LODs, debris, the etc. and you're finally happy with that one and you decide to re-import the model, but you want it to have the same glowpoints, weapon hardpoints, etc. as the old one. Well I'm not sure many people would want to go through the trouble of transferring this data manually...
-
Would it be possible to implement a project style view where you can import cobs as you sub-models of existing Pofs?
-
Would it be possible to implement a project style view where you can import cobs as you sub-models of existing Pofs?
*facepalm*
feature.. already..present
-
Animation preview then?
-
Animation preview then?
maybe
-
Expanding on that. Would it be feasible to have it so that once animations are defined in PCS. It could output to a log that can be copied into a .tbl entry?
-
Would it be possible to implement a project style view where you can import cobs as you sub-models of existing Pofs?
*facepalm*
feature.. already..present
So how do I access that feature?
-
:bump:
I'd just like to make a useful feature request: Transferring data from one file to another.
This could be very useful because... Let's say you import a model once with PCS2, you have it hardpointed, glowpointed, subsystems, the etc. and then you decide you aren't happy with the mesh the way it is. So you decide to go back into your modelling program and add LODs, debris, the etc. and you're finally happy with that one and you decide to re-import the model, but you want it to have the same glowpoints, weapon hardpoints, etc. as the old one. Well I'm not sure many people would want to go through the trouble of transferring this data manually...
For that you want the global import option. Not at home ATM, but from memory I think it's in the file menu? For individual chunks of data, use the load button on the top left side of the right hand properties pane in each section.
So how do I access that feature?
For that you want to use the load button while in the subobjects pane. You then select a POF to grab a subobject from and select the subobject from the list that appears.
Be careful though, as I've encountered array out of bounds errors when using it. (See bug 73 (http://ferrium.org/mantis/view.php?id=73).)
-
Bumping an old thread, but could it be possible to lock the entries listview so it's not always refreshing? When you have a large number of entries (especially with paths) the constant refreshing.
-
might be piossible to do more selective updates too.. i'd have to look at bob's code
-
The only thing PCS2 is missing is Importing.
-
The only thing PCS2 is missing is Importing.
Yes, especially on import subsystems. Something that would just import the properties only.
-
The only thing PCS2 is missing is Importing.
Yes, especially on import subsystems. Something that would just import the properties only.
copy+paste
-
Speaking of importing, any change the array out of bounds on subobject import bug will be fixed anytime soon?
-
I've never ran into that particular bug.
I've imported plenty of objects.
-
Well copy and paste does work..... albiet slowly. lol
Another thought... is it possible to create plugins tools with the editor (not importing/exporting plugins)? I've got a few time saving ideas I'd like to implement.
-
Well copy and paste does work..... albiet slowly. lol
Another thought... is it possible to create plugins tools with the editor (not importing/exporting plugins)? I've got a few time saving ideas I'd like to implement.
i can give you source access if i like your ideas
-
Well copy and paste does work..... albiet slowly. lol
Another thought... is it possible to create plugins tools with the editor (not importing/exporting plugins)? I've got a few time saving ideas I'd like to implement.
i can give you source access if i like your ideas
Dynamic plugin (at least at startup) would be the best solution. That way the main program doesn't need to be updated whenever a plugin gets updated. All you would need to give us is an interface class.
-
Well copy and paste does work..... albiet slowly. lol
Another thought... is it possible to create plugins tools with the editor (not importing/exporting plugins)? I've got a few time saving ideas I'd like to implement.
i can give you source access if i like your ideas
Dynamic plugin (at least at startup) would be the best solution. That way the main program doesn't need to be updated whenever a plugin gets updated. All you would need to give us is an interface class.
making dynamic plugins portable is a PITA AFAIK
-
what about scripting?
might want to talk to WMC bout that.
-
Scripting might work, provided you can a.) create your own dialog windows b.)easily manipluate data.
A) looks like it leaves lua out of the list.
Some examples I've thought of:
1.) if it sees turret0X-arm then it'll automatically assign that for turret0X
2.) round up turret normals to Y points
3.) mirroring paths/engines/weapons...etc alone multiple axis
4.) grid box layout, so for example paths you'll see every paths X,y,z,etc... in a grid list. You can select multiple values and set them at once.
Edit: Is the pme format available and I assume it keeps things like glowpoints/paths/etc... correct?
-
I don't think any scripting language has built in UI, we'd have to implement that ourselves, but that doesn't make it a bad idea. at any rate stuff like that would be up to who ever implements it, assuming such a person should exist.
-
Would it be possible to have a way to edit smoothing directly? i.e. select an edge and set it as sharp or smooth?
-
you mean on geomerty? if/when there is a geometry editor then yes.
-
if /when there is a geometry editor
:(
-
you'll be glad to hear i've been coding on it some yesterday and today
-
w00t
-
Uv adjustment?
-
Uv adjustment?
not yet.. mostly just doing maintenance stuff so far - cleaning up some warnings, updating the wxwidgets version i build against and adjusting my code to reflect the API changes, getting ready to improve some UI behavior then i'll delve into features
-
It'll be excellent no doubt :yes:
-
I wonder if there'll be conflicts merging that with the Collada changes.
Oh, it could do with an insignia editor/viewer.
-
I wonder if there'll be conflicts merging that with the Collada changes.
Oh, it could do with an insignia editor/viewer.
[/quote
mergine what with the collada
i haven't even started writing them
-
I wonder if there'll be conflicts merging that with the Collada changes.
Oh, it could do with an insignia editor/viewer.
mergine what with the collada
i haven't even started writing them
:nervous:.......... <half-life 1 health recharger> fixxed </half-life 1 health recharger>
-
Kaz, he's talking about merging the fixes and changes you make with the Collada support he's been working on. He just wonders if anything you work on will conflict with what he's done.
-
Kaz, he's talking about merging the fixes and changes you make with the Collada support he's been working on. He just wonders if anything you work on will conflict with what he's done.
would someone please tell me WTF you guys are talking about
dekker doesn't have write access to PCS2.. has he been working on writing in collada without telling me and without requesting write access?
-
No; that would be me.
-
give me the patches so i can review them
if they're good i'll give you write access
-
:lol: Coding is not my greatest strength. I've been a fan of PCS since god only knows though ;)
-
Yeah, Spicious has been working on Collada support for months; see some of the last pages of this thread (http://www.hard-light.net/forums/index.php/topic,54757.0.html). There's also a Collada Importer Wiki Page (http://www.hard-light.net/wiki/index.php/Collada_Importer). The structure in the Wiki is probably a bit outdated though. There's been a lot of support for him working on this, a good chunk of the major modelers around here have been testing and giving input as to its functionality. I think Spicious has probably realized this was a lot bigger endeavor than it looked like going in, but it's made some great progress I think. And you weren't around a whole lot lately, so I guess no one figured to suggest he ask for write access. But now you're back, and all is well again :)
-
well if he followed my coding conventions it should be able to be patched into the core repository easily.
[edit]
one potentially PITA issue i notice is that specious is using VS 2008 SP1 and i' using VS 2005 SP1
[edit2]
oh and the PMF format is scheduled to be altered - but that affects all the converters
-
I have a request, a scaling feature. (I recently tried the export to cob-change preferences-import the ship method but it barfed all over me. 'Course, PCS crashes on me alot anyway)
-
A) if PCS2 has been crashing on you why haven't you been reporting it
B) define "barfed all over me"
C) the COB options have a scaling feature
D) try reading the first page of this thread http://www.hard-light.net/forums/index.php/topic,41648.0.html
-
A) I think It got defined as the "random crashes bug" or somesuch. It doesen't like me to look at weapons point, engine points, pretty much anything with points.
B) I think it might be the model itself, it says something about somethingorother being out of bounds when I try to import. I also tried opening it in TS recently and it said "bad data format."
C) that's what I was trying to use ... I think.
-
A) That is a known bug
B) Try reexporting the COB. If it still doesn't work, there may be a bug in COB export.
-
a known bug that we cannot replicate on our machines :wtf:
-
Those are always great.
-
Indeed, though it affects many people. All I know ATM is that it happened in all versions of PCS2 after RC2A. Aardwolf may have made some progress toward identifying its source, so you might want to contact him about that.
-
or he can post here or i can check mantis and see if he posted there :P
-
or he can post here or i can check mantis and see if he posted there :P
IIRC he posted in Mantis ;)
-
link?
-
Judging by the fact that the last comment there is yours, you have already seen it. But here (http://ferrium.org/mantis/view.php?id=63) is the link anyway.
-
bah
didn't realize we were talking about the same bug
-
Just out of curiosity anyone else ever have the .cob2pof processing freeze bug?
Since it was only me when I reported it last year? I figured it would never be fixed just for ONE person if it couldn't be replicated by others.
[Water and others succeeded in converting the models I posted bugfree...]
-
Don't know, if someone else is still looking after this thread. Don't even know, if this is the right place for this.
I wondered, if there is any other program utilizing the .pmf-format and via google I found a site of the " ZFXCE " engine. :wtf:
Here is the address: http://zfxce.sourceforge.net/index.php/Hauptseite.
Also there seem to be some video-managing programs around using the same ending.
So, are there any other programs, especially modeling programs around using the same .pmf data format as PCS2 ?
-
The PMF format is unique to PCS2.
-
PMF is PCS2 Model File basically it's just a dumb to disk of the internal (easy to manipulate) representation of the model data.
it also facilitates only having to write one conversion to the POF format, which is a pain in the ass relatively speaking to convert to and the conversion most likely to have bugs due to complexity issues - less effort, less bugs, etc.
all model formats supported convert to/from PMF
so effectively
COB->PMF / PMF->COB
DAE->PMF / PMF->DAE (in Spicious's builds and in trunk builds once he gets me the patch)
POF->PMF / PMF->POF
-
- Make a ship radius edit box, so we can fix POFs which were created with older versions of the MAX exporter.
already editable
Is this the same as "Max Radius"? Because if it was editable at one point, it is not in 2.0.3 Stable 05/15/08.
-
Could it be possible to "clean" textures? If the texture isn't actually used, but it's included on the material list, ignore it so it won't get loaded. Probably leave the material slot empty or shift everything down one. Include the "-normal", "-heigh" "-shine", "-glow" maps in this. No need to have them on the texture list.
-
Also the user settings should not be stored in the programs folder. It will not be able to save the settings running as regular user under Win 7 (you must run as admin to make modifications to the folder).
-
Could it be possible to "clean" textures? If the texture isn't actually used, but it's included on the material list, ignore it so it won't get loaded. Probably leave the material slot empty or shift everything down one. Include the "-normal", "-heigh" "-shine", "-glow" maps in this. No need to have them on the texture list.
I like this idea, although I wonder if it might get messed up by some special-case textures (I'm thinking retail-style fighter engine-glows and that sort of thing)
Also, I'm curious, has anything been done with that 'omnipoints' ("0000063: When I try to add gunpoints, the program crashes every time. ") issue? Has Bobboau done anything with PCS2 recently?
-
Also the user settings should not be stored in the programs folder. It will not be able to save the settings running as regular user under Win 7 (you must run as admin to make modifications to the folder).
UIh....what? First time I have ever heard of this problem.
For apps in PROGRAM FILES or other WinOS dependent directories, this is a problem (ish) with work arounds. For user generated directories, this problem should not exist unless something got borked.
Could it be possible to "clean" textures? If the texture isn't actually used, but it's included on the material list, ignore it so it won't get loaded. Probably leave the material slot empty or shift everything down one. Include the "-normal", "-heigh" "-shine", "-glow" maps in this. No need to have them on the texture list.
The problem with shifting texture slots up or down, is that it would require a pointer rebuild. Which, being as it is internal to PCS, might be accomplished. But with the current mediavp's, we did run in to a problem (I think when removing the :v: modeled thrusters) that texture slot shifts did not carry over as it was, which led to bad mapping problems or just some textures listed but not displaying on the model.
If this is something that _should_ already be possible, a step course on how to achieve it properly would be appreciated.
-
Also the user settings should not be stored in the programs folder. It will not be able to save the settings running as regular user under Win 7 (you must run as admin to make modifications to the folder).
UIh....what? First time I have ever heard of this problem.
For apps in PROGRAM FILES or other WinOS dependent directories, this is a problem (ish) with work arounds. For user generated directories, this problem should not exist unless something got borked.
Error message when hitting ok during save.
21:12:31: can't open file 'C:\Program Files (x86)\POFCS2\pcs2.ini' (error 5: access is denied.)
21:12:31: Error saving user configuration data.
Settings are saved for that program session only.
On the bright side, once you've gotten everything right, it's harder to muck up. :P
-
if i ever feel like writing code in my free time again i'll fix that stuff... i still haven't been giving the patches for Collada support.
the repo is public, if someone else wants to take over primary maintainer ship they can.
soul-sucking job makes me want to do things other than coding when i get home
-
I think Spicious might be sitting on the patches until he gets that bounty money or whatever. Has that been paid out yet, anyone know?
-
Ufff da.... In Win 7 Aero must be enabled otherwise the model preview window will be solid light grey. This means you can't have studio max 9 running and pcs2 at the same time. :blah:
Probably driver issue.
edit: Studio max 9 and earlier (i don't know about 2008)
-
Newer Max (2009) doesn't shut off Aero does it? I noticed this problem with Max 8 but not with Max 2009.
-
So is there some place for recent/nightly builds of PCS2 or what?
-
They're not stable. For the most part the pof saving is broken right now, to my knowledge. Unless it's been fixed since the last time anyone released a 2.1 based build. Code is publicly available though if you want to make a build.
-
code is in an inconsistent state as I do have some cleanup to do. i'll try to get it done sometime soon.
Hey spicious.. you DO know the license this code is under riiight? give me those patches
-
Kaz, there was a bounty put out for the specific feature he was working on. This was also just speculation on my part. I would like to see those patches get into the main code soon though.
-
Kaz, there was a bounty put out for the specific feature he was working on. This was also just speculation on my part. I would like to see those patches get into the main code soon though.
it's GPL
though he did give me patches a long time ago they didn't work with trunk so i asked him to port it and give me the patches.
-
We'll get it, don't you worry. Threatening the license though isn't going to be very effective, all that does is give you the ability to sue him for distributing modified code without the sources (although he has offered to make them available, it's just been hard getting a hold of him). You wouldn't actually sue him though, I doubt, so it's kind of a moot point. Have you directly contacted him recently to see if he would make the new patches available?
-
We'll get it, don't you worry. Threatening the license though isn't going to be very effective, all that does is give you the ability to sue him for distributing modified code without the sources (although he has offered to make them available, it's just been hard getting a hold of him). You wouldn't actually sue him though, I doubt, so it's kind of a moot point. Have you directly contacted him recently to see if he would make the new patches available?
i was just making a point about the license.
i have attempted to contact him in the past over and over and never get patches that work with head
-
Well all of his recent releases were made using the 2.1 alpha version of trunk, so whatever he's using now should work with the current (or a more recent version) of trunk. *sigh*
-
Good luck.
[attachment deleted by ninja]
-
Gracias, senor, gracias!
-
Good luck.
Thank you, Spicious. :)
-
excellent.. if i ever get around to things...
-
He got you the damn code, you better get around to it! You have any idea how many people would appreciate that? That's what fuels you right? People using your creations? Sorry don't mind the drunk...
-
I have a problem with selecting subobjects with OpenGL VBO activated ,whenever I try it PCS2 crashes. (the error pops up and when I close it ,it appears again)
I also have noticed that PCS2 is missing one of the features of PCS1 ,namely squadron insygnia editor.
It would certainly come in handy for some people ,I don't like this editor in PCS1 ,because it doesn't show current position of the insygnia.
-
IT's alive! it's Alive!
(IT would be me)
-
Good to hear man. You've got great timing, let me tell you.
-
Dang guess that means the hunt is off and I just finished loading the custom rounds for the rifles. Guess we should cancel the order for the camping equipment and Sherpas as we don't need anyone to lug the beer through the mountains and jungles now.
-
hit him with a tranq before he leaves!
-
I just want the code to be restabilized so i can start adding features again (i.e. destabilize it). I just want a safe stable base to start trying to do experimental things, like a geometry editor. I think I may have figured out a way to do that without completely rewriting everything.
-
density variable for mass and moi computations. i always found the density of water to result in mass values much lower than would be expected for a really big piece of metal. fighters in freespace being as low as 1/10th the mass of an equally sized military aircraft.
and fix the crashes with collada builds.
-
2.0.3 with Collada was always pretty stable for me. Just didn't do everything it needed to.
-
density variable for mass and moi computations. i always found the density of water to result in mass values much lower than would be expected for a really big piece of metal. fighters in freespace being as low as 1/10th the mass of an equally sized military aircraft.
and fix the crashes with collada builds.
Collada code isn't mine, but it'll be part of the cleanup
Bob: once we move to SVN it'll be much easier for you to have your own branch to trash.
-
but I want it NOW!
-
but I want it NOW!
the lady wanted to go buy rollerblades tonight, and then i'm going to go do ;7 ;7 ;7 with her
tommorow she wants to use them.
i'm going to try to get some time this week to integrate it.
-
Updated to reflect that The_E is going to make the UI much more awesome.
-
Please wander over to the new board for FS2 Modding tools http://www.hard-light.net/forums/index.php?board=193.0
please repost any requests that have not been added to the officially slated or officially rejected list. thread per feature so it isn't so confusing.