The never ending story. We have lots of processing power and lots of memory and the bottle neck is the "slow" data connections on the circuit boards compared to data buses inside the chips.

I'm not an expert in voxels, which means i haven't done any software involving them, but my experience with polygons is that transforming polygons is not a problem for data bandwidth but texturizing and calculating all the effects which results in lots of memory access unless you have a tile based renderer or big on chip memory.

As far as i know, voxels don't need any textures as they are some kind of 3 dimensional textures themselves so i guess data bandwidth becomes a problem with the amount of voxels used per object.

Might be a good idea to implement some technology that can round objects like bilinear filtering does with textures but in 3d or scales up the voxel count in real time resulting in less strain on the memory buses and giving a smaller memory footprint.

I'm glad you did. Otherwise i would have had less to say...



Best and most obvious example for this should be graphics card drivers.
The standard advice for coping with problems is to de-install them use a cleaner and install new ones. Result: Doesn't work since problem is hidden under the hood.
Modern day drivers have to cope with billions of possible systems and situations resulting in programmers wrecking their nerves and users thrashing their PCs.

But the "casual" user is already used :wink_smile: to re-install the complete OS if something fails since he is not capable of using the provided tools for repairing/servicing.
Dos on the other hand was so simple, it was (almost) impossible to destroy by user actions except for typing "format c:" but it needed some higher knowledge to use it.

Wikipedia is made by humans. Humans sometimes fail. :wink_smile:
But the article in it's entirety describes the problem quite well.

Why am I not surprised that that poster, of all people, would home in on something completely irrelevant to the main point, and completely ignore the main point as a result.

Carmack has already announced the next patch will include some sort of interpolation method for improving the low resolution textures in Rage, but such things are band aids compared to the plastic surgery you are proposing. I suspect by the time anyone could develop something like that it would no longer be necessary.

What problem? This is pure Luddite ignorance. Any fool can put up a wiki.

The game is written to the xbox 360. A weak and out of date machine compared to any recent PC. It's then compiled for PC, pretty simple and PS3, not so simple. Because it's written to run on consoles your statement makes no sense at all.

I have a gaming machine. Rage does not stress it at all. In fact if I force large textures the game will lag out with out stressing my machine. This is because the console code cannot use all my machines capabilities. Because it was written for a console. Without AFR, Alternate Frame Rendering, there will be no SLI, again because it was written to a console.

The console it was written to is an order of magnitude weaker than my machine. Your statement makes no sense at all.

Bull. You're either lying or you have no idea what you're talking about.

Rage on PC uses OpenGL.
Rage on 360 uses D3D/XNA.

You can't just take a bunch of 360 code and recompile it for the PC under those circumstances; it's a completely different rendering API that needs completely different code.

You want another example? Take input. The only way to properly program the 360 controller is by using XInput. XInput cannot be used for PC keyboard/mouse input; Rage on PC uses Raw Input instead.

Final nail in the coffin.
Support for 8192x8192 textures only came in fairly recently. Even support for 4096x4096 textures is quite recent. Older hardware that does not support these texture sizes, no matter how powerful it may be in other respects, is incapable of running Rage. I haven't even touched on shader complexity (older hardware has a max number of shader instructions), video RAM usage (8192x8192 textures in Rage can require 1gb of video RAM), or any other relevant hardware capabilities.

The 360 lets you write to texture memory directly. With a PC you've got to either use glTexSubImage2D (OpenGL, optionally with a PBO) or IDirect3DTexture9::LockRect (D3D9, 10 or 11 are different). That's the key PC bottleneck with Rage - uploading texture data from system memory to video memory. Not a problem on a console, very CPU and bandwidth intensive on the PC, and can lead to CPU/GPU syncing. That's not evidence that the game was written for a console, that's a problem that id games as far back as the original Quake suffered from (Quake used it for updating dynamic lightmaps). Was Quake written for consoles?

Megatexture isn't new or exciting or dangerous technology. It's direct ancestor is software Quake's surface cache - a PC game from 1996. ETQW used it. The Rendition port of Quake used it (1996 again). Were these written for consoles?

If Rage was primarily written for the 360 and was a quick and dirty port to PC, it would have used D3D instead of OpenGL. It doesn't use D3D, therefore it's not a quick and dirty port.

If you want to prove a point so badly, at least stick to the truth when doing so.

Plastic surgery? Sounds like a modelling artist speaking. :hubbahubba:

