Comments 26 to 43 of 43

Quote <A88> 9th November 2006, 20:10
Great stuff! Now someone just needs to find a way of passing on applying this level of efficiency to hardware.

<A88>
Quote Emon 9th November 2006, 20:39
In addition to making textures smaller on disk, procedural generation also has the advantage of not requiring talented texture artists to make high resolution textures. Texture art is becoming more and more of a challenge. These days you have artists making maps at a base resolution of 4096x4096. They make the normal diffuse map, a bump or normal map, a specularity map, and all sorts of other crap. Procedural generation can greatly simplify this.

It doesn't mean texture artists will be obsolete, though, since you still need people to come up with the designs. But the work isn't going to be nearly as hard. It'll make it a lot easier for smaller developers or modders who can't find or hire good, dedicated texture artists. If you have ever worked on anything bigger than a small scale mod for a game in the past four years, you know what I mean.

Also, procedural generation can scale better with texture resolution. The algorithm that generates you a 512x512 texture could generate a 4096x4096 without losing detail.
Quote Mighty Yoshimi 9th November 2006, 21:03
I'm interested, how can it create larger textures from 512*512 thats amazing !
Quote Reaper_Unreal 9th November 2006, 21:06
Having played around with 4k and 64k demos myself, I've gotta say that I find having this technology on mainstream games is going to be a massive boon for the average user and digital distribution. The only thing about this is that levels will take even longer to load now as textures will have to be generated beforehand (on the fly generation is quite processor-intensive). So in reality I don't know if this will be that great, but for now I love it.
Quote DXR_13KE 9th November 2006, 23:07
the future.... today :D me likes.
Quote Emon 9th November 2006, 23:18
Quote:
Originally Posted by Mighty Yoshimi
I'm interested, how can it create larger textures from 512*512 thats amazing !
It doesn't create them from 512x512 textures, it generates them at any given resolution.

I'd also like to point out that procedural texture generation is probably 20 years old. It's just the idea of using it effectively in modern games that is new. Getting procedural textures that don't look fake and repetitive can be quite a challenge.
Quote eddtox 9th November 2006, 23:19
This looks absolutely amazing. The images produced are worthy of Crysis. I think the main points being made against it are a little pedantic, though. Firstly, while processor speed is a factor, we have brand-spanking new quad core processors coming out. In this context ~2cores could be used to render the textures on-the fly, making loading times more bearable. Secondly, just because we have massive 500GB+ HDDs, it doesn't mean that we should waste the space. IMHO, anyone who thinks that 5GB->1GB is not a worthwhile difference is living on a different planet. In today's context of efficiency, anything which improves the way we use the existing resources is a welcome addition. IMO, it's not rocket science: if you could fit the same games on a 80GB HDD as on a 400GB HDD, which would you go for? Surely I'm not the one with old hard-drives lying around!

-ed out
Quote Mighty Yoshimi 9th November 2006, 23:36
Couldn't we use physics engines to helpt the processor out?
Quote Emon 9th November 2006, 23:37
Quote:
Originally Posted by Mighty Yoshimi
Couldn't we use physics engines to helpt the processor out?
:? :?

Texture generation is easily parallelized. It could be split between CPU cores and some offloaded to the GPU. You'd be generating them directly in memory. With any luck on multi-core systems and some fast algorithms, it'll be faster than loading from disk.
Quote Kevin_G 10th November 2006, 00:03
This is just like the whole vector vs. bitmap debate for 2D graphic file formats. Procedural textures are likely just specialize pixel shader programs with several input variables. To change the textures, you just change the input variables for the shader program. From the look of the demo video, it also had procedural bump maps as well.

The downside to procedural textures is the processing requirement on the video card side. There are like a few cheats, like caching the finished texture in RAM. A texture is rendered once so that it doesn't have to be processed again for sequential frames that the textures appears in. The Roboblitz game seems do this for all the textures when the game is loaded, and not on the fly during the game.

The X-Box 360 has several CPU and GPU functions for accelerating procedural operations. The SpeedTree middleware used in Elder Scrolls IV: Oblivion is an example of that aspect of the X-Box 360's functionality. The PS3 has Cell and its vector units which could easily perform such functions as well as a nVidia GPU that can do much of this work.

The end result of games down the road will likely be moderate use of procedural textures with compressed high resolution textures. Procedural texture use will be limited to those that can be performed quickly with caching and those that won't significantly increase load times. Things like realistic floor/ceiling/wall textures and human skin fit well into these catagories. The complex textures and those that don't fit well into a procedural programs will continue to be bitmaps. Things like posters on walls, bill board signs ect. in games are examples that will continue to use bit maps. Even the developers of this technology have stated that not all textures are going to be procedural. Developer time is also a factor in how often procedural textures are used - if the gain is less than investment in time for developers, the technology will find itself in a niche.
Quote apw100 10th November 2006, 07:06
First of all, check THIS game out. It is by the person interviewed in the article. EVERYTHING is procedural, not just the textures. Because of this, the whole thing is only 96k!
The "game" is over two years old, and is more of a proof of concept rather than a true game. It uses an old method of procedural texturing that is much less efficient(and slower) than the one proposed in the article.
Really, it is an amazing technical accomplishment, and will give you an idea of the potential for procedural methods.
Quote eddtox 10th November 2006, 08:08
I've just played kkrieger. I'll start with the bad points: 1. Gameplay was rather poor. 2. There didn't seem to be any anti-aliasing. 3.On my geriatric Athlon XP 2600+/512 DDR/GeForce FX 5200 it was barely playable. In fact, I get higher framerates in NFS Most Wanted. However, that being said, all I can think is WOW!!!! 96k!?!?!?!?! The textures looked absolutely amazing! As a game, this is dire, but as a tech demo, it leaves me speechless. Every other game I have seen with textures this good took up over 1GB. :thumbs:

