Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Bobboau on November 22, 2006, 06:49:40 pm
-
executable (http://freespace.volitionwatch.com/blackwater/fs2_open_Bobboau_11-22-06.zip)
there are also two test pofs that demonstrate how to implement the new amaizeing spectacular "look at" feature, this non-subsystem movement option allows you to make an object that will always do it's damnedest to keep it's look at target in the same relative radial position with it's rotation constrained to one axis. that axis can, of course, be defined to be anything at all useing the off axis rotation feature (and given the nature of look at fvec can be just about anything at all other than 0,0,0).
the most obvious use for this (and the one I invented it for, and tested it with) is hydrolic/pneumatic cylinders. when placed properly two cylinders told to look at each other will effectively appear to be pushing and pulling the objects they are attached to apart and together.
this will be considered an advanced animation technique, because it requires you to have a working animated set of objects already, as it won't be of much use in the arenas I've tested it with (rotating subobjects and turrets (although you might be able to make a cool looking turret using this if you tried a lot harder than I did))
-
Ooooh, so what you're saying is that when a laser turret on an Orion is tracking a fighter, it will actually LOOK like it's tracking it?
-
no, this allows one subobject in a model to look at another subobject in the same model.
turrets already do that.
-
(http://www.dykesplanthire.co.uk/images/pic-construction01.jpg)
look at the arm on that, you can make those piston thingys that make the arm move now.
-
Oh wow. This is going to be oh-so-cool for oh-so-many things I have planned. Awesome and thanks a million! :D
BTW, did you get the PM I sent a few weeks back asking about the detail boxes?
-
yeah, you wanted it to be a detail sphere instead right?
-
turrets already do that.
In a VERY jerky way. When I look at any turret and it's firing The Blob, it jerks to look at the target before firing. =/ I figured this had smooth rotation. :nervous:
EDIT: Wait, hmm... Last time I saw it, anyway. Which was last month or so.
-
well, I happen to be working on fixing that as well at this very moment.
-
yeah, you wanted it to be a detail sphere instead right?
Don't think I mentioned shape actually - I was just wondering if you could get the custom bounding box feature up and running. It's the only non-working part of the detail box feature. :)
I've been trying to use the 'invisible cube to pad-out the bounding box' technique that Omni used on his Death Star, but this screws up the ships radius and thus the target display, target box and chase cam position if the invisible geometry needs to be a fair bit bigger than the actual ship.
-
I've been trying to use the 'invisible cube to pad-out the bounding box' technique that Omni used on his Death Star, but this screws up the ships radius and thus the target display, target box and chase cam position if the invisible geometry needs to be a fair bit bigger than the actual ship.
You know that the detail box stuff was recently fixed to actually work properly, right?
-
I guess this means we can make steam trains in space now, right? :lol: Anyway, I was looking at the test pof data, and trying to see if one could hack together a turret recoil system based on this feature, but to no avail. Looks like we'll have to wait for subobject translations for that.
-
You know that the detail box stuff was recently fixed to actually work properly, right?
lol, if I had, I wouldn't have asked for it. ;)
When & where is this sorta fix announced though? 'cos HLPs search is useless at the moment, and in this case it's rather labourious to re-test it with each successive build.
-
You know that the detail box stuff was recently fixed to actually work properly, right?
lol, if I had, I wouldn't have asked for it. ;)
When & where is this sorta fix announced though? 'cos HLPs search is useless at the moment, and in this case it's rather labourious to re-test it with each successive build.
Uhh, you know, I don't think that I ever even mentioned it on HLP. :) It was something that DaBrain was having trouble with and all of the discussion took place on GW. The the problems were:
1) it didn't read the box details out of the model properly (it could only read out the X var, it screwed up on the Y and Z)
2) box checking was based on View position rather than being based on Eye position and the offset from parent model like it should have been
3) children of a (sub)model would have the detail box check run twice and often fail the second time when they shouldn't have
4) (sub)models which wouldn't have drawn anyway would still get the detail box check and slowed down rendering
All of those things were broken in the initial commit of the code btw, so it has never actually worked properly. I also tied the detail boxes to the model detail slider. Maxed out (level 5) it will scale the values in the model by 120%, at level 4 it will just use the values in the model, scaled by 80% at level 3, 50% at level 2, and 20% on the lowest detail level.
-
I guess this means we can make steam trains in space now, right? :lol: Anyway, I was looking at the test pof data, and trying to see if one could hack together a turret recoil system based on this feature, but to no avail. Looks like we'll have to wait for subobject translations for that.
Oh recoil is possible. (It's a bit jumpy though)
http://www.game-warden.com/narfin/movies/recoilaction.avi
Though it won't recoil if any part of the turret is moving.
-
1) it didn't read the box details out of the model properly (it could only read out the X var, it screwed up on the Y and Z)
2) box checking was based on View position rather than being based on Eye position and the offset from parent model like it should have been
3) children of a (sub)model would have the detail box check run twice and often fail the second time when they shouldn't have
4) (sub)models which wouldn't have drawn anyway would still get the detail box check and slowed down rendering
All of those things were broken in the initial commit of the code btw, so it has never actually worked properly. I also tied the detail boxes to the model detail slider. Maxed out (level 5) it will scale the values in the model by 120%, at level 4 it will just use the values in the model, scaled by 80% at level 3, 50% at level 2, and 20% on the lowest detail level.
Crikey, well those problems would explain some of the odd behaviour I saw but attributed to being because of the custom bounding box wasn't working. Excellent. :D
-
This is awesome Bobboau!
After reading about one of your new features I instantly get ideas how to use them.
Also... my idea to create a tech demo, showing all of FSO's features more and more becomes a plan. ;)
Btw, do you have access to the SoL internal already?
-
Crikey, well those problems would explain some of the odd behaviour I saw but attributed to being because of the custom bounding box wasn't working. Excellent. :D
Oh, almost forgot to add that FRED2 has full support for this too. Based on your view position in FRED it will also use detail boxes like it will in-game. But, FRED2 has a View menu option called "Render full detail" will render every object regardless of whether or not it uses a detail box. This should help you figure out how things look to the player in-game, and also be able to see everything at once to figure out how to properly position things.
The Lab (F3 from the mainhall menu) also has a "Render full detail" checkbox in the Render Options menu which will also show everything there. Between this and the FRED options it should make it easier to figure out your detail box setup as well as help debug it without actually having to jump into a mission to see what the player will see.
-
Ooooh, even more excellent then! Thanks. :)
BTW, Bobboau - might this work you've been doing with Uvecs and Fvecs lead into a workable way to handle subobject translation?
It's pretty much the last remaining thing that we can't properly do with the animation system - and it would allow for a lot more situations you could use this look-at feature with.
In fact there wouldn't really be any types of mechanisms you couldn't quite easily build using combinations. :D
-
Thanks a lot! Thats a cool function! :D
-
Oh recoil is possible. (It's a bit jumpy though)
http://www.game-warden.com/narfin/movies/recoilaction.avi
Though it won't recoil if any part of the turret is moving.
How the **** did you do that ?!?
@Bob: Is the "$look_at:subobject number" in the sumbmodel properties field all that's needed to get this working ?
-
Not sure if this is how that particular recoil is done, but there was a new animation type added not too long ago that triggers an animation when the turret it is a part of fires.
To fake the translation, the recoiling part would need a centre with a big offset from the actual geometry, so when it rotates a very small distance, it appears to be sliding. However, the tiny rotations also mean it's hard to have fine control over - which is what I'm guessing causes the jerk?
http://www.hard-light.net/wiki/index.php/Animation_Code
Specifically:* turret firing
- Animation code is started when selected turret is firing
-
Bingo VA. ;)
-
ok...
"2) box checking was based on View position rather than being based on Eye position and the offset from parent model like it should have been"
that was intentional, View_position is the camera rotated into the model's frame of reference, you just see if it's coords are bigger than the box and it works, there is less math involved in evaluating a box this way, and if you base it off of the eye position then you need to sum up all the offsets in lower children, otherwise it isn't right. a lot of the code involved was originally coded to minimize the cost of a render box evaluation (and the failure there of).
----------
no I don't have access to the SoL internal
----------
I have in a separate code base some work done on getting translation working for triggered animations, the biggest problem is related to bounding boxes and when an object moves far enough that it is no longer in it's parent's bounding box it gets culled from collision detection when it shouldn't. the obvious solution to this is the check all objects that have a translation even if they fail up stream bounding box checks, but given the nature of the object hierarchy tree this is a bit more complicated than it would first seem, I'll probably need to add a subobject flag that indicates that a child has a translation applied.
there is also exactly 3.7 ****loads of places were the code assumes that an object or subsystem's position never changes, and so it will for example precalculate a subsystem's position relative to the ship.
----------
"Is the "$look_at:subobject number" in the sumbmodel properties field all that's needed to get this working ?"
yes, as mentioned it's a non-subsystem animation type, as it does not need to keep track of any information between frames (like triggered animations do) they don't need to be part of a subsystem
-----------
another way you could fake translations in the mean time would be with use of several invisible subobjects that would form a trapezoid, you just squeeze the angles and the top would shrink.
-
ok...
"2) box checking was based on View position rather than being based on Eye position and the offset from parent model like it should have been"
that was intentional, View_position is the camera rotated into the model's frame of reference, you just see if it's coords are bigger than the box and it works, there is less math involved in evaluating a box this way, and if you base it off of the eye position then you need to sum up all the offsets in lower children, otherwise it isn't right. a lot of the code involved was originally coded to minimize the cost of a render box evaluation (and the failure there of).
It is still based on View_position, I didn't mean to write "Eye" there. It does still need to facter in the offset though to deal with how the detail box values are set, at least in an intuitive manner. Otherwise you will have to factor in the offset into the detail box boundries before hand, which means that it has to be done by the model maker. I'm not sure how it was used before, but after tracing through the original code I couldn't see any way how it would have worked properly before. Only if the model maker did an excessive amount of work which was totally unnecessary, perhaps, but that it was apparently too screwed up for anyone to actually get working.
Having it based on anything didn't really matter though, since the min/max Y and Z coords for the detail box were never used from the model. That it worked at all in the first place is something of a miracle. :)
-
it was originally coded to allow for highly detailed hanger bays, so originally it just used the object's bounding box, the option to define a separate box was actually an after thought.
anyway, if it works now thats fine.
on the subject I asked about the detail sphere thing because I was implementing it, I might even make a full subobject LOD in a bit.
-
Somehow, I can see this being used to create a lot more than just pneumatics. I think the Star Wars guys could probably recreate the Battle of Hoth now if they wanted to. ;)