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

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.

 

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.

 

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.

 

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.

 

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.

 

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...

 

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?

 

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).

 

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

 

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

 

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.

 

Neat stuff..

 

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

 

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.