-ed out
Quote Phil Rhodes 10th November 2006, 11:48
I think this is a step in the right direction; however, I'd much rather see the GPUs be able to render these on the fly. That way, a few more advantages could be realised which might actually make things look better or run faster:

- Textures covering a wide area wouldn't need to tile and thereby repeat. This especially applies to dirt overlays and suchlike.

- The granularity of the texture can be tailored to the relative size of the region of interest - that is, close-up views can be rendered with more detail as required, rather than the somewhat kludged "close-up texture" idea that's being used right now.

- It would use vastly less texture memory.

So this is great, but as others have said, it's not really going to make things look enormously better, although it could be the beginning of something that would.

Also, as has been explained, the FFT variety of this sort of thing is ancient news - I was doing procedural textures on the Amiga back in the days of Imagine. I was rather wondering how long this would take.

Phil
Quote CodE-E 10th November 2006, 23:35
I think this is mainly just a lot of hype...


1) Procedural textures look crap compared to what an artist can make with a digital camera (for realistic-looking textures) or a paintbrush / digital palette (for more artistic, creative stuff) and Photoshop + plugins. Maybe one can write a procedural texture which can be rendered to infinitely-high resolutions, but that isn't feasible in real-time graphics engines or even necessary with finite-resolution displays.

There's a big difference between art created by a human and images generated by a computer. Computer-generated stuff is too copy-pastey, too bland, too repetitive. Sure, one can add lots of extra variables to make the textures more random, but at the end of the day, you still need human artists to create unique, high quality content (with the help of image processing software like Photoshop, of course, but that's not procedural texture stuff) for different parts of a computer games.

Just to be clear, I'm talking about state of the art games here, not stuff like RoboBlitz, Pac Man, or Tetris. For visually simple games, going purely computer-generated can work (as RoboBlitz demonstrated). But for triple-A games, it isn't. There's no way you can just write a few lines of code and have a computer spit out all the textures for a game like World of Warcraft, Half-Life 2, or Grand Theft Auto!


2) High-quality content in state of the art computer games are made by professional artists, not coders. Creating procedural textures requires coding skills and maths skill, or? Well, traditional textures in computer games are painted (sometimes purely digitally). Sometimes photographs are taken used and then modified in and processed by Photoshop to make them tessellate seamlessly and such. Either way, artists would seriously be handicapped if they had to create textures by only writing code.

Could you teach artists to create textures by writing code for procedurally generated textures? Maybe, but it would take years for them to learn, and working with and modifying their work through code (instead of something like Photoshop) would be a nightmare, and at the end of the day it just wouldn't be a faster process.

The only real benefit of procedurally generated textures is their low file size, but because they're made by writing code rather than painting stuff by hand, one cannot just convert an arbitrary image into procedurally generated texture code. Well, actually, one can compress an arbitrary image quite a lot (Jpeg, Png, Gif, I'm sure you all know about that), but that's not as small as code for a simple PG texture.


3) Load times. True procedural textures take long to generate, especially if they're complex. Computing them at run-time is out of the question for triple-A games as it would just take too long, and if one would pre-compute them, the benefit of saving storage space would be lost.


(By the way, these arguments apply to 3D models, game levels, sound, music, etc, too. For professionals, using 3D Studio Max, Maya, XSI, Photoshop, UnrealEditor, Valve Hammer Editor, SoundForge (sorry, I don't really know what the industry standard sound/music applications are :p), etc to do make their stuff is way more productive than trying to hack something together by writing code.)


Besides generating pseudo-random levels (like in Diablo) and generating some random bits of environments prior to compilation (like with the forests in Oblivion), I really don't see any more uses of procedurally-generated content in state of the art computer games, at least in the near future.
Quote Jerc 11th November 2006, 09:17
Ok, so you replied without even visiting their website.
It's not coding, you create your textures like you would create a shader under maya or UE3 engine ( http://profxengine.com/index.php?PAGE=PIPELINE.ART ). The textures are created by artists, not coders.

Sure we'll always need classic texture artists, for characters or other complex meshes, but a lot of textures can be created procedurally, with a high quality standard.

And lastly, as it has been stated before, compputing the textures often takes less time than reading them from the hard drive.
Quote brandium 11th November 2006, 09:27
yeah, this looks like its just a bunch of hype to me too. It seems pretty obvious that this is just taking a bunch of stock materials, and composting them together using information about the model geometry, and maybe some physics for the broken tile and stuff. I can see something like this being great for applying a bunch of tiling materials to the geometry for a level to give everything the same look and feel, but it really doesn't seem like it's creating the base color maps from scratch. You can easily see in that bathroom video that theres just two different textures on everything, and it gradually fades from one to the other. Maybe if they had a little more information on what happens after you do the UV unwrapping it would be more convincing. The biggest thing about those renders that makes them look real is the lighting.
Quote Jerc 11th November 2006, 10:11
It's so hard to browse through 2 pages to find the documentation with all details...

If you search a little further you may also find some video tutorials
Quote DXR_13KE 12th November 2006, 12:18
ok.... if i can reduce the size of a game, even if it is by 30% this is great, it is not hype, it has been tested and if you consider that textures that take 1000KB can be reduced to 200KB or less that is great, even if it is for those less seen textures, this is great news for guys like me that want to download games..... they simply are downloaded faster and take less space on your hard drive.
Log in

You are not logged in, please login with your forum account below. If you don't already have an account please register to start contributing.







Mobile Phones

LG Arena ReviewHTC Magic Review

Compare over 250 mobile phones &
52,000 deals!



Broadband

Mobile Broadband

Compare over 100 broadband & mobile broadband deals online!

Dragonage