A lot of people have been e-mailing me about the status of the project and whats been going on. Well to make a long story short we actually got a private investment group on board with the project and I was able to actually start a company off of this project. Doing so we did a complete restart of the codebase, and we are way better off for it. Since were privately backed now I have to be careful with what I release and what I say about the on going progress of the project, but we have been evaluating and integrating various 3rd party libraries into the codebase.

For example we are now using Autodesk Gameware libraries such as Beast, and Scaleform, as well as I just actually started playing around with the new version of speedtree. I decided to slap together a quick test just showing that these things are in, but as you will see with the trees I haven't integrated the leaf billboard code yet.

Attachment:

shot00002.png [ 681.14 KB | Viewed 693 times ]

Lit by single light.

Attachment:

shot00003.png [ 647.92 KB | Viewed 582 times ]

Now why are we leaning towards keeping the Beast route? Especially since any 3rd party libraries are going to have to be somehow abstract in a non-public code module; the answer is simple, virtual texturing. Before I even considered using Beast, I experimented with getting in Unreal 4 realtime light bouncing technique, and it barely ran on my nvidia gtx 6 series card. So if it barely ran on one of the higher end cards out right now, you can forget most of the PC gamers out there, and needless to say you can also probably throw out next gen consoles/mobile devices. So we are edging towards beast simply because our investors want a quick turn around of everything, and I honestly don't think I can code in a system that even would come close to the quality level of beast within the time our investors want this done.

As far as Scaleform and speedtree these implementations will only be aval to people that license those middleware products, I will still support the old D3 UI system.

Now some other features that are:

Direct3D 11
Windows Phone 8 and Windows 8 Metro support
Custom "middleware" compiler that helps speed up compilation, and deployment to different platforms.

Without getting into to much detail about the custom build tool, Epic did something similar with UE3 http://www.xoreax.com/epic-games.htm. The rendering code no longer calls the rendering API directly, instead its abstracted to allow parallel support for both d3d and opengl.

Anyway I just wanted to give a quick update, I hope everything is coherent enough to understand I'm freakin exhausted

sweet pic's.

But what's "CDK"? Is this your D3 code port with the mega-texture like stuff, etc? I assume you're not integrating other code right in to the GPL but loading 3rd party libraries, right? Or did your investment group buy the rights to the source & you guys are making an updated engine? Are you guys now working on a project or just the engine itself?

Congratulations on getting funding!

Congratulations, that sounds like awesome news for your game.

Hopefully some of the cool things you've done will eventually trickle back to community projects. How do you feel about people making use of the work you did while it was an open project?

Oh man proper shadow maps in Doom 3

Jealous

But congrats, this is big stuff. Hope everything works out well.

First of all, like others, I would like to thank you for giving an update. I know I raised an eyebrow when blackenmace.com disappeared from the internet.

While I understand that there isn't much you can probably talk freely about at this moment, I will throw my inquiry in along with the others about whether this new codebase is gpl (or open source in any way) or simply closed sourced based on proprietary licensed code from id software?

jmarshall23 wrote:

I experimented with getting in Unreal 4 realtime light bouncing technique...

Interesting...I was doing a little bit of reading on this not too long ago, now that information is trickling out about the processes used; however, it is still far above my head at the moment since my only previous graphics programming experience was an Intro to Computer Graphics course as an CS undergraduate. Shame that it is so slow, since it seems to be a promising approach. No doubt there are a lot of optimizations outside of the published ones (updating the sparse voxel octree only when the scene changes, lower the voxel scene resolution, voxelization of the scene done on the GPU, etc...) that Epic has done to get this working. This is, of course, ignoring the fact that UE4 has not been seen outside of controlled demonstrations yet.

jmarshall23 wrote:

I will still support the old D3 UI system

Thank you. As far as I can determine, Doom 3 UI's system seems to be quite robust and honestly I really don't see anything wrong with it. Given that, it would be a shame to lock such an essential feature down to a proprietary solution.

All in all, this appears to be good news and thanks again for the update.

Quote:

But what's "CDK"? Is this your D3 code port with the mega-texture like stuff, etc?

Yes it is.

Quote:

Hopefully some of the cool things you've done will eventually trickle back to community projects. How do you feel about people making use of the work you did while it was an open project?

Any and all code that I've released is and always will be open, just if you could give credit somewhere visible to me, other than that I don't care what you do with any of that code.

.

As far as how open will the engine be, what I'm planning on is the engine to be open source as much as possible(as that's the main pitch point of the project

), but that's all I can say on it.

Quote:

