Return to Answer

Lets try to reign stuff in a bit. In practical applications we do not deal with infinites. Because that would mean we would need to use some kind of symbolic solver for all of our stuff. We couldnt afford to do this in many practical applications.

Because of these practical considerations i need to have a near and far plane for my camera rasterizer. If i were to make some kind of vector graphics i most likely wouldnt have infinite objects (or atleast deal with this in the scenegraph) and if we would do some sort of tracing we would have hard time deducing intersections near infinity.

Also because of practical considerations, we do not generally * turn the data into 2D coordinates. What we conceptually do is we transform the points so that they seem like something that looks like a perspective projection from a paralell projection in our z direction. We then use this view to build out the data that we need. During this building process we are free to discard any data that we dont need. So think of this like a preliminarry sorting so that i can really do what i intended easily.

Now usually we have acess to both the transformed data and untransformed data so that being terribly concerned about deducing something from the projection, that we can simply read it from the 3D space directly or from our scene graph for that matter, is a priority. But both the z and even the fourth component data could be useful for building my next stage primitives.

Ok so at this point we are done with projecting and now we can start building our output. But this has nothing to do with any of the math you asked so far. The next stages are about triangle barycentric coordinates, shading, intersection finding, depth sorting etc. The math that you have gone trough so far dont really help with this step.

* It is hard to generalize somebody might be doing this but i wouldnt because its a waste of my time.

PS: theres no need to know where wanishing points lie, since the projection stage has solved both ends of the line.

Let's try to reign stuff in a bit. In practical applications, we do not deal with infinites. Because that would mean we would need to use some kind of symbolic solver for all of our stuff. We couldn't afford to do this in many practical applications.

Because of these practical considerations, I need to have a near and far plane for my camera rasterizer. If I were to make some kind of vector graphics I most likely wouldn't have infinite objects (or at least deal with this in the scenegraph) and if we would do some sort of tracing we would have a hard time deducing intersections near infinity.

Also because of practical considerations, we do not generally * turn the data into 2D coordinates. What we conceptually do is transform the points so that they seem like something that looks like a perspective projection from a parallel projection in our z-direction. We then use this view to build out the data that we need. During this building process, we are free to discard any data that we don't need. So think of this as a preliminary sorting so that I can really do what I intended easily.

Now usually we have access to both the transformed data and untransformed data so that being terribly concerned about deducing something from the projection, that we can simply read it from the 3D space directly or from our scene graph for that matter, is a priority. But both the z and even the fourth component data could be useful for building my next stage primitives.

Ok so at this point we are done with projecting and now we can start building our output. But this has nothing to do with any of the math you asked so far. The next stages are about triangle barycentric coordinates, shading, intersection finding, depth sorting, etc. The math that you have gone through so far doesn't really help with this step.

* It is hard to generalize somebody might be doing this but I wouldn't because it's a waste of my time.

PS: there's no need to know where vanishing points lie since the projection stage has solved both ends of the line.

Lets try to reign stuff in a bit. In practical applications we do not deal with infinites. Because that would mean we would need to use some kind of symbolic solver for all of our stuff. We couldnt afford to do this in many practical applications.

Because of these practical considerations i need to have a near and far plane for my camera rasterizer. If i were to make some kind of vector graphics i most likely wouldnt have infinite objects (or atleast deal with this in the scenegraph) and if we would do some sort of tracing we would have hard time deducing intersections near infinity.

Also because of practical considerations, we do not generally * turn the data into 2D coordinates. What we conceptually do is we transform the points so that they seem like something that looks like a perspective projection from a paralell projection in our z direction. We then use this view to build out the data that we need. During this building process we are free to discard any data that we dont need. So think of this like a preliminarry sorting so that i can really do what i intended easily.

Now usually we have acess to both the transformed data and untransformed data so that being terribly concerned about deducing something from the projection, that we can simply read it from the 3D space directly or from our scene graph for that matter, is a priority. But both the z and even the fourth component data could be useful for building my next stage primitives.

Ok so at this point we are done with projecting and now we can start building our output. But this has nothing to do with any of the math you asked so far. The next stages are about triangle barycentric coordinates, shading, intersection finding, depth sorting etc. The math that you have gone trough so far dont really help with this step.

* It is hard to generalize somebody might be doing this but i wouldnt because its a waste of my time.

