Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: portej05 on January 06, 2010, 12:45:10 pm
-
Dear all coders (potential and on team), modders and artists,
Looking ahead to future versions of FreeSpace Open, it has been identified that the rendering engine is in need of a significant overhaul.
There was recently a post on SCP coding internal by DaBrain which has basically set in motion a lot of thinking about the rendering engine and where we'd like to go with it in the future. It has also highlighted a number of deficiencies and inefficiencies with the current engine.
To this end, we're (members of the SCP Coding Team) putting together a series of consultations and design 'meetings' with artists, coders and modders to develop a project team to work on a new design.
There have been a number of efforts to redo the graphics engine, including the conversion to OpenGL and a large number of performance improvements and feature enhancements. We've also had a number of recent improvements in the performance of the engine. However the FSO rendering architecture is far from modern and fairly difficult to work with (and is blamed for scaring away a number of potential coders). It has also been described by Vasudan Admiral as ``it looks something like what you'd get if an asteroid made of spaghetti hit a shoelace factory and the firemen all used sillystring to put out the blaze''.
We believe that a project like this could drive interest in the FreeSpace Open engine and the FreeSpace game and associated mods. We also believe that allowing early input into the design of a major engine component will encourage a number of coders out of the woodwork, and may even give previous coders some incentive to get involved again.
We're also under no illusion as to how massive a project this could become. It may drain significant resources from other areas of the engine, however we'd like to make it's impact as little as possible for as long as possible. There is also a good chance that this effort may not succeed, however it will be driven hard for as long as we can. It will be done separately to the current SCP codebase for reasons of licencing and ease of development, and will be incorporated in the future.
So what we're looking for at the moment is basically a show of hands of who is interested in participating in this kind of project. We'd also like to know if you have friends who have particular expertise in graphics programming or 'technical art'. We'd also like to know if you have these skills.
This project has the support of the SCP Coding team.
portej05
(on behalf of the SCP Coding team)
-
I'm very interested in it, though I can't do much with the code itself, count on me with testing the new, experimental builds.
-
Unfortunately, I have no acquaintances with any kind of programmer\coder :(
Define "technical art". Also, what would be needed from the artists?
From my part, I am proficient in modelling, digital sculpting, animation and rigging basics, texturing, drawing\painting and design in general. I'm an adept at game design as well, so I have some knowledge of how things work in the gaming industry in terms of development, although I have no clue about the programming part.
Finally, I'd like to give my input on all this (I assume you also posted in order to know what people think of this).
I believe too much emphasis is being placed on the graphical engine. True, it was needed before, and it sure added a lot to the game. However, I think that at the state the game is now (visually competitive with professional products, bar 1 or 2 features), more emphasis should be given to other areas: gameplay, physics, interface, etc.
You guys did all the wonders we have available in terms of Freespace modding, and all for free, with passion. You could expand you area of activity\interest, in order to not only upgrade Freespace like you have so far, but also make an excellent, flexible space sim engine. An application that anyone can easily use to make their own space game, be it one of the likes of Freespace, or the likes of Privateer\Freelancer, or even I-War.
Personally I'd value that far more than dedicating resources to graphical updates again.
And of course, there's always the matter that too many resources are dedicated to this overhaul, leaving the other areas stagnant, but you guys seem to already be conscious of that :)
Ultimately, any way you decide, let me know where I can help!
-
In my opinion, since the graphics engine is the one part of the engine that is in greatest need of an overhaul, it should be done as soon as possible. Once that is under way, the coders can start redesigning other parts of the engine as well.
-
Does it means 3.7?
-
Does it means 3.7?
I think it would warrant a 4.0 myself.
I believe too much emphasis is being placed on the graphical engine. True, it was needed before, and it sure added a lot to the game. However, I think that at the state the game is now (visually competitive with professional products, bar 1 or 2 features), more emphasis should be given to other areas: gameplay, physics, interface, etc.
You guys did all the wonders we have available in terms of Freespace modding, and all for free, with passion. You could expand you area of activity\interest, in order to not only upgrade Freespace like you have so far, but also make an excellent, flexible space sim engine. An application that anyone can easily use to make their own space game, be it one of the likes of Freespace, or the likes of Privateer\Freelancer, or even I-War.
Personally I'd value that far more than dedicating resources to graphical updates again.
And of course, there's always the matter that too many resources are dedicated to this overhaul, leaving the other areas stagnant, but you guys seem to already be conscious of that :)
What is not clear in portej05's post, and as The_E mentioned, is that after this overhaul is done, the game itself will not really look better than it does now from the outside. That is, this rewrite is more about preserving the coders sanity (and possibly scaring less coders away because of the mess) and less about making the engine more pretty, though I am sure there will be some improvements in the looks of the graphics as well.
-
you should consider using Ogre, it would forever end all discussion about DirectX Vs OGL (not that much is happening right now). the big advantage is the whole 'materials system' issue would be solved as well because that's how Ogre works from the getgo.
-
I for one think that sorting the graphics code out would be for the better. I am assuming though initially there will be little difference in visual quality it would work more efficiently and improvements would be less complicated (thus faster) to implement.
if all that is the case then taking time out now make improvements come through faster for us and easier for the SCP ppl gets my vote.
-
you should consider using Ogre, it would forever end all discussion about DirectX Vs OGL (not that much is happening right now). the big advantage is the whole 'materials system' issue would be solved as well because that's how Ogre works from the getgo.
That would have the effect of completely removing responsibility for maintaining the rendering engine from the SCP. Definitely a plus.
In my opinion, since the graphics engine is the one part of the engine that is in greatest need of an overhaul
It's not. Collision detection is. :p
That code has really needed an update since day one.
-
I'd be willing to test buggy code on my machine, but that's all I can offer.
History majors aren't very good at coding. :P
-
So what is needed besides coders? Can one help without being able to code?
-
you should consider using Ogre
This brings up a good point. If the current (hodgepodge) graphics engine is to be scrapped (for the sake of argument) and replaced with something completely new, why not start with a pre-existing one?
What would be the technical, legal or philosophical reasons not to do this?
-
While this is my area of expertise, I can't assist the SCP due to time constraints (as I have mentioned before on several occasions). Unless of course one of you guys can pay me $60000 a year :P I will, however, do my best to point you guys in a few right directions:
Don't use Ogre. You will regret it, I promise, and this is from personal experience. Ogre is too bloated to be of any use to this project. In general from my analysis of open source generic graphics engines, there are very few out there with the kind of stuff that freespace 2 needs. What might be worth looking into is the treasure trove of open source space simulators out there that have their own graphics engines. These can be used as jumping off points for design decisions and graphical techniques.
In general, I would strongly argue against using a pre-existing graphics engine simply because it will utterly fail at providing the functionality that Freespace 2 requires, and you will spend so much time trying to integrate it into a functional C based API and getting it to render things the way you want to you'd be better off just overhauling the thing using another engine as a working off point. Pre-existing graphics engines will not work. If you don't believe me then by all means, ignore what I say and find out the hard way.
Another thing: Scrap DirectX completely. If you already have figured out how to make OpenGL work then there is no point in supporting DirectX in a project like this. It only serves to complicate the crap out of matters, and unless you guys start using Shader Model 3.0 with geometry shaders, you probably won't run into too many issues with OpenGL. DirectX is better for games in the long run, but if you've already built an entire graphics API with OpenGL there is no point in supporting DirectX, especially since this graphics engine will have to be specific to the game.
When constructing the graphics engines, many things need to be decided early on. Are you going to use stencil shadows or shadow maps? How will the material system work? What's going to be hardcoded and what isn't going to be hardcoded? Some things just have to be hardcoded or they'll be too damn slow. How are you going to cull things? How is the engine going to handle local lighting as opposed to the gigantic sun that's omnipresent in all missions? What about multiple suns? What about integrating a terrain system? How will the physics be handled? How much are you integrating physics into the graphics engine and how compatible is it? What's the timespan of this overhaul? What areas of code need to be encapsulated in order for this to work? How will you work with beams? How will you handle postprocessing effects when they aren't screenspace effects (I.E. billboard related distortion effects that don't effect things in the foreground)? You guys need to make a list of everything that you want to support, and more precisely a list of SITUATIONS that you want to support and how you want each situation to look like. Then use this to figure out what the graphics engine needs to support and how best to implement it.
This is all from my personal experience of building a 2D graphics engine over the course of 2.5 years and counting.
-
Thanks for your responses so far!
We did have a look at Vega Strike briefly the other day, and whilst they are sporting an 'Ogre3D' badge, a glance through their code suggests that they abandoned it some time ago.
I can also attest to not wanting to use Ogre - it wasn't pretty last time I tried :P It's tailored more to building an engine around, not just using as a graphics front end (that was my experience, at least, and that may be entirely wrong).
@Dragon: It's not going to be done in-engine. Whilst the needs of the engine will be kept in mind, the majority of development will be done separately in order to ignore any limitations introduced by the engine. (which will need to be overcome at some point!). We'll need to get feedback at some point though!
@Raven2001: The issue with the engine is that it is incredibly 'coupled'. There is no real separation between components. This is needed in a modern engine and for coder sanity. Changing something at the moment is a nightmare because you don't know what else it changes! The collision detection code hasn't been touched because coders that venture there don't usually come back :P
It's not that we're focussing on the graphics engine, it's that we're focussing on removing the massive coupling to the graphics engine, which will likely result in better management of the scene.
'Technical Artist' is a term for someone who is able to do both art and coding and knows how they affect each other in a particular engine.
@karajorma: Collision detection code is.... ugly.
@Solatar: If you can read, we'll probably need you. It's amazing how often someone reading some documentation or planning says something like 'there's nowhere for the trucks to turn around' (true story from an engineering project in Australia).
@FreeSpaceFreak: We need people who use the engine (i.e. modders and coders) to tell us what they want and expect. We're planning to do this separately so that we can evaluate any existing options and/or design our own without having to consider any limitations of the engine.
@ChronoReverse: Technically, we have different requirements to MMO (or whatever you call those Age of Empires) style games, and that seems to be what Ogre is designed for. Legally, we have issues with licences because we're effectively 'no commercial use', which is incompatible with GPL and we'd need to talk to a lawyery kind of person if the software didn't allow us to do this (we have code in one case that a project developer has licenced separately to us, and we also have code that is under NDA (trackir) )
@blackhole: This project isn't going to be a coding project for a little while, it won't become a serious coding project until probably way after 3.6.12. You've added a pile of very useful questions. It's more likely to be a C++ API than a C API though. Hery did mention a desire to play with SM3.0 for particle systems.
If you're able to give us any time at all it would be great!
Thanks for your responses everyone! We'll keep you posted on what is going on (likely just organising style things for a while). Please keep an eye out for friends/family who do coding or have expertise in art or game design.
-
One thing I would like to bring up, in which I know not (fully) the particulars of how it goes from 0's and 1's to
lovely things on screen.... is such things as HUD moddability.
I've understood from past research around HLP and our own interests at FringeSpace, is that folks would like to have
every ship be capable of having a unique HUD. That HUD should also be capable of somewhat more complex animations
than what is possible with the ANIs. I can't articulate this very well, but think if you're comparing PCX to Flash.
You've simply got more options to play with in Flash (actionscript, et al). If this isn't partially related to what's being
discussed, please ignore me.
Furthermore, you might actually get more done by choosing the option which will solve the most feature
or bug requests at one time with this overhaul. IE. If HUDs, and shaders, and so forth are planned to be fixed in one
fell swoop, you can quit allocating people to those items - trying to hack a solution together in the current environment.
More than likely this is obvious to most.... but hey, what was said about those trucks in Australia?
Here's some guides on making yourself more productive, doing what you're doing. Perhaps in some small way it'll help.
http://lifehacker.com/5437929/top-10-mind-hacks-for-making-your-resolutions-stick (http://lifehacker.com/5437929/top-10-mind-hacks-for-making-your-resolutions-stick)
http://plpatterns.com/post/307982918/its-hard-to-change-a-little-its-much-easier-to (http://plpatterns.com/post/307982918/its-hard-to-change-a-little-its-much-easier-to)
http://lifehacker.com/5437156/run-effective-google+style-meetings-by-focusing-on-data-not-politics (http://lifehacker.com/5437156/run-effective-google+style-meetings-by-focusing-on-data-not-politics)
http://lifehacker.com/5435879/get-things-done-with-the-middle-way-method (http://lifehacker.com/5435879/get-things-done-with-the-middle-way-method)
-
@ChronoReverse: Technically, we have different requirements to MMO (or whatever you call those Age of Empires) style games, and that seems to be what Ogre is designed for. Legally, we have issues with licences because we're effectively 'no commercial use', which is incompatible with GPL and we'd need to talk to a lawyery kind of person if the software didn't allow us to do this (we have code in one case that a project developer has licenced separately to us, and we also have code that is under NDA (trackir) )
Oh definitely. I didn't mean to use Ogre but rather if it might be a good idea to also look for and compile a set of existing 3D engines that might be suitable.
As for the licensing, I had no idea there was code licensed to the SCP as well as NDA code. That's pretty neat.
In any case, the sentiment about first figuring out what the engine should do is the most prudent course of action. In fact, even if this isn't done, such a list should be made anyway. That is, an organized list of the things the current code can and is expected to do. Then that could be cross-referenced with what's already used in retail, the mediavp's and the FS1 port. Finally it should be checked against whichever mods people have vested interests in :drevil:
-
There's some enhancements to the custom hud gauges table coming down the pipe. Should expand its flexibility quite a bit. Just FYI.
-
@blackhole: This project isn't going to be a coding project for a little while, it won't become a serious coding project until probably way after 3.6.12. You've added a pile of very useful questions. It's more likely to be a C++ API than a C API though. Hery did mention a desire to play with SM3.0 for particle systems.
If you're able to give us any time at all it would be great!
I sort of meant a C-influenced API since I thought you'd be working with the original codebase, which is still heavily C-inspired in its writing and has very little OOP aside from the stuff that's accumulated with random improvements over the years. If you're going to be massively rewriting everything then its a non-issue.
OpenGL is notorious for its hacked on support for SM3.0, so if you guys want to play around with that make sure its in a highly separated component from everything else to maintain stability. It's probably got better support nowadays, but it'll likely drive a couple of coders bonkers with driver incompatibilities. I'd still advise against adding support for directX because its too time consuming with little reward when most of your graphics coders know how to use openGL anyway.
The only time I can offer you is my advice, since I'm completely unfamiliar with the codebase and have my own projects to attend to.
-
i'm no coder at all so i won't be any help, anyway , for the end project there are things we would like to see, (i don't know for the feasability)
-a rewritten hud rendering : That's the last thing we need for a full triplehead support, if we could choose at wich resolution from the center of the screen the hud will stretch that would be cool.
-Having a full normal map support (i mean using all normal map channel, because the actual one doesn't use all channel and we loose some information)
-A improved reflexion system :
actually when we take off from an inside tube or hangar, if you look at your wingmate's cockpit glass you see the reflexion of the skybox, and it looks a bit weird, i think it should be improved if it's ever possible
-light and shadow system : having shadow would really improve the game looking.
-volumetric cloud/nebula system
-having Post process and aa etc... able to work together would be cool
I think that's already too much to ask :D
-
here is a random thought does this mean we will finally have a firm fix for the slight miss-aligned crosshairs that wide screen users report?
-
@ChronoReverse: Technically, we have different requirements to MMO (or whatever you call those Age of Empires) style games, and that seems to be what Ogre is designed for. Legally, we have issues with licences because we're effectively 'no commercial use', which is incompatible with GPL and we'd need to talk to a lawyery kind of person if the software didn't allow us to do this (we have code in one case that a project developer has licenced separately to us, and we also have code that is under NDA (trackir) )
Ogre is LGPL not GPL and I believe we have looked at using LGPL code in the past as it doesn't conflict with our license in the same way that GPL does.
Not that I'm pushing using Ogre. :)
-
They will be working with the original code somewhat, but the rendering engine itself will be brand new, independent from the rest of the game code, and fully OOP in C++ probably. That's what was discussed in IRC the other day.
-
@karajorma: Collision detection code is.... ugly.
Which is why it needs upgrading. :)
Yes, the graphics stuff could use an upgrade, but it's not the weakest link in the codebase. (Said in general, because I know portej already knows this.)
Another thing: Scrap DirectX completely.
DirectX was deprecated in 3.6.9 and completely removed in 3.6.10.
-
Another thing: Scrap DirectX completely.
DirectX was deprecated in 3.6.9 and completely removed in 3.6.10.
Well that solves that problem :p
volumetric cloud/nebula system
Volumetric effects are exceedingly expensive and difficult to do. The coders should not attempt volumetric effects unless they know exactly what they're doing or it'll just be a giant waste of time.
-
One also wonders how necessary such effects really are for Freespace. The current facsimile works rather well for the intended purpose (IMO anyway). I suppose someone will want to do clouds (IN SPACE!) though.
What about the platform targets of the proposed new engine? A line should be drawn early about how far it should go both ways in terms of support. Is this supposed to bring FSO into the realms of a modern engine or is it going to retain the old requirement of being able to do "vanilla" on the same platform as "retail"? For instance, building it on top of OGL3 (or perhaps 3.1 to allow use of the older stuff) could avoid some of the ARB extension hell issues.
Incidentally, it seems that as of the latest Ogre is now under the MIT license (http://www.opensource.org/licenses/mit-license.php) which reads rather like a BSD license.
-
-Having a full normal map support (i mean using all normal map channel, because the actual one doesn't use all channel and we loose some information)
There is no need to use more than 2 channels for normal maps. Actually, DXT5nm is effective only when the other channels are unused.
-having Post process and aa etc... able to work together would be cool
That doesn't need the entire graphics engine overhaul. You should expect post-processing and aa working together soon :D
-
However, I think that at the state the game is now (visually competitive with professional products, bar 1 or 2 features), more emphasis should be given to other areas: gameplay, physics, interface, etc.
Yes, FS2 can still produce some pretty nice visuals.
That's not the point. This is actually more about making things possible, that are currently impossible and stop wasting so much memory and GPU time for simple effects, just because FSO doesn't allow you to do some things properly.
It's too hard and takes too much time to create something visually stunning for FSO, which is one reason why some mod projects take so damn long to get finished.
Everything around the size of a fighter is fine. The basic shaders work ver well for fighters, but everything bigger is a problem.
If you want to create something really impressive for FS2, it takes a lot more time than it would with another engine.
Also artists have to waste a lot of resources to create simple effects.
Two examples:
1. My 3d shockwave. It's using a LOT of memory, because FSO doesn't support texture translation. It could have been done with 1-3MB memory.
2. The huge asteroid in Beyond the Red Line. A horrible waste of memory. And the result looks 'ok' at best. On close-ups the textures look still pretty blurry.
The asteroid uses multiple 2048² maps.
Why? Well, actually it should use just one smaller tile map. But without any bakes AO, tile mapped asteroids of that size look simply horrible.
Neither FSO nor the POF format support a second mapping channel. So there was no way to do this any better.
There is also a lot of 'effects' that artists had to kind of hack into the game.
I.e. the flare on the missiles (MVPs), that appears at a certain distance. I think it looks pretty cool.
The proper way would be to use a special shader for this.
I (ab)used the mipmaps for this.
You really shouldn't use mipmaps for an effect like this, if you can help it. They're unpredictable.
The results will vary on different gfx cards, different drivers and differnt driver settings.
There is no way of knowing how the effect will look on other machines.
When you're creating a mod, or want to upgrade the FS2 content, you'll always run into some limitations.
The capital ships in FSO simply won't look "great", no matter how many polygons you push into them.
Missions on planet surfaces are a problem as well.
I hope for the rendering engine to be overhauled because I'd like to see more projects using the engine.
More creative games with new environments.
And it should all take artists and designers less time. I'd love to see projects prgress faster.
-
However, I think that at the state the game is now (visually competitive with professional products, bar 1 or 2 features), more emphasis should be given to other areas: gameplay, physics, interface, etc.
Yes, FS2 can still produce some pretty nice visuals.
That's not the point. This is actually more about making things possible, that are currently impossible and stop wasting so much memory and GPU time for simple effects, just because FSO doesn't allow you to do some things properly.
That may not be the point being discussed here, but Raven has a very good point that deserves more attention than it has historically gotten. FSO already has very good graphics. FS2 had very good graphics in 1999 (read the contemporary reviews). On the bell curve of quality, graphics are well along on the high end.
Most features in FSO have not been upgraded as dramatically or as consistently as the graphics engine. Collision detection, for example, is atrocious and has barely been touched since the original 2002 release. AI code has had very little work done on it until a year ago when someone offered us a plugin architecture (which IIRC we still haven't merged) and more recently when Blue Planet came up with its custom AI enhancements. FRED still isn't cross-platform.
I choose a game for its gameplay, not for its graphics. I still play X-Com, Master of Magic, King's Quest, and yes, FreeSpace. ST:R was designed to be compatible with retail FS2. I would have been perfectly happy to play BTRL with retail-era models. All of my SCP efforts have been toward non-graphical enhancements.
I think graphics gets more than its fair share of attention.
[/rant]
-
Fair enough, but improving the efficiency and usability of the graphics code is different from improving the game's looks. When we can render more efficiently, we can put more stuff on screen, enabling (if not necessarily better missions) more lavish cutscenes and more creativity.
And yeah, the AI adventure was a lot of fun. As I understand it we tracked down a few bugs that were around since retail. And the stuff we learned about the way the AI works is stuff every modder should know.
-
@Goober5000
Like I said, for me graphics are the first limitation I run into, when I try to create something 'new' in FSO.
I've been less active, because it takes just so much effort to do something new with the engine.
I don't like wasting huge ammounts of memory for effects, just because of some engine limitations.
I agree with you (two) on the collision detection and I actually somewhat see it as part of the of the problem, I described.
We really need to do something about it.
What's the point in being able to create stunning landscapes in future, if the players keep glitching through collision holes and suffer from bad performance?
And yes, the graphic code got quite a bit of care. It's like you said. Freespace 2 = good graphics.
It had oustanding graphics back then, it still looks ok today.
However, how many of the features have been added properly into the code and how many have been (more or less) hacked in?
From what I heared, even the basic T&L support was pretty much hacked in.
There is hardly anybody willing to work with the current graphics code.
And thanks to the free versions of the UDK and Unity3d, many artist might decide to leave as well. Even I am tempted...
The UDK would pretty much allow me to create a completely new world. Less limitations, great tools. Not very well suited for a space game though. At least not without a lot of work.
Anyway, the rendering engine needs to be rewritten and I think it might be too late if we wait for much longer.
Creating a graphic asset is only the first step. Once you can create it, more gameplay features will be needed.
And on a sidenote, I also still play Star Craft, but unlike Freespace 2, I never played it because it had great graphics.
I think those games used different ways to immerse the player into the game and I think in some games graphics are a very important factor when it comes to immersion.
Most features in FSO have not been upgraded as dramatically or as consistently as the graphics engine.
I have to say, that's to be expected when you want to change the gameplay from the original game.
I also think that FS2 was way ahead of it's time in some areas and I'm not talkin about graphics now.
FS2 is still a reference for space sim games, without any nostalgic factor. In the year 2010(!)
The FS2 graphics were only the reference for one, maybe two years.
I-War 2 looked better in most areas.
-
Even if it came down to, ok, we need to rewrite several parts of the engine completely, where do we start? We already see that we have more coders more interested in the graphics section currently than other areas. Not to say a group can't also start looking at revamping the collision stuff, but with things like that going on cross-group communication would be necessary. But we can't exactly make any of them tackle something they just don't want to do. It's good that we know everyone would love to see better collision code though, as that can be a motivator. But in the end it'll come down to what the coders want to spend their time on.
-
well it seems that once the high level stuff is figured out what should be actually worked on first is the POF format, the biggest thing FSO lacks at this point, IMHO, is multiple texture coordinates, their is also the issue about the POF format not being able to handle sub-object orientations. once a set of requirements is made for the new renderer I think work should proceed immediately on upgrading the POF format to handle the new features while the details for the new graphics engine is worked out. this of course leads to the issue that was brought up recently about new management being brought into PCS2.
also if you want to overhaul the collision detection/physics you could always use something like bullet or ODE
-
I would strongly argue against using a pre-existing graphics engine simply because it will utterly fail at providing the functionality that Freespace 2 requires,
the biggest thing we need is a materials system, Ogre is effectively just that, a materials system, I'm not sure what functionality you think we will need that it will not provide.
-
what about a container file format for EFF's animations? especially with CBanims now working with eff the ANI's could be thrown away completly...
-
In general, I would strongly argue against using a pre-existing graphics engine simply because it will utterly fail at providing the functionality that Freespace 2 requires, and you will spend so much time trying to integrate it into a functional C based API and getting it to render things the way you want to you'd be better off just overhauling the thing using another engine as a working off point. Pre-existing graphics engines will not work. If you don't believe me then by all means, ignore what I say and find out the hard way.
So you strongly argue against something that 99% of the gaming industry is doing every day? Against an engine that has a very well working and well maintained C++ API and has been used in commercial production already?
Just out of curiosity... how many graphics engines have you written from scratch and how many games have you produced trying to use an existing one to have such a strong opinion about that?
-
what about a container file format for EFF's animations? especially with CBanims now working with eff the ANI's could be thrown away completly...
FlamingSword is already doing that and it is supposed to be introduced in the "Antipodes #5" build when it comes out.
-
*Lots of stuff*
I'm not arguing that it may not be necessary, or that those effects are optimized or anything.
All I'm saying is that I'd prefer to have our resources being used in gameplay additions, instead of more graphics (or optimization of existing ones), because, like Goober said, the graphics had more than tehir fair share of attention. The game looks very good as it is. Sure there may be the odd thing that we can't make easily (like that asteroid in BtRL), but for the most part, things look super.
We've spent the last years making Freespace look pretty (a good selling point no doubt). But how about, physics(to not speak of collisions and AI again)? I mean almost real physics, like in for example I-War 2? Blind fire? Better mouse controls? Interface improvemens? In mission jumps? Having the possibility of defining the star system and let the player roam freely there? Localized nebulas? Better asteroid fields? Other ways of playing? And so on.
Keep in mind I don't keep tabs on what's going on in terms of improvements, so some of those things may be implemented already, I don't know. And probably some of those things would require some work on the graphical side of things.
But the point is that those kind of things should receive more love than what they do. And that's as true as the graphical engine needing an overhaul. I strongly believe more resources should be allocated to gameplay, instead of allocating even more resources to the graphics.
Right now you seem to be thinking mostly of not scaring away coders. I think we've been "scaring" away modders, by not giving them ways of modifying the gameplay.
Also, you say things take too long to do. Its natural, they take long to do for the professionals in the industry, and they are hard coded to work fast. How would you expect us to be any different?
I also think that FS2 was way ahead of it's time in some areas and I'm not talkin about graphics now.
FS2 is still a reference for space sim games, without any nostalgic factor. In the year 2010(!)
Well, how many space sim games did you have since FS2? As oposed to say FPS's? Or RTS's? There weren't enough games to warrant evolution.
-
First, I fully support this as a long term initiative.
Second, I can absolutely see the need to pull apart the different areas of the code. It's good to have the SCP team working on bughunting and feature editing, while a separate team works on a new visual engine. There have been enough engines open-sourced (like iDTech) that there should be plenty of research material available. Even a ten year old Quake 3 Arena-style materials system would be superior to what we have now.
Something to consider (along with everything else, such as shadows and occlusion etc.) is whether we can implement a per-vertex animation system. That, alone, would be a massive revolution in what the engine could do. Wishful thinking, of course, but it's worth considering at this stage.
-
In response to everyone's rantings about how graphics gets too much attention these days and gameplay is what really matters: Do you want to attract more people to the SCP or not? I completely agree that too much emphasis is put on graphics these days, but that doesn't change the fact that if you want to attract more people, you need better graphics. Its stupid, but it's just the way things are.
-
i think a lot of things need a complete or partial overhaul, graphics and colisions both being on that list. somewhere in there id also stick an input overhaul (something ive wanted for a long time now), and (another) scripting overhaul, mainly to integrate it with new features that have been implemented since the last overhaul. but you got to start somewhere. since a lot of the math is the same and there are some inter dependencies, would it not be wise to do a simultaneous physics and graphics overhaul?
of course on my wishlist for graphics are really only 2 things:
better/faster rtt camera support
faster/more particles/pointsprites (see my particle demo build for reasons why)
and for physics:
modular physics model
more space
-
In response to everyone's rantings about how graphics gets too much attention these days and gameplay is what really matters: Do you want to attract more people to the SCP or not? I completely agree that too much emphasis is put on graphics these days, but that doesn't change the fact that if you want to attract more people, you need better graphics. Its stupid, but it's just the way things are.
This is not about better graphics, this is about a more efficient and more modern engine. This engine is nearly 15 years old for crying out loud. And lots of it is probably even as old as Freespace 1.
With that rendering engine the game is totally stuck where it is. People cannot use modern ways to generate game content, can only use shaders in a very very limited way, there's no way to get hardware accelerated physics, better collision detection or anything else for that matter.
The engine is written in stone-age C which needs to be brought to a C++ object oriented level, if only to get it to a level where it can be maintained and profiled and tested easier.
That has NOTHING to do with giving graphics too much attention, or getting new fancy effects. It is about bringing very old legacy code into the 21st century. It's about software engineering and modernizing an engine that has extreme potential even today but is limiting itself by its design.
Sorry but maybe you should leave this discussion to people who have any idea what they're talking about and stop trolling.
-
that doesn't change the fact that if you want to attract more people, you need better graphics. Its stupid, but it's just the way things are.
Fact?!? What facts? I wonder what the Wii would have to say about it? or CS? Or LittleBigPlanet? And other examples that capitalized on gameplay instead of graphics, and were successfull. :rolleyes:
No my friend, people still play cards and chess, and a multitude of games with crappy graphics. You know why? Because they have a good and fun and engaging gameplay.
Please, next time use the encephalic mass before typing.
That has NOTHING to do with giving graphics too much attention, or getting new fancy effects. It is about bringing very old legacy code into the 21st century. It's about software engineering and modernizing an engine that has extreme potential even today but is limiting itself by its design.
Intruding a bit here, but indirectly this is also resource allocation (of the coding team), and as far as I'm concerned that's the main thing to have in mind. I'm all for overhauling the engine, as long as it is done with care to not suck even more resources from the other areas. A side project so to speak.
I think the most important thing here is being aware that both are important, and that none should suffer because of the other. I know I'm repeating the same thing over and over again, but sometimes its a good way to make a point :P
-
Intruding a bit here, but indirectly this is also resource allocation (of the coding team), and as far as I'm concerned that's the main thing to have in mind. I'm all for overhauling the engine, as long as it is done with care to not suck even more resources from the other areas. A side project so to speak.
I have to ask, what other areas are there, in your estimation?
The problem, as I see it, is that without a major overhaul of the engine, adding new features becomes increasingly hard as hacks are piled on hacks built on funky legacy code.
AFAICT, there are very few "must-have" features planned that can be added to the engine right now without having to redo them again once a new architecture is implemented. At some point, the feature creep has to be paused so that the overhaul can take place, and as far as I am concerned, the sooner that happens, the better.
Just look at all the features like the AI, or scripting, that have been underutilized right now. Documenting all the capabilities the engine has now so that modders can utilize them properly has to have priority over adding new features just because mod A wants something in the engine that could possibly be done using existing tools and capabilities and a bit of brainpower (speaking hypothetically here. I am unaware of what other teams beside those I am a member of wish to have, and I do not want to point fingers).
-
I have to ask, what other areas are there, in your estimation?
I already mentioned some in a previous post:
physics(to not speak of collisions and AI again)? I mean almost real physics, like in for example I-War 2? Blind fire? Better mouse controls? Interface improvemens? In mission jumps? Having the possibility of defining the star system and let the player roam freely there? Localized nebulas? Better asteroid fields? Other ways of playing? And so on.
Those were off the top of my head. Its pretty late already so I'm already too mind-tired to be able to think more. I'm sure I could come up with more with a fresh head :)
The problem, as I see it, is that without a major overhaul of the engine, adding new features becomes increasingly hard as hacks are piled on hacks built on funky legacy code.
AFAICT, there are very few "must-have" features planned that can be added to the engine right now without having to redo them again once a new architecture is implemented. At some point, the feature creep has to be paused so that the overhaul can take place, and as far as I am concerned, the sooner that happens, the better.
Just look at all the features like the AI, or scripting, that have been underutilized right now. Documenting all the capabilities the engine has now so that modders can utilize them properly has to have priority over adding new features just because mod A wants something in the engine that could possibly be done using existing tools and capabilities and a bit of brainpower (speaking hypothetically here. I am unaware of what other teams beside those I am a member of wish to have, and I do not want to point fingers).
Again, I never said that I flat out disagree with the overhaul. However, and this may be just talking semanthics, but you refered to a Rendering Engine overhaul, not an Engine (as in a full game engine) overhaul. Just that extra word gives the impression that only graphics are being considered. Even so, again I didn't say I disagree with the overhaul, and in fact showed that I'm conscious that there is a need for it. I even went as far as listing my proficiencies, in case you guys needed anything.
And if you were talking on an Engine overhaul, that would be another ballgame, that would warrant calling out other issues.
I'm also conscious however, that the other areas have been sort of neglected so far, and I'm afraid that they will be even more neglected because of this overhaul. Like I said before again and again: balance the two :)
EDIT: And don't take for granted that only the features that are being requested by the projects are the only ones needed. In fact, implementing stuff that people didn't ask for might spark ideas and creative projects people wouldn't think of otherwise!
-
Sorry but maybe you should leave this discussion to people who have any idea what they're talking about and stop trolling.
This is exactly what I mean about you flying off the handle. He is agreeing with you, for goodness' sake. And even if he weren't, personal attacks are un-called-for.
-
Seriously.
-
This is not about better graphics, this is about a more efficient and more modern engine.
I'm really confused here. Isn't the name of this topic "Rendering Engine Overhaul" and weren't we just discussing what is needed in the code to support more modern, and hence better-looking, graphics? If I'm not mistaken you are currently ridiculing me for being on-topic.
With that rendering engine the game is totally stuck where it is. People cannot use modern ways to generate game content, can only use shaders in a very very limited way, there's no way to get hardware accelerated physics, better collision detection or anything else for that matter.The engine is written in stone-age C which needs to be brought to a C++ object oriented level, if only to get it to a level where it can be maintained and profiled and tested easier.
...but, that was just cleared up earlier when I asked about it! They said they would have ported most of it to C++ OOP by the time this rendering engine was implemented! Have you even read the rest of the thread?!
Sorry but maybe you should leave this discussion to people who have any idea what they're talking about and stop trolling.
But... I had someone PM me asking me to help. I mean, its just, I don't, what?! :wtf:
-
Okay, this is rapidly headed for a split. Goodness.
-
I am just a learner at C++. Can I be of any use at all? I've never done more than console "Hello World" and "Hello, <name>"
-
One also wonders how necessary such effects really are for Freespace. The current facsimile works rather well for the intended purpose (IMO anyway). I suppose someone will want to do clouds (IN SPACE!) though.
I think it's important to realize that not everyone wants to be limited to making their projects exclusively IN SPACE anymore. The current rendering engine is horrible at doing atmospheric scenes compared even to flight games of FS2 Retail's age. FS2_Open can do basic space combat graphics fairly well, but there are many, many things that it cannot do or cannot do well that it really should be able to do and many things that it could do a lot better--the full-nebula system is messy (the effect could be greatly enhanced even with something as simple as true fog), the engine isn't designed to handle some of the more advanced shader effects, the particle system is a performance nightmare, etc.
-
Maybe setting a goal for this would be a good idea; Something to work towards? As far as I've noticed, there's always been a lot of talk about shadows and HDR and stuff like that, and each time, the obvious truths like FSO not having proper post-processing are mentioned. So maybe, if you're doing an engine overhaul, you should set some kind of graphical goal as an incentive. I remember a few threads mentioning stencil shadows in particular, which, as far as I understand, don't cost that much in the performance area. What about that?
-
I put off everything waiting for the game models to get updated there is a lot of stuff that can not be well implemented without a lot of changes to the POF format, stencil shadows is a good example, decals is another, these two features can only be well implemented if there is some structure holding information about neighboring polygons, and that is data that cannot be feasibly implemented at run time. there is tones of stuff that the pof should be doing differently, a lot of how different it does things depends on what we plan to do, but I still think the POF file is the primary bottleneck of features. before the graphics engine can be updated it needs data in a ready to use format, how are we going to implement multi-texturing if there is no way to load a multi-textured model?
and I know my response didn't have all sorts of fun personal attacks in it but I was genuinely asking for a more detailed explanation.
"the biggest thing we need is a materials system, Ogre is effectively just that, a materials system, I'm not sure what functionality you think we will need that it will not provide."
I think having all of our render-able effects linked to a script-able material would work well, I think the ability to specify multiple scene graphs would be desirable (especially for those wanting terrain missions). I am a bit leery about the amount of internal configuration files there seems to be with it and I have concerns about things like how textures would be handled. but I think the fact that the single most important graphics system is effectively done and waiting for us should not simply be discounted without a proper discussion.
I think the bigger problem will be integration, not functionality, as it has all sorts of functionality all over the place.
if I imply you are a nitwit will you not ignore it this time?
nitwit.
and a lot of you are talking about game play enhancements, well thats good and all except one of the central tenants of the SCP is to maintain backward compatibility, so Newtonian physics can never happen unless there is some way to modularize it away, so if that is your game the first thing you need to do is basically make an abstraction layer for the system you want to overhaul.
-
My boss mentioned something the other day, and it actually has meaning here as well. He brought up the concept of technical debt, and when he did I immediately thought of the SCP. We are saddled with a gargantuan amount of technical debt, and only so much currency to deal with it. What this is turning into, whether anyone wanted it to or not, is a discussion about how to handle this debt. So maybe that is what we really need, a polite discussion about where the most debt can be paid with the least resources, and for the biggest return on the investment. Obviously we already have a group passionate about overhauling the rendering engine, but that's not to say we can't decide that other areas are more attractive from a debt standpoint, and perhaps attract some of their attentions to those areas. Just keep in mind, with the resources we have, you're always robbing Peter to pay Paul. But, making moves that motivate the greatest majority of the team is the best way to make any progress at all, since this is a volunteer project. Keep that in mind.
-
This whole discussion makes me want to plunge into researching collision detection and to start learning how to code crap that isnt basic console programs :p
But in all seriousness, this whole thing is very quickly going to turn downhill if it is not going to be WELL documented, with firmly set goals and defined implementations and solutions. What the SCP team needs to do is shut off from the outside ideas and alien things. You folks need to sit down in a private channel somewhere, iron out the plans and whip up a proper design document. Then you need to assign people from the pool of availible and willing programmers on what they do best at first. Get organised, stop listening to folks going "we should do it this way" or "no that way sucks, we should do it this way". Figure out what is the best method to get things done. I am quite aware that all of you are doing this as a hobby. But that doesnt mean that anyone can do whatever the hell they want.
Thank you for reading this and i believe that i am just wasting more time than being usefull in any way...
-
well before you can make a design you need requirements which is what I think this thread is mostly about, what is the new renderer going to do.
-
Guys, think for two seconds.
The graphics structure is highly influential on EVERY PART (clearly not sound or IO, but you get the point) of the ENTIRE engine.
Attacking the graphics section will allow us to get to those other parts of the engine.
Otherwise, we overhaul those other parts, then come to the graphics component, and then go and overhaul those other parts AGAIN because their structure doesn't match what we need for graphics.
-
Actually the current plan was for it to be a dropin replacement for what we have now, only that it would be easier to add new features to it once that's done, and some other areas of the code are cleaned up to access it more intelligently so the legacy interfaces can be removed. And no one's doing whatever they want, everything the coders would like to do is stuff that also needs to be done, so it's not a question of the staff going off all willy nilly.
-
A drop-in replacement for the current renderer? Isn't that supposed to be highly intertwined with almost everything making it a rather daunting (understatement) task?
-
Did you read the rest of my post? The rendering code will be updated, with legacy interfaces. Then the areas of code that rely on them will be updated, so the legacy interfaces aren't needed anymore. One step at a time.
-
This whole discussion makes me want to plunge into researching collision detection and to start learning how to code crap that isnt basic console programs :p
But in all seriousness, this whole thing is very quickly going to turn downhill if it is not going to be WELL documented, with firmly set goals and defined implementations and solutions. What the SCP team needs to do is shut off from the outside ideas and alien things. You folks need to sit down in a private channel somewhere, iron out the plans and whip up a proper design document. Then you need to assign people from the pool of availible and willing programmers on what they do best at first. Get organised, stop listening to folks going "we should do it this way" or "no that way sucks, we should do it this way". Figure out what is the best method to get things done. I am quite aware that all of you are doing this as a hobby. But that doesnt mean that anyone can do whatever the hell they want.
Thank you for reading this and i believe that i am just wasting more time than being usefull in any way...
Documentation is one of the key issues with the engine at the moment. Sure, there is a lot of modder documentation, but ask anyone which engine functions are per-frame, and which are per-time period (and we do have timer callbacks, last I checked), and it would be hard for anyone to give a complete or definitive answer.
If you want another way to visualise the engine at present, think of a bunch of game related modules, assign them all to octopuses and give them a cricket ball to fight over. That's the kind of intertwined we're talking about. Removing just one octopus significantly decreases the complexity :P
You're not wasting time - this thread is about announcing a project (with a delayed start). This isn't the project thread, it's just to see what people think. We'll be setting up a project team to examine this in the near future. It was really about finding out who'd be interested in contributing.
-
Actually the current plan was for it to be a dropin replacement for what we have now,
oh, well then Ogre's definitely not what you want then.
-
@karajorma: The other issue is that we're statically linked - we can't use LGPL code.
-
I am a bored coder from time to time.
Unless there are two open source 3d graphics engines called ogre, it uses the MIT licence now, which is a lot more permissive than LGPL.
This thread seems to have degenerated into shouting out what you're unhappy about/want from the engine which seems slightly non-ideal. But on that note: hardware tessellation!
-
Locked as per portej05's request.