Pretty Epic ...

**pottburter** · 01-04-14, 10:03

SHOP - Your Wisdom of Ceres Disc purchase payment is processing

WTAF?
Neocron goes Item Shop??

:-)

**Alduin** · 01-04-14, 12:10

Originally Posted by Zoltan

[..] in case of Plaza 1 it tooks ~4 days with the original tools to compile the whole world with "high" details.

#LifeFacts

The "high" quality option did not really look any different imo.
There is a lot of room where we can improve in terms of bsp compilation. At the moment we have not made any efforts to rewrite/optimize the current bsp compiler or even to use newer algorithms to do the bsp compilation. In case someone has experience with those algorithms, drop us a line!

Originally Posted by Zoltan

so we were forced to implement some workaround such as "softwareprocessing".

This is not quite correct, so let me clarify this a bit more. Neocron does not use classic software processing which would be: writing an own renderer which works purely CPU based. DirectX offers vertices to be processed by the GPU if it supports it, which is of course prefarable. However, if the hardware does not support it you can ask DX to do the computations on the CPU. The workaround which Zoltan refers to is that you have to explicitly choose the way vertices are processed and so you need to cater for all possibilities in the computers setup which we initially did not do, we had to add that functionality.

Originally Posted by aKe`cj

The question has to be whether it [porting Neocron to another engine] is feasible with the status quo we're looking at.

aKe cj raises a good point there. The question is whether the benefit for Neocron would be higher if we port it to a new engine or if we keep on improving on the one we currently have. Looking at the long term benefits the port would definitely win. However, on the short term point of view improving the old engine definitely wins.

The port to a new engine has several risky downsides:

No more patches for a long time
No major (information wise) updates for a long time
Possibility of loosing the look and feel of Neocron
Many more downsides along the same lines of the points already mentioned

The one main major upside would be that we would be far more productive with a c++ conformal code base and a toolset which is up to date.

This also brings me to the one major downside of sticking to the current code base: it is a huge pain in the arse maintaining it. It has grown huge over time with a lot of copy and paste code which was written way before modern coding patterns and C++11 emerged. Most often it had to be optimized for speed instead of readability which is highly noticable (the guys back then did quite an awesome job). Also the workflow (as well as the performance) of the current toolset is not optimal and really needs to be improved upon (in case you like to develop new tools, apply!).

After all we decided to stick with the current code base, because of one major benefit: evolution. Evolution meaning that Neocron will not be in a frozen state for more than a year but instead will be continuously developed and improved. It is still a very long way to go towards a c++11 conformal code base, but some parts of the code have already been improved quite alot and made more readable, the performance nowadays makes it possible and the size of our team makes this a must have.

Slauncha,
Alduin

**aKe`cj** · 01-04-14, 13:05

Originally Posted by Alduin

[snip]

... that post was "on-topic" in a quite literally sense.

I am excited to hear you have means to edit and compile the bsp and possibly even the source to the toolchain. The tools involved must be a pain to work with compared to modern editors, but I think you have raised valid points for keeping the technical foundation in place and building on top of that. Good luck with the refactoring.

**Netphreak** · 01-04-14, 20:48

Originally Posted by Alduin

... [snip]
...

Good post showing how things look from the developer and maintenace side of things.

The only thing I worry about regarding sticking with the current engine, is that while you can make it look better and streamline some features, is that things like gunplay, player position tracking etc. all that 'stuff' will be always be limited by the very old game engine.

As much as I appreciate all the work and progress the support team manage with the engine nc has, certain things like op fights will never be able to be fully realised (and by that I mean large number of players, fluid movement, position update, hit reg) to the level yourselves the support team and the community would like.

**aKe`cj** · 01-04-14, 21:38

Originally Posted by Netphreak

As much as I appreciate all the work and progress the support team manage with the engine nc has, certain things like op fights will never be able to be fully realised (and by that I mean large number of players, fluid movement, position update, hit reg) to the level yourselves the support team and the community would like.

What you touch on here is mainly the netcode - not really my domain, but it is not unusual to find 3rd party netcode integrated in all sorts of engines. If NC was to be ported to UE4 it would not provide a smooth, open world no syncs PvP environment either (although level streaming is a cool feature for such a thing). Many multiplayer games of scale integrate 3rd party middleware for the netcode (e.g. Reakktor used RakNet, I believe). There is no reason why the same middleware used for UE4 should not be used for Genesis3D.

Is that feasible? I don't know.
I guess it depends on how well separated the tech stack is for NC. Going by Alduin's post above, my bet would be that it is not like you can just remove a lego brick and replace it with another... too much hot glue involved in keeping it all together

**Zoltan** · 01-04-14, 21:41

Originally Posted by Alduin

The "high" quality option did not really look any different imo.
There is a lot of room where we can improve in terms of bsp compilation. At the moment we have not made any efforts to rewrite/optimize the current bsp compiler or even to use newer algorithms to do the bsp compilation. In case someone has experience with those algorithms, drop us a line!

There are actually differences (short info: there are no decals included in the low quality version).

With "original tools" I mean the unoptimized versions ofc, at least we have a .NET wrapper for the old compile-codebase which allows us to run multiple instances of the compiler so we are able to setup a "compiler farm". This should save some time

In case of PLAZA-SEC 1 we can not compile it at "FULL QUALITY" at this time without crashing the process - KK did some changes in their version of the compiler and we just have the binaries not the source unfortunately. Solving this is just an another point of our endless list of things we have to do

Originally Posted by Alduin

This is not quite correct, so let me clarify this a bit more. Neocron does not use classic software processing which would be: writing an own renderer which works purely CPU based. DirectX offers vertices to be processed by the GPU if it supports it, which is of course prefarable. However, if the hardware does not support it you can ask DX to do the computations on the CPU. The workaround which Zoltan refers to is that you have to explicitly choose the way vertices are processed and so you need to cater for all possibilities in the computers setup which we initially did not do, we had to add that functionality.

I agree but I just don't want to bore someone in here with the details so I shorted it into "Softwareprocessing" (with quotes!)

**aKe`cj** · 01-04-14, 21:53

