John Carmack PCGamer interview...next engine to have "unique texturing on everything"

[Gabrobot]

Let's say you have your finished terrain, it's working in-game, and you decide you want to add a cave. You're screwed. All the hand-drawn touch-ups will be lost. This is not an insignificant limitation.

Like I said, the programmers who only deal in abstract ideas and tech demos will dismiss the practical implications of this, but the development teams that actually have to produce shipping titles are going to feel it.

It's uneconomical not because of the unique texturing, but because it makes the production pipeline much more inflexible. I will be proven right once people start using the technology in a production environment.

What is uneconomical is trying to do the final art and basic gameplay design at the same time. What id Software (and other devs...Epic specifically) do is they rough out the gameplay and geometry until it's final...as in, that is what they want in the final game and they won't change anything. Then they move on, and the artists come in and go crazy making it look pretty. So the times that they come in afterwards and decide to add a cave or something after all that is finished should be pretty minimal (as in never).

In fact you can kind of see this with Quake Wars...the terrain texturing in a lot of older screens and especially some of the leaked beta test screens looked absolutely awful...this was because they were still working on the terrain and they hadn't gone in and prettied it up yet.

 

[JoshKlint]

It's up to the design tools to handle this sort of thing well. I wouldn't be worried about this being a problem until you've seen the actual design tools.

I figured this out from watching Carmack's presentation of the "MegaGen" tool. I asked on the Quake Wars forum and it was confirmed. They actually said it was up to you to unwrap the mesh in your modeling application, so no, id has not invented a magical tool that will allow non-destructive re-mapping. If you make any geometry changes that change the way your modeler unwraps the mesh, you will lose all texturing info.

If you're prepared to accept the division of production into strict geometry and texturing phases, that's up to you. It looks like id is applying this approach to all level geometry now, not just terrain, so the same principles will apply; You have to make sure the entire scene geometry is final before you start texturing. To me, having a lot of experience with level design, this is an unacceptable restriction.

 

[Laa-Yosh]

Seems like you don't have much experience with 3D applications and haven't worked in a game dev studio either...

I really can't understand all the Carmack hate. It's total nonsense.

 

[Gabrobot]

If you're prepared to accept the division of production into strict geometry and texturing phases, that's up to you. It looks like id is applying this approach to all level geometry now, not just terrain, so the same principles will apply; You have to make sure the entire scene geometry is final before you start texturing. To me, having a lot of experience with level design, this is an unacceptable restriction.

"Accept"? Why would you do it any other way? The only reason you'd need to go back and modify a bunch of stuff is if you screwed up to begin with (and no matter what engine you were using it would present a big pain in the ass).

And I don't think you understand what they're doing...everything else is modeled and textured by the artists in their program of choice (clearly you've never seen ZBrush or Mudbox in action if you think this is at all a problem) but without any texture limits. In fact, even the terrain is originally textured like that (the base that they start with appears to be what they sculpted and then baked into a normal map). They then layer more details on after that. (Note that Quake Wars doesn't use this method, they start by procedurally generating the base layer)

I've done a fair amount of level design as well, and the fact is that nowadays everything takes a lot more work because of the amount of detail involved. As such it's really hard for single mappers...but for actual studios it's not, they have a ton of different people working on the same level anyway, so they can't be going back and changing things well into the development. What id is doing makes things easier for devs because once the gameplay stuff is done they can let the artists loose without any restraints. The "issue" you're bringing up doesn't really factor into the way things are structured.

 

[Jodi]

I would have thought that level design, like alot of other design work, would be iterative in nature. So its quite possible for someone to want to change the geometery even though its "final", because they are tweaking and improving the design.

Having the geometry done before the texturing seems to break that idea as I understand it, because the geometry and texture are coupled somewhat, that is, geometry and texturing are finished at the same time, not one after the other.

 

[Saem]

You don't need final textures (ones with the texture artist touching them up, you have procedural textures which are 90% save the touch ups) for level play testing, in fact, you would leave all that out until the level is finalised. I would imagine this would allow for much better prototyping as one could have textures much closer to what they're going to look like rather than solid colour place holders. That's helpful, as colour can effect preceived scale.

 

[JoshKlint]

I always view level design as the place where all the artists' work comes together in a flexible environment that is varying degrees away from the actual gameplay. I spent many hours tweaking things in UnrealEd and then playing the results in the engine. I find it more fun than the game itself.

So to me, it is very disappointing to see level design go from this flexible limitless system to a rigid mesh, where the entire scene is designed in 3ds max and then touched up in an intermediate program. I find the Crysis and Unreal 3 editors much more interesting than a workflow obviously designed by a core engine programmer. I usually like Carmack's stuff, but he is striking at the very heart of why I got into 3D graphics.

 

[Gabrobot]

Well I myself would rather trust that the two top companies in engine development (id Software and Epic) know what they're doing. They both start by roughing out the gameplay until it is final and then have the artists do their thing. As I said before when you have large teams working on a single level, you can't be bouncing the design back and forth between different people. By the time final touch-ups are done they won't be going back and changing the geometry...final touch-ups are (as one might guess) at the end of the development cycle for a level.

 

[Laa-Yosh]

Reworking polished content in a game has huge extra costs, so every sane studio will avoid it and push out the actual art-related work as far as possible. This whole discussion makes no sense at all...

 

[sonix666]

Well I myself would rather trust that the two top companies in engine development (id Software and Epic) know what they're doing. They both start by roughing out the gameplay until it is final and then have the artists do their thing. As I said before when you have large teams working on a single level, you can't be bouncing the design back and forth between different people. By the time final touch-ups are done they won't be going back and changing the geometry...final touch-ups are (as one might guess) at the end of the development cycle for a level.

And then the game gets release, played online alot and people will find bugs in the geometry as they always have. And then in a patch you tweak the geometry. That sounds like a big overhead. Neither software development and artistic processes are rigid processes. The art and software evolves over time. Any process that tries to break that will result in a disaster.

 

[KimB]

And then the game gets release, played online alot and people will find bugs in the geometry as they always have. And then in a patch you tweak the geometry. That sounds like a big overhead. Neither software development and artistic processes are rigid processes. The art and software evolves over time. Any process that tries to break that will result in a disaster.

I don't see why any change to the geometry would remove texturing information. For example, it should be trivially easy to deform geometry while maintaining texturing information. And, after all, aren't most geometry errors errors in placement, not in the number of triangles?

 

[Gabrobot]

And then the game gets release, played online alot and people will find bugs in the geometry as they always have. And then in a patch you tweak the geometry. That sounds like a big overhead. Neither software development and artistic processes are rigid processes. The art and software evolves over time. Any process that tries to break that will result in a disaster.

You are aware that the software minimize the texture coordinate problems for those sort of changes anyway? For minor tweaks it shouldn't be a problem. They shouldn't have to be adding caves though. (Although from what I've heard of ZBrush even that might not be a problem)

And as a side point: with the whole production organization, something like adding a cave would be a far bigger problem (design wise) then re-doing the final texture touch-ups. It's like worrying about a cars paint job after it's been totaled.

Really people don't know what they're talking about here...just about every dev already works like id is working...the technology was designed to fit that, not vice versa. I think too many people have some kind of romanticized view of Crytek's SandBox editor without fully understanding the trade-offs. There is no "magic tool" that allows devs to willy nilly screw around however they want.

 

[Warrick]

Some of you aren't getting what is quite a valid point...

"Reworking polished content in a game has huge extra costs, so every sane studio will avoid it and push out the actual art-related work as far as possible. This whole discussion makes no sense at all..."

Yeh it has huge extra costs but it happens and if it does it's a problem as you acknowledge. Thus it makes lots of sense to talk about and its not ideal way of working: choose the most productive way of working and _try_ and make the tools to suite not the other way around.

If the geometry topology is untouched and you just move vertices around you could have a tool to reproject the existing texture space mapping into a new texture space mapping that minimises the distortions. Otherwise you would have to start fiddling with your texture chart and packing arrangement which you require you to have some connection data between your modelling package and the painting tool which as far as I know Tech 5 doesn't have - ideally they would both be the same custom package anyway.

One approach to be able to do level changes that can be flexible from a game level construction point is that of polygonal level hull with a mega-texture style displacement map but thats not without some fun issues especially trying to get artists to work that way (believe me). It would let you shift and bend corridors around etc. It has limitations though.

Where you want to be *I think* is virtual sculpting and painting - megatexture has one bit right. This is what Carmacks wants to do with ID Tech 6 as he has mentioned. In concept it could be seen similar to zbrush in terms of usage but under the hood a different beast.

I think its likely he will try an octree volume and texture representation that is heavily compressed and polygonised as needed for rendering (Maybe some distance field representation). Lots of headaches within that simple sentence though I think that may be the future.

In some ways you could see it as taking crysis' voxel objects a few steps further merging it with megatexture and solving the resulting problems and allow FFD style modification tools on level segments (corridors, rooms, etc).

 

[Silent_Buddha]

Other than MMORPGs (which the ID engines aren't designed for anyway) I can't think of many released games where geometry is modified in any significant way after release. The Elder Scrolls series maybe (Morrowind, Oblivion, etc) with user mods.

And in production in most software houses, I'd imagine that geometry is pretty much set in stone before it goes to the art team for final texturing and touchups.

Might there be corner cases, where this might not be ideal? Maybe. But with any engine there are tradeoffs that you have to work with when producing art for it. So, I really fail to see the big deal.

Regards,
SB

 

[Warrick]

I wasn't talking about after release but from extensive experience with many a games production. Again I re-iterate the ideal current process is how you say but it will go wrong in practice - levels change, feature cuts/creeps, neccessary gameplay changes cause it etc.

You certainly plan to minimise it and so you could say if that happens you didn't plan well enough but then who's ever had a perfect plan hey ;-)

Game production is all about minimising stalls and bottlenecks more than ever these days and this is a common one.

But anyway you are missing the key point I was making about what the better way of working would be even if it isn't technically possibly currently....

Plus ID Tech 5 streaming texture tech would be pretty attractive for MMORPG I'd say... given enough DVD's

 

[Gabrobot]

Well, if you want to set up your terrain as a simple vertically displaced mesh then you can just do a vertically projected uv map. The uv map will stay the same and you won't have to worry about it screwing up your work. Basically you'd have the same thing other engines have...the only problem comes in when you want to go further and have more detailed terrain meshes that go beyond vertical displacement. So id Tech 5 doesn't create any problems where none existed before...any engine that has terrain that goes beyond vertical displacement will have the same problem (because they have to use models that need to be uv mapped).

The second thing you can do is just use procedurally generated texturing (ala Quake Wars' first texturing stage)...this would make uv map changes irrelevant, but you wouldn't be able to make manual changes.

Now the only issue comes in when you want to do more detailed work than can be done in any other engine...so the point seems kind of silly. There's nothing wrong with the engine, it just takes more planning to get more detailed work. This is kind of a no brainer, this is where the industry has been heading since it began.

Edit: And lets not forget that the worst case scenario in the case of a painted terrain mesh needing a major modification is simply repainting it. They've already demonstrated how easy and fast the process is, so it's not like it's even any kind of disaster to have to do that. I would guess it would be the easiest part of the process of making those kind of late development changes.

 

[Laa-Yosh]

I still can't understand the problem here. It's a giant step forward in realtime 3D technology, allowing for some unprecedented visuals. Of course it takes more work, it's usually the only way to get better assets. So should we drop this technology and the superior results just because of this? Well, why not go back to Quake1 software rendered graphics then, it takes a lot less time to build levels, especially with the faster machines and better tools we have today... Or rather, give me Pac man, that sure won't take too much extra work; and f*** MegaTexture.

 

[Ilfirin]

Neat stuff..

 

[Laa-Yosh]

Gamedev.net has a long discussion on the virtual texturing implementation with links to interesting papers and theories on Carmack's approach that could very well be spot on...

http://www.gamedev.net/community/forums/topic.asp?topic_id=460053

 

[Warrick]

First thoughts on that: The paper referenced (In the same place there is a cool one on tiled texture trees - I like those guys) and some of the discussion would seem to me very close to how it is probably implemented as well.

The only bits I'm not 100% sold on are how the mip levels are determined and how filtering issues are dealt with. The system he uses to cull backfacing texture tiles must be interesting as well.

Although its nice to think of using the hardware to calculate the miplevels and reading back the results I can't but think he is doing a simpler estimate on the CPU side (A few possible hints of that being given in that thread).

On the filtering issue I think he probably just pads uploaded tile borders so the hardware can do it as doing it manually in the shader seems more complicated then he has described it being - but then I do seem to remember him mentioning somewhere about having to do something in the shader to deal with those cases. With 128x128 tile sizes and the hierarchal nature of the virtual mipmap chain though I wonder how often these border cases do actually happen in the scheme of things. Maybe he does a mixture of border padding and manual shader filtering?

Does really make you want ubiquitous native hardware tiled texture support now for this and other things.