Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.
Posted 03 September 2012 - 12:35 AM
Posted 03 September 2012 - 12:50 AM
Actually, if you want to produce an image without aliasing, you need to evaluate multiple geometry samples per pixel.-detail on a per-pixel level (naturally because you can't have more than that!)
This is called ray-tracing - computerized versions of the idea were described in the 60's and has been researched to the current day.You start by cycling through each pixel on the screen. For each pixel [x, y] you find the point in 3D space that lies within the near clipping plane and matches the pixel's coordinates when projected into 2D. We will call this point "a".
Now you can find the 3D point on the far clipping plane that corresponds to the 2D pixel you are on. We will call this point "b".
Now draw a line from a to b and you pass through all points in the frustum that match the 2D pixel.
Somewhere along this line segment is the 3D point you need for calculating the current pixel.
This form of rendering doesn't [have to] use triangles or any sort of polygons at all ... there would be no poly budget or any problems with creating curves
The key to fast ray-tracing is using a very fast method for determining the "which piece of geometry does this ray collide with" question.In theory this would mean the rendering would take roughly the same amount of time regardless of your view point or how many objects you are rendering.
Edited by Hodgman, 03 September 2012 - 12:56 AM.
Posted 03 September 2012 - 12:51 AM
Posted 03 September 2012 - 02:12 AM
To expand on this, the speed of traditional ray-tracing is dependent on screen resolution by a linear factor (increase render width by two, work needed increased by two) by definition and the relationship to scene complexity depends on the underlying acceleration structure used to make collision tests faster. Existing algorithms (octrees, kd-trees, BVH's) have brought down this cost to O(log(n)) in the number of primitives in the scene, and that's the best you can do in the general case. Thought you also have to take into account how efficient it is to *create* the acceleration structure, which is often not a concern for static scenes provided it is reasonable, but is a problem when you have dynamic objects.The key to fast ray-tracing is using a very fast method for determining the "which piece of geometry does this ray collide with" question.
The above quote is assuming that your ray-collision algorithm is not all all affected by the amount of objects in the scene or visible to the camera (that is to say, collision has O(1) complexity with regards to scene size). This is usually not the case, although the snake-oil salesmen at "Unlimited Detail" do make such a claim.
Edited by Bacterius, 03 September 2012 - 02:21 AM.
“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”
Posted 03 September 2012 - 07:53 AM
Edited by spacerat, 03 September 2012 - 08:07 AM.
Posted 03 September 2012 - 11:13 AM
I don't see how this will be a problem. It will find an intersection with accuracy equal to how many times you want to repeat the intersection finding process.Actually, if you want to produce an image without aliasing, you need to evaluate multiple geometry samples per pixel.
e.g. if the edge of some geometry cut a 2D line through a pixel's bounding box, so that only 40% of the pixel is filled with that geometry, then to produce a correct image you need to find out which geometry fills the other 60% of the pixel.
I was thinking of the time it takes to find a collision being equal to the time it would take to to march from point a to point b in the smallest interval you allow it to use. But now that I think about it, if you add objects in the scene, you have to check each object per ray movement, so it would add up time. But without any objects and just rendering a height field, wouldn't there be a maximum time it could take per pixel?The above quote is assuming that your ray-collision algorithm is not all all affected by the amount of objects in the scene or visible to the camera
Edited by frobot, 03 September 2012 - 11:18 AM.
Posted 03 September 2012 - 01:06 PM
I don't see how this will be a problem. It will find an intersection with accuracy equal to how many times you want to repeat the intersection finding process.
And yes I know what ray tracing is, just not a whole lot about it. I usually hear it described as just moving in a fixed step from a to b looking for a ray-polygon intersection, so I assumed what I described was different.
Posted 03 September 2012 - 06:44 PM
The "lost precision" is the difference between this and this. And that's just the two-dimensional case. Consider it in three dimensions, especially with perspective projection which means objects far away will need more samples by definition since you see more of the scene per pixel. Have you ever played vanilla minecraft? Move the mouse one pixel to the left, and the whole screen seems to jitter randomly, because at a distance, much more than one texel (texture pixel) of information is condensed into a single pixel, and depending on the view angle, any one texel is chosen randomly, which produces a weird color soup which is very straining on the eyes - that's what the lack of multisampling results in. If you used multisampling, you could weigh each texel according to its contribution to the pixel's color, and produce a correct pixel color which will not change just by looking at it from a slightly different angle. It adds stability to the render.If a pixel is made 75% of one information source and 25% another, it would usually just use the 75%
You just lose some precision
Edited by Bacterius, 03 September 2012 - 06:48 PM.
“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”
Posted 05 September 2012 - 11:16 AM
Posted 06 September 2012 - 02:51 AM
Edited by CryZe, 06 September 2012 - 03:02 AM.
Posted 11 September 2012 - 06:52 PM
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.
GameDev.net™, the GameDev.net logo, and GDNet™ are trademarks of GameDev.net, LLC.