huge difference in the shadow resolution, too.

**Zoltan** · 01-04-14, 23:06

Originally Posted by aKe`cj

huge difference in the shadow resolution, too.

Thats the point. Raytracing "vis portals" and calculating the lightmaps based on the raytracing data results are the main reason why the compilation of those maps tooks so many time.

**Alduin** · 02-04-14, 12:12

Originally Posted by Zoltan

There are actually differences (short info: there are no decals included in the low quality version).

With "original tools" I mean the unoptimized versions ofc, at least we have a .NET wrapper for the old compile-codebase which allows us to run multiple instances of the compiler so we are able to setup a "compiler farm". This should save some time

In case of PLAZA-SEC 1 we can not compile it at "FULL QUALITY" at this time without crashing the process - KK did some changes in their version of the compiler and we just have the binaries not the source unfortunately. Solving this is just an another point of our endless list of things we have to do

What do we learn from this: never let Alduin touch asset related tools he is just too dumb to use them

Let's use the Runner's machines to bitcoin! Uhm I mean to compile maps

Originally Posted by Zoltan

I agree but I just don't want to bore someone in here with the details so I shorted it into "Softwareprocessing" (with quotes!)

You know how much I love to bore people with boring techy details

**Bifrost** · 02-04-14, 12:29

Originally Posted by Zoltan

...I just don't want to bore someone in here with the details so I shorted it into "Softwareprocessing" (with quotes!)

You can bore me with the technical details. Plus I got to make sure I find the holes and issues with the new code.

**Xortag** · 14-05-14, 13:14

Things evolve...

sign2.jpg

R-Click -> Open image in new tab will get you to a higher resolution.

**Divide** · 14-05-14, 19:10

Originally Posted by Xortag

Things evolve...

sign2.jpg

R-Click -> Open image in new tab will get you to a higher resolution.

The new textures are pretty. It would be totally transforming if you were to up the textures for walls/floors/ground/etc.. instead of logos. The logos and stuff are sexy, don't get me wrong - but the "big hits" are in textures that are used to cover huge surfaces.

**aKe`cj** · 14-05-14, 19:25

Originally Posted by Divide

The new textures are pretty. It would be totally transforming if you were to up the textures for walls/floors/ground/etc.. instead of logos. The logos and stuff are sexy, don't get me wrong - but the "big hits" are in textures that are used to cover huge surfaces.

If you look at the floor tiles in this short clip, it seems like that is being worked on as well.
http://forum.neocron-game.com/showth...=1#post2225498

The big problem I see with supporting high def textures is that these resolutions are very unforgiving when it comes to the quality of the assets. If something looked wrong earlier, it would go unnoticed as it would still blend in nicely with the rest of the pixel mud. Now, with high def assets, anything that is not absolutely "spot on" will be noticeable and also repetition will be problematic. That is why procedural textures and shaders play such a big role in modern engines. When every sign of type X shows the exact same rust pattern it looks silly. When floor or wall tiles show visible patterns in cracks, the same applies.
How are you tackling that problem? Increase the texture/model variants?

**Xortag** · 14-05-14, 21:48

Originally Posted by aKe`cj

How are you tackling that problem? Increase the texture/model variants?

The oldschool way: handmade.
If you look properly, you notice some differences in those two signs. There are even 2 more variants. Yes, varity is one point to tackle those issue and also give NC a little bit more ambience.

Getting High-Res isn't that hard, but for NC, you need to work somewhat different. We have those baked lightmaps, along with a Day/Night cycle. And you may know all those Up-to-date Shaders and blingbling, applying automagic things to the environment are missing. Decals (in their technical meaning) are placed outside of any baked light. Thus, they become unlit. Every place you may wan't to place some sign has a different light scenario, but the sign does not receive any light.
If you catched the right ambient values in your texture, the Night cycle kicks in, darkens everything and your decal looks ugly again...

That's what it makes much harder and what i am mostly deal with.

**aKe`cj** · 15-05-14, 00:20

Originally Posted by Xortag

The oldschool way: handmade.
If you look properly, you notice some differences in those two signs...

There is no need to assume I looked improperly.

It is from looking properly at those (and other new textures) that I see clarity/resolution and repetition/visual d�j�-vu becoming an issue. Throwing in a few more variations will work for lesser utilized assets, while for more widespread assets, I would assume that holding back on the detail frenzy and making the textures a little more monotonous would help.

In any case - good to see you are busy on that frontier. I am curious of the impact it will have when everything is put together for a facelift.

Thread: Pretty Epic ...

Thread Tools

Search Thread

Display

Posting Permissions