[karajorma]

@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.

[chief1983]

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.

[Goober5000]

@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.

[blackhole]

Another thing: Scrap DirectX completely.

DirectX was deprecated in 3.6.9 and completely removed in 3.6.10.

Well that solves that problem

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.

[ChronoReverse]

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.

[Hery]

-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

[DaBrain]

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.

[Goober5000]

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]

[General Battuta]

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.

[DaBrain]

@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.

[chief1983]

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.

[Bobboau]

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

[Bobboau]

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.

[Nighteyes]

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...

[KeldorKatarn]

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?

[pecenipicek]

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.

[Raven2001]

*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.

[Galemp]

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.

[blackhole]

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.

[Nuke]

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