id Tech 5

[peoplessi]

This is the thread for the discussion, debate over id Tech 5 - and id's direction with it. Feel free to compare it to other engines and previous engines :) This way we can keep the other threads clean of pure id Tech 5 talk. Couldn't fine the previous thread, so will start fresh here.
http://peoples.pp.fi/images/idtech5.png
wikipedia: id Tech 5 (http://en.wikipedia.org/wiki/Id_Tech_5)
id Software Debuts id Tech 5 (http://www.idsoftware.com/business/press/index.php?date=20070611000000)

A lot of videos:
id Tech 5 Engine Exploration HD (http://www.gametrailers.com/player/23275.html?type=flv)
id Tech 5 Developer Walkthrough Part 1 HD (http://www.gametrailers.com/player/23184.html?type=flv)
id Tech 5 Developer Walkthrough Part 2 HD (http://www.gametrailers.com/player/23183.html?type=flv)
Long Quakecon presentation:
QuakeCon 07 Press Conference Pt. 1 (http://www.gametrailers.com/player/23295.html?type=flv)
QuakeCon 07 Press Conference Pt. 2 (http://www.gametrailers.com/player/23294.html?type=flv)
QuakeCon 07 Press Conference Pt. 3 (http://www.gametrailers.com/player/23293.html?type=flv)
QuakeCon 07 Press Conference Pt. 4 (http://www.gametrailers.com/player/23292.html?type=flv)
Interviews/Rage:
Quake-Con 08: Game Design Interview HD (http://www.gametrailers.com/player/37901.html?type=flv)
Quake-Con 08: Game Design Interview Part 2 HD (http://www.gametrailers.com/player/37949.html?type=flv)
Quake-Con 08: Game Design Interview Part 3 HD (http://www.gametrailers.com/player/38002.html?type=flv)
Quake-Con 08: Game Design Interview Part 4 HD (http://www.gametrailers.com/player/38004.html?type=flv)
Quake-Con 08: Carmack on Consoles Interview HD (http://www.gametrailers.com/player/37902.html?type=flv)

Will update more stuff to here later on.

[Damien_Azreal]

Good idea. The threads for RAGE, Doom 4 and Wolf were getting a bit distracted by debates over the engine itself. :)

[alexgk]

I'd love to see more games based on id's technological base. Hope this engine gets more love from other companies than id Tech 4...

[Damien_Azreal]

Yeah. The Quake 2 and 3 engines did great with other developers, specially the Q3A Engine (yeah I know, id Tech 3... screw that, to me it's still the Quake 3 Arena Engine), but the Doom 3 Engine kind of fell flat on it's face with other companies.

Besides PREY there wasn't a game outside id's own IPs that used it.

[ZuljinRaynor]

It kinda sucked that id Tech 4 fell flat on it's face. I rather liked everything about the engine. Kinda sucks that Creative made the shadow thing first before Carmack though. :(

[Nihilanth]

Good thinking, peoplessi.

On the subject of the main platform. Id Tech 5 is focused on being a multiplatform engine. The game is being built simultaneously on all four platforms, it's sharing the same assets. Due to the fact that 360 and PS3 are locked down systems some design decisions have to be made from a console standpoint first because PC will do everything the devs want anyway. The game is not completely designed on a console first and even though some decisions are based on a 360 or PS3, all platforms are getting stuff at the same time and without a doubt are being polished and balanced separetely for each platform. For what it's worth, PC is not the main platform but PC version is not a port. We'll see how id works out their first multiplatform title but after all it's id. You can pretty much bet that the game, whether it's Rage or DOOM will be rock-solid, polished as much as possible and that the shooting part will get all the needed attention.

On a more general note, I'm curious about the future of id Tech 5 as well, you know, it's future outside id. It sounds like it's gonna be a very designer-friendly engine so hopefully other developers will license it and try to do a lot of things with it.

I know that I'm probably saying it for a hundreth time but I REALLY can't wait for that moment when id showcases DOOM, hopefully at this years QuakeCon. Not only because that's the number one upcoming game for me but also from a purely technological standpoint, I can't stop thinking about what id Tech 5 is really capable of. I mean, Rage is one of the best looking games already and it's undershooting its capabilities. Perhaps this is another thing that indicates bright future for possible licensing.

[ZuljinRaynor]

It's not a port. The goal of the engine is that the assets are shared and the code compiles itself properly for each platform so nothing is a port.

[ZuljinRaynor]

id Tech 5 will not require rewriting of the code to work on PC or PS3. It's natively supported. A Port is when you rewrite code to work on other platforms... id tech 5doesn't require that. I thought that was the whole point that they could easilly do this.

[Hudson]

I cannot wait for saran-wrap renderer 2.0!

[Gryph]

Yes, but can they actually do that? I forgot to add in my last comment, doesnt the 360 devtools produce binaries optimized for the 360 internal architecture? You know, the ibm ppc multi-cores ? Can id tech 5 basically produce optimized binaries for all platforms on command? Arent the x86 and the 360/PS3 very different to say the least?

The different hardware architectures were taken into account when this engine written pretty much from the ground up. That's one of the biggest selling points about this engine.

[peoplessi]

Another thing, is the development tools - this time dubbed "id Studio" - which is fully featured WYSIWYG -editor, this wasn't the case with previous id Techs. As far as I know, it will only run on Windows - or that was the case about year ago. Too bad id Studio isn't likely to be distributed with the game, only for licensees.

For me, based on what we've seen, the new "level editor" is far more intuitive and advanced than we've seen with GTKRadiant in the past. The shown material so far suggests that, but is it just the level editor - or was it a part of the id Studio. I hope that tool at least carries to the end users :)

Overall, I'm not too worried about id Software targeting consoles - they certainly will not forget PC crowd - as a notion of that we get the sources for past id Tech engines(or have already) and tools with release. That's a great thing. Visually, they've said id Tech 5 allows seamless work between the three versions, so PC version can have higher res textures and all that stuff. If DOOM 4 will push the boundaries even further - it will look great too.

I remember being awestruck after seeing DOOM 3 for the first time, but when it finally got released - a lot of time had already passed and it still looked great. Back when I first saw, I didn't think we would have the hardware to run it, but in the end we did. I can't really see the same scenario happening here this time :) Not a bad thing, but hardware seems to be more predictable nowdays.

John Carmack has already laid outlines for id Tech 6 - and that's some heavystuff to read, really hard to imagine that far ahead how will the whole rasterization vs. raytracing move. It's still years and years away, but interesting discussion, more of this here: John Carmack on id Tech 6, Ray Tracing, Consoles, Physics and more (http://www.pcper.com/article.php?aid=532)

We’re working on our RAGE project and the id Tech 5 code base but I’ve been talking to all the relevant people about what we think might be going on and what our goals are for an id Tech 6 generation. Which may very well involve, I’m certainly hoping it involves, ray tracing in the “sparse voxel octree” because at least I think I can show a real win. I think I can show something that you don’t see in current games today, or even in the current in-development worlds of unique surface detail. By following that out into the extra dimension of having complete geometric detail at that same density I think can provide something that justifies the technological sea change. - John Carmack

tommy-vercetti, that's the beauty of it - it can :) They said that PC <-> Xbox 360 is a breeze, but in 2007 PS3 still needed few lines of code to compile properly. I reckon that has since changed, they've gained some PS3 staff, so essentially all platforms come from 1 oven - single "bake" for each of them from same source.

[Gryph]

id studio does come with the game I'm sure. That's what Carmack said in a video I saw. You just bring down the console and type in idstudio or something like that just like radiant in Doom 3.

[peoplessi]

id studio does come with the game I'm sure. That's what Carmack said in a video I saw. You just bring down the console and type in idstudio or something like that just like radiant in Doom 3.

Well that's even better, I understood id Studio to be more than just the leveleditor, so distributing stuff beyond that is all good in my books :) I can't recall the video where he said that, but if somebody can verify this it would be great! There is hours and hours of stuff online about this, and it's about year since I last watched these :)

[ZuljinRaynor]

The only thing that's hard to do is make the megatextures for it apparantly.

[Gryph]

Well that's even better, I understood id Studio to be more than just the leveleditor, so distributing stuff beyond that is all good in my books :) I can't recall the video where he said that, but if somebody can verify this it would be great! There is hours and hours of stuff online about this, and it's about year since I last watched these :)

It's actually in the first video you posted.
http://www.gametrailers.com/player/23275.html?type=flv

He says it at about 8:45

[peoplessi]

And people say they've forgotten about PC. This doesn't sound like that to me at all :)

[Sayantan]

:love: the logo. :D

[Malgon]

I'm hoping id picks up more licensees for the engine this time round. It looks very versatile and I'd be interested to see what other developers could do with it.

[peoplessi]

I don't really know what happened with id Tech 4, it didn't really catch up in the way you'd expect. Same thing happened with CryEngine 2.

[Bad Sector]

The common aspect with both engines were than once their respective games were released, very few computers could run them in "high quality" (i had a top PC at the time of D3 release and it struggled - and today i have a top PC too and even after a year since Crysis' release there are still areas which lag a bit).

I don't know if that means anything though...

[Kristian Joensen]

Yes, but can they actually do that? I forgot to add in my last comment, doesnt the 360 devtools produce binaries optimized for the 360 internal architecture? You know, the ibm ppc multi-cores ? Can id tech 5 basically produce optimized binaries for all platforms on command? Arent the x86 and the 360/PS3 very different to say the least?

Obviously the 360 version is compiled using the 360 dev tools. But the other version are compiled with the respective compilers/tools for that platform.

[Mountain Man]

Yeah. The Quake 2 and 3 engines did great with other developers, specially the Q3A Engine (yeah I know, id Tech 3... screw that, to me it's still the Quake 3 Arena Engine), but the Doom 3 Engine kind of fell flat on it's face with other companies.

Besides PREY there wasn't a game outside id's own IPs that used it.
Probably because id -- possibly for the first time -- faced real competition from Epic and Valve. They were no longer the only game in town when it came to engine technology, although of the three, the Unreal Engine is obviously the top dog in terms of market penetration.

[Bad Sector]

Source uses a very similar toolchain to Id's engines (and its inferior to id Tech 4's integrated editor if you consider that the editor uses the engine itself to render the view so you have a somewhat WYSIWYG view) but its much much more popular than id Tech 4. In fact according to this survey made by Hourences (http://www.hourences.com/book/surveyresults.htm) (an Unreal Engine modder and professional mapper) in modding communities, gaming sites and other places, most people prefer the Source tools most.

Asked about the technology and editor they prefer, Source wins the vote (38 percent). In second place comes Unreal (31 percent). All other engines and development platforms were well behind. Quake technology only pleases 12 percent of the people, and Crytek technology only 5 percent. So even though Unreal is assumed to be by far the most popular platform of choice for professional game development, this is not reflected by the communities.

And personally i totally agree with them. UnrealEd is basically a gargantuan mess and the only thing going for it is that it has realtime preview of the map. Hammer on the other hand is a very simple and intuitive tool to use (and keep in mind: i've used QuArK, */GtkRadiant and other editors before Hammer, so its not that "i'm used to it" - its really simple). And i assume that if there weren't so many games using variations of the Unreal Engine out there, that 31% would be much lower.

But really, the Source engine isn't very different (especially from a toolset perspective) from id Tech 4. And its not like Hammer or DoomRadiant are the only editors capable of using these engines. QuArK for example supports both Half-Life 2 and Doom 3/Quake 4 (although my opinion of QuArK isn't really much better than UnrealEd - this editor is very cluttered too, although i really like the ability to rotate viewports).

When you're using an engine you're not limited to what you get with the engine, especially an id engine for which there are plenty of 3rd party tools. Valve knew this when they made Half-Life and used Worldcraft instead of QuakeEd.

[peoplessi]

Community use is totally un-comparable. The simple fact is, that Source powered games are more widespread, there is more information available, and so on. Take for example Unreal Engine 3, it isn't that widespread in PC use. Just to say, there is more to it then just "which is better". Source just is the #1 modding platform, hard place to wedge into now.

I beg to differ on UnrealEd being "gargantuan mess" - it really isn't, I use both Hammer and UnrealEd. Small differences here and there, but in the core they are so much alike. Only bit medieval editor is GTKRadiant, to do the same things you need to do extra work. Nothing is really as intuitive as they are in more modern editors.

[ZuljinRaynor]

Yeah, I heard the Source SDK tools are the biggest weakness of it since Hammer sucks and the tools are a mess.

[Bad Sector]

@peoplessi:
Actually the survey was done to both mod communities and professional mappers so that it covers both.

@tommy-vercetti & ZuljinRaynor:
There is no noob-friendly 3D tool (except probably Google Sketchup or whatever it is called - this is considered somewhat noob friendly). 3D isn't a walk in the park, its hard and needs practice and patience. When it comes to level editing, you need to learn techniques, special tools, have a little knowledge about architecture, design, visual storytelling, etc, know about differences between single and multi player level flow and other stuff. When you know these, you are far from being a noob and what you need is a tool to do the job. When you know how to do the job, this knowledge has little to do with the tool you use. All mentioned editors (QuArK, GtkRadiant, Worldcraft/Hammer, UnrealEd, etc) provide you with the ability to create high quality maps. My argument is that, once you know how to make maps, Hammer is much easier to use than UnrealEd.

As for those who say that Hammer is hard, they probably haven't realized what making maps is all about or they're used to some other form of making content (like making worlds in generic 3D tools such as Blender, Maya, Max, etc). Of course that steps on another topic, brushes vs meshes, which is a whole other story. Personally i believe brushes (and CSG in general) are more suited to architectural design, whereas meshes are better for organic design (although Valve proved in Episode 2 that if with displacement mapping and the right shader, you can make good organic areas).

I've seen people who know Max well to rant about how Hammer is hard because they cant wrap their heads around the process of carving brushes and believe that CSG is bad because it was broken in some Max versions.

[peoplessi]

One could say that same thing about Hammer too, I think both are just fine. For the survey, only 151/1000 were professionals - that alone distorts the survey. I would bet that UnrealEd is more used in the professional enviroment, there aren't that many source powered commercial projects going on.

Some people use 3D modelers to carve out the level, so that's an option too. Then import that geometry to your editor. Both ways work. I wouldn't dig too deep to Static mesh vs. Brush debate, since both have their advantages. You use the tool, the method, that works for your ultimate goal.

I didn't notice anything special between UnrealEd 4 and Hammer - both are good, but UnrealEd 4 has some neat features like matinee and kismet - which make your life a bit easier.

[Gryph]

I think most of the level geometry in Rage is being made in 3D modeling software and brought in. But we've mainly only seen outdoor environments so far. I wonder if the inside areas are being made in a similar way or with brushes.

[Bad Sector]

@Gryph:
Id still maintains Radiant, so i assume they still use it.

@peoplessi:
One could say anything actually, this is why i said "my argument" :-). For the survey, i take it as a whole because its not only professionals who use the tools. Besides its not even the mappers (or "level designers") who are choosing the engine - its the producers or some other higher lever person who in most cases won't touch the engine himself, will just tell to others what to do and have criteria like "how many buttons are onscreen" and "what other people use".

Some people can make maps by editing .MAP files in Notepad and some other can type raw vertex data in a hex editor. Its possible (i hardcoded this in C back when i wrote it (http://gimme.badsectoracula.com/badlab.gif)), but it doesn't mean its the best or even a good method :D

As about kismet, i haven't really tried but from what i've seen it seems much easier to just pop up a text editor and write the script code in there instead of drawing boxes and connections between them - of course it makes artists have little butterflies in their stomachs, even if most decent mappers have more than enough scripting/programming knowledge :-).

[peoplessi]

Some people can make maps by editing .MAP files in Notepad and some other can type raw vertex data in a hex editor. Its possible (i hardcoded this in C back when i wrote it), but it doesn't mean its the best or even a good method

I can't see the connection you are trying to make, it's not that out of this world. Certainly not as cumbersome.

As about kismet, i haven't really tried but from what i've seen it seems much easier to just pop up a text editor and write the script code in there instead of drawing boxes and connections between them - of course it makes artists have little butterflies in their stomachs, even if most decent mappers have more than enough scripting/programming knowledge :-).

That varies, but to judge everything that isn't how you do it only sounds elitist :) You can code too if you like, Kismet doesn't take that part away. In certain cases it might even be more simpler to do that way. Kismet has it's advantages too. I'm more in favor of stylized scripting language that is simple, and focused.

[Bad Sector]

Of course it isn't, i just have a habbit to make extreme examples :-P. But i see using a model editor to make maps as a pretty "low-level" way and very prone to errors as how it will be used from the engine (in fact, i experienced this while working in a games company as a programmer* - since we didn't had time to build a full fledged editor** and the artists preferred working on Max anyway, we just wrote a Max exporter and ... a few rules on how the maps should be made. Needless to say, these rules -which we could enforce in an editor- were the source of much frustration from our part because they were constantly broken either by bringing the engine to its knees due to bad visibility setup or by producing glitches/invalid rendering due to bad material setup, using invalid channels, features which the engine didn't support or other stuff that just couldn't be done if the engine had its own editor - not to mention people wouldn't spend as much time making the architectural parts if brushes were used, although thats my own estimation and others could work faster by moving vertices around).

Another method could be to create reusable static meshes, much like lego bricks. I'm not very fond of this method though since i have a feeling that it limits the free design and focus on reusing the same stuff again and again, thus introducing repeating environments (unless there is a /massive/ amount of "blocks", which probably throws most positive aspects of this method out of the window).

(*=yes i'm mostly a programmer, although very interested in visual arts, especially level design for FPS games :-)
**=that was what i was told at least, when i started working there there were much work already done)

Anyway, i think we derailed the thread a bit. In short though, i don't believe it was game tools that made id Tech 4 to not be used much, but that Half-Life 2 had a much bigger impact on the gaming world than Doom 3 (personal preferences aside, thats the truth - and i was one of those saying "pfft, what Half-Life? Doom 3 will be the game of the decade" :-) and between id Tech 3 and id Tech 4, Unreal Engine picked up by enough studios to generate a form of "speciality" (ie. people knowing the engine), so id lost some ground there.

On the other hand, i'm not sure if id's policy of making a brand new engine every few years is a good licensing strategy. When a studio finishes a game with id Tech n, if they stick with id's engines, id Tech n+1 will be a totally new engine and the people would need to re-learn it. On the other hand, Unreal Engine hasn't changed much (design-wise) since Unreal 1 so knowledge is carried from older projects.

[Parkar]

As about kismet, i haven't really tried but from what i've seen it seems much easier to just pop up a text editor and write the script code in there instead of drawing boxes and connections between them - of course it makes artists have little butterflies in their stomachs, even if most decent mappers have more than enough scripting/programming knowledge :-).

The point of Kismet is to allow user with no experience of programming and scripting to do more advanced things in levels without having to bug programmers about new ways things should be able to interact. It s in no way intended to replace regular scripts for actual game play logic.

It's very quick and effective when doing advanced mover behaviour. Things like these are a lot easier to think of in terms of a visual diagram then a bunch of code. and each node can be rather complex and the system can be extended with new nodes by uscript. It also ties neatly into the animation of objects and other time varying parameters in a way similar to how key framing in a regular 3d package works. And I don't just say this since I am incapable of writing uscript which I have been doing on and of since Unreal 1.

It's surely not a necessary tool to get things done but when used for the right things it makes things easier, faster and with less risk of introducing bugs then scripting everything.

[peoplessi]

...Another method could be to create reusable static meshes, much like lego bricks. I'm not very fond of this method though since i have a feeling that it limits the free design and focus on reusing the same stuff again and again, thus introducing repeating environments (unless there is a /massive/ amount of "blocks", which probably throws most positive aspects of this method out of the window).

Well, the plus sides is lowered use of system resources if you need to use object/geometry A multiple times in a map. It's isn't as restrictive as you make it out to be. id Software uses similar approach on Rage (http://www.luxology.com/community/blog/images/ws1.jpg) - so, it really varies.

On the other hand, i'm not sure if id's policy of making a brand new engine every few years is a good licensing strategy. When a studio finishes a game with id Tech n, if they stick with id's engines, id Tech n+1 will be a totally new engine and the people would need to re-learn it. On the other hand, Unreal Engine hasn't changed much (design-wise) since Unreal 1 so knowledge is carried from older projects.

Well, as they've said, before they only made tools from "themselves" and that showed. Maybe this new id Studio with id Tech 5 will offer more modern approach - and based on what we've seen, this is true.

[Bad Sector]

@tommy-vercetti:
Source games use the editor to make levels (and static meshes for detail of course) and they look very good. The same applies for Jupiter EX games (FEAR 2, Condemned 2, etc) - they use their editor too.

I don't disagree that it is possible to make a good level in a 3D modelling package (many games do this) - but i disagree that it is easier. Every level designer has his own workflow, but most have these steps in common when it comes to visuals:

1. design the layout
2. blockout the level
3. put detail/add lighting

#1 is editor independent (you usually do that on paper or some sort of drawing program). For #2 its a godsent to have brushes. It simply is much faster this way (remember: for a mesh-based engine you not only have to create proper geometry for the engine -something that a brush-based engine has automatically-, but also collision geometry which usually is different -again something that a brush-based engine gets automatically), not to mention less error prone (beyond the horror story i mentioned above, brushes contain more useful information about the geometry than a bunch of polygons for preprocessing purposes). #3 is the same either way.

@peoplessi:
This depends on the engine, although you won't use CSG/brushes to make complex shapes. You use crude shapes for the level and use static meshes (which can be instanced) to put detail.

Hm.

Just to make sure i wasn't misunderstood: i'm not against using static meshes in a level. I'm just saying that using /only/ meshes to build a /whole/ level is much harder than using CSG/brushes or a combination of CSG/brushes and static meshes where the CSG/brush part creates the level's layout and the static meshes add detail.

[peoplessi]

That certainly has ringed some bells over at id too :) It's a win win situation with the new better tools. Certainly feels like a solid effort to move to the licensing market too. Pricing is bit open, I've heard numbers that are similar to id Tech 4.

id Tech 4 - $250 000 USD (+ per platform?)
Unreal Engine 2 - $250 000 USD (+ $50 000USD per platform)
Unreal Engine 3 - ???

Just to make sure i wasn't misunderstood: i'm not against using static meshes in a level. I'm just saying that using /only/ meshes to build a /whole/ level is much harder than using CSG/brushes or a combination of CSG/brushes and static meshes where the CSG/brush part creates the level's layout and the static meshes add detail.

Yeah, I think we mean the same thing, but approach from two different directions. I'm just saying that too, using only and only :)

[Bad Sector]

Some recent engines that i know...

Brush-based (meaning you use brushes to build the levels):
id Tech 4
Source
Jupiter EX
Whatever the latest CODs use

Mesh-based (meaning you use mostly -or only- meshes):
id Tech 5 (? not sure)
CryEngine 2
Dubia looks like one (Far Cry 2)
Gamebryo

Unreal Engine 3 is somewhere between actually. You can create levels using only brushes but they're not required - you can make levels using only meshes.

Btw, if you notice, most of the mesh-based engines are used for outdoor (terrain-based) environments, while most of the brush-based engines are used for indoor (or indoor-like) environments. I believe this happens because as i said above, brushes are more suited to architectural environments (besides solid modeling in general was created for stuff like industrial and architectural designs).

[Sayantan]

OMG ... static mesh fight ....... "mine is more static than yours" .... LOL. :p

---------- Post added at 03:23 PM ---------- Previous post was at 02:44 PM ----------

Sorry, Im not too acquainted with this whole brushes vs meshes debate. Which engines nowadays are brush-based and which ones are mesh-based?

Source - Basically brush-based. But props are usually done with static meshes.
idTech3 - Same but static meshes has usage limitations
idTech4 - Almost same as idTech3, but just a bit more fexible with improved graphics obviously
idTech5 - Terrain is completely crafted inside engine (parts can be imported). Props are completely static meshes, .... even complete buildings.
Crytek2 - Same as idTech5.
UE2 - Same as idTech3.
UE3 - Don't know about the terrain part, rest quite like idTech5 and Crytek2.

Also note, I'm only talking about the usability.

Edit: Damn Bad Sector, you're fast. :p

Btw, if you notice, most of the mesh-based engines are used for outdoor (terrain-based) environments, while most of the brush-based engines are used for indoor (or indoor-like) environments. I believe this happens because as i said above, brushes are more suited to architectural environments (besides solid modeling in general was created for stuff like industrial and architectural designs).

This is basically because of the culling techniques used. Indoor engines still use BSPs (Binary Space Partitioning). Whereas outdoor engines uses octree and stuff (not my thing, so I don't know too much). :)

[Kristian Joensen]

"id Tech 4 - $250 000 USD (+ per platform?)"

Peoplessi, here are the details from id's site:

Each license includes full source and tools for DOOM 3, QUAKE 4 and Enemy Territory: QUAKE Wars (beta). The final version of Enemy Territory: QUAKE Wars and the next Wolfenstein game code will be provided upon completion. Platforms supported by id Tech 4 include, at minimum, PC, Mac, Xbox 360 and PS3. (Obviously this was written before the release of ETQW).

And the cost:

If your title requires the best technology available, id Tech 4 is what you're looking for. You absolutely will not find a more elegantly coded technology solution. For a single title license (see Licensing Options for multi-title), we charge a $250,000 guarantee against a 5% royalty of the wholesale price for the title (less Cost of Goods Sold and certain other allowable deductions). This includes all platforms on which you may release your title. To get started, contact us and we will send you an evaluation SDK.

And UE2 details from Epic:

Unreal Engine 2 Licensing Terms

Representing years of development and powering numerous best-selling titles on multiple platforms, the Unreal Engine 2 technology is available for license on a per-platform basis. Three platforms are available: PC, Xbox, and PlayStation 2.

A PC platform license is only required if you intend to ship a retail PC game. If you are developing a console-only title, you may freely use the PC code for development, testing and for its back-end game-server components (for multiplayer games). Note that a PC license includes the right to ship your game on all personal computer operating systems, including Windows and Linux, as well as MacOS X; by paying once for the PC platform license you may ship on any or all of these operating systems at no additional cost.
Royalty-Bearing License - For retail console & PC products

A non-refundable, non-recoupable license fee is due on execution of the agreement. The cost is US $350,000 for one of the available Unreal Engine 2 platforms, plus US $50,000 for each additional platform. A royalty of 3% is due on all revenue from the game, calculated on the wholesale price of the product minus (for console SKUs) console manufacturer fees. In the case of massive-multiplayer online games, the royalty is also due on the additional forms of revenue including subscriptions and advertisements

UE3, id Tech 5, Source and CryEngine(Any version) pricing info is not available.

[Bad Sector]

Two corrections/comments:

idTech5 - Terrain is completely crafted inside engine (parts can be imported). Props are completely static meshes, .... even complete buildings.

Actually according to a video (or article?), the terrain is first made in a 3D modelling program such as Max and then converted to a format that the editor will use to add detail.


UE2 - Same as idTech3.


Unreal Engine 2 has a terrain engine, whereas id Tech 3 does not.


UE3 - Don't know about the terrain part, rest quite like idTech5 and Crytek2.

Actually i believe UE3 is "a little bit of everything", using an occlusion-query visibility system similar to the one used in Serious Engine 2.

This is basically because of the culling techniques used. Indoor engines still use BSPs (Binary Space Partitioning). Whereas outdoor engines uses octree and stuff (not my thing, so I don't know too much). :)

Actually you can use octrees for pretty much anything. The engine i worked on in that company i mentioned used hand-placed "areas" which were connected via portals and big areas were broken in octrees. Of course i'm a big fan of automatic visibility info generation, so i didn't liked this approach but it can be done and if done right it works fine. Besides BSP and octrees are somewhat related data structures.

I haven't wrote a terrain engine, but from what i know these engines use some sort of raycasting method to find the visible part of the grid and octrees are used only for the buildings in the terrain.

I can't say i like terrains though :-). First of all i don't like outdoor areas :D but also i believe they're limited in functionality. They're just 2D height maps in need of all sorts of tricks to produce some nice looking images. But you can't have structures like caves due to the 2D nature of the data.

Voxels on the other hand, now these are nice for crafting outdoor areas :-). Unfortunately they're currently very expensive (performance-wise) to render and converting them to polygons (like Cry Engine 2 does with its voxel patches) ends with just a static mesh so you can't have all the fine stuff voxels are good for (destructible terrain for example).

Of course there is also Source's solution of using big brushes with displacement mapping. I doubt it can do huge outdoor areas like a more focused terrain engine does (think Far Cry 2), but it is a nice method for many cases, and "sculpting" those displacement maps in Hammer is fun :-).


Btw, i'm writing a new 3D engine and toolset. You can imagine what kind of paradigm i'm following for the engine's design and tools :D.

[peoplessi]

Not limited to only that, I expect there to be to as much effort on brush based tools also.

[Sayantan]

Unreal Engine 2 has a terrain engine, whereas id Tech 3 does not.

Is it like the one in Q3 and D3?? I'm not so well-versed with the U-series.

occlusion-query visibility system

I want to know a bit more on that if you know.

Actually you can use octrees for pretty much anything. The engine i worked on in that company i mentioned used hand-placed "areas" which were connected via portals and big areas were broken in octrees. Of course i'm a big fan of automatic visibility info generation, so i didn't liked this approach but it can be done and if done right it works fine. Besides BSP and octrees are somewhat related data structures.

These days as most engines are becoming kind of an outdoor-cum-indoor engine, both BSP's and octrees are used as I heard. Not sure how true that is though.

but also i believe they're limited in functionality. They're just 2D height maps in need of all sorts of tricks to produce some nice looking images. But you can't have structures like caves due to the 2D nature of the data.

Well people found a way out for that. They cut a hole in there and put a indoor level geometry over there .... LOL. So for those engines, they actually model the caves and shove it in there ... LOL. :p

Btw, i'm writing a new 3D engine and toolset. You can imagine what kind of paradigm i'm following for the engine's design and tools :D.

Cool man. I'll make you stupid models in my pass-time to play with. :D

[Bad Sector]

Is it like the one in Q3 and D3?? I'm not so well-versed with the U-series.

Q3 and D3 do not support terrain at all. They have curves, though and there are 3rd party tools which generate terrains using curves and/or brushes. But there isn't any terrain specific code in the engine.

I want to know a bit more on that if you know.

Well, its simple. Your GFX card can count how many pixels were drawn between some calls to the graphics API. An occlusion query is done by sending an approximation of some complex geometry (like a bounding box for a statue) with everything except depth testing turned off (so just depth values are calculated but not color, normal, specular or whatever else is used) to the card and receiving the number of the pixels processed (passed the depth test, since only depth testing is enabled). If there were no pixels processed, then the approximation (f.e. the box) is invisible, so there is no reason to process the full geometry, thus saving time.

In simpler terms, occlusion query is done by asking the card to render a bounding mesh but with a locked framebuffer so the mesh wont be really rednered, and if this mesh can be rendered if the framebuffer wasn't locked then the engine sends the full mesh this bounds.

An example is sending a bounding box (12 flat triangles with no textures) of a big statue static mesh (can be more than 10k triangles with textures, normal maps, speculars, etc). If the bounding box can be drawn, then the engine sends the big statue. If not, the engine skips the statue and the processing of all the textures, triangles, etc is skipped.

There are some small details about the whole process (like not asking for the result immediately to avoid synchronizing the CPU with the GPU), but the generic idea is this.

More info in this presentation (http://www.cs.virginia.edu/~gfx/Courses/2002/RealTime.fall.02/GDC2002_occlusion.ppt). Its a little old and NV_occlusion_query is replaced with ARB_occlusion_query which now is a part of the core OpenGL since version 1.5, but what the presentation mentions is the same.

[Bad Sector]

Yea, id Tech 4 didn't supported terrains initially. Now of course it supports huge terrains using megatextures (like in Quake Wars), but personally i see id Tech 4 as a indoor engine mostly - especially the original version.

All voxel-based engines did support terrains (in fact most voxel engines in 90s games were basically terrain engines). For example, this game (http://en.wikipedia.org/wiki/Comanche_series) (shot (http://upload.wikimedia.org/wikipedia/en/4/46/Comanche_1992.png)), although the most advanced use of voxel rendering in a game so far is probably Outcast (http://en.wikipedia.org/wiki/Outcast_(video_game)) (shot (http://upload.wikimedia.org/wikipedia/en/a/a8/Outcast.jpg)). But Outcast was released in 1999 so its not as old as the other (1992).

[Parkar]

Actually i believe UE3 is "a little bit of everything", using an occlusion-query visibility system similar to the one used in Serious Engine 2.


You no longer have to place any kind of special occulsion objects like you used to in UE2. BSP geometry and any mesh thats closed will occuld. I am not sure what technuiqe the enigne uses though.

Is it like the one in Q3 and D3?? I'm not so well-versed with the U-series.


It has a special special terrain actor you place and can then paint height, textures and meshes onto it. You can also import height maps as a starting point.


As someone mentioned earlier UE3 is a bit of everything.

Generally levels are heavily mesh based and mehses are better then BSP for performance so BSP is only used for the skeleton of the map and things you don't want to lock down and be able to change if needed. I have not played around much with the terrain but I think it's more or less the same as in UE2 but with a bit better tools.

[Bad Sector]

@Parkar:
Occlusion queries do not need special occlusion objects.

[Bad Sector]

AFAIK Carmack said about a full voxel world, these games use only a heightmap for their voxels. Although i do remember seeing somewhere at the past an engine with full voxel world.

I had some ideas about this about a year ago which would produce worlds with theoretically infinite detail (practically as detail as the artists can put), using some sort of hierarchical cells-and-portals raycasting system. I didn't tried to implement it though because i have no practical use for it at the moment (basically, i don't have an army of ultra-talented artists to use it :-P). I wasn't the only one thinknig about this it seems, since two weeks ago i found a paper about rendering voxels in a similar fashion i was thinking (at least from a quick scan i did, i didn't read it). Here is a video of the algorithm in action (http://www.youtube.com/watch?v=HScYuRhgEJw).

Voxels seem to come back basically, there are some nice looking engines (http://atomontage.com/?id=gallery) with voxels. And the related tools seem to improving (http://www.3d-coat.com/v3_voxel_sculpting.html).

EDIT: btw, CSG fits nicely with voxel world editing :-)

[Parkar]

@Parkar:
Occlusion queries do not need special occlusion objects.

Yea, I know. I wasn't trying to invalidate your statement. Just added what I know about occlusion in UE2/3.

[Bad Sector]

I dont see this as much of a problem, unless you don't have access to these tools. Today's OSes support multitasking just fine :-P. The terrain scenario you mention its exaggerated i think, its mostly a tool (basically a plugin for GtkRadiant, so its actually in the editor) for making/editing/whatever the terrain.

[Sayantan]

Another reason id engines have fallen off devs' preference is IMO, the amount of additional tools you need to make decent levels. As its been mentioned here, dont id tech 3 and 4 need several extra tools to generate terrain? One for making it, another one modifiying it, another one for exporting it. Unreal 2 let you use create terrains from the editor, didnt it? And I think both Cry editors 1 and 2 let you do so as well, right?

For idTech4 you can make terrains (or terrain section to be precise) in 3dsmax and then export it. Works just fine. Though works like a typical model with collision. Hence you just need 3dsmax(which most studios use already) for modeling the terrain, Photoshop (obviously) for texturing that, and lastly Radiant for integration. There's nothing else you need.

[peoplessi]

Bad Sector, nice link, 3D Coat plus voxels looks great. Too bad they don't use something like OpenCL so that anyone could enjoy those features.

[Bad Sector]

OpenCL is very new thing, whereas CUDA is much older and proven. OpenCL probably didn't exist when 3D Coat was in development.

On the other hand, OpenCL's design is about the same as CUDA's and if 3D Coat uses the driver api and not the enhanced C language, it will be easy to port it to OpenCL (although personally i find the enhanced C language much easier to use).

[Jokke_r]

i don't seem to understand the difference with brushes and meshes? whats what, i've only ever really used one level editor (MaxED, for Max Payne) and the term "brush" never came up, although you are dealing with meshes there. You draw a 2D outline point to point (vertex to vertex) on a grid and when complete, you extrude a 3D mesh from that outline which you can manipulate in certain ways. You can union/join/intersect/subtract with other meshes to create more complex forms, depending if the mesh has faces culled inwards or outwards it can be either a room or an object which is grouped to a room, rooms are divided by "portals" which are simply 2 sided polygons wchich divide certain areas. I assume they work in the way that first the game engine determines what room the player is in in order to get the list of objects/polys within the room, then checks for visibility of those objects/polys on the screen to be drawn, if the portal is visible then the objects and polys of the connected room must also be checked for visibility.


EDIT: just read wikipedia and according to it, the word Brush, in relation to game design is just a convex piece of geometry, same thing as a mesh.

[Bad Sector]

A brush can be used to make a mesh, but the opposite isn't always true (you can convert a static mesh to a set of brushes, but the process is hardly error-free and works only for simple meshes).

A brush is defined by some planes. A plane is an infinitely long flat geometry (as opposed to the "plane" found in some 3D modelling programs which is in fact a quad - a rectangle in 3D space). The brush is a solid area which is defined by the intersection of all planes - in other words the "common area" behind the planes (a plane has a front and a back side which is usually identified by the plane's normal - a vector that points towards the front side). What we see as a brush's mesh is basically an approximation of the brush using triangles (and there are many methods to produce the mesh of a brush - personally i use a simple method of creating a huge polygon for each plane and clipping it using the other planes to figure out the visible part of that plane).

This way of representing solids (brushes) is very efficient for doing CSG calculations such as subtraction, keeping common area, keeping the area that is unique to two brushes, etc. It is also efficient for doing collision detection, makes sure that the map is made of closed meshes (can be useful for stencil shadows and other algorithms requiring closed meshes and/or geometry silhouettes), its harder to make invalid geometry for BSP+PVS cases, requires less storage space than a mesh with the same shape, provides automatic texturing and other things. Using plain meshes does not provide the above or provide very limited support (usually by converting the mesh to a brush-like structure for the lifetime of the operation).

Of course using brushes has its downside, with the most prominent that it is hard to make detail with brushes. However i believe that detail should be done with other methods (static meshes, engine generated geometry, etc).

[Jokke_r]

i understand, so if every face of the geometry must be have a plane which is parallel to it (a plane which must be represented with x,y,z coordinates and angles x,y,z) instead of having vertex and edge information. But why use this kind of geometry? other than to save memory, since it cannot be used for concave geometry, or well if not the "object" is segmented into many convex pieces. Anyhow, how are the brushes made then? i assume you don't make them by manipulating these planes but by normal modeling, as in placing verts and extruding(usually) and later converted to a brush.

I Would assume regular meshes are faster to render than brushes since you don't have to calculate the vertices first since they are explicit and as far as i know in order to rasterize you need the vetices.

So yeah, only benefits i see here is memory, but downsides i see extra computation which would be bad if it's done during runtime.

[Parkar]

The term brushes usually refer to geometry that's used to build the level geometry. In other words the brushes in say quake and unreal based engines are compiled to to make the final geometry. When you refer to a mesh it's usually actual geometry used in the game. In some sense the brush is just a tool.

At least that's the way I think of it. The terms might be used in other ways in other game engines.

[Jokke_r]

Hmm, so brush based geometry is compiled to polygons when the level is complete, makes sense. I understand that using brushes when making a level could be faster when say having to extrude a face of a cube, instead of manipulating say the X coordinates of the four verts that make the face, it instead only needs to modify the x coordinate of the plane, which would make it faster, still when compiled all brush based geometry is compiled to polygons with vertex and edge data usually i assume. So it is indeed merely a tool of creating and manipulating unfinished geometry.

[Bad Sector]

Brushes have some nice features i mentioned above (like for collision detection). Of course they have to be converted to meshes so they'll be rendered, but this is done -depending on the engine- at compile or load time.

Note that in Unreal brushes although similar with most other engines, they're not the same. In Unreal the geometry has to be rebuilt if you want to see it and in the meanwhile you work with an approximation, which makes the process a little harder if you expect instant feedback. There are positive and negative side effects to this method. Unlike in Quake, Unreal supports negative (subtractive) brushes, which allows for non-destructive editing (in Quake if you subtract a brush from another, you end with a different set of brushes). On the other hand, since you have to rebuild the geometry for every few steps, which takes a bit of time, you probably lose the time benefit from the negative brushes.

[peoplessi]

Not really, you dont have to rebuild after every few blocks - and when you do, it's not that tedious, it's a quick press of a button. The benefits of it are much higher.

---------- Post added at 02:29 PM ---------- Previous post was at 12:52 PM ----------

VE3D Video - Unreal Engine 3: New Features Trailer (Flash HD) (http://ve3d.ign.com/videos/play/47108/PC/Unreal-Tournament-III/Trailer/Unreal-Engine-3-New-Features-Trailer/Flash-Video)

Touches the subject at hand over here. New video of new new features in UE3. They seem to be updating it as they go along, same with Valve on Hammer.

[Bad Sector]

Its still an approximation of what you get, thats what i mean. But indeed the rebuild is fast.

Nice video.

[Gryph]

That voxel video Bad Sector posted was really cool. :) I look forward to a polygon less world.

[Nihilanth]

Agreed, cool stuff. I wonder what's to come.

[Bad Sector]

Well, even if voxels are used for the world, most of the current algorithms for animation (current=those invented the last decades) are for polygons, so voxels will probably be used for statics environment and polygons for the dynamic stuff. Of course some effects, such as liquids can probably be animated better with voxels than with polygons (because, after all, liquids are volumes and voxels are "volumetric pixels" :-).

[peoplessi]

We will see, so far what've heard from Carmack, id Tech 6 just might have something like that(sparse voxel octree). Interesting times, but to remember how far away that still is if we talk about years.

[Jokke_r]

well red faction already did that like 8 years ago

[peoplessi]

It was highly restricted to certain elements, so it hasn't been done.

[Bad Sector]

@tommy-vercetti:
The method i'm thinking (beh, at some point i'll just give in and implement it, i know, even if its mostly useless) works exactly like that, minus the initial terrain: you use "brushes" that add and remove volume. Think brushes as volumes (spheres, cubes, pyramids, etc) that can be of any size and shape, not brushes as the definition i gave above (although these could work as well). The way i'm imagining the editor is that you simply fly around in 3D and add/subtract volume to/from the world using big brushes for the grand scale and small brushes for detail.

I might try to implement a rough version of this idea in OpenCL once nVidia releases a proper SDK.

[Bad Sector]

This would require a huge amount of physics processing power to be done right. We'll eventually come to this, but i'm not sure if the current hardware we have can process such a system in realtime.

The terrain digging part would be possible, i suppose, since this is what the whole thing is all about: adding/subtracting volumes. It doesn't matter if its a terrain, a building, some huge creature or whatever - it just has to be volume. But as i said, animating this is very tricky and i doubt it'll be used for dynamic stuff.

In any case, you might want to check out Ken Silverman's Cave VOXLAP demo (http://advsys.net/ken/voxlap/voxlap03.htm) which uses voxels and you can dig everywhere (there are some physics involved too but very simple - IIRC you can cut some area and it'll fall if nothing supports it, but it wont collide and fall through the rest of the geometry). Its low resolution and runs on a single CPU thread, but you can think of it as the "Quake 1"* of what will happen next.

(*i mean compare Quake 1's graphics and engine with today's engines to figure out the progress).

[SpinX]

outcast was a wonderfull example of what voxels could do, it had the best graphics of that year... classic game too...

[unforgiven]

Unigine Engine is one of the best engine I ever used. ( it's not comparable to Source Engine or UnREAL , IdTech 5 but it's cheap with lot of features )

http://unigine.com

[Kristian Joensen]

It seems that Terminal Reality are licensing their Ghostbusters engine, Infernal Engine (http://www.infernalengine.com). Courtesy of 6th Venom of doom3world.org.

[peoplessi]

Gamespot: Hollenshead Rages about PC gaming, E3 surprises
(http://www.gamespot.com/news/6207773.html) - Thanks to Gryph for digging this up, had a lot of id Tech 5 in it.

id TECH 5 REVS ITS ENGINE (Steve Nix answering)
GS: Now, let's talk about the id Tech 5 engine. How hard is it breaking into a middleware market that is pretty much dominated by Epic Games' Unreal engine?

Steve Nix: Well, we don't have to break in, because id was one of the original tech licensees, as is [Wolfenstein-maker] Raven [Software]. There are a number of studios throughout the world who are evaluating id Tech 5 right now, and we don't disclose licenses that haven't been announced for games yet.

However, our goals are obviously going to be different from Epic's. I mean, Epic does a great job with their engine technology license, and they're very dominant right now. There are a number of other engines out there--the Infernal engine, Gamebryo--that are sort of going for a larger market share. But id's goal has always been to work with a small set of high-quality partners who are going to build really, really great games full of technology. It's not to build a large middleware technology organization.

Also, we are primarily a game developer. It just so happens that we create, in our opinion, the best technology in the world, and we occasionally license it out to other game developers. Games like Half-Life, Call of Duty, and Medal of Honor use our technology. But again, our goal is not to be a middleware organization.

The other thing is that, with respect to the way we've always done technology, is we're very careful with what we promise is going to be in the Tech, so that it's actually there when we do it. So we've been guarded about getting it out to people until we knew how things were ultimately going to work out. It's only been recently that all the things that we expected to happen are now working, or demonstrable.

[LadiesAndGentlemen]

Is it me, or does Crystal Tools make this engine look like a worthless pile of trash?

http://www.grayhouse.com/wp-content/uploads/2008/02/ff13crystalengine.jpg

http://kotaku.com/assets/resources/2008/02/crystal_tools.jpg

http://cache.gawker.com/assets/images/kotaku/2008/10/final_fantasy_versus_xiii.jpg

[SpinX]

is this ingame?! I really doubt it... That hair is tooo good...

[LadiesAndGentlemen]

Apparently, not only is it real-time but it's supposed to run on a PS3.

[predefined]

hahaha...right ;)

[SpinX]

I think this is pre renderd HD footage that can be played with blu ray quality on a PS3 :)

[Talos]

lmao who tagged this thread "god"? :D

Btw. this ff13 shot looks more like in-game to me http://www.unlimitedgamer.net/wp-content/uploads/2006/09/final-fantasy-13-tgs.jpg ;)

[Nihilanth]

Better luck next time LadiesAndGentlemen.

[LadiesAndGentlemen]

That screenshot is so old.

[peoplessi]

Would you mind changing those to thumbnails or something, and yes, prerender stuff doesn't qualify. There is enough gameplay footage to say it's not like that in game.

[MeatWagon]

Regarding the Voxel subject previously mentioned has anybody checked out c4 engine? http://www.terathon.com/c4engine/index.php

It uses voxels to sculpt the terrain (A triangle mesh is generated over the surface on the fly, just like the afore mentioned 3d Coat)

The tools are primitive at the moment because it has only just been implemented but its pretty good so far.

[predefined]

lmao who tagged this thread "god"? :D

Btw. this ff13 shot looks more like in-game to me http://www.unlimitedgamer.net/wp-content/uploads/2006/09/final-fantasy-13-tgs.jpg ;)

That was me...i hope that ain't considered as "trolling"? :p

[Bad Sector]

Regarding the Voxel subject previously mentioned has anybody checked out c4 engine? http://www.terathon.com/c4engine/index.php

It uses voxels to sculpt the terrain (A triangle mesh is generated over the surface on the fly, just like the afore mentioned 3d Coat)

The tools are primitive at the moment because it has only just been implemented but its pretty good so far.

I know about C4 since 2-3 years now (unless you're talking about the terrain tools, the tools haven't changed much since then). Its an ok engine, but its awfully slow and the world is made of meshes which makes editing a bit difficult if you want to use the in-engine editor. It also has the bad habit to require manual visibility information. Its basically a good example of how i would not like an engine to be made.

On the other hand its cheap, -people say that it is- documented, has a nice code cdesign and the guy behind it (its made by a single person AFAIK) is a regular publisher of graphics-related articles and known in the computer graphics programming community, which probably makes it a good choice for a new studio.

I even thought to buy an indie license back when the engine was in beta stage and the price was $100 so i could play a little with it, but i decided to wait until the speed issues was fixed. Eventually the indie price rised to $350 and the speed issues still exist :-P.

[MeatWagon]

^I got myself a license a few years ago and have been messing with it ever since. The tools have changed a hell of a lot in that time, including the terrain tools (Which is what I meant was primitive at the moment, theres only an add, subtract and a smooth brush)
Before hand the terrain was just an imported height map that couldnt be edited and had no terrain shader.

I agree about the manual visibility set up, the portals can be tiresome.
As for speed, its always ran ok for me on my older hardware, and performance has improved over the years, it runs very smoothly for me now on my new system.

Theres also a node based shader editor and node based scripting tool which are both pretty powerful.

But anyway its not to everyones taste. programmers love it though.

[Bad Sector]

Speak for yourself, i'm a programmer :-P.

What kind of computer you have? I have a 1GB GTX280, 2GB of RAM and a quadcore processor and the performance is bad when compared to other engines (especially full blown games with better technical features - note that i mention features not content).

Also as i said in some other page (about Unreal Engine's tool), visual scripting is a nice gimmick but when it comes down to doing serious stuff using a proper (text) scripting language is always better and faster (unless you cannot type of course). In both cases you need to think as a programmer anyway, so its not like its easier for artists because it is "visual".

The visual shader editor is a more useful tool though, since shaders are all about visuals. Not that personally i mind using plain text files for defining shaders, but in this case using text files is actually harder and the proper way should be to use a visual tool. So this is a nice feature.

[MeatWagon]

right now I'm on a quad core system,(AMD Phenom II 940) only a geforce 9500gt with 512 meg vram, 8 gig of sytem ram (Althought I'm on XP so it may as well be only 2 gig)

But I will concede your point about performance compared to full blown games, thats a good point which I never considered.

[Reaper]

In any case, you might want to check out Ken Silverman's Cave VOXLAP demo (http://advsys.net/ken/voxlap/voxlap03.htm) which uses voxels and you can dig everywhere (there are some physics involved too but very simple - IIRC you can cut some area and it'll fall if nothing supports it, but it wont collide and fall through the rest of the geometry). Its low resolution and runs on a single CPU thread, but you can think of it as the "Quake 1"* of what will happen next.
Wouldn't a more playable example be Voxelstein 3D? (http://sourceforge.net/project/showfiles.php?group_id=224163)

[Bad Sector]

The Cave demo shows a destructible terrain/cave system with digging, which is what we were talking about. Voxelstein 3D has a destructible world, but you need to play for a while (especially the initial boring* part where you have to break free) to get to a point where you can see the effect.

(*=imho)

[peoplessi]

Bad Sector, would you mind commenting on this thread? :) http://forums.3drealms.com/vb/showthread.php?t=35328 - more specifically, the LRBini.

[peoplessi]

More about Infernal Engine in these two very good presentations:

Ghost Busters Gameplay and Testing - Infernal Engine VELOCITY Physics (http://www.hardocp.com/news.html?news=MzkwMjUsLCxoZW50aHVzaWFzdCwsLDE=)
Infernal Engine VELOCITY Physics PS3 Demo (http://www.hardocp.com/news.html?news=Mzg5NzksLCxoZW50aHVzaWFzdCwsLDE=)

[Gryph]

Short interview with Todd Hollenshead. Nothing really new new revealed since it's more about their licensing philosophy.

http://www.gamasutra.com/php-bin/news_index.php?story=23580

[Tualmasok]

It kinda sucked that id Tech 4 fell flat on it's face. I rather liked everything about the engine. :(

Ever played Escape From Butcher Bay? It came out *just* before Doom 3, had better graphics and superior gameplay. I suspect the failings of id Tech 4 became apparent when a relatively unknown developer could match and even better what id had spent years developing and promoting.

I love Butcher Bay. Looked great on a 9800 Pro...

[vcxzet]

id makes the best engines. tech 4 sucked when it first came out
but now it is kick ass. maybe they may get it right in tech 5 from the beginning

[Bad Sector]

@Tualmasok:
The Starbreeze engine is much like the Source engine: instead of making a new engine every time around (like id does), the engine follows an evolutionary path. Basically the engine used for Escape from butcher bay is the same engine they used in their previous games and its development started back in late 90s.

[Theonewayman]

Speak for yourself, i'm a programmer :-P.

What kind of computer you have? I have a 1GB GTX280, 2GB of RAM and a quadcore processor and the performance is bad when compared to other engines (especially full blown games with better technical features - note that i mention features not content).

You can't compare a 350€ indi engine made by one guy to a engine made by a team and that custs much more.

C4 is a impressive engine for its price, and the maker seams to be very active and helpful. The problem with it is the lack of a good demo with good art. But technically it is very powerful.

Also if you don't know the placement of Portals/sectors by hand for visualization is not a bad thing it is even used by AAA game engines like id tech 4 and the MaxFX engine, it is a good way to optimize a level and gives more flexibility and control them automated methods that also take precious CPU cycles.

[Sayantan]

You can't compare a 350€ indi engine made by one guy to a engine made by a team and that custs much more.

C4 is a impressive engine for its price, and the maker seams to be very active and helpful. The problem with it is the lack of a good demo with good art. But technically it is very powerful.

Also if you don't know the placement of Portals/sectors by hand for visualization is not a bad thing it is even used by AAA game engines like id tech 4 and the MaxFX engine, it is a good way to optimize a level and gives more flexibility and control them automated methods that also take precious CPU cycles.

I've heard programmers complaining about optimizations in C4.

[Theonewayman]

I've heard programmers complaining about optimizations in C4.

What kind of optimizations? Engine optimizations, level optimizations? Saying complaining about optimizations is a litle vague.

I add no problem using portal's and zones in C4 if is that you are referring to. :)

Also any engine will have is share of problems if the team using it is not familiar with it, thats why theres a forum there to help solving them, you will see that Eric is very helpful.

I'm not saying for you guys to buy the engine theres a free demo with all the tools available if you want to mess with it, thats what i use.

[Sayantan]

What kind of optimizations? Engine optimizations, level optimizations? Saying complaining about optimizations is a litle vague.

Forgot. Long time back.

[predefined]

Article on Id-tech 6 (http://www.gamestar.de/hardware/specials/1956284/neue_id_software_engine_mit_voxel_grafik.html)

Yes, number 6! Its about the usage of voxels!

[Nihilanth]

If I could only understand a word.

Wait, are those pics from id Tech 6!? :eek:

[predefined]

Actually i think not exactly. The screens are from a research project from one of the designers from id as i recall. But it's a good demonstration of the idea behind "next gen" voxel technology. Things are supposed to become more "volumetric".

unfortunately my German isn't that great either. Someone has to come around and point out the key points.

[hellchicken]

Are you interested in the parts specifically about how voxel technology works? Because that is basically the whole article.

Only the first part of the article has to do with id Software, stating that id-tech 6 will be based on voxel-technology and that they will use "Sparse-Octree (SOT)" to keep the amount of data required for high-end visuals using voxels to a manageable level. Also, currently the biggest problem with voxel-technology apparently is lighting, i.e. wether they can use dynamic lighting or will have to revert to "static means of lighting", which would be a big step back in the industry.
And of course the article states that it will be a long time before we can substantialy see the technology in action.


Personally I love that id is trying to push forward voxel technology. I remember playing Outcast many years ago and that it looked fu**in' beautiful. If you had the right hardware that is.

[Kien]

What is the advantage of everything being small boxes? (Meaning it needs a hell lot of them to make anything look close to smooth)

http://www.drububu.com/tutorial/images/voxel_pixelart.gif

Just look at it. You would need a hell lot of voxels to come close to the smoothness of a polygon mesh. And there is no local detail level. If you want a small detail then you must "subdivie" the whole thing.

[hellchicken]

What is the advantage of everything being small boxes? (Meaning it needs a hell lot of them to make anything look close to smooth)

http://www.drububu.com/tutorial/images/voxel_pixelart.gif

Just look at it. You would need a hell lot of voxels to come close to the smoothness of a polygon mesh. And there is no local detail level. If you want a small detail then you must "subdivie" the whole thing.

According to the article voxels make bump-mapping, normal-mapping and texturing absolete.

Though, I wouldn't know. I'm absolutely clueless about these things.

[Jokke_r]

i'm still completely lost when it comes to animating voxel models, the complexity just boggles my mind.

[Gryph]

It looks like Jim Dose has rejoined id software after a stint at Valve for a few years. Jon Olick, the guy who gave that siggraph voxel presentation, has moved on to be a Sony Advisory Board Member.

[Damien_Azreal]

Voxels are an interesting concept, but I'm not sold on them. Specially in the thought of them being used for high detail characters and such.
If we could see a voxel created character in action, that could help.

[Paroxysm]

i'm still completely lost when it comes to animating voxel models, the complexity just boggles my mind.

Same here. I always imagine it would be something akin to working on claymation. Manipulating something with mass. Of course that comparison might be retarded so probably ask someone who actually knows.

[Kien]

So... get someone here who knows. :p

[Bad Sector]

I don't think dynamic parts will be made with voxels. Probably it will be a voxel+polygon hybrid.

@Kien:
Voxels are not solid cubes, although this is a common way to represent them in realtime. However a voxel is volume and using cubes is an approximation (in fact a very crude one). A voxel can have a cloudy form, or a solid form or a procedural material which makes up its appearance.

[Kristian Joensen]

It looks like Jim Dose has rejoined id software after a stint at Valve for a few years. Jon Olick, the guy who gave that siggraph voxel presentation, has moved on to be a Sony Advisory Board Member.

Actually, he had that advisory board membership prior to leaving(even joining I think) id.

---------- Post added at 02:40 PM ---------- Previous post was at 02:37 PM ----------

Voxels are an interesting concept, but I'm not sold on them. Specially in the thought of them being used for high detail characters and such.
If we could see a voxel created character in action, that could help.

Actually last I heard, id intended to still use polygons for the characters.

[Kien]

@Kien:
Voxels are not solid cubes, although this is a common way to represent them in realtime. However a voxel is volume and using cubes is an approximation (in fact a very crude one). A voxel can have a cloudy form, or a solid form or a procedural material which makes up its appearance.
Uhm ok. (o,o) Never herad of any such. I still don't get it.

ANyway when will we not have to use boxy shapes at all for making 3d shapes? When will we have true smooth surfaces that does not consist of triangles? :p

[peoplessi]

Voxels are an interesting concept, but I'm not sold on them. Specially in the thought of them being used for high detail characters and such.
If we could see a voxel created character in action, that could help.

That's one of the better places to use them.

[Gryph]

http://www.idsoftware.com/iphone-doom-classic-progress/

Carmack mentions using the idtech5 content creation pipeline for future iPhone projects.

[XPM]

Ah voxels...reminds me of outcast
Beautiful game that was :)

[Denz]

now i would like to try a demo that uses voxels on a certain scene and the same demo but using what we have in game now

[IceColdDuke]

For complex models wouldnt voxels put alot of strain on the CPU?

[Bad Sector]

The idea is to raycast voxels in GPU.

[peoplessi]

That's something ATI, nVidia and Intel are looking to solve. Considering how fast the new GPUs will be, the speed-up from generation to another is huge.

Voxels are interesting, even if used for terrain only in the near future. For parts, the upcomping new console generation plays a big part in defining how the tech moves forward. We are almost in the crossing point where you could see viable options in the non-traditional ways, voxels, raytracing - the current way of doing things has been around for a long time to refine itself. Sweeney & Carmack will be the first to pave the way. Just because you don't currently know how to do it, doesn't mean there isn't a way to do it.

[Bad Sector]

Actually, Ken Silverman's voxlap engine has animated voxel characters (as can be seen in Voxelstein), so its possible. I'm not sure how he does it though.

I have an idea about a voxel-based raycasting engine which is *probably* similar to this octree-based talked about (judging from skimming through a related paper), although instead of a hierarchical tree of nodes it is based around a free-form set of convex polyhedrons with portals in the faces that make up each polyhedron. Animating this would probably be a matter of assigning bones like a polygon-based model but instead of vertices, the bones are assigned to the planes that make up the polyhedrons.

[Kien]

Voxel animation wouldn't that require creating and destroying voxels everytime a mesh would be stretching it's polygons? Only rotaion and movement on whole objects would work without changing it's topology if "topology" is the right word with voxels.

[Bad Sector]

If it is a pure voxel engine, then meshes are not used at all. Bones will be attached to voxels directly.

If it is a voxel+polygon hybrid, the static voxel world will generate a depth buffer against which the polygon items will be tested. Its basically the same idea that was used in Quake 1's software renderer: the world was rendered using a different method (scanline span buffers) than the dynamic entities but also generated a depth buffer. Then the dynamic entities were rendered against this depth buffer.

The same idea is used in Polymost actually: the world is rendered using trapezoids with a custom visibility algorithm while the a depth buffer is generated that is used to clip against models and sprites.

And a similar idea is used in my RayFaster 2 (http://www.badsectoracula.com/peponi/rayfaster2/) Flash 3D engine - the world is rendered using raycasting while generating a set of depth span buffers that is used to clip the sprites later.

When having the ability to write your own rendering code, its usually nice idea to use what its best of each problem.

[IceColdDuke]

Stupid question, I never learned raycasting/voxel based rendering approaches that older games used, does anyone know of a good document describing how like Doom/Wolfenstein's renders worked?

[XPM]

About Outcast:

"Outcast's graphics engine is mainly a combination of a ray casting (heightmap) engine, used to render the landscape, and a texture mapping polygon engine, used to render objects. The "Engine Programming" section of the credits in the manual[2] has several subsections related to graphics, among them "Landscape Engine", "Polygon Engine", "Water & Shadows Engine" and "Special effects Engine".

Although Outcast is often cited as a forerunner of voxel technology[3], this is somewhat misleading. The game does not actually model three-dimensional volumes of voxels. Instead, it models the ground as a surface, which may be seen as being made up of voxels. The ground is decorated with objects that are modeled using texture mapped polygons. When Outcast was developed, the term "voxel engine", when applied to computer games, commonly referred to a ray casting engine, for example the VoxelSpace engine. On the "Engine Technology" page of the game's website, the landscape engine is also referred to as the "Voxels engine"."

http://en.wikipedia.org/wiki/Outcast_(game)

[Bad Sector]

Stupid question, I never learned raycasting/voxel based rendering approaches that older games used, does anyone know of a good document describing how like Doom/Wolfenstein's renders worked?

Wolfenstein 3D's renderer and Doom's renderer works in very different fashions. They're still raycasting, of course, but the raycasting is done differently.

For Wolf3D-style raycasting this tutorial (http://www.permadi.com/tutorial/raycast/index.html) is the best i've seen. It actually goes beyond drawing walls and adds stuff like floor and ceiling texturing, diminishing lighting, fog, variable wall height and other stuff. My RayFaster 1 (http://gimme.badsectoracula.com/rayfaster) uses mostly stuff from this tutorial, although the floor/ceiling rendering is done using a different (but similar) method. The tutorial doesn't describe how to render sprites though, but for the single wall size version its easy: when finding walls fill a 1D depth buffer (an array that contains a single depth value for each vertical span). Then for each sprite, bring the sprite's position in camera's space (subtract the camera's position from the sprite's position and counter-rotate it to match the camera rotation), sort the sprites by depth (how far the sprite is from the camera - note that at this point you ignore sprites that are behind the camera or closer than a predefined value), use the projection formula describe in the article to find the sprite's size (with and height usually are the same) and draw the sprite in vertical spans. For each span check if the value stored in the depth buffer is larger than the sprite's depth (so the wall span is farther than the sprite) and draw the span if it is. This will clip the sprites against the world.

For Doom, there is much less information and there are many ways to get the same or similar results. I did a search and found this document (http://www.gamers.org/dEngine/doom/papers/doomrend.ps.gz) (you'll need a PostScript reader such as GhostScript to read it) describes the basic ideas, although it doesn't go in much detail.

My understanding (from what i've read around the net in several places, by writing a similar engine (http://www.badsectoracula.com/peponi/rayfaster2/) and of course fueled by a wild dose of speculation) is that Doom uses a combination of BSP and PVS, like Quake (Carmack said at some point that he realized much later that the development of Quake's visibility algorithms did a full circle and he basically did the same thing as he did in Doom). The map is divided in areas (not the sectors, i think a grid is used) and each area contains a list of possibly visible linedefs. Then raycasting is performed but instead of casting against a grid, the raycasting is performed by intersecting the camera's rays against the linedefs. If an intersection is found, the span is drawn like described in the ps document. The BSP is used to have the linedefs sorted from far to close so there won't be a need to do any sorting. I assume (but i'm not sure) that the sprite drawing order is also figured out from the BSP.

Of course this is my assumption.

Note that once RayFaster 2 (http://www.badsectoracula.com/peponi/rayfaster2/) is at a game usable state i plan to write a technical article on how i made it since there seems to be a lack of information about writing a sector-based engine.

[Theonewayman]

I don't know much about this stuff but afaik voxels (pixels with volume) are more fast them triangles (thats why they are used in sculpting tools like zbrush and 3DCoat and also to represent medical scans in 3D) the problem is that a voxel takes more memory them a triangle (thats because they contain more information), a single voxel model can sometimes use GB's of memory. They aren't also very easy to animate and unfortunately GPU's don't accelerate them.
Imo what Carmake hopes with idtech 6 is to make the GPU makers see the benefits of the tech and put some silicon to accelerate voxels on future GPU's.

For the ones that don't know Id tech 6 will be a hybrid it will have voxels for the static world geometry and triangles for the characters and animated objects.

[Kristian Joensen]

There is actually a chance that the first id Tech 5 licensee game has been announced. Since we know that Splash Damage uses id technology. But it is currently unknown wheter Brink uses id Tech 5 or id Tech 4.

[predefined]

Is id at e3 at all? Haven't seen anything from them so far.

[Bad Sector]

@Theonewayman:
Voxels are *not* faster than triangles - triangle rasterization is currently the faster method for most cases. However voxels have some properties that allow for some sorts of optimizations not possible with triangles. One of them is dynamic LOD with theoritically infinite detail.

The reason zbrush and similar tools use voxels has to do more with the fact that its easier to "skulpt" voxel data (from a code perspective) than triangles. Although i'm not 100% sure these are true voxels.

[Kien]

No voxels in zbrush. :P Only in 3dcoat and freeform (or what it's called).

The good about voxel shapes is that they have no topology. Which is what you want then sculpting, not worry about topology.

[Gryph]

There is actually a chance that the first id Tech 5 licensee game has been announced. Since we know that Splash Damage uses id technology. But it is currently unknown wheter Brink uses id Tech 5 or id Tech 4.

Do we know for sure they're using id tech? They could just as easily be using UE3. Since they're quite experienced with id tech I'd expect them them to use it but I don't want to flat out assume they are. But if they are using id tech then I'm quite sure it will be id tech 5.

[Derfernet]

Zbrush uses "Pixols". It's easy to get confused with the terms.

[Kristian Joensen]

Do we know for sure they're using id tech? They could just as easily be using UE3. Since they're quite experienced with id tech I'd expect them them to use it but I don't want to flat out assume they are. But if they are using id tech then I'm quite sure it will be id tech 5.

A) There have been job ads asking for people with id technology
B) They have specifically stated they are still using id technology(Although I haven't got that quote handy).

---------- Post added at 11:40 PM ---------- Previous post was at 11:25 PM ----------

Look at the first thing mentioned under preferred skills here. (http://splashdamage.com/content/graphics-programmer)

[Gryph]

Great news! Thanks for clearing that up