Quote:Original post by Butabee

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 is exactly what the matrices are doing. They are just a compact representation of a series of formulas (Object to world scaling, rotation, transformation, world to view transformation, rotation, projection).

And
x' = c * x / z;
y' = c * y / z;
is exactly what the projection part of the projection matrix is doing. And it's doing even more (far / near clipping planes, aspect ratio)

I guess you got tired of my asking what you were really trying to do, huh? :) You could have just posted to your existing thread, you know - it's allowed ;)

I think it's worth noting that you got a similar response here:

Quote:Original post by clb
If my reply was off, please try to be more specific what you are looking for?

Quote:Original post by karwosts
Now if you can be more specific there may be optimizations you can do to your restricted case.

Which suggests that the responses you got in your original thread maybe weren't that out of line after all.

Quote:Original post by Butabee
Are you saying there's no smart people in game development?

What's being said is that smart people have been working on these problems for decades, so it's unlikely that some random person on this forum or any similar forum, no matter how smart, is just going to suddenly come up with a radical new way of rendering things that's more efficient/powerful/whatever than existing methods. It's not that innovation never occurs, since it obviously does; it's just kind of unlikely that some random person who's not already at the forefront of ongoing research is going to be the one to do it. (Or so I would guess.)

As for what you're wanting to do, sure, you can eliminate redundant or unnecessary computations in some special circumstances. But, keep in mind that in order for it to be a win performance-wise, you have to be able to perform your 'fewer computations' faster than specialized hardware can perform the 'usual amount' of computations. So don't just assume that you're going to be able to perform a few divisions here and there and suddenly have a groundbreaking new renderer; you'll need to compare your results carefully against similar results derived using conventional techniques to see if you're actually getting anywhere.

Quote:Original post by Hodgman
Whenever you want to speed up a specific type of matrix transformation, take a copy of your matrix-multiply function, then determine which variables (cells of the matrix/vector) are going to be constants (like 0 or 1) and factor them out of the equation.

i.e. A general matrix/vector multiplication, performed on a perspective-matrix and a position-vector will include a lot of "+0" and "*1" operations. If you strip these out, you've discovered the actual operation that the matrix multiply is performing. Then take this operation and write it optimally.

For what it's worth, clb actually gave this exact same answer earlier in the thread (first reply to the original post).

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;

I think this only holds true if your camera is effectively at the center of the world -- 0, 0, 0?

Quote:Original post by Hodgman
oops teal deer ;'(

Hehe...I had to Google 'teal deer'. Hadn't seen that one before :)