How can it be done?
I'm trying to think of new ways to render 3D that needs to be as fast as possible.
Getting 3D coords to screenspace without matrix transforms.
Are you talking about theory, or practice?
Theory-wise, matrices represent linear transformations. 3D Perspective projection and orthographic trasnformation are both linear transformations in four dimensions. If you are asking for a simpler theory, you are looking for a 3D->2D mapping that is a simpler operation than a linear one. I'm quite confident that doesn't exist.
Practice-wise, the only complaint one can have with matrices is that if you have a matrix that has lots of zeroes or ones, you are doing redundant multiplications that could easily be optimized by hand if you did the transformation manually. (With generic 4x4 homogeneous transforms, you could be doing a redundant homogeneous divide per transform as well!) With GPUs and vectorized instruction sets this hardly a problem since they have dedicated instructions for the task. If you are looking to optimize this part, it is as simple as taking a pen and paper, and multiplying out the perspective projection matrix with your vector, and canceling out all the useless terms there. What remains are the "essential" operations that need to be done, and you can craft manual expressions that perform the projection, instead of doing the Matrix*Vector multiply.
If my reply was off, please try to be more specific what you are looking for?
Theory-wise, matrices represent linear transformations. 3D Perspective projection and orthographic trasnformation are both linear transformations in four dimensions. If you are asking for a simpler theory, you are looking for a 3D->2D mapping that is a simpler operation than a linear one. I'm quite confident that doesn't exist.
Practice-wise, the only complaint one can have with matrices is that if you have a matrix that has lots of zeroes or ones, you are doing redundant multiplications that could easily be optimized by hand if you did the transformation manually. (With generic 4x4 homogeneous transforms, you could be doing a redundant homogeneous divide per transform as well!) With GPUs and vectorized instruction sets this hardly a problem since they have dedicated instructions for the task. If you are looking to optimize this part, it is as simple as taking a pen and paper, and multiplying out the perspective projection matrix with your vector, and canceling out all the useless terms there. What remains are the "essential" operations that need to be done, and you can craft manual expressions that perform the projection, instead of doing the Matrix*Vector multiply.
If my reply was off, please try to be more specific what you are looking for?
Author
I'm talking about theory, thinking of ways that haven't been done, or at least aren't widely known.
Thanks for the reply.
Thanks for the reply.
It's not possible to just 'render faster' in the general case. This mathematics for 3d rendering have been developed by decades by very smart people, some guys on a game forum aren't just going to invent a new way to do it that is any faster.
Now if you can be more specific there may be optimizations you can do to your restricted case. If you can add constraints to the equation you may be able to optimize, but you can't shortcut the transformation process unless you're willing to give up something. I don't know what that might be in your case.
Now if you can be more specific there may be optimizations you can do to your restricted case. If you can add constraints to the equation you may be able to optimize, but you can't shortcut the transformation process unless you're willing to give up something. I don't know what that might be in your case.
As a practical matter, 3D graphics are executed on graphics cards whose hardware is specifically designed do matrix transformations fast. Obviously, doing not-matrix-transformations on hardware optimized for matrix transformations will almost certainly be slower [smile]
But that said, computer scientists haven't all just been using matrices to represent coordinate transformations by some weird accident. It's actually a pretty fast way to do things.
What specifically do you find slow about matrices? Is it just that you don't understand the math?
-me
But that said, computer scientists haven't all just been using matrices to represent coordinate transformations by some weird accident. It's actually a pretty fast way to do things.
What specifically do you find slow about matrices? Is it just that you don't understand the math?
-me
Author
Quote:Original post by karwosts
It's not possible to just 'render faster' in the general case. This mathematics for 3d rendering have been developed by decades by very smart people, some guys on a game forum aren't just going to invent a new way to do it that is any faster.
Now if you can be more specific there may be optimizations you can do to your restricted case. If you can add constraints to the equation you may be able to optimize, but you can't shortcut the transformation process unless you're willing to give up something. I don't know what that might be in your case.
Are you saying there's no smart people in game development?
I guess to be more specific, I want to speed up transformation. Or maybe even do without it? Come up with a way to map 3D-2D like clb said? Something like that.
Author
Quote:Original post by Palidine
As a practical matter, 3D graphics are executed on graphics cards whose hardware is specifically designed do matrix transformations fast. Obviously, doing not-matrix-transformations on hardware optimized for matrix transformations will almost certainly be slower [smile]
But that said, computer scientists haven't all just been using matrices to represent coordinate transformations by some weird accident. It's actually a pretty fast way to do things.
What specifically do you find slow about matrices? Is it just that you don't understand the math?
-me
That's pretty much my point, I want a faster way to find 3D coordinates on the CPU because they aren't designed to do matrix transforms fast like a GPU.
I played around very briefly with some software rendering stuff before there was such thing as 3d vid cards and opengl/directx (as im sure lots of people here did)
How i converted from 3d points to screen space was just this...
xScreen = xWorld / zWorld;
yScreen = yWorld / zWorld;
It worked just fine. Less math than doing matrix transforms but of course it isn't as powerful.
If you wanted rendering to be even faster, you might be able to do this:
xScreen = xWorld * zWorld;
yScreen = yWorld * zWorld;
and just make objects store their z coordinate as 1/z so you could turn the division into a multiplication during rendering. It would speed up your rendering, but whenever you moved an object it would take more time. If you have a lot of static objects it may be worth while.
If going this route, i'd say get it working with the first equation first before trying to get fancy.
Also, after you get your xScreen and yScreen you can do something like this to get a poor man's fov setting:
xScreen *= xFactor;
yScreen *= yFactor;
Hope this helps!
PS: If using the above equations, you probably will need to add half the screen width and half the screen height to the xScreen and yScreen so that the origin/vanishing point is in the center of the screen like you would expect instead of the upper left corner (which is the traditional 2d origin)
How i converted from 3d points to screen space was just this...
xScreen = xWorld / zWorld;
yScreen = yWorld / zWorld;
It worked just fine. Less math than doing matrix transforms but of course it isn't as powerful.
If you wanted rendering to be even faster, you might be able to do this:
xScreen = xWorld * zWorld;
yScreen = yWorld * zWorld;
and just make objects store their z coordinate as 1/z so you could turn the division into a multiplication during rendering. It would speed up your rendering, but whenever you moved an object it would take more time. If you have a lot of static objects it may be worth while.
If going this route, i'd say get it working with the first equation first before trying to get fancy.
Also, after you get your xScreen and yScreen you can do something like this to get a poor man's fov setting:
xScreen *= xFactor;
yScreen *= yFactor;
Hope this helps!
PS: If using the above equations, you probably will need to add half the screen width and half the screen height to the xScreen and yScreen so that the origin/vanishing point is in the center of the screen like you would expect instead of the upper left corner (which is the traditional 2d origin)
Author
Quote:Original post by Atrix256
I played around very briefly with some software rendering stuff before there was such thing as 3d vid cards and opengl/directx (as im sure lots of people here did)
How i converted from 3d points to screen space was just this...
xScreen = xWorld / zWorld;
yScreen = yWorld / zWorld;
It worked just fine. Less math than doing matrix transforms but of course it isn't as powerful.
If you wanted rendering to be even faster, you might be able to do this:
xScreen = xWorld * zWorld;
yScreen = yWorld * zWorld;
and just make objects store their z coordinate as 1/z so you could turn the division into a multiplication during rendering. It would speed up your rendering, but whenever you moved an object it would take more time. If you have a lot of static objects it may be worth while.
If going this route, i'd say get it working with the first equation first before trying to get fancy.
Also, after you get your xScreen and yScreen you can do something like this to get a poor man's fov setting:
xScreen *= xFactor;
yScreen *= yFactor;
Hope this helps!
Thanks, this is the kind of stuff I'm looking for.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
