Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: DahBlount on October 15, 2015, 11:17:04 pm
-
Okay, since I managed to get modeled thrusters to render multiple animations (http://www.hard-light.net/forums/index.php?topic=90633.0) instead of the species defined or $Thruster Normal Flame: anim, I'm in need of some input from both modders and other coders on what would be the best method to make afterburner animations work when the "use thruster materials" ship flag(currently not merged into master) is present.
AdmiralRalwood (MageKing17) suggested a method that takes the base thruster anim name followed by the name of the anim to replace it with when afterburner is activated. This would naturally be a ships.tbl parameter.
If anyone else has any other suggestions, please feel free to put them forth.
-
Given that we already have textures that change colour in the engine, might it be possible to do something similar with afterburner textures, save some texture memory?
-
I do not believe I know what you're talking about. Unless you're talking about -misc maps, but those don't really save texture memory afaik.
-
Given that we already have textures that change colour in the engine, might it be possible to do something similar with afterburner textures, save some texture memory?
I think there is enough memory available that we do not have to worry about extra anis
-
Yeah, it's not KSP (in which memory is a primary concern due to lousy coding), we have memory to spare. :) It's not like those are big animations anyway. BMPMAN slots should not be a concern, either, as long as the anim isn't absurdly long.
-
I tested the replacement texture system and found that it doesn't work for afterburners. Did some checking around in the code and I have come to the conclusion that $Texture Replace: doesn't even work at all. The code for replacement textures works just fine with FRED, but they can't be set by tables apparently. I'll need to go fix that then test once more. Basically, the replacement textures never get used after being parsed into ship info.
-
If you fix Table Based Texture Replacement.. you will be a god amongst men. I have wanted that feature for years.
-
It was actually a moment of idiocy on my part, table based texture replacement does work, unless you're in the F3 Lab. That does raise the question of why it doesn't work in the lab, but it works just fine in missions.
With this though I can move ahead with the modeled thruster work.
-
It doesn't work in F3 lab for the simple reason that there isn't a specific ship; we'd have to add another code path for loading the replacement textures into an array, and then set it in the render info. It could be done, but it wouldn't be a simple fix.
-
I recently discovered a method in UE4 with which we can soften the edges of modeled thrusters, essentially making them appear to be gaseous instead of solid.
(http://puu.sh/nmp5F/beb2de6caa.png)
(http://puu.sh/nmpaN/4ff41f820a.png)
All the functionality to achieve this already exists in FSO's shaders, it's just a matter of implementation. I'll be working on this over the next few days between school related assignments and projects.
-
Wow! All of my yes! :nod:
I guess it could be usefull for weapons fire too.
-
duuuuuuuuuude
-
How would non convex, like H-shaped thruster cone work? I believe I've seen those somewhere in use.
-
How would non convex, like H-shaped thruster cone work? I believe I've seen those somewhere in use.
That is a good question. Let me get back to you on that.
Update: It doesn't seem to do poorly. Although it does still have hard edges at certain view angles. I can probably remedy that, I'll just need some time.
(http://puu.sh/nnCg3/f8328fda89.png)
-
Wow! All of my yes! :nod:
I guess it could be usefull for weapons fire too.
And shield hits, too!
-
Cool. I'd love to see it implemented in the near future :D
Would it however be better to implement deferred, dynamic area lighting over the engine thruster/glows in realtime, without having to create glowpoints at engines and rendered them via glowpoint overrides?
-
Would it however be better to implement deferred, dynamic area lighting over the engine thruster/glows in realtime, without having to create glowpoints at engines and rendered them via glowpoint overrides?
This is a pretty unrelated problem. We currently do not have area lights in the engine.
-
I hope this will be resolved by Swifty, who may have plans to add area lights to the FS2_Open engine at some point in the future.
Anyway, does these require shaders, with refractive, glowing, and lens flare ones?
-
I hope this will be resolved by Swifty, who may have plans to add area lights to the FS2_Open engine at some point in the future.
Anyway, does these require shaders, with refractive, glowing, and lens flare ones?
First off, lack of area lights is not an issue with the engine. You can get a similar effect anyways by using the glowpoint override system.
As for what is required for the thruster updates to work, they will only be able to added to the engine once the PBR branch gets merged in because they require the Fresnel function (Fresnel and use cases explained here (https://docs.unrealengine.com/latest/INT/Engine/Rendering/Materials/HowTo/Fresnel/index.html)) to work correctly and Swifty hasn't had the time to get back to me on certain conventions relating to that. We don't currently have Lens Flares and both glow maps and refraction/distortion are done in the fragment shaders via different functions.
-
What's wrong with lens flares used for stars? If I remember correctly old BP also used them for bomb explosions.
-
What's wrong with lens flares used for stars? If I remember correctly old BP also used them for bomb explosions.
Lens flares for stars aren't used in the shaders and only apply to the stars afaik. BP uses a separate effect for the bomb explosions via scripting iirc.
-
First off, lack of area lights is not an issue with the engine. You can get a similar effect anyways by using the glowpoint override system.
The only drawback is when you destroy an engine subsystem, the glowpoint doesn't vanish. It requires the SEXP to disable it once it is destroyed. Area lighting could solve this (since it saves FREDders and modders a lot of time), but for the moment, the engine doesn't have support for this.
What's wrong with lens flares used for stars? If I remember correctly old BP also used them for bomb explosions.
Lens flares for stars aren't used in the shaders and only apply to the stars afaik. BP uses a separate effect for the bomb explosions via scripting iirc.
I know lens flares only apply to the stars (at the moment), and this is a issue. We'd would like to expand it to include glows from ships, but care must be taken to reduce over-use of lens flare effects as seen in the 2012 Total Recall remake, whose movie universe being reused as a setting in my Shattered Stars campaign.
-
The only drawback is when you destroy an engine subsystem, the glowpoint doesn't vanish. It requires the SEXP to disable it once it is destroyed. Area lighting could solve this (since it saves FREDders and modders a lot of time), but for the moment, the engine doesn't have support for this.
I can think of several ways to make this easier(LUA scripting, perhaps a flag for submodels with glowpoints that have overrides), area lights would have to be handled the same way glowpoint overrides would be, they just wouldn't have a visual object in game like glowpoints. The engine doesn't need to support area lights when it has a similar feature that is just as functional.
I know lens flares only apply to the stars (at the moment), and this is a issue. We'd would like to expand it to include glows from ships, but care must be taken to reduce over-use of lens flare effects as seen in the 2012 Total Recall remake, whose movie universe being reused as a setting in my Shattered Stars campaign.
Applying lens flares to glow maps would be next to impossible without generating and rendering the lens flares based on the space taken up by the glow maps in the view port (something UE4 is capable of), and this would be fairly destructive to performance in FreeSpace, so I don't think it's going to happen any time soon, especially since there's not even support for the OpenGL Core Profile.
Edit: This is also the wrong thread to discuss rendering features that aren't currently present in FSO. This thread is purely for modeled thruster updates and I would like to keep it as such.
-
I can think of several ways to make this easier(LUA scripting, perhaps a flag for submodels with glowpoints that have overrides), area lights would have to be handled the same way glowpoint overrides would be, they just wouldn't have a visual object in game like glowpoints. The engine doesn't need to support area lights when it has a similar feature that is just as functional.
Thanks. I'll keep that in mind.
Applying lens flares to glow maps would be next to impossible without generating and rendering the lens flares based on the space taken up by the glow maps in the view port (something UE4 is capable of), and this would be fairly destructive to performance in FreeSpace, so I don't think it's going to happen any time soon, especially since there's not even support for the OpenGL Core Profile.
Edit: This is also the wrong thread to discuss rendering features that aren't currently present in FSO. This thread is purely for modeled thruster updates and I would like to keep it as such.
Fine, though I would like to say further improving performance in FreeSpace via other options to possibly enable lens flares from glowmaps/glowpoints, as well as area lighting is something that we can discuss somewhere else. Right now, I'm having problems with nightly builds when testing large-scale missions.