[KeldorKatarn]

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.

[Raven2001]

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

[The E]

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

[Raven2001]

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!

[Goober5000]

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.

[General Battuta]

Seriously.

[blackhole]

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?!

[General Battuta]

Okay, this is rapidly headed for a split. Goodness.

[Kiloku]

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

[Woolie Wool]

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.

[Nemesis6]

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?

[Bobboau]

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.

[chief1983]

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.

[pecenipicek]

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


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

[Bobboau]

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.

[portej05]

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.

[chief1983]

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.

[ChronoReverse]

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?

[chief1983]

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.

[portej05]

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


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

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.