New Graphics Engine

Wolf Rider said:

>>We have been advised by the developers: the sim won't look any different but it will run better, in comparison to the release engine. <<

Yes, this is correct, and needs drawing attention to. Many might have forgotten this over time, so it's as well to remind the forum from time to time. It cannot be stated often enough, especially to those who wish to do nothing but complain.

The forum needs more of this style of factual post, far too much moaning has taken place recently.

A breath of fresh air, Wolf Rider. Thank you.

[skarden]

would you rather have the development team here explaining stuff that has been explained many many times over ( and yet again, very well too by blackdog ) or have them working on the beta? ya can't really have both, they don't have a big team and I for one would rather they be working on ironing out the bugs in the beta then answering the same whining questions over and over to people who don't bother to read previous posts.

[Ploughman]

Originally Posted by tarks

Looking at this thread from Oleg back in 2007/2008 the graphics really don't look any different to now , in some shots better i'd say.

http://forum.1cpublishing.eu/showthread.php?t=2040

Hmmmm. Looking through those links I noticed with some delight the tail hook on one of the shots of the Sky Raider.

[Thee_oddball]

Originally Posted by Blackdog_kt

My understanding is that the work on the sequel is primarily about 3d modeling and laying the groundwork at this point in time.

It's entirely possible to make "static" models in the meantime, but eventually each engine will handle these models differently to give them motion. One engine might do effects one way while the other engine does effects with a different algorithm, the same for calculating lights and shadows, etc, (and this is what results in the differences in performance and quality) but in the end they all take a 3d object and make calculations on top of it: the initial object that is being "read" into the engine can be the same, even if the calculations to be performed on it are different.

To give a simplistic example, it's like you have a bunch of oranges in your kitchen. You can just eat them, make them into orange juice, or extract the pulp and some orange skin shavings and put it in a cake, the oranges will work fine in every case.

I've taken up a computing degree course this year and one of the things they try to really press in all the classes i attend is modularity, especially for the so called object oriented languages.

To give you another example, as a form of practice for my computer classes i've taken up a project with a mate and we want to build an interface that will allow us to play pen-and-paper tabletop RPGs over the internet with other friends.

I don't know anything about how to handle databases, save data to disk or push packets through a network yet. However, i can still design and implement the interface of the application, as well as define categories of all the objects the game includes (with their proper attributes and ways to interact with them). So, what i'll do is exactly that, then i'll give the code over to my buddy and he'll do the rest.

There is no need for us to be doing exactly the same thing, nor is there a need to be able to do things at the same pace. It's like installing household appliances more or less. I can design my part of the modules (ie, pick some electrical appliances in the above example), the other guy can do the same for his share of the work and the we just have to plug it into a suitable outlet. Well, the power grid in that case is the programming language you use. And languages nowadays don't tell you "you can't plug in a fridge unless you first connect a hair dryer", they just let you plug each module in at your own convenience and, most importantly, take a module out, redesign it (to improve it) and put it back in.

That's pretty much what is being done with the sim currently. It's just that the module they are working on is being built from scratch and it's one of the biggest in the game. However, that doesn't mean it needs every other module to work correctly before it can function: new graphics engine will be just that, regardless of whether the switchology in the cockpits is corrected and vice-versa.

