DVD9 limits PGR4 (HUGE DISAPPOINTMENT)

Since 6830 Days

Posted by n3ro

This is Microsofts fault. WHYYYY DON'T THEY CHANGE TO HDDVD IN THE 360 ?!?!??!??!!?!?

Instead of selling a external HDDVD they could have it intergrated and keep the price. I don't give a sh*t about pricedrops. It's the gaming that's important. That's why PS3 is going to defeat XBOX 360 next year and the year after until another next-gen consoles gets released. Then probably discs will have 300 GB space but Microsoft will stick with intergrated HDDVD. Idiots !! =/

Once the ship left the harbor w/o a large format optical drive, it was pretty much impossible. Switching to HD-DVD for games now would be an even more monumental mistake imo.

This is a good point, but not necessarily a drawback. There are several pathways to procedural generation. Since procedural textures are easily paralleled, they can be divided between Xenos or the three Xenon Cores or both.

Granted, there may be the processing power to handle procedural generation, but given the option I'd rather that horsepower be used in other areas, even if it doesn't seem very significant. The same goes for compression -- it only gets you so far. If the space is available, then I'd rather do without. The biggest advantage procedural algorithms represent (imo) is the ability to generate content that offloads some of the work that otherwise would have to be handled by artists.. not the amount of disc space it saves.

In reply to

[quote=n3ro]This is Microsofts fault. WHYYYY DON'T THEY CHANGE TO HDDVD IN THE 360 ?!?!??!??!!?!?

Instead of selling a external HDDVD they could have it intergrated and keep the price. I don't give a sh*t about pricedrops. It's the gaming that's important. That's why PS3 is going to defeat XBOX 360 next year and the year after until another next-gen consoles gets released. Then probably discs will have 300 GB space but Microsoft will stick with intergrated HDDVD. Idiots !!  =/[/quote]

Once the ship left the harbor w/o a large format optical drive, it was pretty much impossible.  Switching to HD-DVD for games now would be an even more monumental mistake imo.

[quote]This is a good point, but not necessarily a drawback. There are several pathways to procedural generation. Since procedural textures are easily paralleled, they can be divided between Xenos or the three Xenon Cores or both.[/quote]

Granted, there may be the processing power to handle procedural generation, but given the option I'd rather that horsepower be used in other areas, even if it doesn't seem very significant.  The same goes for compression -- it only gets you so far.  If the space is available, then I'd rather do without.  The biggest advantage procedural algorithms represent (imo) is the ability to generate content that offloads some of the work that otherwise would have to be handled by artists.. not the amount of disc space it saves.

INDIGO

Since 7532 Days

It still takes artists to make procedural textures. Procedural does not necessarily mean they are generated automatically. Think of them more as layered textures.

In reply to

GriftGFX

Since 6830 Days

Posted by INDIGO

It still takes artists to make procedural textures. Procedural does not necessarily mean they are generated automatically. Think of them more as layered textures.

No it means they're generated based on a mathematical algorithm, which offsets the amount of actual art involved in creating them. Using procedural textures definitely lightens the load on the artists more than anything.. not to say that it doesn't save disc space as well, but I don't honestly believe that is its greatest benefit personally.. especially when you consider that you're eating SOME CPU cycles regardless of how efficient your model is.

An example of a procedural texture:

/* Copyrighted Pixar 1988 */
/* From the RenderMan Companion p.355 */
/* Listing 16.19 Blue marble surface shader*/

/*
* blue_marble(): a marble stone texture in shades of blue
* surface
*/

