This entire post is like one, big ball of misconceptions.

You can't get a better quality image in less RAM space. The hardware needs those images in a very basic (essentially .bmp) format, in RAM, in order to draw them to the screen. If you want better quality, then you need to be using more RAM.

Next, you don't seem to understand what "procedural" means. Literally, from a procedure. So, you have an algorithm that, given certain inputs, outputs a texture. However, you can't reasonably go the other way: you can't have a texture and then figure out an algorithm for it, because it wasn't generated from an algorithm in the first place. Hell, even if it was, it's essentially a one-way operation, and would require an absurd amount of work to go the other way.

What you did get right, however, is that using procedural content will be smaller and load faster... on/from the disk. You're not going to get better performance out of procedural content, because content is content, however it was developed.

Short answer: No, nobody does, and nobody ever will, because such a thing does not exist. If you want to develop procedural textures, then you're going to need to start with some upper-division mathematics. Try looking up fractals.

VorpalKnight wrote:

http://digg.com/software/ Game_file_sizes_could_soon_be_70_smaller
http://www.spot3d.com/vray/help/150SP1/displMod_params.htm
http://www.creative-3d.net/ productFeatureDisplay.cfm?content=simbiontmax
http://www.google.com/ search?hl=en&q=does+procedural+textures+require+less+ram%3F& btnG=Google+Search

^ Requires less ram. ^_^

Take another look at those links. The first three talk about things you can do to save yourself development time and file size, not RAM. The fourth link is a Google search, and the third item down says: "Procedural textures USE THE SAME AMOUNT OF RAM AS NORMAL TEXTURES" [emphasis in original].

Procedural textures are easy to describe as an algorithm, hence they save disk space by not having to store every pixel. But for a game engine to use them it has to either calculate each pixel on the fly (very inefficient) or use a pre-calculated bitmap that it can store in the graphics hardware's texture RAM. Most games opt for the latter, so when loaded the texture is converted into a bitmap at the desired resolution. Thus, procedural textures don't save RAM, but only file space and (to an extent) load times. They also have the advantage that, like vector art, you can upscale them as high as your memory will allow. Practically speaking this means a modern high-def game really doesn't need to be on Blu-Ray to get tremendous levels of detail; a garden-variety DVD will do if the textures are procedural.

(If you have adequate RAM you can also gradually calculate the bitmap in the background by going with progressively higher resolutions, changing textures as better ones get loaded. E.g. you might load a procedural texture at 128x128 and then start calculating a 256x256 version. Then you'd switch all the old textures to the new one and free up the old. This saves some load time as well.)

Displacement mapping is siilar, since to use it you have to have an algorithm that modifies a simple 3D surface and makes it a more complex 3D surface by adding more vertices and triangles. The point is to save you modeling time, by automatically creating a more detailed model out of a more simplistic one. But once you go to use the object, you need all those vertices and triangles. Whether you made them or a program generated the lion's share of it, it'll use just as much memory and processing power to display.

What I mean by "quality I'm driving at" is using procedural texturing to lower the amount of ram I'm using. When I lower the amount of ram I'm using, I then have extra ram to spare for other things, like atmospheric effects, animated-textures, particles, etc.

The only way to lower the amount of RAM used in a 3D game is to display fewer objects at a time and reuse textures as much as possible.

Lummox JR

VorpalKnight wrote:

Thanks for clearing that up.

I've finally gave up on finding software to reverse-engineer
textures, and may just have to settle with my own code -_-...I'm not an mathamticians and API calls are a pain...

Yeah, reverse-engineering textures would basically be a tricky proposition that would only work for certain textures, and only for cases where you already knew they could be fit to a given algorithm. If you knew that much though you could just as easily re-create them from scratch.

Lummox JR

Compression doesn't lessen the need for video RAM - it just saves disk space.

The basic idea would to scan each pixel in a row and classify them based on color (ignoring minor variations) until the program hit a pixel that was of another color (significantly different). It would continue scanning each row and each column till it had a index of significantly different pixels compared to the images average. Then it's just a matter of creating maps of pixels that are near to each other and similar enough in color to constitute a group. This group is then separated from the main image and stored as a pixel-map.

Next, the program would finish finding other pixel-groups. Once all pixel-groups are converted into pixel-maps the program would begin the process of reverse engineering each individual map.

Essentially it contains a database of algorithms that produce various types of fractals. The program takes a pixel-map and compares the shape contained in it with base-sample outputs from each algorithm in it's database. It then compiles a list of algorithms based on the similarity of the algorithms base-sample output to the actual pixel-map currently being analyzed.

The top three algorithms that *most* meet the criteria are kept and all the rest are removed from the list. Next the
program applies each algorithm, compares the output to the
pixel-map, and if the output does not match the pixel-map
to a high accuracy (95%+) then it is adjusted iteratively and the process is restarted. If after a user-specified amount of cycles the algorithm does not meet the accuracy-criteria it's results are indexed and the next algorithm is applied.

The results from all algorithms applied are then compared, and the algorithm and the accompanying parameters that meet the criteria of accuracy *most* are kept.

This process is applied to every pixel-map. In this manner complex textures can be broken down into a layers of procedural textures.

It's a conceptual model but I'm certain it will work :P

As far as textures that don't lend themselves to analysis, thats one of the main problems. Determining the orientation of a fractal is just a matter of applying the fractal in different orientations (from the database) in comparison to the pixel-map. Granted this would significantly increase processing time, but it's not like your average Pentium is going to be reverse-engineering textures.

I was thinking of having a control-panel, where bye the user can adjust how "Sensitive" the engine is to different colors and shades. Basically the parameters would determine where each pixel-group terminates.

Of coarse theres still issues with certain things. For example, suppose we have the image of a triangle. Normally this wouldn't provide much of a challenge as far as reverse-engineering goes, but what if the lines composing the
triangle are multi-colored?

The engine *may* be able to correctly identify the shape so long as the background color was not the same as one of the colors contained within any of the three edges of the triangle.

It's a work in progress I guess :P