Rage mods not possible, maybe.

[xav1r]

link:

http://www.gamasutra.com/php-bin/news_index.php?story=20291 (http://www.gamasutra.com/php-bin/news_index.php?story=20291)

From what i understand, it comes down to the amount of time and power to bake the megatexture information for a level. Since Im not very acquainted with megatexture/graphics technology, could some of the expert developers here provide their opinions on this?

thanks

[Dragonlord]

The problem is that Rage ( or Tech5 in this case ) is a pure mesh based game world. This means the entire world is modeled in a 3D application and texture with one huge texture. This means changes late in the production is a killer. Furthermore working with such huge textures is not for the feint hearted since the disk and memory consumptions ( CPU and GPU wise ) are just insane.

I checked out that mega texture myself while looking for a suitable way to deal with terrains in my engine but John's solution fell flat for me. The idea is good and his optimizations are well thought off but still it's limited and fails if you try to venture outside the boundaries of the system ( like multi-rendering, redirected rendering or seamless and giant worlds ).

For modders this is going to be tricky since it's like making one huge scene in Blender and then doing a huge texture for it. There's no room for prototyping and this is one of the huge shortcomings of this technique. This is also why I do not think MegaTextures are going to catch on. Good case study of John nevertheless.

EDIT: I need to make a little precision on the things I wrote. There is one huge mesh with one huge texture used for the terrain ( mostly height-map type terrains where small overhangs are possible ). Object meshes though can be used with conventional texturing for doing things like caves, buildings and various stage props.

[Svartalf]

Not possible isn't quite accurate. Dragonlord's telling it mostly as it probably will be. What'll end up happening is if you're doing modding, you'll need a small cluster of dual/quad/oct-core systems to do the work. It won't be the same story as it was in the past. It won't be impossible to mod, but you're going to have to be more of a nutball like myself with something like that class of hardware just kind of lying about. ;) Moreover, the skillset's going to be a couple of notches higher up the food chain to be able to do a level or a complete conversion if this stuff catches on. As Dragonlord said- I don't see this taking off in the large anyhow. :D

[grantek]

Not possible isn't quite accurate.
Well, there's also the question of "if it's so difficult to mod, will id even release tools/support for modding". There's an SDK for ETQW, so without knowing anything about it I'm guessing there's Megatexture support there, but it's still a concern. I hope in the end id's philosophy wins through, they release an SDK and people prove them wrong with awesome mods :)

[Aradreth]

I'm sure that if iD releases the tools to mod rage it will be done in time. Where there's a will there's a way and so on. ;)

[Dragonlord]

As mentioned you have one huge mesh with one huge mega texture. Yet though you have conventional mesh+texture support which can be done the old way. Hence for building and complex structures mega texture is not suitable ( since it works with a huge non-overlapping uv-unwrap of the huge mesh allowing for small overhangs but not complex structures ). Hence if you use mostly complex buildings instead of large land masses then you can get away without mega textures ( and you have to ).

[Thetargos]

May this boil down to the way the "world" is actually created by the tools? I mean, if in the editor you are able to build small bits independently before being "merged" into the world geometry and the textures appended into the one MegaTexture? Again, I do not understand much of how could it be feasible to do, much less the logic behind it :p

[Dragonlord]

No, this doesn't work like this. You use a 3D modeling application to create the mesh which is then exported to the editor ( as far as I know... not 100% sure on this step ). The mesh is uv-unwrapped in a non-overlapping fashion. The problem with non-overlapping unwrap is that the unwrapped geometry is required to not contain "stretching". Now how to explain this. If you take a plain for example and you create hills and valleys then you can look downwards on the terrain and make a snapshot and you see all the surface of the terrain. In this case you can make a non-overlapping unwrap. Now make an overhang, or a cave mouth for example. You find no angle of view anymore where you can see all surface at once. In this case the texture has to be stretched a lot to warp the surface into one which can be seen without overlap. You have then though introduced stretching into the uv-unwrap which is noticeable since some geometry seems to be texture with higher resolution others with less ( and the blend between different resolutions is what breaks afterwards ). Hopefully I could explain this a bit. You have to fiddle once with Blender and using the unwrap tool for different geometry ( use a kind of grassy plain and on the other hand the blender monkey ) and see what happens with the uv-unwrap.

[Thetargos]