blue_marble(
float Ks = .4,
Kd = .6,
Ka = .1,
roughness = .1,
txtscale = 1;
color specularcolor = 1)
{
point PP; /* scaled point in shader space */
float csp; /* color spline parameter */
point Nf; /* forward-facing normal */
point V; /* for specular() */
float pixelsize, twice, scale, weight, turbulence;

/* Obtain a forward-facing normal for lighting calculations. */
Nf = faceforward( normalize(N), I);
V = normalize(-I);

/*
* Compute "turbulence" a la [PERLIN85]. Turbulence is a sum of
* "noise" components with a "fractal" 1/f power spectrum. It gives the
* visual impression of turbulent fluid flow (for example, as in the
* formation of blue_marble from molten color splines!). Use the
* surface element area in texture space to control the number of
* noise components so that the frequency content is appropriate
* to the scale. This prevents aliasing of the texture.
*/
PP = transform("shader", P) * txtscale;
pixelsize = sqrt(area(PP));
twice = 2 * pixelsize;
turbulence = 0;
for (scale = 1; scale > twice; scale /= 2)
turbulence += scale * noise(PP/scale);

/* Gradual fade out of highest-frequency component near limit */
if (scale > pixelsize) {
weight = (scale / pixelsize) - 1;
weight = clamp(weight, 0, 1);
turbulence += weight * scale * noise(PP/scale);
}

/*
* Magnify the upper part of the turbulence range 0.75:1
* to fill the range 0:1 and use it as the parameter of
* a color spline through various shades of blue.
*/
csp = clamp(4 * turbulence - 3, 0, 1);
Ci = color spline(csp,
color (0.25, 0.25, 0.35), /* pale blue */
color (0.25, 0.25, 0.35), /* pale blue */
color (0.20, 0.20, 0.30), /* medium blue */
color (0.20, 0.20, 0.30), /* medium blue */
color (0.20, 0.20, 0.30), /* medium blue */
color (0.25, 0.25, 0.35), /* pale blue */
color (0.25, 0.25, 0.35), /* pale blue */
color (0.15, 0.15, 0.26), /* medium dark blue */
color (0.15, 0.15, 0.26), /* medium dark blue */
color (0.10, 0.10, 0.20), /* dark blue */
color (0.10, 0.10, 0.20), /* dark blue */
color (0.25, 0.25, 0.35), /* pale blue */
color (0.10, 0.10, 0.20) /* dark blue */
);

/* Multiply this color by the diffusely reflected light. */
Ci *= Ka*ambient() + Kd*diffuse(Nf);

/* Adjust for opacity. */
Oi = Os;
Ci = Ci * Oi;

/* Add in specular highlights. */
Ci += specularcolor * Ks * specular(Nf,V,roughness);
}

Artsy, huh?

In reply to

[quote=INDIGO]It still takes artists to make procedural textures.  Procedural does not necessarily mean they are generated automatically.  Think of them more as layered textures.[/quote]

No it means they're generated based on a mathematical algorithm, which offsets the amount of actual art involved in creating them.  Using procedural textures definitely lightens the load on the artists more than anything.. not to say that it doesn't save disc space as well, but I don't honestly believe that is its greatest benefit personally.. especially when you consider that you're eating SOME CPU cycles regardless of how efficient your model is.

An example of a procedural texture:

[quote]/* Copyrighted Pixar 1988 */
/* From the RenderMan Companion p.355 */
/* Listing 16.19  Blue marble surface shader*/

/*
 * blue_marble(): a marble stone texture in shades of blue
 * surface
 */

blue_marble(
         float   Ks    = .4, 
                 Kd    = .6, 
                 Ka    = .1,
                 roughness = .1,
                 txtscale = 1;
         color   specularcolor = 1)
{
   point PP;            /* scaled point in shader space */
   float csp;           /* color spline parameter */
   point Nf;            /* forward-facing normal */
   point V;             /* for specular() */
   float pixelsize, twice, scale, weight, turbulence;

/* Obtain a forward-facing normal for lighting calculations. */
   Nf = faceforward( normalize(N), I);
   V = normalize(-I);

/*
    * Compute "turbulence" a la [PERLIN85]. Turbulence is a sum of 
    * "noise" components with a "fractal" 1/f power spectrum. It gives the
    * visual impression of turbulent fluid flow (for example, as in the 
    * formation of blue_marble from molten color splines!). Use the 
    * surface element area in texture space to control the number of 
    * noise components so that the frequency content is appropriate 
    * to the scale. This prevents aliasing of the texture.
    */
   PP = transform("shader", P) * txtscale;
   pixelsize = sqrt(area(PP));
   twice = 2 * pixelsize;
   turbulence = 0;
   for (scale = 1; scale > twice; scale /= 2) 
       turbulence += scale * noise(PP/scale);

/* Gradual fade out of highest-frequency component near limit */
   if (scale > pixelsize) {
       weight = (scale / pixelsize) - 1;
       weight = clamp(weight, 0, 1);
       turbulence += weight * scale * noise(PP/scale);
   }

/*
    * Magnify the upper part of the turbulence range 0.75:1
    * to fill the range 0:1 and use it as the parameter of
    * a color spline through various shades of blue.
    */
   csp = clamp(4 * turbulence - 3, 0, 1);
   Ci = color spline(csp,
   color (0.25, 0.25, 0.35),      /* pale blue        */
       color (0.25, 0.25, 0.35),  /* pale blue        */
       color (0.20, 0.20, 0.30),  /* medium blue      */
       color (0.20, 0.20, 0.30),  /* medium blue      */
       color (0.20, 0.20, 0.30),  /* medium blue      */
       color (0.25, 0.25, 0.35),  /* pale blue        */
       color (0.25, 0.25, 0.35),  /* pale blue        */
       color (0.15, 0.15, 0.26),  /* medium dark blue */
       color (0.15, 0.15, 0.26),  /* medium dark blue */
       color (0.10, 0.10, 0.20),  /* dark blue        */
       color (0.10, 0.10, 0.20),  /* dark blue        */
       color (0.25, 0.25, 0.35),  /* pale blue        */
       color (0.10, 0.10, 0.20)   /* dark blue        */
       );

/* Multiply this color by the diffusely reflected light. */
   Ci *= Ka*ambient() + Kd*diffuse(Nf);

/* Adjust for opacity. */
   Oi = Os;
   Ci = Ci * Oi;

/* Add in specular highlights. */
   Ci += specularcolor * Ks * specular(Nf,V,roughness);
}[/quote]

Artsy, huh?

Acert93

Since 6801 Days

But Grift, compression is absolutely necessary for consoles. Even if a game is only 2GB big, all the data is compressed on the DVD. Assuming even minor compression, 2x, that allows disk data to be streamed 2x as quickly to the system memory -- and CPU decompression speeds are insignificant in comparison to the time it takes to stream data. As a developer I know stated: All good developers use compression.

As for procedural textures, I think quality is the biggest issue. But if you could get quality textures from procedural methods, there is no reason not to create them while loading or caching data. Imagine this scenario:

You are starting a new level in PGR5. You have 100MB of audio, 100MB of geometry, and 200MB of textures to cache before the user can begin racing. Lets assume magically 50% (100MB) of those textures could be procedurally created on the GPU.

So lets say it takes 40 seconds to stream 400MB to system memory, so what if you could write 300MB in 30 seconds and at the same time create 100MB of the textures procedurally?

They are stored in memory like any other texture, but instead of coming from the disk they were created in memory by a procedural generation application.

We aren't quite there yet... but we are getting closer. Much closer. So much so I think the next wave of consoles will rely on such techniques in a significant manner because of the benefits in modification, reduced artist load, reduced memory transfer (imagine 4GB of system memory and a BDR transfering to it... no, just no!) and such.

We will see though, although the field is very interesting and fast moving. MS talked it up a lot at GDC 2005 and as time goes on it will become more popular in content creation -- because applications are cheap, artists are not -- for things like cities, forests, etc.

In reply to

But Grift, compression is absolutely necessary for consoles. Even if a game is only 2GB big, all the data is compressed on the DVD. Assuming even minor compression, 2x, that allows disk data to be streamed 2x as quickly to the system memory -- and CPU decompression speeds are insignificant in comparison to the time it takes to stream data. As a developer I know stated: All good developers use compression.

As for procedural textures, I think quality is the biggest issue. But if you could get quality textures from procedural methods, there is no reason not to create them while loading or caching data. Imagine this scenario:

You are starting a new level in PGR5. You have 100MB of audio, 100MB of geometry, and 200MB of textures to cache before the user can begin racing. Lets assume magically 50% (100MB) of those textures could be procedurally created on the GPU.

So lets say it takes 40 seconds to stream 400MB to system memory, so what if you could write 300MB in 30 seconds and at the same time create 100MB of the textures procedurally?

They are stored in memory like any other texture, but instead of coming from the disk they were created in memory by a procedural generation application.

We aren't quite there yet... but we are getting closer. Much closer. So much so I think the next wave of consoles will rely on such techniques in a significant manner because of the benefits in modification, reduced artist load, reduced memory transfer (imagine 4GB of system memory and a BDR transfering to it... no, just no!) and such.

We will see though, although the field is very interesting and fast moving. MS talked it up a lot at GDC 2005 and as time goes on it will become more popular in content creation -- because applications are cheap, artists are not -- for things like cities, forests, etc.

The fans have spoken. Concerning the graphics of the Halo 3 Beta: "There's so many little effects and things going on that make this game pretty much 2nd only to Gears at the moment."

INDIGO

Since 7532 Days

http://en.wikipedia.org/wiki/Procedural_texture

See the example there; it's a combination of layers of alphas and patterns. It still takes an artist a lot of work to create it (and some programming apparently when it comes to games). I use procedurals a lot in my work mainly because UV's are a bitch. ;)

From what I'm reading the main consideration actually is storage limitations, and the randomness procedurals can create.

In reply to

Acert93

Since 6801 Days

Posted by INDIGO

It still takes artists to make procedural textures. Procedural does not necessarily mean they are generated automatically. Think of them more as layered textures.

Not really. You can create procedural textures without artist activities (e.g. imagine a tree that when "cut" procedurally creates various wood chip textures for the fragments). Of course as time moves on we will see more tools that offer procedural textures that artists can mix, match, and modify (stuff already exists) and in many ways this is similar to the shader tools available where artists can take basic shaders and mix and match and adjust values. They are not creating anything, necessarily, but using sliders (because math is too hard for them :P ) to dynamically create these effects which really are the result of mathematical values. Right now you can do that with textures, too, e.g. creating a wood grain or brick and such. Apps allow you to use sliders to dynamically alter the pattern, colors, grain size, etc. The design seen is all mathmatics.

In reply to

[quote=INDIGO]It still takes artists to make procedural textures.  Procedural does not necessarily mean they are generated automatically.  Think of them more as layered textures.[/quote]

Not really. You can create procedural textures without artist activities (e.g. imagine a tree that when "cut" procedurally creates various wood chip textures for the fragments). Of course as time moves on we will see more tools that offer procedural textures that artists can mix, match, and modify (stuff already exists) and in many ways this is similar to the shader tools available where artists can take basic shaders and mix and match and adjust values. They are not creating anything, necessarily, but using sliders (because math is too hard for them :P ) to dynamically create these effects which really are the result of mathematical values. Right now you can do that with textures, too, e.g. creating a wood grain or brick and such. Apps allow you to use sliders to dynamically alter the pattern, colors, grain size, etc. The design seen is all mathmatics.

The fans have spoken. Concerning the graphics of the Halo 3 Beta: "There's so many little effects and things going on that make this game pretty much 2nd only to Gears at the moment."

GriftGFX

Since 6830 Days

Posted by Acert93

But Grift, compression is absolutely necessary for consoles. Even if a game is only 2GB big, all the data is compressed on the DVD. Assuming even minor compression, 2x, that allows disk data to be streamed 2x as quickly to the system memory -- and CPU decompression speeds are insignificant in comparison to the time it takes to stream data. As a developer I know stated: All good developers use compression.

Granted, but the most efficient compression algorithms are incredibly lossy, so I suppose it comes down to weighing the benefits versus the potential drawbacks. This doesn't only apply to textures, but to other data as well.. including audio.

Posted by INDIGO

http://en.wikipedia.org/wiki/Procedural_texture

See the example there; it's a combination of layers of alphas and patterns. It still takes an artist a lot of work to create it (and some programming apparently when it comes to games). I use procedurals a lot in my work mainly because UV's are a bitch. ;)

From what I'm reading the main consideration actually is storage limitations, and the randomness procedurals can create.

Funny that you quote the same article that the procedural marble code comes from -- that hardly requires any artist intervention at all. Math isn't art.. well.. I guess that depends on who you ask.

In reply to

[quote=Acert93]But Grift, compression is absolutely necessary for consoles. Even if a game is only 2GB big, all the data is compressed on the DVD. Assuming even minor compression, 2x, that allows disk data to be streamed 2x as quickly to the system memory -- and CPU decompression speeds are insignificant in comparison to the time it takes to stream data. As a developer I know stated: All good developers use compression.[/quote]

Granted, but the most efficient compression algorithms are incredibly lossy, so I suppose it comes down to weighing the benefits versus the potential drawbacks.  This doesn't only apply to textures, but to other data as well.. including audio.

[quote=INDIGO]http://en.wikipedia.org/wiki/Procedural_texture

See the example there; it's a combination of layers of alphas and patterns.  It still takes an artist a lot of work to create it (and some programming apparently when it comes to games).  I use procedurals a lot in my work mainly because UV's are a bitch.  ;)

From what I'm reading the main consideration actually is storage limitations, and the randomness procedurals can create.[/quote]