I completely agree with you, but the fact is scaleform is the industry standard at the moment. When trying to pitch new engine tech its really important to lessen the learning curve as much as possible. So I have to atleast include it.

Hey! This is good news, I had high hopes for this. What I'm wondering is what your selling point against say UDK and Cryengine is at the moment. I'm not sure how Doom3 + beast + scaleform is really different from UDK or Cryengine. It just seems like deploying Doom3 against these other toolsets is just reinventing the wheel if you're not going to make it open. I also was under the impression that deferred rendering was the way to go, Doom 3 was realtime and I always thought this was a huge advantage over lightmapping. We're working in Cryengine right now and it's amazing that I don't have to light map anything. Also we'd like to move to a more open engine, one that is cross platform, is the CDK going to be compilable on Mac or Linux?

Quote:

I'm not sure how Doom3 + beast + scaleform is really different from UDK or Cryengine.

I completely agree with you : ), but as I said before Scaleform is just there because its industry standard at the moment. If you don't have it your engine is lacking. Scaleform isn't so much a selling point as it is a must to even compete with either UDK or Cryengine.

What I can say though is we want to take the development intertation power of say UE4, and be able to make it deployable to more platforms. I don't have a problem with forcing developers to have high end machines, but requiring the same of end users is a problem. So if you could develop your game in real time, and than when your ready to ship you say use beast to get the same result, you get the benefit of quick interation time without isolating clients or platforms that aren't capable of doing things in realtime.

Quote:

Also we'd like to move to a more open engine, one that is cross platform, is the CDK going to be compilable on Mac or Linux

We are building everything concurrently every day for windows, mac and Linux. It works right now on Windows Phone 8 and later we will add support for iOS. Anyway that's all I can really say right now

Sounds very cool, excited to hear more about things, and super glad you're still very much working with idTech4.

You might check out the work that's been done on getting idTech4 ported to Android: http://omcfadde.blogspot.fr/

Quote:

You might check out the work that's been done on getting idTech4 ported to Android: http://omcfadde.blogspot.fr/

Nice! Hows the battery life with their version?

I think they're only in the 'got it compiled and running testmap' phase. Single digit framerate on whatever test device they're running, so it's probably both not optimized and a huge battery suck. It's up on github, and the project lead has hinted at writing up a guide to get the whole toolchain set up.

When you went into media blackout, I was wondering if you were working on a funding model- something like kickstarter would have been a good model for maintaining and open development process while still paying the bills.

jmarshall23 wrote:

What I can say though is we want to take the development intertation power of say UE4, and be able to make it deployable to more platforms. I don't have a problem with forcing developers to have high end machines, but requiring the same of end users is a problem. So if you could develop your game in real time, and than when your ready to ship you say use beast to get the same result, you get the benefit of quick interation time without isolating clients or platforms that aren't capable of doing things in realtime.

Sounds good, but hopefully the toolchain is scalable as well so that one is still able to create something on a mid-range setup. Even if that means opting out of certain features like large virtual textures, etc...

Hopefully the tools are cross-platform along with the rest of the project.

All in all, I'm excited about any further news on the project. An open, cross-platform, modernized, idtech4 with a focus on fast development iteration is something I would very much like to see happen.

parsonsbear wrote:

You might check out the work that's been done on getting idTech4 ported to Android: http://omcfadde.blogspot.fr/

I came across that project not that long ago. What initially caught my attention was the change from Blinn-Phong to Phong shading. I'm still unaware of what the author's intention for the project is at the moment, though.

Looking good jmarshall, I'm glad to see more modern features in the engine. Though the middleware will likely look cool and be useful, I fear it might complicate things for those who will want to use this CDK. As I assume all the middleware starts costing some real money if you want to use it commercially. I at least hope it will be "easy" to pull that stuff out if needed.

Good luck though, as this is really shaping up.

parsonsbear wrote:

It was double digit in the main menu GUI for me. Though I couldn't get far(see the post I made on the blog).

I don't want to continue to derail this thread though, we should maybe start a new topic discussing this?

Great that you're helping to test on different hardware, hopefully the minimal assets http://wiki.iodoom3.org/Minimum_Assets will get to a point where it could be used as a test package.

Back on topic, I'm very curious about the performance considerations for this engine on mobile platforms. Virtual texturing in particular has interesting ramifications for tile based hardware, and Carmack's gone into using memory mapped data files in some detail. RAGE HD on the iPhone was an interesting project, but effective VT streaming forced the unpopular on-rails gameplay. Might not be so bad for other game genres though.

The_Raven wrote:

Any news on this, I am also curious whether the sdk/cdk editor/tools will be cross-platform?