I was thinking about scaling the voxel count to match the pixels of screen resolution to prevent this blocky lego like visuals and not about altering shape or form by adding or subtracting voxels.
This is one of the biggest problems we already have with polygons: We waste a ridiculous amount of polygons and texels per screen pixel with objects far away from the camera viewpoint for absolutely nothing since everything is crunched into a single pixel of a frame.
In fact, we also need lots of additional bandwidth for anti aliasing and anisotropic filtering to get rid of the artifacts as a result of this unoptimized type of rendering.
If we would be able to scale the amount of voxels of an object to match exactly the amount of pixels of the part of the screen it is rendered to, we wouldn't need any kind of filtering.
At least not at higher resolutions.

I guess this post reveals you not being a software programmer.
The article describes the common problems software architects face when assuming what a program has to deliver in it's environment.

Modern software is way more complex than just printing "hello world" onto the screen.
In fact, i completely lost track of the amount of lines of code in my own D3D engine which is able to fully matrix transform and rotate in every imaginable way, scale, enlight, texturize and move polygon models with a completely free camera system including frustum culling and additional particle support + physics. I have yet to implement support for decent shadowing.
And these are very few abilities compared to what a modern blockbuster game has to do.

Most of the c functions used for my engine are D3D9 exclusive and would have to be completely rewritten when ported to another library or hardware.

Porting a game like Rage from one hardware to another involves heavy rewriting of code, often even alterations to the logical steps of the rendering pipeline to fit the needs of the target platform.
So calling Rage a game written for the Xbox and than ported is just wrong.
Porting a software from one hardware to another involves way more adjustments than just changing the compiler.

The reason for Rage not being better or sometimes even running badly on PC is not that it is also available on consoles.
This typical PC user myth is often brought up by pc guys trying to justify the large amount of money and electrical power they put into their machines wich fail to efficiently make use of their resources. In fact, the PC is the worst imaginable architecture for optimizing software as it is the most flexible.
PCs sold so well over the years because they can be easily tuned to users needs and not because they are well optimized high end hardware.

You could compare a console to a Porsche 911 and the PC to a bus.
Both have similar horsepower yet the Porsche is more efficiently using it's power to make it go fast where the bus is able to be used not only for driving fast but also for transportation of persons and objects which wouldn't fit into the Porsche.

Flexibility always results in loss of efficiency.

Not sure what you're proposing. Anti-aliasing is used because of the limited resolution of monitors. Its a pointless filter if you have something like the new "retina displays" coming out because the human eye simply can't distinguish individual pixels on them. That's a hardware limitation and not a software problem. Unfortunately you'd need something like 4,000+ resolution for a desktop monitor to do away with AA and that would cripple the computer to compute all those pixels. The whole point of AA is to produce a compromise for lower resolution displays and if your display has a high enough resolution you can just turn it off.

This is the wisest judgement of RAGE's difference from other games that I've heard.

Also, I'm glad that this thread has sparked a fairly mature discussion about graphics.

May i recite the last two sentences of my post with putting an emphasis on sentence No. 2:
"If we would be able to scale the amount of voxels of an object to match exactly the amount of pixels of the part of the screen it is rendered to, we wouldn't need any kind of filtering.
At least not at higher resolutions."

So we have the same view towards the purpose of AA. :icecream:
Nevertheless, fullscreen AA (not Edge- AA!) can also smoothen up some texture related artifacts by filtering the complete screen.
Not as effective as anisotropic filtering used on the texture itself but using all methods at once usually gives the best results. And the lowest framerate... :whistling:

What i was talking about primarily is the effect you get when you draw textured polygons into the framebuffer at certain angles or distances to the camera which results in the texture resolution being actually higher than the pixels that are available at the position of the screen at the chosen video resolution resulting in flickering pixels and jaggies inside the portrayed texture.
The usual solution is to use mip maps to reduce texture resolution of objects farther away from the camera to avoid mentioned problem. To enhance visual sharpness and get rid of the visible lines between two mip maps, you use trilinear and anisotropic filtering which kills most artifacts that come with it.
That means we have to at least apply three additional (bandwidth heavy) filtering methods to reduce artifacts related to the usage of static textures.

It is easy to scale the amount of polygons in a mesh related to it's distance to the camera but it is impossible to (down)scale the amount of pixels in a texture related to camera distance without destroying it's content.
If you have an untextured object built out of voxels, it should be possible to scale the amount of voxels WITHOUT immediately destroying it's looks making any additional filtering usually applied to textures completely obsolete. Texture related operations are by far the most bandwidth heavy operations in modern rendering processes.

Btw.: I turned 40 this year and my eyes degrade quickly resulting in AA already being applied inside my eyeballs in realtime. :biggrin:

bump 4 great commentors

It went a little bit off topic in the end... :whistling:

But a forum about an ID game should be the best place for talking technical rubbish after all. :celebration: