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

[neliz]

Further, I'm not even sure everyone agrees that id created the first 3D killer app.

Wolfensteind wasn't 3d, at the same time the much more impressive ultima underworld was launched and showed the real capabilities of the 80386 processor!

no seriously.. Wolf3D is childsplay compared to some stuff that came out in those years.. Heck even Doom isn't 3d...

 

[Mate Kovacs]

Carmack didn't invent 3d graphics, many ideas are several decades old

Yep. Maze War

 

[Reverend]

BTW, and just for the fun of asking , does MegaTexture qualify as "3D Technology"?

 

[emacs]

after reading the preceeding posts, this geometry clipmap / MegaTexture stuff sounds rather interesting. i figured i'll have abit of time in the spring to actually start implementing the concept from scratch and learn from there. that said, however, does anyone know if there's an open source or public domain implementation of geometry clipmaps? if there isn't an implementation out there, i might as well share mine when i finish it. thanks.

 

[Simon F]

after reading the preceeding posts, this geometry clipmap / MegaTexture stuff sounds rather interesting. i figured i'll have abit of time in the spring to actually start implementing the concept from scratch and learn from there. that said, however, does anyone know if there's an open source or public domain implementation of geometry clipmaps? if there isn't an implementation out there, i might as well share mine when i finish it. thanks.

FWIW, there is lots of speculation on the GD "algorithms" mailing list, which is frequented by games developers (and IHVs ), about what Carmack may or may not be doing. FYI, the archive can be found here.

 

[emacs]

FWIW, there is lots of speculation on the GD "algorithms" mailing list, which is frequented by games developers (and IHVs ), about what Carmack may or may not be doing. FYI, the archive can be found here.

thanks for the info. take care.

 

[Saem]

From what I can recall seeing in an earlier ET:QW video, Splash showed a content creation (mapping) tool. They basically had the geometery, set a few parameters and the entire terrain was textured. Then they went in and touched it up.

As for saying an artist doesn't have time to texture a mile long brick wall, only true if it's done purely by hand, but false in the context of iD/megatexturing. The idea is that the brick wall's texture would be procedurally generated, and then an artist would touch up whatever they cared to. Especially, as of Doom 3, Carmack has repeatedly commented on reducing the burden on artist, hence creating a lighting system as he did. This is merely another piece of that puzzle. Now procedural textures for terrain and soon all objects can be employed and where necessary artist can add the human touch.

Sorry for coming late to the party, but it was sad to see all the posts, "it's too costly to uniquely texture everything", as stated previously the intention is NOT to do so by hand.

 

[JoshKlint]

The problem is not an issue of uniquely texturing everything. What no one seems to realize is this forces the workflow to go:

geometry -> unwrap uv coords -> texturing -> game

You can't texture your geometry and then decide you want to change anything other than moving a few vertices around, or you will lose all texturing info when the mesh gets unwrapped again.

I see this as something that programmers won't think is a big deal, but once the artists start working with it, they will stop singing the praises of "megatextures" really quick.

How many times does a game level get playtested before it is final? A map designer will tweak a level hundreds of times to get it right. This includes texturing, geometry, object placement, lighting, and other things. With this system, once the artist starts texturing, the geometry is pretty much locked in place and finalized. This reduces flexibility and the ability of artists to test their work, and thus increases time and budget requirements. I think it's a bad idea.

 

[_xxx_]

Yes. Carmack didn't invent 3d graphics, many ideas are several decades old --> if not Carmack then someone else would have created the 3D killer app.

Further, I'm not even sure everyone agrees that id created the first 3D killer app.

AFAIK Descent was a bit older than Wolf/Doom?

 

[Simon F]

AFAIK Descent was a bit older than Wolf/Doom?

I don't know about older but it was certainly better and true 3D!

I just looked at my Underworld II box and it has a date of 1992, so that is earlier.

 

[Richard]

AFAIK Descent was a bit older than Wolf/Doom?

Wikipedia says 1995 which sounds about right. I remember it was after DOOM and before QUAKE.

I just looked at my Underworld II box and it has a date of 1992, so that is earlier.

Both id Software's Hovertank 3-D and Catacombs 3-D predate Ultima Underworld by roughly a year.

 

[DeanoC]

Wikipedia says 1995 which sounds about right. I remember it was after DOOM and before QUAKE.

Descent is much later than Wolf, IIRC it pioneered the perspective correction trick that would also be used in Quake... Alot more 'proper' 3D than the renderers used in Wolf or Doom for example.


Deano

 

[_xxx_]

Well Descent had 3D models instead of sprites, if I recall that correctly. So it was a "real" 3D game.

 

[Arwin]

Well Descent had 3D models instead of sprites, if I recall that correctly. So it was a "real" 3D game.

I bought this game back then. It supported bump-mapping patch my Matrox G400 (or whatever it was called), and I think it was one of the first games to support this at the time.

 

[Simon F]

Well Descent had 3D models instead of sprites, if I recall that correctly. So it was a "real" 3D game.

The mine models also allowed for bizarre interconnects so that you could, technically, have more than one room/chamber in overlapping the same x,y,z space and they wouldn't interfere!

The lighting was also somewhat dynamic in that you could fire flares to light up portions of the mine - the lighting would change as the flare progressed.

Hmm... we seem to have drifted away from the original "unique texturing on everything" subject.

 

[DeanoC]

How many times does a game level get playtested before it is final? A map designer will tweak a level hundreds of times to get it right. This includes texturing, geometry, object placement, lighting, and other things. With this system, once the artist starts texturing, the geometry is pretty much locked in place and finalized. This reduces flexibility and the ability of artists to test their work, and thus increases time and budget requirements. I think it's a bad idea.

Why? Transferring textures between changed geometry or UV sets is a fairly trivial (if a bit slow) operation used a good old fashioned raytracer.

You move something, it stretches and distorts real-time, you then press a button and then the new geometry is re-atlased and texels raytraced off the original version.

There are properly faster/better ways but considering I could do that with the tool set I play around at home, I really doubt it would be a problem for a pro dev environment.

 

[Saem]

If the geometry is altered, and the procedural component of the texture is simply recalculated. The artist touch ups would be the tricky part. Touch ups such as placeable, say a stain on the floor, could just be reapplied to the translated position.

Furthermore, since one knows what's procedural and what's artist generated, one could go a step further and provide a listing of all the items that need review, and further refine that by way of an ignore list -- stuff you know that doesn't need review.

This also completely ignores a drafting process: as geometry is being built you use procedural content with minimal, hopefully no, hand tuning and then layout the level until you're happy. Afterwards, touch up to your hearts content.

 

[JoshKlint]

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.

 

[tabs]

Why would all the hand drawn touch ups be lost?

I'm sure the texture could be remapped to accomodate new geometry, leaving everything but the new geometry in place.

 

[KimB]

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.

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.