Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Tools => Topic started by: Spicious on November 11, 2010, 06:41:36 am
-
Next up on requested PCS2 features is applying transforms (scaling, rotation, translations) to either the entire scene or to specific subobjects, turrets etc.
What do you want it to do? Describe your use cases!
-
It can do translations already no? (just change the centerpoint coords of the subobject in question, or just drag it IIRC)
Scaling and rotation would be awesome though.
-
Scaling would be appreciated. I've often rigged something in Max, thought I had it down
size wise, only to throw it in PCS2 and be off a few meters from where I wanted it.
So having a viewport scale and then a text box for precise values in XYZ planes would be helpful.
I would also suggest that if you continue to add "tool" functions, it might be wise to put them
into a utilities drop down menu. This way you're not cluttering up the normal rigging display.
-
Scaling is the big one. With and without points. I just had to rescale a ship and max messed it several times in different ways(but only on newer nvidia cards for some reason) so it's not the easiest thing.
I have moved objects in PCS2 (by accident). Is it possible to move just pivots? That might be something useful as well. Had a use for it once before. Pain to tweak the pivot, export, import, make pof, repeat.
Cloning an object might be nice as well.
-
Translation for individual subobjects would probably be for moving its pivot, or for handling moving other things linked to it (paths).
It should already be possible to copy subobjects.
I would also suggest that if you continue to add "tool" functions, it might be wise to put them
into a utilities drop down menu. This way you're not cluttering up the normal rigging display.
Local transforms would probably end up with a button with the new/copy/delete buttons. Global would end up with a menu item like global import.
-
just support a 4x4 transform matrix. that should be able to handle everything.
-
Cloning an object might be nice as well.
You can already clone objects, just save it as a pof, and import the object from the POF you saved :P
-
just support a 4x4 transform matrix. that should be able to handle everything.
That doesn't answer the question. A matrix doesn't do anything by itself.
Cloning an object might be nice as well.
You can already clone objects, just save it as a pof, and import the object from the POF you saved :P
Or you could use the copy button:
[attachment deleted by admin]
-
Well in older versions sometimes that copy button would spit Array out of Bounds. If that's fixed then :) :D
-
I'd like to be able to set object origin, or whatever it's called, myself in pcs. I am talking about the point the subsystem is rotating around. It is alrady possible to choose axis, but I think I can't SET it. Correct me if I am wrong
-
just support a 4x4 transform matrix. that should be able to handle everything.
That doesn't answer the question. A matrix doesn't do anything by itself.
my point was that most transforms can be represented with a 4x4 matrix. you could probibly calculate one yourself and enter all 16 values, and then click apply. and the submodel in question would be transformed by that matrix. all you would need at that point was a front end to do common stuff rotation/translation/scale/mirroring maybe some other advanced transforms, and maybe raw matrix to cover any other bases that modders may come up with.
-
I understand that point. A 4x4 matrix is what I'm planning on as at least the initial input method (though probably only allowing editing of the first 3 rows). Under the hood it's actually a 3x3 matrix plus a translation vector.
The question is more about what the frame of reference should be.
For a subobject, should the transform be with respect to the pivot, or the subobject's parent, or to the origin?
In general, each choice produces very different results.
-
That would probably depend on if you are doing transforms on multiple objects or single ones. For instance if you want to scale the whole model then detail0 pivot would be the one to use. If you are only scaling a single subobject I believe that modeling programs use the objects pivot. Now it gets tricky if you want to do multiple subobjects. Do you use the calculated center based on all of their pivots or detail0?
-
There are no transforms on multiple objects, unless they're naturally grouped already (glowpoints, dockpoints etc.). Now, for dockpoints , the obvious pivot is the origin, but there's also potential applications for pivotting about the centroid.
So far it's possible to transform subobjects, turrets, eye points, thruster glows and glowpoints. Transforms on subobjects also transfer to their associated child subobjects, turrets and eye points.
-
I understand that point. A 4x4 matrix is what I'm planning on as at least the initial input method (though probably only allowing editing of the first 3 rows). Under the hood it's actually a 3x3 matrix plus a translation vector.
The question is more about what the frame of reference should be.
For a subobject, should the transform be with respect to the pivot, or the subobject's parent, or to the origin?
In general, each choice produces very different results.
you definitely want some kind of origin vector. id love to be able to set origins of subobjects, but thats another feature entirely. in practice you would set the origin (or use the existing origin) before applying the transform.
-
It's ready to play with. The transform button replaces the save button next to the load button. It applies to globally if the header is selected, or to the current object otherwise.
Edit: As an added bonus, the render should continue working (without needing to reload textures or similar) after visiting the preferences dialog.
-
Has anyone tried this?
It now has friendlier transform input options (scale, translate, rotate).
-
I tried it and I like it. New rescaling is a great. I hasn't tried matrix, because I don't know how it works, but it can be effective tool in proper hands :yes: .
-
Testing would be easier if we had any idea at all on how to use this. :p
Entering random numbers into individual cells of the rotate dialogue box didn't have any effect until I tried the last one - the rightmost box which apparently defines rotation about the ships X axis?
Then I changed the leftmost box from the default 1 to a 0 and my subobject vanished. :(
-
Maybe I should have left it just with the 4D matrix input. There's no ambiguity there.
The rotation thing is the first three specify the rotation axis and the fourth the rotation angle (in degrees) about that axis.
-
Haha, I think there might need to be an additional layer to the interface to make it usable for normal people man. ;)
-
The options that aren't matrix are supposed to be that easier layer.
Is the rotation one better now?
-
What changed since the last one? I can't see anything different?
Basically what I'm saying is that in its current form, almost no one will have a clue how to use it, regardless of how detailed any documentation is. From a user standpoint, having to do it in matrix form just doesn't make any sense.
So, what I'd suggest is changing it to something like one of these:
OK: A dialogue with 3 fields for rotation (in degrees) about the X, Y and Z axes. This would be ok for simple rotation tasks but tedious for anything more.
Best: In addition to the three-field numerical system, have a system where you select an axis you want to rotate it around (essentially radio buttons of X, Y, Z or user-defined vector) from the top menu, and then shift+click&drag lets you rotate the object around that axis in the 3d window. This system lets users very quickly define any rotation they want because of the real-time feedback, and lets them experiment a bit too.
(Oh and also, any operation needs to be undoable plz! :) )
-
What changed since the last one? I can't see anything different?
Labels
Basically what I'm saying is that in its current form, almost no one will have a clue how to use it, regardless of how detailed any documentation is. From a user standpoint, having to do it in matrix form just doesn't make any sense.
That's why the other options are there now. If a transform cannot be expressed as a sequence of scales (which includes flips with nothing ending up inside out), rotates and translates then it's time to learn some linear algebra.
So, what I'd suggest is changing it to something like one of these:
OK: A dialogue with 3 fields for rotation (in degrees) about the X, Y and Z axes. This would be ok for simple rotation tasks but tedious for anything more.
Probably doable without too much effort. Most likely to just be the current rotate option + radio buttons for the standard axes.
Best: In addition to the three-field numerical system, have a system where you select an axis you want to rotate it around (essentially radio buttons of X, Y, Z or user-defined vector) from the top menu, and then shift+click&drag lets you rotate the object around that axis in the 3d window. This system lets users very quickly define any rotation they want because of the real-time feedback, and lets them experiment a bit too.
Sounds painful...
(Oh and also, any operation needs to be undoable plz! :) )
Not possible for anything that affects other objects without a rework of the undo system. We'll see...
Any sensible transform should be invertible anyway.
-
I can't see any labels sorry. (the version in your sig was last modified on the 27th)
That's why the other options are there now. If a transform cannot be expressed as a sequence of scales (which includes flips with nothing ending up inside out), rotates and translates then it's time to learn some linear algebra.
Not quite sure what you mean here. Like, yeah sure any transform can be expressed that way but that's got nothing to do with the usability of the feature for the target users.
Probably doable without too much effort. Most likely to just be the current rotate option + radio buttons for the standard axes.
That would be cool enough for now. :)
Sounds painful...
I was hoping it wouldn't be, but oh well. :\
-
I can't see any labels sorry. (the version in your sig was last modified on the 27th)
You're probably getting a cached version.
I was hoping it wouldn't be, but oh well. :\
On second thought it probably definitely isn't. Probably painful to use without being able to undo though. Getting undo working with transforms is rather non-trivial, but undo needs fixing in general anyway; try deleting a subobject and undoing to see why.
Something should be ready to try shortly.
Edit: It's ready. Hold down alt and:
- left click to translate;
- right click to rotate;
- scroll your mouse wheel to rescale.
The movement constraints in the toolbar apply.
-
!!!!!!
:eek:
Dude! Brilliant! :D
Seriously that's heaps smoother and faster than the systems I was thinking of.
(And frighteningly quick too - massive well done!) :yes:
-
(And frighteningly quick too - massive well done!) :yes:
That's how a nice-ish design helps. Most of the work for this was already done.
Probably doable without too much effort. Most likely to just be the current rotate option + radio buttons for the standard axes.
That would be cool enough for now. :)
This is done now, and for scaling too.
-
Wow! Again! :eek:
And it has the custom axis vector option too! Brilliant!
Unstoppable man. :cool: :yes:
Also I reckon this has opened up a TON of possibilities for fredders or other people who want to change models without learning to use a 3d app and go through the rigmarole of learning to convert back and forth.
Ie, if a fredder suddenly finds they need a freighter with say, a radar and a few extra guns for a particular mission, they can do it in a few minutes! :)
-
There's still plenty to do:
- options for transform origin, most likely just:
- centre of the current thing or centroid if there are multiple things
- centre of its parent or (0,0,0)
- subobject rotation axes - are arbitrary rotation axes ever coming?
- transforming subobject property fields
- transforming/adding fvec/uvec
- what to do with detail boxes
- undo
I welcome suggestions on how to deal with some of these issues.
-
Just got a crash with this build. All I did was load a .dae, calculate moi, a global import, changed eyepoint and glow point parents, and do a autogen on paths. I've tried it 2 more times and no luck reproducing. The crash happened when exiting PCS2.
That brings me to my next request. Have autogen generate paths for subobject subsystems not just special point ones.
-
Just got a crash with this build. All I did was load a .dae, calculate moi, a global import, changed eyepoint and glow point parents, and do a autogen on paths. I've tried it 2 more times and no luck reproducing. The crash happened when exiting PCS2.
I've noticed this happening sometimes; I'm not sure why yet.
That brings me to my next request. Have autogen generate paths for subobject subsystems not just special point ones.
That's not how the system works, but this one's pretty trivial so it's done.
-
These new PCS2 builds have a little issue on Win7.
Whenever I try to select new pcs2.exe to open a pof file with, Win7 won't display the new exe in recommended programs list at all. See picture. Pcs2-insignia.exe is the build from July 29th with insignia support. Pcs2.exe is an old build from February 2008.
When I deleted both of those older exes, with only new exe with transform support remaining, Win7 decided to open pofs in aniview for whatever reason, that's why it too is now displayed in the screenshot's recommended programs. I can only open pofs in new pcs2 exes if I first open the application and use open file dialog from there. It's annoyingly slow.
I wonder if others have noticed this on Win7 or if I'm the only one?
[attachment deleted by admin]
-
I haven't noticed this, but I usually replace the old version with the new.