No, this doesn't work like this. You use a 3D modeling application to create the mesh which is then exported to the editor ( as far as I know... not 100% sure on this step ). The mesh is uv-unwrapped in a non-overlapping fashion. The problem with non-overlapping unwrap is that the unwrapped geometry is required to not contain "stretching". Now how to explain this. If you take a plain for example and you create hills and valleys then you can look downwards on the terrain and make a snapshot and you see all the surface of the terrain. In this case you can make a non-overlapping unwrap. Now make an overhang, or a cave mouth for example. You find no angle of view anymore where you can see all surface at once. In this case the texture has to be stretched a lot to warp the surface into one which can be seen without overlap. You have then though introduced stretching into the uv-unwrap which is noticeable since some geometry seems to be texture with higher resolution others with less ( and the blend between different resolutions is what breaks afterwards ). Hopefully I could explain this a bit. You have to fiddle once with Blender and using the unwrap tool for different geometry ( use a kind of grassy plain and on the other hand the blender monkey ) and see what happens with the uv-unwrap.

That is actually quite clear. So what are the benefits of MegaTexture when it seems to be so limited? The only advantage I see to it is that you'd rather have one large texture map for stuff like purely outdoor levels, and if you have a mix in your mod/game, then the advantage of MegaTexture is rather limited (not to mention encumbered). The way I thought this worked was that if you created your level's base geometry and apply several little (or large) texture maps to form the basic look of the scene, and if you added (for example) buildings and stuff like that, the textures composing this geometry would then blend together in the MegaTexture. From your explanation, though, it would seem as if the buildings (being a protrusion, braking the plane) would introduce overlap and hence "stretch" and "distortion" to the uv-unwrapped map, in which case only the terrain texture is feasible to merge into the huge MegaTexture and the buildings would have to still rely on individual texture maps, like "objects" laying on top of the terrain (covered by MegaTexture). I suppose this technique is useful for the case of Rage and maybe other large outdoor based games with large outdoor levels, but it wouldn't be too useful for stuff like MMORPGs and other type of seamless transition worlds where this hugely immense texture map would be (I think, anyway) too much trouble to juggle around, even though the idea behind MegaTexture is to stream it to the GPU rather than loading it into memory and feeding it to the GPU... but wouldn't that cause too much I/O overhead, like in the past some games when running on tight resources had to resort to load from disk geometry/texture data, slowing things down? I guess on multicore systems it maybe possible to dedicate one CPU for I/O operations so that gameplay wouldn't slowdown, but then the rate at which data is fed into the GPU or another CPU would be critical.

At any rate, thanks for the explanation. I have used the UV map tools in Blender and it CAN be hard.

[xav1r]

As Thetargos was saying, yes, Im too failing to see the advatages of megatexture as a level building technique. So far its advantages only seem to be visual, as in "it looks more realistic, or prettier". Damn, so John Carmack's awesome megatexture creation is only making modding more difficult then. :rolleyes::rolleyes:

[Dragonlord]

It might be a good idea to google around. There is on GamaSutra an article explaining the technique behind megatextures which could help gain some insights.

What goes for the mega textures itself it is definitely geared for outdoor scenes although seamless transitions to indoor should be possible. At last a demo video of Rage claimed so. It's though some time ago so I don't remember anymore how exactly it looked like. The advantage of mega textures are a couple though. First you have only one set of textures ( or rather said concentric tiles, 4 to be precise ) you render with. This prevents multi-pass rendering as required with conventional texture-blob terrains with decals. Also it avoids repetition in terrain textures which usually are covered by cleverly placing vegetation props. Also resolution problems as prevalent texture-blob are not existing. That said it introduces also some problems ( depending on your game that is ). First it requires tremendous disk space even if John came up with quite a clever compression ( which is variable but requires mappers to designed areas as higher compressable which is not always a good thing to offload on mappers ). Another problem is that only smaller changes to work geometry is possible since it requires repainting the affected texture area. There had been a discussion at GameDev about this and although I can understand the late-changes=fail faction I'm a large prototype guy myself so blocking changes for me is a red towel.

So in general it can be boiled down to this:
+ no repetition in terrain
+ requires few render passes
+ high visual appeal

- dynamic terrain is problematic ( changing terrain features or texture )
- disk consumption for moderate game world is huge ( unsuitable for huge game world )
- hostile to map geometry changes

My game for example is based around high interaction with the environment ( dynamic environment ) and huge worlds. For such a setup this technique is not suitable which is why I'm working on something similar but inspired by the old game Trespasser ( for those still remembering this little gem ). Mega Texture has a certain resemblance to their terrain engine but the Trespasser one is different in an important part which makes it suitable for huge worlds whereas mega texture is not. Let's see if I can revive this technique for todays demands ( various material properties, deferred rendering and so forth ).

[xav1r]

Damn Dragonlord, you know a lot about terrain building and whatnot, are you a modder, or are in a modding team? I could use your skills for the mod im trying to put together. :)

[Svartalf]

Damn Dragonlord, you know a lot about terrain building and whatnot, are you a modder, or are in a modding team? I could use your skills for the mod im trying to put together. :)

No... He's an engine developer. Indie. I'm hoping he succeeds with what he's doing- if he does, it means more players doing innovative things. Moreover, it'll open up avenues for us to have cool stuff to play down the line.

[xav1r]

No... He's an engine developer. Indie. I'm hoping he succeeds with what he's doing- if he does, it means more players doing innovative things. Moreover, it'll open up avenues for us to have cool stuff to play down the line.

Ah, yea i think i read something about that. So is there a website for the engine he's making??

[grantek]

I'm not a developer, but I still don't see the problem with Megatextures:
- If you have a cliff, just create multiple disconnected Megatextures. MTs are good for big deformed planes, not specifically one large floor in your world. Maybe it's not implemented in id Tech 4/5, but there's nothing stopping you tearing a Megatexture either and assigning another texture to the torn "cliff face" of your plane.
- For prototyping/late changes, you can use decals on top of the MT, then merge them down as often as needed. I don't really have any experience with 3d modelling programs, but I'm assuming decals are easy enough to do (if not it's more a shortcoming in the 3d modeller). There should be a way to draw textures however you want, fly around the world in the modelling program, then export everything as a MT.
- For dynamic rasterised environments, you can still store an initial state on the surface with MT, and dynamically texture the inside of any holes you dig into it.
- If you're changing the shape of polygons, you'll need to store hi-res data for the entire surface, so you can use mipmaps until you go too far into procedural texturing, where traditional textures aren't much use either.
- If you REALLY want to go nuts with environment destruction/deformation, the MT idea will help even MORE, because you'll need to store a 3d texture - ie. instead of one megatexture, you've potentially got thousands stacked on top of each other. You'll also need to store all the other material properties in a similar data structure.

To me a Megatexture is just a handy data structure that makes it EASIER to do heavily detailed textures. It doesn't FORCE you to do heavily detailed textures (even if you have to tesselate your tiles into a MT as an added step in map creation), and it doesn't take away anything.

I think the guys at id are just saying that games are getting so much more detailed that people will expect a mod to be heavily detailed, and that's getting harder and harder for a mod team to do.

@Dragonlord - I'm not familiar with Trespasser, how did it do things?

[mirv]

I don't see too much of a problem with terrain deformations & megatexture type systems - but only up to a point. Stretching does become a problem with terrain that's too steep - as far as I'm aware etqw gets around this by modifying the uv-coords, which in turn really ties the current terrain to the texture.
Megatexture type systems can (or should be able to) work with continuous large worlds. I started work (still poking at it) on something which is probably akin to how megatexture works, and with a few small tweaks would work just great in that sense.
As for modding - I agree with the general sense in that it wouldn't be impossible, just require lots of storage and processing power. A lot of work on good editing tools would make things easier (such as auto generation of terrain based upon selected inputs), but working with extremely large data sets is always going to take time and resources.

[grantek]

I want to see a Megatexture engine implemented into the GIMP, so that it auto-saves bits off-screen and auto-loads as you scroll :)

[Dragonlord]

So is there a website for the engine he's making??
There is... but I tend to not spam URLs or advertise around forums. Just not nice netiquette.

- If you have a cliff, just create multiple disconnected Megatextures.
In general this is true. You could use multiple mega textures. The problem is more how the system is implemented. John keeps around 4 same sized textures ( 2048 after his writing ) which are centered at the player position but each one is X times larger than the former. This yields similar texel-to-point ratio along the view of the player similar to what CSM ( cascaded shadow maps ) do. Hence only one megatexture can map to this texture stack. You could use more mega textures at the expense of more GPU RAM required ( and increased paging, uploading to GPU RAM ). Not sure if John has this is mind somewhere but in rage there is only 1 mega texture as far as I know.

- For prototyping/late changes,
I meant more mesh modifications. Modifying the texture late on is rather easy.

- If you REALLY want to go nuts with environment destruction/deformation, the MT idea will help even MORE, because you'll need to store a 3d texture - ie. instead of one megatexture, you've potentially got thousands stacked on top of each other. You'll also need to store all the other material properties in a similar data structure.
Keep in mind that one MT texture stack already consumes 134M GPU RAM uncompressed and with compression ( 25% for diffuse, 75% for normals maybe ) this still chomps 67M out of your memory budget. And this only uses diffuse(3)+normal(3)+specular(1) as material properties so far. You can chomp this down to 25% by halving the dimensions nevertheless there are also other components competing for GPU memory. MT with 3D textures would be interesting but fitting that into 512M ( and on disk especially ) is a rough call :D

To me a Megatexture is just a handy data structure that makes it EASIER to do heavily detailed textures. It doesn't FORCE you to do heavily detailed textures (even if you have to tesselate your tiles into a MT as an added step in map creation), and it doesn't take away anything.
They definitely yield a lot of detail. That said though they also consume disk space like a Gilvader. On the other hand I always tend to question how much graphics really are required. If you have a nice forestine area or a densely covered terrain how much difference do you see between a full blown mega texture and some more straight forward system? I think you can often get on with less and use the disk space previously consumed by texture data for some nifty things like good animations, good voice acting, good music ( something which todays game developers seem to have forgotten about <.=.< ), better AI, or just more props to make the game world vivid. At least that's how I see it in the end.

I'm not familiar with Trespasser, how did it do things?
They separate the world into tiles ( driven by the terrain system ). Each tile has a diffuse texture. Now a map contains sort of "terrain texture meshes". They are conventional textured flat meshes which are though invisible. When a tile is dirty the texture meshes affecting the tile are projected down on the texture and combined with shadows ( hence shadows are backed into the tile textures... only sun shadows but affecting all moving objects ). In contrary to MT the tiles are at fixed positions not centered around the player. Also while MT are precalculated and stored in disk Tres builds all textures on the fly using the texture meshes.

[grantek]

Thanks for the info :) - my ravings about 3d textures were really looking forward to a time when we all have 16GB of fast video RAM, but I'm sure there's some small proofs of concept that could be done today that would be really interesting to see.

I guess it also depends on what you want your 3d engine for - ETQW benefits because it's about vast open spaces, and it does look pretty, but then again I never noticed any tesselation in the big maps in a game like Battlefield 1942.

[Dragonlord]

Nothing against proof of concept. 3D textures indeed are an interesing thing. I think though the future is up to shaders producing volumetric textures on the fly not requiring much GPU RAM except maybe for a small reusable 3D texture ( like a randomizer or a coarse grain density distribution ).

What goes for the resolution I don't know now what texel-to-pixel resolution rage is going to feature. I estimate though up to 1dm ( meaning one texel covers 1dm squared on the ground ). It could be less but judging from the figures of texture resolutions I heard flying around ( somebody mentioned once 25'000 x 25'000 texture for an entire map ) I would stick to 1dm resolution. So don't get too close to the ground or it might look rather shit :D ( detail textures [ which is another name for texture splatting ] can achieve 1mm resolution if required ).

I'll definitely take a look at the game engine since I would like to see how this implementation performs. Nothing beats an actual implementation to compare with raw figures.

[xav1r]

speaking of proof of concepts, dragonlord, what are your opinions on voxels? I read that there were a few early games, circa 1992, that used voxels, and more recently i think 2 or 3 used them too. But somehow, voxels didnt catch on, with polygons with textures being favored instead. Why do you think that was the case?

[Dragonlord]

I have read only very little into the topic of voxels. Nowadays they are out of use in favor of triangles mostly because voxels are a pure CPU render work while triangles can be accelerated a lot by GPU. Futhermore with increasing triangle troughput more complex scenes can be created which voxels can not cope with. That said the idea behind voxels is not dead. CryEngine for example uses voxels for some "terrain carving" ( or how they call it exactly ). But there again it's only an editing tool to help producing terrain but the actual rendering is done using the fast triangle pumping.

EDIT: Not sure about the last one. I think I read somewhere the voxels are used also in-game for destructible geometry although again converted to triangles once calculated.

[grantek]

...when it's being done in the game engine though, that's where the "3d Megatextures" I was talking about come into play. It's mainly a bandwidth/memory thing (polygons are way more efficient), but the blurring that's been going on between the GPU and CPU (shader languages, larrabee, fusion, scaling of CPU core counts, the physics accelerators that were around for a while etc.) means it's going to be something that we'll see in the near future :)

[Dragonlord]

What do you mean now? Doing voxels on GPU using 3D MTs? I don't think this is going to exist in the near future. You need to fabricate the triangles on the fly. Granted this could be done using GPU4 and the geometry shader unit but if this is faster than a straight forward triangle pusher with an optional true-form type triangle beef-up stage done in geometry unit I would question. One of the objections against voxels I caught up on the GameDev forum is that voxels deliver a rather blocky result. While on a distance this is good since we can not notice the blockiness close up it's a problem. It's kinda like a low resolution shadow map right in front of your nose ( pixelation alert :D ). I would definitely bet my money on a triangle beef-up instead of going crazy on a voxel approach.

What goes for the bluring... yes and no. The strength of GPUs is their parallel architecture. Having like 12 slaves working in parallel yields quite some working power ( why does China jump to my mind thinking about this scenario <.=.< ). The problem though is that those slaves ( aka pixel pipelines ) have to work on non-correlated data. As soon as you have dependencies between the pixels you process it's becoming very difficult and the parallel structure can not play out its cards.

On the other hand there is CUDA and company. I have though not looked yet closer into this enire CUDA thing. Erwin Coumans ( once at havok ) could give you definitely a better view about this topic. The last time I saw him on his home-turf forum ( http://www.bulletphysics.com/Bullet/phpBB3/index.php ) he had a healthy interest in GPU accelerated physics so he would be the better pal to hook up with about this topic.

[xav1r]

Well, what if the voxels are really really tiny? Then it wouldnt look so blocky after all, wouldnt it? They'd be like atoms. :)

[mitch074]

A few years back, I was amazed by a demo-based game called .kkrieger, which fit almost 1.5 Gb of data in 96k (textures, sound, level, UI, AI etc. all fit in the same .EXE).

The technique's name is procedural content generation; it allows data to be stored not as-is, but the way it is created (and then branching takes place to generate alternate versions) instead; then the actual content is re-generated when needed.

The game took ages to load on a slow CPU, but the disk space savings were incredible; some variations, not as constrained in disk space were much faster to load but achieved still impressive 'compression' ratios.

Now however, I'm wondering: wouldn't it be possible to use procedural content generation in a GPU, re-creating a texture at render time instead of having to store it? As far as I know, shading units would be especially apt at doing that, and would actually solve the biggest problem current GPUs have: being VRAM-starved.

[Dragonlord]

.kkrieger has been made by the same guys doing the 64k demo "Farbrausch - The Produkt". Their editor is free to download if you want to poke at how things work.

In fact this idea is floating around for my game engine too. Back then I started with the idea of using procedural content to save disk space. Currently I'm using disk stored content but the procedural one is not far behind... I just need a consider formulation of the construction process ( it's the "dynamic texture" content which I left open right now ).

There's just a little problem there. Procedural content works mostly with composing of shapes generated by math functions. Unfortunately this is not as optimized as a triangle mesh build by a skilled modeler or terrain meshes build by a skilled mapper. Since with games nowadays we struggle with increasing scene complexity saving triangles where possible is important.

Now for textures this would work since the domain is a pixel array where optimizations happen elsewhere. Unfortunately there is a different problem here. Texture artists are used to work with 2D applications like GIMP and company. Procedural textures require an entire different creation work flow since you compose images using mathematical functions fiddling with parameters. Such applications exist already by the way but using 2D painted textures is usually easier and faster. My idea here is to have both techniques so you can choose which one fits best... that is... if I come up with a good formularization.

What goes for shaders it would be possible but it has a hook. First long and complex shaders are slow. So called "uber" shaders should be used only scarcely since they tend to bog down render speed. The second problem is a much more important one: lack of mip-mapping. If you use a shader to calculate textures you can not take advantage of the mip-mapping features nor any kind of filtering. While this might sound like not a problem ( hey, anti-alias it in the shader ) it's a problem nevertheless since mip-mapping and filtering tries to solve the problem of "over-sampling". Over-sampling means that a lot of texels affect a given screen pixel ( in contrary to under-sampling where many screen pixels share one texel ). Mip-maps help to solve this by filtering multiple pixels. Since though your shader can only calculate the current texel ( as mentioned, shaders have to work on pixels independently of other pixels ) you are in a problem there. Hence the only viable solution is to produce a texture on the GPU using the procedural rules and then using this texture. Some clever texture management keeps the RAM usage low.

Oh god... I made an "uber" post again... :P

[Dragonlord]

Well, what if the voxels are really really tiny? Then it wouldnt look so blocky after all, wouldnt it? They'd be like atoms. :)
The problem is memory consumption. If you increase the resolution by the factor of 2 the memory consumption increases by the factor of 8 ( 2*2*2=8 ). Hence the smaller the voxels get the more your memory consumption explodes. And GPUs have only a limited memory, not only what goes for RAM but also what goes for texture sizes ( 4096 is more or less the upper limit ).

[mitch074]

...

What goes for shaders it would be possible but it has a hook. First long and complex shaders are slow. So called "uber" shaders should be used only scarcely since they tend to bog down render speed. The second problem is a much more important one: lack of mip-mapping. If you use a shader to calculate textures you can not take advantage of the mip-mapping features nor any kind of filtering. While this might sound like not a problem ( hey, anti-alias it in the shader ) it's a problem nevertheless since mip-mapping and filtering tries to solve the problem of "over-sampling". Over-sampling means that a lot of texels affect a given screen pixel ( in contrary to under-sampling where many screen pixels share one texel ). Mip-maps help to solve this by filtering multiple pixels. Since though your shader can only calculate the current texel ( as mentioned, shaders have to work on pixels independently of other pixels ) you are in a problem there. Hence the only viable solution is to produce a texture on the GPU using the procedural rules and then using this texture. Some clever texture management keeps the RAM usage low.

Oh god... I made an "uber" post again... :P

About the mipmapping and supersampling: why not make use of content generation to generate the different mipmap levels? Instead of downsampling a big, just-generated texture, the shader generates it "roughly" (distant texture), then "refines" it (not-so-distant, closer, very close, right under your nose...) saving on GPU cycles by not needing to generate said mipmap levels! I'm pretty sure there could even be a way to use said über shaders to remove the need for mipmapping by adding more generation stages the lower the Z-value gets.

Considering 5 mipmap levels (0 is your character's feet, 4 is distant): at step 4 the generated texture is a single brown pixel; at step 3 it's a 16x16 brown-to-black wavy pattern (steps: repeat original pixel, add alpha variation); at step 2 it's a 32x32 wood texture with grain (supersample, do a sharpening pass, generate alpha noise), and at step 0 it's 64x64 a wood panel with nodes, bug bites and a 3D lighting map.

I have no idea if that's really possible, but what about it?

Or, following a different tack, use shading units to do ray tracing - which doesn't NEED textures as much as it requires surfaces: more power required, but less RAM taken up.

Let's go further, and imagine a game engine that uses procedural content generation to store materials, and ray tracing for rendering. Depending on the amount of VRAM, surfaces would be more or less precise, and rendered precision would directly depend from screen definition, number of light sources, computed ray bounces and bounce precision.

Since this is what Intel hint at with Larrabee and their ray-traced Quake demo, and what languages such as CUDA hint at, is it too far fetched?

[Dragonlord]

The problem is not generating the different "layers", the problem is the "neighborhood". For mip-mapping or just any kind of distance based sampling/filtering technique you need to query additional pixels around the one you ask for. Most simple box filter queries 4 pixels on the current and the next deeper texture resulting in 8 texel queries per screen pixel. You would have to calculate all these 8 pixels in the shader and do the blending on your own. I doubt this is feasible since calculating texels multiple time per pass ( 4 times each ) means 4 times less throughput than a simple mip-map unit in hardware. Furthermore such a shader would be really long and even if OpenGL doesn't require shaders to be limited anymore they are still limited by the hardware ( don't know exactly where the instruction limits are but they are still capped ).

I would not wave this idea away but I think for a real-time approach in a real complex game world it's not feasible. Just too much load on the shader units especially if you have a real fast texture unit at your disposal.

What goes for ray-tracing I don't know the results Larrabee produces but ray-tracing requires a lot of data passed to the shaders. Uniforms are quite limited and using a texture for lookup restricts you to a certain number of elements. For quake this works since it is a game with low complexity. For a typical game world of todays games though I doubt there are enough uniforms/textures available to do this without adding heavy multi-pass rendering ( which chokes on fill-rate... something most engines today fight against ).

So for the time being I do not see it to be a viable solution. Maybe once it is but currently the existing texture hardware is your best bet and just plain outperforms any other approach. It's one of the problems with "academic" solutions: if it ain't better/faster than the existing hacks/fakes then it won't catch on :D

[mitch074]

@Dragonlord: Thanks for your answers! Oh, I know a bit about mipmapping and how filtering is done (I also know the difference between nearest neighbor, bilinear, trilinear and anisotropic filtering); I also know that these operations are best treated by texel units, not shading ones (that's why even current top of the line cards show off an impressive array of texel units).

It's because the academic answer wasn't interesting until now that such solutions weren't really considered; but, when you see the pure shading processing power you can get in a RadeonHD 4850 or a Geforce 9800GT, I think we might be getting there.

At a time where shaders were fixed function ones, sure, fakes were the only solution for impressive effects; but now that we can get the real thing...

As far as I know, ray tracing requires large amount of data treatment - but, contrary to textured polygons, they don't require loading a lot of external data; it's more a matter of computing physics (something current GPUs have demonstrated they can certainly do much better than an x86 CPU) from a 'few' basic formulas, and storing computational results until rendering is ready (amount of light bounces is done, for a screen section) - a bit like procedural content generation, in fact.

In short, ray-tracing rendering would tax a card's VRAM, but leave the card's PCIe connection almost free - say, to share the load with another card (this is where SLI and Crossfire would shine)

The nice advantage of ray tracing is that you don't care about mipmaps: data is generated for a given pixel, instead of a pixel being averaged from existing data. If you take away texel units and go full shading, such rendering gets more interesting than polygon mapping.

You may also achieve antialiasing at a lower 'dedicated' cost than polygon edge superampling.

The problem, as you hinted at, is that there isn't really a cross-platform language to allow such programming; Nvidia and Amd have their own, and OpenGL does provide GLSL - but while the latter is cross-platform, it is as far as I know ill-geared towards such tasks.

[Svartalf]

The problem, as you hinted at, is that there isn't really a cross-platform language to allow such programming; Nvidia and Amd have their own, and OpenGL does provide GLSL - but while the latter is cross-platform, it is as far as I know ill-geared towards such tasks.

Heh... The standard you're looking for may be already there and just waiting for the finalization of it: OpenCL (http://en.wikipedia.org/wiki/OpenCL)

It's been submitted for standardization, it's what you will be using on MacOS in the near future and AMD has stated they're going to be backing it instead of their proprietary CTM answer. It won't be too hard to layer in the same stuff on Gallium 3D for the FOSS drivers. The only holdout for that one would be NVidia right at the moment. OpenCL is on everyone else's agenda on GPGPU stuff as much as I know right at this moment.

If you don't want to wait until the dust settles, you might want to try to brave getting the last supported version of the Sh metalanguage library up and running on your machine (The code SHOULD compile and work, it's just that nobody's been officially maintaining the codebase since middle of 2006, with the original developers forming RapidMind and making a commercial version with serious enhancements to it...) or to put BrookGPU on the machine and go with that. In either of those cases, you can start playing with GPGPU computation that doesn't use CUDA, CTM, or anything else proprietary, and brings to the table the ability there in a cross-platform manner on C++.

[deanjo]

s. The only holdout for that one would be NVidia right at the moment.

Considering OS X 10.6 was shown off @ WWDC this year on Nvidia hardware I can pretty much guarantee that they are on board. They just haven't made a big tadoo about it.

[Svartalf]

Considering OS X 10.6 was shown off @ WWDC this year on Nvidia hardware I can pretty much guarantee that they are on board. They just haven't made a big tadoo about it.

That's my take on it, but I'm not working for 'em so I'm not presuming what they will/won't provide the Linux community. ;)

[deanjo]

Khronos Launches Heterogeneous Computing Initiative

June 16th 2008 – San Francisco, CA – The Khronos™ Group announced today the formation of a new Compute Working Group to create royalty-free, open standards for programming heterogeneous data and task parallel computing across GPUs and CPUs. The creation of this open standard is intended to enable and encourage diverse applications to leverage all available platform compute resources on a wide range of platforms. Initial participants in the working group include 3Dlabs, AMD, Apple, ARM, Codeplay, Ericsson, Freescale, Graphic Remedy, IBM, Imagination Technologies, Intel, Nokia, NVIDIA, Motorola, QNX, Qualcomm, Samsung, Seaweed, TI, and Umeå University. Any company is welcome to join the Khronos Group to participate in this and the other Khronos working groups that are creating an ecosystem of open standards for graphics and media authoring and acceleration. For more details please visit www.khronos.org (http://www.khronos.org/).
The Compute Working Group will follow proven Khronos processes and invite member contributions as a basis for standardization efforts. Apple has proposed the Open Computing Language (OpenCL) specification to enable any application to tap into the vast gigaflops of GPU and CPU resources through an approachable C-based language. A widely available open-standard compute programming specification with high-performance, general computation support and robust numerics will complement existing solutions and further liberate GPU-based compute power from the realm of graphics-only applications and provide a multi-vendor, portable interface for coordinating all the many-core GPUs and multi-core CPUs within a system. Such capability will have broad applicability - including a central role in the Khronos API ecosystem by providing a powerful compute front-end to OpenGL and OpenGL ES, and a platform for accelerating tasks such as physics and image processing / recognition.
“The Compute Working Group potentially will be one of the most significant standardization efforts at Khronos. Highly-accelerated parallel computation across GPUs and CPUs is essential to many emerging rich consumer applications that will transform the computing experience of diverse users,” said Neil Trevett, president of the Khronos Group. “Significantly, this initiative is aimed at both desktop and embedded devices – the day when you will be able to hold a supercomputer in the palm of your hand is perhaps not so far away.”
Representatives from Khronos and the Compute Working Group will be available in person for briefings at SIGGRAPH in Los Angeles, 11-15th August 2008. Contact Elizabeth Riegel at the contact information above for appointments.
About The Khronos Group
The Khronos Group is an industry consortium creating open standards to enable the authoring and acceleration of graphics and dynamic media on a wide variety of platforms and devices. Khronos standards include OpenGL®, OpenGL® ES, OpenMAX™, OpenVG™, OpenKODE™, and COLLADA™. All Khronos members are able to contribute to the development of Khronos specifications, are empowered to vote at various stages before public deployment, and are able to accelerate the delivery of their cutting-edge media platforms and applications through early access to specification drafts and conformance tests. More information is available at www.khronos.org (http://www.khronos.org/).

[xav1r]

I recently read an interview with Epic's (what a coincidence heh?) Tim Sweeney where he coincides with many of the opinions being mentioned here.

http://www.gamersglobal.com/news/1310

Among them, he says that directx, and more importantly, graphic APIs like it, are obsolete, :D and the trend is now towards a truly multiplatform coding dialect that works for all.

[Dragonlord]

That would be a nice thing to have but with the current mess we have in the graphics programming landscape it's most probably going to take quite some time until the big players finally consent ( and implement ) a common standard. After all computer science is one of the best examples of how standard-elitism ( mostly done by M$ but also others ) really can kill off any sane development.

About the shader having to compute only one pixel... there's a reason why mipmapping exists in the first place. If you compute exactly one pixel then you end up with "swimming" ( or I think English speaking people call it shivering ). Hence a subtle change in the camera orientation causes a pixel to change the color dramatically. The idea behind mipmapping is to average between neighbor pixels to make such effects vanish. It's a hack but a powerful one in that the logical structure of displays ( pixel grid ) helps to smooth out transitions in a distance. But this requires looking at neighbor pixels in the texture. What you could do in the one-pixel shader would be to sample the function at neighbor points and averaging them but then we are back at the initial problem of an overly complex shader killing speed. Personally I opt for a hybrid solution in which a finite texture is calculated on the fly using the procedural shader and then using this one with conventional mapping techniques. After all games programming showed that the hybrid approaches tend to be the best ones ( although a lot more complex ).

[mitch074]

@Dragonlord: maybe the word you're looking for is shimmering? I'm not really sure, as I am not a native English speaker either.

True, I hadn't considered the problem that, as ray tracing results in a static image, 'making it move' may result in 'dancing pixels'. I had forgotten about this use of mipmapping; in my mind, its main advantage was in reducing resampling errors caused by big textures seen at an angle from a distance.

But then, last time I disabled mipmapping was back in the days of the RivaTNT, and textures weren't big enough to show this effect too much.

[mirv]

The word most commonly used in English for the effect is shimmering.

[Svartalf]

@Dragonlord: maybe the word you're looking for is shimmering? I'm not really sure, as I am not a native English speaker either.


Shimmering is the one most people use for most of the class of problems Dragonlord's referring to...


True, I hadn't considered the problem that, as ray tracing results in a static image, 'making it move' may result in 'dancing pixels'. I had forgotten about this use of mipmapping; in my mind, its main advantage was in reducing resampling errors caused by big textures seen at an angle from a distance.

Some renderings don't "need" mipmapping, but many do to prevent shimmers or bad distortions in the texture's rendering, even in a static scene.

Here is a discussion on part of the problem we're talking about here... (http://www.daylongraphics.com/products/leveller/tut/imagemap/index.htm)

I don't know if you're going to see people use mipmaps in a raytrace engine- mipmaps are more used for rasterization rendering of 3D scenes to do anti-aliasing via averaging of the pixel spaces against the mapping of the texture to the surface at varying distances to make it all look "right". There are other techniques that work as well that are more geared for raytracing (from my recollections on the subject when I was putzing with this sort of stuff on my boxes...) that are more compute intensive than mipmaps, but mesh in nicer with the rendering. But, I'm not doing engine code, so I could be wrong on that. ;)

[Dragonlord]

I could definitely see a use for GPUs to accelerate ray tracing since after all you process there pixels independently. Though keep in mind that a good ray traced scene takes many hours to complete. ;)

[xav1r]

I dont see whats so great about ray-tracing. When youre playing a fast online fps game, or a objective based one, the last thing you worry about is how awesome the light reflects on the different areas of the level. :P

[Svartalf]

I could definitely see a use for GPUs to accelerate ray tracing since after all you process there pixels independently. Though keep in mind that a good ray traced scene takes many hours to complete. ;)

Heh... I know this. I used to DO POV-Ray, Vivid, etc. renderings.

However, that's with none of the tricks one can do to speed things up, or with more modern algorithms. They're doing "good" ray traced scenes in 640x480 at 20-30 FPS with current hardware (This doesn't get into the advanced stuff waiting in the wings...).

While I'm still skeptical right at the moment, what Intel's flogging is certainly possible and viable with what might come out of the next generation. If not in the next 6, certainly within the next 12-18.

[Svartalf]

I dont see whats so great about ray-tracing. When youre playing a fast online fps game, or a objective based one, the last thing you worry about is how awesome the light reflects on the different areas of the level. :P

Heh... It's not so much the ray-tracing itself, but the things they're doing with the eye-candy's so complex that it's entertaining. The stuff we're all talking about requires the same class of muscle to accomplish the framerates you're talking about to do with ray-tracing and the ray-tracing uses simpler and easier to follow algorithms. Moreover, an RTRT engine isn't about photorealism, it's more about doing the same operations that the rasterization engine does with simpler algorithms, lower system resources save the CPU/GPU muscle you're fielding. Photorealism is just the cherry on top.

I'm not saying that we've got it in hand right now, but we ARE close now. Is it this year? Maybe, maybe not. Is it next? Possibly. Is it in 2-3? Probably.