search

cnlohr / noeuclid

Non-euclidean GPU Raytraced Game
BSD 3-Clause "New" or "Revised" License
644 stars 48 forks source link

jump space transformation matrix is relative to origin. #13

Open phiresky opened 9 years ago

phiresky commented 9 years ago

Maybe create a proxy function to allow rotation around center of the jump field.

cnlohr commented 9 years ago

It was unbelievably frustrating to get the jump fields to rotate correctly, to boot (needing a field offset, etc.) But, now that they are working, it is necessary to do it in the C/C++ side of things, so I think a utility function to create the jumps would be super helpful.

phiresky commented 9 years ago

Why was it so complicated? Shouldn't the transformation just be single multiplication of the ray with a matrix?

cnlohr commented 9 years ago

The problem with transformations is that upon entrance of a specific cell, you have to do a transformation. Figuring out the actual offset/position of where that cell should be put out is a pain because it would nominally be different for each cell provided you're not only doing a translation instead of a translation + rotation.

New thought: I wonder how arbitrary the matrix can be and still work - could we have portals that give an isometric view? (how weird would that be?)

cnlohr commented 9 years ago

To be fair, I think as long as it's built on top of the existing system, it should be relatively easy.

phiresky commented 9 years ago

I don't fully understand yet how it works and why it's hard, I just noticed when passing a 3x3 rotation matrix into JumpSpace() it rotates the whole world around (http://youtu.be/nEpnNfgPB6w).

New thought: I wonder how arbitrary the matrix can be and still work - could we have portals that give an isometric view? (how weird would that be?) I think that should be possible, considering that basically all graphics manipulation is usually already done in matrices. Would be pretty weird.

I think the matrix has to be extended to 4x4 to allow for every kind of transformation.

cnlohr commented 9 years ago

That is acceptable. It appears we are truncating the existing 4-wide floats for the Rotxyz, move. Also, there is little need to keep that packed... We should be fine extending the matrix.

It would need to be changed both places in Pass1.frag and Pass1Physics.frag. I have no idea how one could use the bizarre matrix transformations, but I am confident kooky uses could be found.

Also, animating the transform. Brilliant!

phiresky commented 9 years ago

I have no idea what I'm doing

cnlohr commented 9 years ago

O.O Ok... I now understand why we need to be able to have arbitrary matricies instead of jump + rotation.

cnlohr commented 9 years ago

Also, what happens when you walk through?

phiresky commented 9 years ago

I do sometime in the video.. nothing spectacular, looks kinda wrong. Also I had to remove the part where you also apply the matrix to the current ray location for this to work, otherwise it's exits at some other world location.

cnlohr commented 9 years ago

I think you are going to have to use more words to explain the thing that people have never had to explain to one another before. If you are talking about handling if the ray is already in the jumpspace correctly (first texture lookup) that is relatively important -- at least it was. Maybe it's OBE?

phiresky commented 9 years ago

:D I had to change this line: https://github.com/cnlohr/noeuclid/blob/master/Shaders/Pass1.frag#L222 to ptr = ptr + offset;. And I know that can't be a permanent change, because without rotating the position vector too the output plane of rays is parallel to the input plane, and thus when only the output directon is rotated there is distortion.

By the way I moved it into an extra function because you used the same code twice.

cnlohr commented 9 years ago

I just realized, I've been updating your branch most of the time, as per why I didn't see anything new.

Re the matricies: To be fair, I could believe anything that messes with the frustum matrix values (that bottom row) would not be displayable upon a jump. That doesn't mean I wouldn't want to totally mess with it anyway. I guess there are situations where a game designer would want to have something that is displayed that one could not actually jump to. I.e. switching to an orthographic view. Upon a jump, the view would reset.

Second though: Right now we are mixing the quaternions after a jump. I wonder if we could probe more stuff to get 'view' back from the shader, then mix the matricies?

Third thought: That is an awful idea. If you would have to turn around, or upside down, everything would break on the process from "here" to "there."

P.S. I agree with the not a permanent solution. There is a lot of difficulty with handling rotation through jumps, but we have to be careful to maintain it. I am not entirely sure how to fix it at the moment.

cnlohr commented 9 years ago

P.P.S. The current repo still seems to fully work. Impressive. If I were you, I'd have broken things by now considering how seriously you've rearchitected everything.

phiresky commented 9 years ago

I deleted my copy of the repo for now.

Yes I'm also not sure how to fix the Rotation, but I'm sure it's possible.

The current repo still seems to fully work. Impressive.

Well I am pushing to your master, so I can't really break everything can I ;). Also, there are some bugs with the rooms (like door opening/closing) and when skipping levels. Also the automatic file reload doesn't reinit the levels immediately.