Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Goober5000 on February 08, 2016, 09:53:34 pm
-
I require a simple POF model for the purposes of testing the look_at feature, as described in Mantis #3115 (http://scp.indiegames.us/mantis/view.php?id=3115) and GitHub pull request #530 (https://github.com/scp-fs2open/fs2open.github.com/pull/530). Could any of the HLP model makers help me out? It requires no textures and can be composed entirely of model primitives. All it needs are a series of submodels arranged in a certain way, in a certain orientation.
I've created a very ugly prototype by messing around in Sketchup for 15 minutes. See the attached picture and model files in Sketchup, Collada, and 3DS formats. This model is only for reference purposes; I shudder to think what might happen if someone actually created a POF based on it. :)
The main model should be a T shape, where the top of the T is pointed in the positive Z direction and the cross-bar of the T is along the X axis. On either side of the T's cross bar should be individual submodels (cubes or spheres). These two submodels will serve as targets for the submodels that have look_at properties. The T should lie entirely on a flat plane, and the centers of the two submodels should be on that same plane.
On the bottom of the stem of the T should be a vertical pivot point, on which three arrow submodels are mounted. The arrows should be made of shapes that clearly point forward in the positive Z direction, and the point of the arrow should be aligned with its centerline. The three arrow submodels should be able to pivot left and right on the Y axis. There should be one arrow that is on exactly the same plane as the T and the two target submodels, one arrow a short distance above it, and one arrow a short distance below it.
Note: it should be possible to tell whether each arrow is rightside-up or upside-down. I illustrated this in Sketchup by giving each arrow a peaked "roof". The coplanar arrow and the top arrow should be rightside-up. The bottom arrow should be exactly 180 degrees upside-down, but still aligned with the axes (in contrast to the Sketchup model where the bottom arrow is not quite rotated 180 degrees).
Thanks for your assistance! Your contribution will allow me to close out the look_at feature, which should lead directly to the release candidate stage of version 3.7.4.
[attachment DELETED!! by Strong Bad]
-
:confused: I uploaded this when I did the bug report Goob.
http://scp.indiegames.us/mantis/file_download.php?file_id=2575&type=bug
It has look at all set up and ready to go.
-
It turned out that look_at wasn't set up correctly according to vector math, and that model was using those incorrect vector calculations.
-
More specifically, the Praetor submodels seem to have their orientations flipped or offset by 90 degrees.
The Praetor model was very useful throughout the majority of dumb_rotate and look_at coding, but now I've run into the issue where the submodels simply aren't pointing in the proper direction. I decided to run a simple test using the Orion model and the submodels point exactly where I expect them to, whereas the Praetor submodels don't. Now I want to verify this with a model that unambiguously has submodels lined up in the standard orientations.
-
Any takers?
I see that model_exports.zip has been downloaded by two people, so I assume both are competing to see which one can finish it and post first. ;)
-
I've seen it and I'd like to help... But to be honest, I don't get it :P. I mean I don't understand which model should me parent, which submodel and stuff. I have no idea how to set hierarchy properly, based on your description.
-
The T, plus the vertical pillar, should be the main model. The submodels are the arrows and the spheres/cubes on the sides of the T.
Black Wolf is taking a look at it though, so your help may not be needed. But thanks. :)
-
Color coding is your friend...
-
Any takers?
I see that model_exports.zip has been downloaded by two people, so I assume both are competing to see which one can finish it and post first. ;)
I'm the second taker.
Here's what I have now:
(http://www.ciinet.org/kevin/myimages/others/look_at_test_2.blend.png)
I spent a lot of time unifying the T, the big pillar, the middle arrow, and the cylinders at the side. However, I just now removed the cylinders from the side and replaced them with subobjects.
-
Ah, brilliant. Thanks, this is exactly what I wanted. :)
Yes, the two cylinders at the side, as well as all three arrows (not just the top and bottom) should be subobjects.
-
Done.
Is this the orientation you wanted? (Green = Y, top of screen is bow (front), bottom of screen is aft (back))
(http://www.ciinet.org/kevin/myimages/others/look_at_test_3.blend.png)
EDIT: I changed the orientation so that the top of the "T" points forwards. Here's the POF (http://www.ciinet.org/kevin/myimages/others/look_at_test_2.pof).
-
Thank you, this looks perfect. :) I will test it post-haste.
EDIT: Eek, this is way too small! Could you scale it up about 100x? The size of a Fenris would be good.
EDIT2: Also, it looks as if you simply imported the Sketchup model, rather than creating three separate arrow submodels and duplicating them. Can you tell me whether the bottom arrow has an "upside down" orientation relative to the others?
-
A recent build of PCS2 can scale up models without needing to go back into the modelling program.
I was expecting you to edit the subobjects in PCS2 anyways, since I have absolutely no idea how look_at works.
EDIT: New version of POF (http://www.ciinet.org/kevin/myimages/others/look_at_test_3.pof). Now much larger, and uses the same mesh for all 3 arrows. The arrows' pivot points have been slightly adjusted, as well.
-
Hmm. Are the pivot points in the center of the submodel? And does the point of the submodel align with the submodel's local axis? Because the submodels are pointing somewhat askew, and I wonder if it's because the submodel's local coordinate axes aren't precisely aligned. See the attached screenshot.
This is why I suggested using my Sketchup model as a prototype, rather than converting the Sketchup model directly. I made no attempt to line up the corners.
I see that the bottom arrow is also aligned the same way as the top two arrows. Can you flip the bottom arrow upside-down, i.e. 180 degrees around the Z axis? Currently all the models are pointing in the correct general direction, but I want to test whether that direction is orientation-dependent.
[attachment DELETED!! by Strong Bad]
-
New version of POF (http://www.ciinet.org/kevin/myimages/others/look_at_test_4.pof).
This is where the pivot points for the arrows are. The pivot points for the cylinders at the sides are in the center of each cylinder.
(http://www.ciinet.org/kevin/myimages/others/look_at_test_4.blend.png)
-
Hmm. It appears that, even though the bottom arrow is now rotated, it still has local coordinate axes that are aligned with the model's coordinate axes.
I had thought that flipping the bottom arrow upside-down would also cause the submodel's coordinate axes to be upside-down relative to the model's. Is it possible to do this?
-
I don't know if that's possible or not. I'm thinking that it might be possible through use of the animation code for initial rotation, but as far as I know, it's only possible to use that code to set an initial orientation for multi-part turrets.
-
Here's what MjnMixael had to say on IRC:
[20:37] MjnMixael Goober5000, if I understand that thread correctly, he'll need to reset the xforms (Blender calls that something different) in order to get the submodel axes to change with the geometry
[20:37] MjnMixael i think
[20:37] MjnMixael it's possible that I have no idea
This is consistent, at least, with my experience: I know that submodel orientations can be changed, but changing them in PCS2 doesn't work (that is, the shape is rotated, but the axes remain the same as the world axes). This leaves the source modeling program as the only option.
-
PCS2 will complain and refuse to import ("instance geometry not found") any geometry that's axes are not the same as the world axes (this is what resetting the x-form does no?). In which case you'd have to try some POF converter that isn't PCS2. That is, if it's not a limitation/requirement of the POF format itself that things be that way.
Could be totally wrong and have no idea what I'm talking about but that seems to be what I've observed when converting things.
-
Err. Hmm.
Well, then, is there anything different about radardish01 (the one on the bottom) and the other two radardish submodels on the retail Orion model? Because I gave all three of them look_at properties to look at a certain turret. The two dishes on the top of the Orion are looking at it properly, but the dish on the bottom is looking 90 degrees away from it.
-
Talon, can you post the model you used to create the POF?
-
OK. Here's the Blender file (http://www.ciinet.org/kevin/myimages/others/look_at_test_2.blend).
-
Thanks. Vasudan Admiral may be able to use it to adjust the orientations, depending on what we need to test next.
-
I'd like to learn how to change the axes of a submodel in Blender myself.
According to this blog post (https://blenderden.wordpress.com/2014/12/28/transitioning-from-3dsmax-to-blender/), the equivalent of Reset XForm in Blender is Apply Location/Scale/Rotation/etc.
15) ResetXForm. In 3ds max, to reset an objects transformation, you access the utilities panel and click on Reset XForm button. This will reset all transformations. In Blender, you have the choice of resetting only a certain type of transformation. Go to Object>Apply>Then choose the type of transformation you want to reset.
However, I think doing this just rotates the shape and sets its axes to be the same as the world axes.
Before applying rotation:
(http://www.ciinet.org/kevin/myimages/others/look_at_before_xform.png)
After applying rotation:
(http://www.ciinet.org/kevin/myimages/others/look_at_after_xform.png)
-
Thanks for the update. I don't know if it's related, but Vasudan Admiral has discovered that there may be a problem in the way FSO treats submodel hierarchies. He'll be running more testing, and maybe your above post will have some relationship. Hopefully VA himself will post in this thread. :)
-
Well he could, but that would just take all the mystery out of me wouldn't it? :P
Ok so Talon: You're on the right track with how to do that in Blender. "Ctrl+A -> Apply scale and rotation" with all objects selected. When you export to DAE you want them all to read 0° rotations, and 1.0 in scale. (Otherwise chances are that PCS2 will make them into 0° and 1.0 with no regard for what that does to the model!)
Note: The POF format as far as I can tell, doesn't care at all about subobject rotation. I don't think it even stores it. So however something appears in a POF has no rotation in-game unless that is defined for that subobject, and then the game will handle that.
Anyway so we managed to get the look_at function working...sort of. We found that a lot of the problems I was having were actually due to naming my test model's hydraulic rams things like 'Ram1_A' and the matching 'Ram1_B', all because FSO unhelpfully interpreted them to be different LODs of the same object, which then didn't play nice with the look_at code.
But where it stands now is that if your look_at enabled subobjects are attached to the hull, or attached to another subobject that is attached to the hull, then they will work fine: http://slickpic.us/1092822NDVl
Where it fails is anything further down the hierarchy than that - the further down you go, the more your look_at subobjects will miss their target by. That implies to me it's a cumulative error in the code that runs through the hierarchy to work out where things are in relation to each other.
If people want to have a look themselves, here's a test model with a table and test mission: (Though you'll need Goob's latest builds, which I don't think he's posted here)
http://www.mediafire.com/download/j27ifbegf9q63cr/LookAtTestRod_H.zip
The key "1" extends the 3-segment arm, "2" retracts.