PS: theres no need to know where wanishing points lie, since the projection stage has solved both ends of my line.

Lets try to reign stuff in a bit. In practical applications we do not deal with infinites. Because that would mean we would need to use some kind of symbolic solver for all of our stuff. We couldnt afford to do this in many practical applications.

Because of these practical considerations i need to have a near and far plane for my camera rasterizer. If i were to make some kind of vector graphics i most likely wouldnt have infinite objects (or atleast deal with this in the scenegraph) and if we would do some sort of tracing we would have hard time deducing intersections near infinity.

Also because of practical considerations, we do not generally * turn the data into 2D coordinates. What we conceptually do is we transform the points so that they seem like something that looks like a perspective projection from a paralell projection in our z direction. We then use this view to build out the data that we need. During this building process we are free to discard any data that we dont need. So think of this like a preliminarry sorting so that i can really do what i intended easily.

Now usually we have acess to both the transformed data and untransformed data so that being terribly concerned about deducing something from the projection, that we can simply read it from the 3D space directly or from our scene graph for that matter, is a priority. But both the z and even the fourth component data could be useful for building my next stage primitives.

Ok so at this point we are done with projecting and now we can start building our output. But this has nothing to do with any of the math you asked so far. The next stages are about triangle barycentric coordinates, shading, intersection finding, depth sorting etc. The math that you have gone trough so far dont really help with this step.

* It is hard to generalize somebody might be doing this but i wouldnt because its a waste of my time.

PS: theres no need to know where wanishing points lie, since the projection stage has solved both ends of the line.

Lets try to reign stuff in a bit. In practical applications we do not deal with infinites. Because that would mean we would need to use some kind of symbolic solver for all of our stuff. We couldnt afford to do this in many practical applications.

Because of these practical considerations i need to have a near and far plane for my camera rasterizer. If i were to make some kind of vector graphics i most likely wouldnt have infinite objects (or atleast deal with this in the scenegraph) and if we would do some sort of tracing we would have hard time deducing intersections near infinity.

Also because of practical considerations, we do not generally * turn the data into 2D coordinates. What we conceptually do is we transform the points so that they seem like something that looks like a perspective projection from a paralell projection in our z direction. We then use this view to build out the data that we need. During this building process we are free to discard any data that we dont need. So think of this like a preliminarry sorting so that i can really do what i intended easily.

Now usually we have acess to both the transformed data and untransformed data so that being terribly concerned about deducing something from the projection, that we can simply read it from the 3D space directly or from our scene graph for that matter, is a priority. But both the z and even the fourth component data could be useful for building my next stage primitives.

Ok so at this point we are done with projecting and now we can start building our output. But this has nothing to do with any of the math you asked so far. The next stages are about triangle barycentric coordinates, shading, intersection finding, depth sorting etc. The math that you have gone trough so far dont really help with this step.

* It is hard to generalize somebody might be doing this but i wouldnt because its a waste of my time.

Lets try to reign stuff in a bit. In practical applications we do not deal with infinites. Because that would mean we would need to use some kind of symbolic solver for all of our stuff. We couldnt afford to do this in many practical applications.

Because of these practical considerations i need to have a near and far plane for my camera rasterizer. If i were to make some kind of vector graphics i most likely wouldnt have infinite objects (or atleast deal with this in the scenegraph) and if we would do some sort of tracing we would have hard time deducing intersections near infinity.

Also because of practical considerations, we do not generally * turn the data into 2D coordinates. What we conceptually do is we transform the points so that they seem like something that looks like a perspective projection from a paralell projection in our z direction. We then use this view to build out the data that we need. During this building process we are free to discard any data that we dont need. So think of this like a preliminarry sorting so that i can really do what i intended easily.

Now usually we have acess to both the transformed data and untransformed data so that being terribly concerned about deducing something from the projection, that we can simply read it from the 3D space directly or from our scene graph for that matter, is a priority. But both the z and even the fourth component data could be useful for building my next stage primitives.

Ok so at this point we are done with projecting and now we can start building our output. But this has nothing to do with any of the math you asked so far. The next stages are about triangle barycentric coordinates, shading, intersection finding, depth sorting etc. The math that you have gone trough so far dont really help with this step.

* It is hard to generalize somebody might be doing this but i wouldnt because its a waste of my time.

PS: theres no need to know where wanishing points lie, since the projection stage has solved both ends of my line.