Funny that you quote the same article that the procedural marble code comes from -- that hardly requires any artist intervention at all.  Math isn't art.. well.. I guess that depends on who you ask.

INDIGO

Since 7532 Days

Of course you can create procedural textures without artists. But you wouldn't for most of the texture work you see in a game.

Math is hard for artists? Tools for creating procedural texture will *become* available? You really have no idea what you are talking about, I'm sorry, because procedurally generated textures have been around since the first 3d app on PC's.

In reply to

GriftGFX

Since 6830 Days

Posted by INDIGO

Of course you can create procedural textures without artists. But you wouldn't for most of the texture work you see in a game.

Math is hard for artists? Tools for creating procedural texture will *become* available? You really have no idea what you are talking about, I'm sorry, because procedurally generated textures have been around since the first 3d app on PC's.

And those algorithms were written by artists? Huh? And yes -- the actual math and programming aspect of 3D design is hard for artists. Hell, using Maya is pretty freaking complicated on a high level and we're not even really talking about the design of the procedural methods themselves, but just using the tool.. which isn't very math intense at all.

Using these tools does not require a very complete understanding of how procedurally generated textures are actually being generated.

In reply to

INDIGO

Since 7532 Days

And those algorithms were written by artists? Huh?

No, they were probably generated by software that extracted them from the 3d app the artist was using.

I have never seen a texture generated by code like that. But you can install Modo and layer textures and play with layers and blending options 'til the cows come home if you like, and you will never need to enter a lick of code.

http://www.luxology.com/

I am not arguing for the sake of arguing, I happen to be a 3d artist. And I do not know what acert's field is, but I am willing to bet that I was required to take more math and physics classes than he has taken.

In reply to

GriftGFX

Since 6830 Days

Posted by INDIGO

And those algorithms were written by artists? Huh?

No, they were probably generated by software that extracted them from the 3d app the artist was using.

I have never seen a texture generated by code like that. But you can install Modo and layer textures and play with layers and blending options 'til the cows come home if you like, and you will never need to enter a lick of code.

http://www.luxology.com/

I am not arguing for the sake of arguing, I happen to be a 3d artist.

I'm not completely naive to these tools either, but we're not talking about the same thing. No, you don't need to know a lick of math -- because the people who designed the tools for you did. That's my point. Generating textures on the fly, from scratch, in a video game, requires math and code.

Generating a fractal, which is one of the most basic examples of procedural generation is ALL math, and it requires a pretty good handle on math and programming to make that happen -- that's not too far off from what we're talking about in the real time implementation of these concepts in a videogame.

In reply to

[quote=INDIGO][quote]And those algorithms were written by artists? Huh?[/quote]

No, they were probably generated by software that extracted them from the 3d app the artist was using.

I have never seen a texture generated by code like that.  But you can install Modo and layer textures and play with layers and blending options 'til the cows come home if you like, and you will never need to enter a lick of code.

http://www.luxology.com/

I am not arguing for the sake of arguing, I happen to be a 3d artist.[/quote]

I'm not completely naive to these tools either, but we're not talking about the same thing.  No, you don't need to know a lick of math -- because the people who designed the tools for you did.  That's my point.  Generating textures on the fly, from scratch, in a video game, requires math and code.

Generating a fractal, which is one of the most basic examples of procedural generation is ALL math, and it requires a pretty good handle on math and programming to make that happen -- that's not too far off from what we're talking about in the real time implementation of these concepts in a videogame.

INDIGO

Since 7532 Days

Of course it does. Interfacing with the controller does too.

......

Forget it.

In reply to

GriftGFX

Since 6830 Days

Posted by INDIGO

Of course it does. Interfacing with the controller does too.

......

Forget it.

But using a controller doesn't have anything to do with the creation of the content in a game. Take the tree example -- not generating the tree procedurally and then placing it (which would be done by an artist) in the game -- but having the game actually generate the landscape itself, in real time. In this way we're saving on disc space, and saving on the amount of work an artist would have to put into the game (by tweaking and placing those objects). That's what we're talking about...generating content from scratch...from code.

I'm not arguing that artists don't use procedural tools.. just that procedural algorithms can indeed by implemented in ways that save time for the artists, which saves man hours, and in the end, takes away from the amount of hand painted textures they might have to use.

There's a game that's in the kilobyte range.. you should check it out. You can bet that the person who implemented those procedural algorithms has a pretty wicked handle on math, and isn't necessarily an artist.

In reply to

[quote=INDIGO]Of course it does.  Interfacing with the controller does too.

......

Forget it.[/quote]

But using a controller doesn't have anything to do with the creation of the content in a game.  Take the tree example -- not generating the tree procedurally and then placing it (which would be done by an artist) in the game -- but having the game actually generate the landscape itself, in real time.  In this way we're saving on disc space, and saving on the amount of work an artist would have to put into the game (by tweaking and placing those objects).  That's what we're talking about...generating content from scratch...from code.

I'm not arguing that artists don't use procedural tools.. just that procedural algorithms can indeed by implemented in ways that save time for the artists, which saves man hours, and in the end, takes away from the amount of hand painted textures they might have to use.

There's a game that's in the kilobyte range.. you should check it out.  You can bet that the person who implemented those procedural algorithms has a pretty wicked  handle on math, and isn't necessarily an artist.

Acert93

Since 6801 Days

http://www.profxengine.com/index.php?PAGE=GALLERY....

Some nice videos that only use procedural textures. Some pretty nice textures... this is the same company who did the tech the Roboblitz folks used.

Most of the demos use less than 512KB in size for the app and textures and generate 100s of MBs of textures... and more importantly the materials, as they are procedurally created, and be altered as such. So you scuff a wall, for example, and it can get a scratch as per determined by the material characteristics of the texture.

The bathroom scene is very impressive because you can see how the bathroom ages and how plaster cracking reveals wood behind the wall -- all procedurally created.

In reply to

The fans have spoken. Concerning the graphics of the Halo 3 Beta: "There's so many little effects and things going on that make this game pretty much 2nd only to Gears at the moment."

Acert93

Since 6801 Days

96KB game using procedural textures: http://www.theprodukkt.com/

And related to procedural textures is MS's patent on procedural synthesis which Ars broke down many moons ago: http://arstechnica.com/articles/paedia/cpu/xbox360...

The idea of using basic stock material and using applications to generate the content by user defined criteria (e.g. I want 100-150 pine trees per acre of various heights from seedlings to 200ft with the averge being 125ft and the median being 100ft, with average-to-thick density) is definately gaining steam because it allows artists to create masses of content quickly and for them to fine tune later if they so choose. This is exactly what Speedtree does. http://www.speedtree.com/

Right now most procedural synthesis is done at creation time, but eventually it will be done in some circumstances at loadtime and eventually even at runtime (many procedural texture applications are in the range of 40 ops).

The fact is games are using procedural technologies now and have been and they will only become more common as games need more art assets and hence artists, which are expensive, and game size increases but storage medium transfer rates remain low.

In reply to

96KB game using procedural textures: http://www.theprodukkt.com/

And related to procedural textures is MS's patent on procedural synthesis which Ars broke down many moons ago: http://arstechnica.com/articles/paedia/cpu/xbox360-1.ars/2

The idea of using basic stock material and using applications to generate the content by user defined criteria (e.g. I want 100-150 pine trees per acre of various heights from seedlings to 200ft with the averge being 125ft and the median being 100ft, with average-to-thick density) is definately gaining steam because it allows artists to create masses of content quickly and for them to fine tune later if they so choose. This is exactly what Speedtree does. http://www.speedtree.com/

Right now most procedural synthesis is done at creation time, but eventually it will be done in some circumstances at loadtime and eventually even at runtime (many procedural texture applications are in the range of 40 ops).

The fact is games are using procedural technologies now and have been and they will only become more common as games need more art assets and hence artists, which are expensive, and game size increases but storage medium transfer rates remain low.

The fans have spoken. Concerning the graphics of the Halo 3 Beta: "There's so many little effects and things going on that make this game pretty much 2nd only to Gears at the moment."

Optimusv2

Since 6722 Days

Isn't carmack's engine a good solution?

20GB of textures or something like that while only taking up 2GB of space was it?

In reply to

Hironobu Sakaguchi is coming back to reclaim the throne :)

October 20th 2007 (A good day)

Don't ask any questions just shut up and buy Halo : Ghosts of the Onyx one of the greatest books ever.

GrimThorne

Since 6702 Days

Posted by Optimusv2

Procedural textures like others have said are certainly not a solution because some programmer trying to make some textures look great wont be better at it than a great artist. I prefer they continue to do textures using great artists I don't want something to look technically impressive, but generic as hell.

Optimus, artists still have to create their own textures, they would only have to use the procedural tools to store their textures into memory.

Artists still have to paint and create their own textures. More importantly procedural algorithms wouldn't require that artists suddenly becoming coding masters. The artist can continue to create whatever he wants.

In reply to

Optimusv2

Since 6722 Days

Posted by GrimThorne

Optimus, artists still have to create their own textures, they would only have to use the procedural tools to store their textures into memory.

Artists still have to paint and create their own textures. More importantly procedural algorithms wouldn't require that artists suddenly becoming coding masters. The artist can continue to create whatever he wants.

Wow then if thats the case I suggest more devs start using it :)

Hopefully it doesn't take away too many valuable resources from other aspects of the game. I suppose it shouldn't especially since the 360 was designed with this in mind?

In reply to

Hironobu Sakaguchi is coming back to reclaim the throne :)

October 20th 2007 (A good day)

Don't ask any questions just shut up and buy Halo : Ghosts of the Onyx one of the greatest books ever.

newbielives

Since 6769 Days

What you are talking about is not just compression?

Posted by GrimThorne

Optimus, artists still have to create their own textures, they would only have to use the procedural tools to store their textures into memory.

Artists still have to paint and create their own textures. More importantly procedural algorithms wouldn't require that artists suddenly becoming coding masters. The artist can continue to create whatever he wants.

In reply to

GriftGFX

Since 6830 Days

Posted by Acert93

Right now most procedural synthesis is done at creation time, but eventually it will be done in some circumstances at loadtime and eventually even at runtime (many procedural texture applications are in the range of 40 ops).

The fact is games are using procedural technologies now and have been and they will only become more common as games need more art assets and hence artists, which are expensive, and game size increases but storage medium transfer rates remain low.

This seems to be the bulk of what people aren't getting.. oh well.

In reply to

n3ro

Since 6526 Days

I'm still very angry at Microsoft.

You just can't get full NEXT-GEN games with DVD-9.

Blue-Ray and HDDVD were available in the end of 2005. PS3 announced years ago that the PS3 will have Blue-Ray.

The external HDDVD-player only gives 1080p when watching movies but it can't be used too develop HDDVD-games. If they do that then all 360-owners will get mad to pay more money to play the best games. 199$ is expensive.

Huge d*ckmove by MS and the second hugest mistake after the hardwareproblems !!

In reply to

Xbox 360

Halo 3 - Call of Duty 4 - Bioshock - Turok

deftangel

Since 6698 Days

So Gears of War isn't a next gen game? Some would argue it's the very definition of it, not that I'm starting that discussion here mind.

In terms of business, not including HD-DVD is the smart move. Of course for us we want everything and will probably have paid $500 odd for a HD-DVD 360 anyway.

As for procedural texturing, the load times in PG3 were bad enough (though they were rushing for launch so I'll let them off) but does anyone have any idea how long we'll be waiting for an entire city to load up with procedural textures? It'll be like going back to the C64 days on current hardware!

It's a nice tech but not applicable in all situations.

In reply to

SimonM7

Since 6853 Days

Well, at the risk of launching the BR/DVD crapstorm debate, I think this lends some credibility to statements out of PS3 development camps that BR is actually a rather nice thing to have access to. I think a lot of people have dismissed it as pure PR speak, suggesting that there's no way we're running out of space that soon unless there's tons of HD FMV on there, but PGR is simply a content heavy game regardless.

In reply to

deftangel

Since 6698 Days

Well one can say you need to fill 25GB of space to make Blu-Ray worthwhile but you only need to go over 8.5GB for it to be useful. The equation is the extra cost of HD media vs the benefits. I don't think anyone would deny there is a benefit, just that it can be overplayed/underplayed depending on what PR you listen to.

To be fair to PGR4, 10 cities the size of the first one makes for a pretty big game so it's not like we're being undersold. When we get to the point of needing the space just to get a decent length game out we'll have more things to worry about.

Still, such things might appear as DLC as 500MB for this isn't a big ask. If it's only a matter of rebaking the textures there's no reason why it can't be done for those willing to make the HD space.

In reply to

JXB

Since 6162 Days

Blu-ray and Hd-dvd arent needed, as time goes by tools will get better, compression techniques will advance and we wont need all that space.

In reply to

F1 24

Still Wakes the Deep

Black Myth: Wukong

Hellblade II in HDR and on GeForce NOW

GSY Preview: F1 24

We reviewed Hellblade II