Now, both the previous IL2 series and the new one are built with languages that follow this method (C++ and Java for the old one, C++ and C# for the new one).

So, long story short, I can't tell you exactly how they do it, but i can understand the process somewhat to tell you it's not wasted time.
Heck, you could probably take the code that governs the systems modelling in the sim and port it to another sim with totally different graphics if you wanted to.

I hope this helps explain a few things

just for clarification BD, IL2 had the core game written in C++ CLOD has the core written in .NET with some small libraries written in C++

[6BL Bird-Dog]

Originally Posted by Blackdog_kt

My understanding is that the work on the sequel is primarily about 3d modeling and laying the groundwork at this point in time.

It's entirely possible to make "static" models in the meantime, but eventually each engine will handle these models differently to give them motion. One engine might do effects one way while the other engine does effects with a different algorithm, the same for calculating lights and shadows, etc, (and this is what results in the differences in performance and quality) but in the end they all take a 3d object and make calculations on top of it: the initial object that is being "read" into the engine can be the same, even if the calculations to be performed on it are different.

To give a simplistic example, it's like you have a bunch of oranges in your kitchen. You can just eat them, make them into orange juice, or extract the pulp and some orange skin shavings and put it in a cake, the oranges will work fine in every case.

I've taken up a computing degree course this year and one of the things they try to really press in all the classes i attend is modularity, especially for the so called object oriented languages.

To give you another example, as a form of practice for my computer classes i've taken up a project with a mate and we want to build an interface that will allow us to play pen-and-paper tabletop RPGs over the internet with other friends.

I don't know anything about how to handle databases, save data to disk or push packets through a network yet. However, i can still design and implement the interface of the application, as well as define categories of all the objects the game includes (with their proper attributes and ways to interact with them). So, what i'll do is exactly that, then i'll give the code over to my buddy and he'll do the rest.

There is no need for us to be doing exactly the same thing, nor is there a need to be able to do things at the same pace. It's like installing household appliances more or less. I can design my part of the modules (ie, pick some electrical appliances in the above example), the other guy can do the same for his share of the work and the we just have to plug it into a suitable outlet. Well, the power grid in that case is the programming language you use. And languages nowadays don't tell you "you can't plug in a fridge unless you first connect a hair dryer", they just let you plug each module in at your own convenience and, most importantly, take a module out, redesign it (to improve it) and put it back in.

That's pretty much what is being done with the sim currently. It's just that the module they are working on is being built from scratch and it's one of the biggest in the game. However, that doesn't mean it needs every other module to work correctly before it can function: new graphics engine will be just that, regardless of whether the switchology in the cockpits is corrected and vice-versa.

Now, both the previous IL2 series and the new one are built with languages that follow this method (C++ and Java for the old one, C++ and C# for the new one).

So, long story short, I can't tell you exactly how they do it, but i can understand the process somewhat to tell you it's not wasted time.
Heck, you could probably take the code that governs the systems modelling in the sim and port it to another sim with totally different graphics if you wanted to.

I hope this helps explain a few things

Thanks for a clear explination.

[Jaws2002]

Looks like throwing away the "old" graphics engine and starting from scratch, wasn't such a smart thing to do. They just replaced the bugs they knew about, with new ones and lost some of the advanced featured in the process. This "new" graphics engine was suposed to be a quick fix. LMAO.

[von Pilsner]

Originally Posted by Jaws2002

Looks like throwing away the "old" graphics engine and starting from scratch, wasn't such a smart thing to do. They just replaced the bugs they knew about, with new ones and lost some of the advanced featured in the process. This "new" graphics engine was suposed to be a quick fix. LMAO.

Where did you read that the new graphics engine was to be a quick fix? I seem to recall they said it would take time to do and get right.

[RickRuski]

Just read Blacksix's April 28th post, dear o dear another excuse how sad. Blackdog, I understand that this sim is in modular form but the moduals still have to be able to talk to each other. A mistake in one module should create problems further on. If the main module can't hear what the other is saying correctly then the resultant answer would be something like this. (this is from a birthday card my wife gave me, she says my hearing is getting worse).

Three old friends are walking on the beach one day, male A says "it' fine day" male B replies "no it's Thursday" male C responds "so am I let's have a beer"

A typical example of statements getting mis-interpreted from one to the other. So once again I still can't see how programmer A can complete his module until the master is finished. He will have no way of testing it as has been shown by recent delays in the patch release.

[Chivas]

Originally Posted by Jaws2002

Looks like throwing away the "old" graphics engine and starting from scratch, wasn't such a smart thing to do. They just replaced the bugs they knew about, with new ones and lost some of the advanced featured in the process. This "new" graphics engine was suposed to be a quick fix. LMAO.

The graphic engine had to be rewritten to provide the necessary performance and stability to allow people to actually play the sim. It appears the rewrite has succeeded in its main objective of the performance increase and fixed CTD's etc, but there are still enough graphics bugs to delay the release. Not sure how you figured a major rewrite of the graphic engine would be a quick fix, the developer certainly never alluded to that.

Chivas said:

>>The graphic engine had to be rewritten to provide the necessary performance and stability to allow people to actually play the sim. <<

Yes, it would appear that way.

>>It appears the rewrite has succeeded in its main objective of the performance increase and fixed CTD's etc, but there are still enough graphics bugs to delay the release.<<

Correct. These are deductions we can all agree with...apart from the silly whiners and complainers of course.

>>Not sure how you figured a major rewrite of the graphic engine would be a quick fix, the developer certainly never alluded to that. <<

Correct again. I wonder if the devs should not consider hiring you in some capacity - perhaps in the PR dept - since your knowledge of the dev process seems second to none, and your predictions have unerring accuracy. Perhaps the role of liaison officer?