Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Trivial Psychic on July 11, 2010, 08:08:27 am
-
I'm fairly certain that something similar to this has been proposed in the past, but only in terms of the effect not the means for it. Since animated glowmaps, in either .ani or .eff format, are made up of multiple maps, they can be quite the memory hogs. Periodically, people have expressed the desire to incorporate a system where a single file is simply pulsed in its intensity. What I am proposing is to do this with something akin to an eff file, perhaps .pgm for Pulsing Glow Mapwhich references only one map but acts like a table file. Entries in this would control the duration of a pulse map, how long it will take to go from minimum intensity to maximum intensity, as well as what those minimum and maximum intensities are. It might even be possible to have it control more than one glowmap on the same surface, so you could have maps that pulse alternately from each other. I'm not saying that this would be a complete replacement for the existing animated glowmap system, as it offers the ability to do some more exotic and specific visuals, which is why I've suggested this as an alternative rather than a replacement.
So, is this feasible... desirable... practical?
-
It'd only be able to pulse one specific frame, which would be fine for something like the Mara or Moloch, but for the Ravanna piping or the older Pegasus (which i love personally) it'd look odd.
I'm a fan of the concept and wish it every sucess however as it could work in tandem with the more complicated maps.
Goes without saying that you;d have to render the full lighting though.
-
I believe this will become completely redundant once FSO gets better material and shader support. With just better shaders, you could do quite impressive visual effects.
-
Yes, that is one thing that could be done with the material system.
We could optimize many things with it.
I think we could reduce the gfx memory usage of FS2 by at least 1/3, maybe even cut it half and also use some simplified shaders on many objects. (i.e. do asteroids really need an environment map?
-
Not likely to see THAT anytime soon though, right?
-
Define "soon"...
In my eyes, it's the most important issue right after the collision problems.
From what I understand the current shader system wasn't ment to be used as it is now. The hardcoded way the game decides which shader will be used doesn't give artists much room. (Still I'd say it's a good fallback for models without a proper material, later on.)
You should not only consider the progamming work required for this. Once we have a proper material system, the FSU team will have to redo every animated glowmap and most of the effects (especially the shockwave), use optimized shaders for some objects, and maybe make use of a few additional features, such as lightmaps, a glossiness channel, dirt maps, detail textures and more.
It's a lot of work, but in the end FSO will look look and perform a lot better.
BTW I think Bobboau once worked on a feature for glow maps that worked like the one you suggested.
If I'm not wrong, it was based on an experimental material system.
-
First thing for me would be to drop the shader hardware requirements to Shader Model 2, really.
-
Why keep trying to support older hardware when going forward more and more people will have newer hardware?
-
Because I'm very selfish and want to see shadery goodness, but am stuck on a machine that can only do SM2.
-
Well... I'd rather like to see support for shader model 4.
There are hardly any SM 2.0 cards left out there and pretty much all game require at least SM 3.0.
SM 2.0 card owners can still use the fixed-function renderer, so it's not like they can't play FSO.
I think the material system should allow one or more fallback shaders/materials, so each mod could decide if they still want to support old video cards.
Why keep trying to support older hardware when going forward more and more people will have newer hardware?
I agree. Supporting older cards with old drivers (an no updates in sight) might lead to additional problems we'll have to take care of.
A lot of work for very few people...
-
Like I care.
The problem, right now, is twofold.
SM2 cards can't use the shaders at all; The engine doesn't even consider loading the shaders on those. If we were to allow those cards to load the shaders, it would then be possible to write shaders that are SM2 compatible.
So, why would dropping the minimum requirement be a problem? It would just give guys like me the option of writing shaders we can use. There is no mention of inflicting SM2 shaders on cards that can do more; just to allow us the option of writing and using SM2 shaders if we want to.
-
Define "soon"...
In my eyes, it's the most important issue right after the collision problems.
From what I understand the current shader system wasn't ment to be used as it is now. The hardcoded way the game decides which shader will be used doesn't give artists much room. (Still I'd say it's a good fallback for models without a proper material, later on.)
You should not only consider the programming work required for this. Once we have a proper material system, the FSU team will have to redo every animated glowmap and most of the effects (especially the shockwave), use optimized shaders for some objects, and maybe make use of a few additional features, such as lightmaps, a glossiness channel, dirt maps, detail textures and more.
It's a lot of work, but in the end FSO will look look and perform a lot better.
I don't deny that the materials system would constitute a substantial improvement in performance and graphical possibilities for the game engine, I just gather that its a LOT of work, requiring dedicated, skilled, and long-lasting coders. Besides that, I haven't seen any recent activity on the open forum (or those private forums that I have access to) that indicate that any widespread work is being done on this. That said, if there is chatter taking place out of those boards, or if someone on the team is doing a lot of work behind the scenes, I can't tell, and I know that since 3.6.12 is in release candidate status so primary efforts should, in-theory be towards its primary release, but I don't get the impression that the Materials system is "on the table" right now. So in summary, based on this assessment, I personally don't expect such a feature to make it into code "any time soon", which I deem as "not before 3.7".
This is not, I repeat NOT a put down to the team as a whole or anyone on it. I eagerly await any improvements made to the engine and I look forward to new builds with baited breath even though I haven't loaded up the game in more than 2 years and even troll THIS (http://svn.icculus.org/fs2open/) website to see what changes are being committed even though I often can't make heads or tails of what it means sometimes. I just don't expect to see such improvements "for a while".
BTW I think Bobboau once worked on a feature for glow maps that worked like the one you suggested.
If I'm not wrong, it was based on an experimental material system.
I recall some discussion of simplified animated glowmaps, as I stated in my first post, about four years ago. I was just hoping that with my "not anytime soon" time expectations for the more advanced materials-based system, that perhaps a short-term alternative could be created with the system I proposed, if it was simple enough to create. If it was, then it it might allow some reductions in both memory footprint and download sizes, implemented sooner rather than later. When Materials does get implemented, then (again, it its something that can be easily done) it can be disabled or removed from the code, with proper notice given for any mod using it to switch over to the new system.
-
I one time posted a build that had a basic materials system in it, but no one on the Open GL side wanted to work with me so I pretty much gave up working on the graphics end of things, and that was what precipitated directx getting cut.
-
I eagerly await any improvements made to the engine and I look forward to new builds with baited breath even though I haven't loaded up the game in more than 2 years and even troll THIS (http://svn.icculus.org/fs2open/) website to see what changes are being committed even though I often can't make heads or tails of what it means sometimes. I just don't expect to see such improvements "for a while".
You might want to just add the RSS feed (https://svn.icculus.org/fs2open/?date=all&view=query&format=rss) to your reader/iGoogle/etc instead. Or get rid of the &format=rss and you have a very detailed listing of the entire history. You can add /trunk/fs2_open after the /fs2open and narrow it down to only trunk commits as well.