Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Trivial Psychic on November 30, 2006, 11:11:50 pm
-
Howdy All:
I was recently helping a friend setting up FSO and the latest eye candy (the friend who in fact, introduced me to FS in the first place) and he noted that we don't see the ambient glow from ship engines, when you're not looking directly at the engines, say from behind. I seem to recall that this disappeared sometime around the introduction of the first 3.6.9 release candidates. I recall that a few people noticed and brought it up, others replied that they hadn't noticed until it was brought up, and a few even said that they liked it better this way. After that, there wasn't too much discussion about the subject. Has there been any attempts to restore this visual effect?
-
I, for one, would love to see it.
More eye-candy == more awesome frantic action scenes!
-
Apparently the earlier behaviour of the ambient glow (type 3, omnidirectional ball) was a bug. To get those back you may have edit the thruster radius factors in each ship entry in ships.tbl
-
As Wanderer stated, this was a bug which got fixed. The problem was that for tertiary glows the values for angle and radius were reversed. So a tbl value setting a radius would have nothing to do with radius but instead apply to the angle. There won't be any code changes to resolve this problem, since we already did that, and no functionality was removed or broken in the process. Any remaining issue is simply a data problem.
All you need to do is fix the tbl values to replicate the old way that it looked. This should be much easier to do now since the values would actually have the intended affect.
-
BTW... has anybody worked on this table already? I'd like to include it in the MV packs.
-
angle and radius were suposed to be linked... :doubt:
-
angle and radius were suposed to be linked... :doubt:
Linked? The problem was that the call to geometry_batcher.draw_bitmap() was passing the radius value to angle and the angle value to radius, for the tertiary thruster only. Do you mean that it was supposed to do that? If so then why?
-
the problematic part about this is that tertiary thruster glow does not work on capital ships. Is this intended?
-
the problematic part about this is that tertiary thruster glow does not work on capital ships. Is this intended?
Nope, and I have no idea why it wouldn't. I don't think that I've noticed it not working yet so I'll have to look into that.
-
Well, I couldn't get them to work, not on cap ships at least. And now that I think of it: only trail thrusters in TGA format will be rendered in OpenGL mode. Not that I would bother about them, but... :)
-
Just tested... All three thrusterglows work both on fighters and on capships. Tested with fs2_open_3_6_9-7dot9x.exe using OpenGL and TGA graphics.
And the scaling works also. Tertiary thruster is actually rather meaningless currently as it is very difficult to see as its so microscopic
EDIT:
Example: GTC Aeolus using single graphics file for all the glows
(http://koti.mbnet.fi/vekkup/FS2/Pics/thrusters.jpg)
The tiny specs are the tertiary glows...
-
that's the point. They are visible on fighters, but not on cap ships.
-
It seems like the tertiary glow wouldnt be scaled according to the set thruster radius value at all unlike all the other thrusterglows. That is there is no 'automatic scaling' like with primary and secondary glows but instead you have to set $Thruster03 Radius factor: to proper values
-
in other words: greater values are required for for tertiary glow? I.e. I used values around 1.0 for the first two glows, but I may need to use greater values for the third glow? I can't try it out at the moment, since I am at work :)
-
Yup, I just checked. Tertiary glows are still working on capships but are very tiny. I'm not sure if it should be scaled like the other glows, or if it's just a matter of table editing.
-
confirmed, you have to use higher values on capital ships :)
-
oh what has happened to my poor beautiful thruster effects :(
were any of the changes ever discused, cause I don't remember any discussion on the subject, I vaugely remember someone decideing to have them turned off by default, but that was about it.
angle and radius were suposed to be linked... :doubt:
Linked? The problem was that the call to geometry_batcher.draw_bitmap() was passing the radius value to angle and the angle value to radius, for the tertiary thruster only. Do you mean that it was supposed to do that? If so then why?
maybe something got changed along the way, as radius was suposed to be sent to radius, but angle was suposed to be a function of radius, this ment the bitmap would rotate semi-randomly as the thruster's radius changed small amounts, smaller radius would have smaller rotations applyed, this was because radius was a function of thrust, so the more thrust, the more chaotic the engine glow was suposed to look.
-
oh what has happened to my poor beautiful thruster effects :(
My thoughts exactly :(
-
maybe something got changed along the way, as radius was suposed to be sent to radius, but angle was suposed to be a function of radius, this ment the bitmap would rotate semi-randomly as the thruster's radius changed small amounts, smaller radius would have smaller rotations applyed, this was because radius was a function of thrust, so the more thrust, the more chaotic the engine glow was suposed to look.
I didn't change what any value was, just fixed it so everything got passed correctly. You broke that part of it when you added the geometry batcher. Right now the call works like you originally set it up, before the geometry batcher. So if it's wrong now then you coded it that way to begin with. ;)
The tertiary radius is computed differently than either the primary or secondary thrusters (you used "magatude*4" instead of "w*0.5f"), but you coded it that way so I didn't touch it. If you want to change the radius computation to be more appropriate then go for it.
-
So uhm, I was just looking through the TBP ships table. We use ship specific thruster glows on various occasions, but only set the "$Thruster Bitmap" without any "$Thruster0X Radius factor", so they all get scaled accordingly to the radius factor in the POF.
But as Wanderer noted, tertiary glows don't seem to get scaled the same way as the primary and secondary ones (but they used to be scaled the same way). I guess this is a code issue that was overlooked in the recent fixage. Could that be corrected ? Otherwise we'll have to go through the whole ship table again, introducing "$Thruster03 Radius factor"s for all ships.
-
now, I want to make sure I don't give the wrong impression, here, I've reread my last post and I may have made it sound like I was lamenting that taylor touched my code, I view this as at worse a miscomunication on desiered behavior, I am looking into the change logs right now to see who did what. and because there tends to be a great deal of drama around stuff like this, I want to nip that right now.
I haven't actualy looked at this, I'm baseing my statements on what I am hearing in this thread, I haven't been able to look at it, because I haven't had power for the last four days and I still have no internet at home.
allright from the looks of it, I may have placed the scaleing factor in the wrong place, it is an incredably stupid thing for me to have done wich makes me wonder if I forgot the real reason why I did that or, if the interface for geometry_batcher::draw_bitmap got changed at some point (I seem to recall those two parameters got swaped at one point). but it could just be that I origonaly put it in the wrong spot and nobody has used the scaleing factor this whole time and noticed it didn't do anything noticeable.
I find it hard to beleive that no one would have noticed a diference in behavior that signifigant when the change to geometry batching went in. so something seems odd about this situation, particularly, why is the current result so, obviusly (based on the screen shots and other people's testomony) not right?
I have to go home now, wich mean's I'm not going to be able to respond to anything untill tomarow, so maybe this is just people freaking out over nothing, I'll have to look at this myself.
-
I thought nearly everyone saw the altered graphics (it was changed in May i think). I reported it to taylor as soon as i saw it but after a discussion i got an impression that the earlier graphics had been a long persistent bug that had finally been fixed.
-
I think noone used the scaling factor for the tertiary glows so far, so nobody noticed the bug with the scaling factor/angle mixup. Now it's fixed, but the standard scaling (with the radius value stored in the POF) seems to be borked now. That's the situation I guess, no drama so far :)
-
DRAMA DRAMA DRAMA DRAMA DRAMA DRAMA DRAMA DRAMA DRAMA DRAMA ...
... Just getting it over with. ;) :D
allright from the looks of it, I may have placed the scaleing factor in the wrong place, it is an incredably stupid thing for me to have done wich makes me wonder if I forgot the real reason why I did that or, if the interface for geometry_batcher::draw_bitmap got changed at some point (I seem to recall those two parameters got swaped at one point). but it could just be that I origonaly put it in the wrong spot and nobody has used the scaleing factor this whole time and noticed it didn't do anything noticeable.
From the original commit of the feature I don't think that it worked. Not until the bug created by the geometry_batcher change did it work as far as I know. I went through the logs pretty thoroughly before making the change to begin with so it wasn't just some willy-nilly thing. I can say why no one noticed it wrong with the geometry_batcher change though, the default value for the angle is close enough to the default value for the radius that it was enough to fake it working properly. The problem, of course, is that the modder specified radius value had no affect on the radius. Also, the intended angle was incorrect, but I'm not sure that anyone ever noticed that properly for some reason.
I find it hard to beleive that no one would have noticed a diference in behavior that signifigant when the change to geometry batching went in. so something seems odd about this situation, particularly, why is the current result so, obviusly (based on the screen shots and other people's testomony) not right?
Here is the current issue, and why the default radius value is fubar:
primary_thruster_batcher.draw_bitmap( &p, 0, (w * 0.5f * Interp_thrust_glow_rad_factor), (w * 0.325f) );... that is the line for the primary thruster glow, and this is the tertiary glow...
tertiary_thruster_batcher.draw_bitmap( &p, 0, (magnitude * 4 * Interp_tertiary_thrust_glow_rad_factor), (w * 0.6f), (-(D > 0) ? D : -D) );As you see, with the bug fixed the (w * 0.6f) was used for the radius, and if Interp_tertiary_thrust_glow_rad_factor is 1, then it looks ok (though perhaps a little large). The problem is how the radius is done, with (magnitude * 4 * Interp_tertiary_thrust_glow_rad_factor). The radius for the tertiary glow uses a different scale than the primary and secondary glows. (Those are all the numbers from the original commit of the code, btw, and it has never been changed.)
So if the intent was for it to work the same as primary glows then changing the scale to do the same should fix the radius issue. Not sure if the angle value would still be correct though.
And I did bring this up at one point before making the changes (both Goober and myself have cleaned up the thruster code over the past year), but never got a response indicating that the changes were anything other than bug fixes.
-
Good, now that the drama is over: Will the code be corrected, so that tertiary glows are scaled the same way as the primary glows. Or will it stay that way and the correction is up to the table entry ?
Because I don't want to correct the table more than once ;)
-
From what taylor told me: we are supposed to wait for a fix :)
-
Yeah, just wait for a fix. I'd prefer to wait for Bobboau's blessing on new values to use, but I'll make the changes myself in a couple of days if he doesn't have a chance to offer anything by then. And I'll be sure to put out a test build before 3.6.9 final for you guys to test out, just in case it needs to be tweaked a little bit still.
-
I'll be sure to put out a test build before 3.6.9 final for you guys to test out, just in case it needs to be tweaked a little bit still.
Lovely! ;)
-
ok
void geometry_batcher::draw_bitmap(vertex *pnt, int orient, float rad, float angle, float depth);
int g3_draw_rotated_bitmap_3d(vertex *pnt, float angle, float rad,uint tmap_flags, float depth);
as we see here to maintain the same behavior between these two versions the angle and radius values need to be swaped.
here is the problem, it would seem the radius scaleing factor was put on the wrong parameter in the earliest version of the thruster effect, not when it got ported over to the geometry batcher. the default value for this scaleing factor is 1.0, so it has no effect unless it is specificly changed, and if you tried to change it all you would likely notice is nothing happened (the angle probly wouldn't jump out at you unless you were looking for it, also this is a little known feature, so I doubt many have tried) so, I think the way to handle this should be to put the two parameters back the way they were, and move the scaleing factor over to the corect parameter. this would put the effect back into the same basic behaviour that we have been used to for the majority of it's life
magnatude is based on the normalization of the thrust vectors, and is thus never more than 1, so the current code will draw the glow with a radius of only 0-4, no mater the size listed in the pof, or the size of the model.
obviusly 0-4 makes more sence as something that would have to do with radians, and w (wich is a scalar of the thruster point size) would make more sence as the radius of the glow.
-
****. :snipe:
Ok, I'll switch it around, but make the user-specified radius factor actually apply to radius. :)
-
Good, I'll wait for the next RC then. Thanks muchly. :)
-
I'm not really in the mood to do a full build (cut a clean patch, drop it in a clean tree, do new builds from scratch), so I just uploaded builds off of my current 3.6.9-dev tree. Some of the changes in here won't hit 3.6.9 (there are particle rendering issues for instance, and big slowdowns if you alt-tab back to the game when in-mission), but the bulk of my fixes which aren't in CVS yet are in here. Make sure that the tertiary thrusters are working as expected now, and I'll start getting all of the various fixes in CVS tomorrow.
http://icculus.org/~taylor/fso/willrobinson/hoopla.rar
-
excellent, thanks! It works :)
-
I've been doing some testing today (taylor fixed tertiary thrusters on cap ships) and noticed another issue, that has been bothering me for some time now, although it was not that obvious without the tertiary glow.
Take a look at this. Is this intended? Can't see why it should, but...
(http://www.wcsaga.com/~team/tolwyn/pictures/thrusters.jpg)
I mean, how should thruster flame be visible from one angle and not from another?
-
Make sure that the tertiary thrusters are working as expected now, and I'll start getting all of the various fixes in CVS tomorrow.
It works yay :yes:
Tertiary thrusters are scaled like the others and even the $Thruster03 Radius factor: works correctly. May I point out a little typo before you commit the fix ?
The secondary glows length factor is called $Thruster01 Length factor: in the table, that might confuse some people.
Also, whoever put it in the wiki misspelled it as Lenght.
@Tolwyn: That's supposed to be like that, IIRC is serves to hide the clipping.
-
@Tolwyn: That's supposed to be like that, IIRC is serves to hide the clipping.
I was not aware about the $Thruster01 Length factor. Now I can tweak it to my liking :)
-
The secondary glows length factor is called $Thruster01 Length factor: in the table, that might confuse some people.
Ok, fixed. Both the old and correct options are valid, but the old one ("Thruster01") will issue a warning to use the correct option instead.
Thanks for pointing that out btw. No telling when we would have noticed otherwise. :)
-
Also, whoever put it in the wiki misspelled it as Lenght.
That would probably be me.... :doubt:
-
No worries, it was easy to guess the correct syntax. If you're gonna edit the wiki page, you could also fill in what they define.
"$Thruster02 Radius factor:" varies the width of the secondary glow
"$Thruster02 Length factor:" varies the length of the secondary glow