I’m making a Portal-like game and I have a lot of problems.
But it’s mainly for one problem that I write here : the portals rendering.
I tested many methods like ImageRender with a lot of mathematics and I try now to use ImageMirror, like in this demo.
But…it doesn’t work as well as I want…
I show you a blend file, you’ll certainly see the problem. Controls are made for a azerty keyborad so you have to change it in the init.py script if you want to change them. MouseLeft to fire and MouseRight to change portal color.
I make my tests with the third level, but if you want to try the others, it’s E to catch the ball.
I think you should use ImageRender. It can be used as
VideoTexture.ImageRender(scene,camera)
scene is the scene, camera is a non-active camera.
You need to place the camera at the right position with the right angle, to show you the right view.
I think a sketch could help you. Keep in mind. they must dynamically change the position with the active camera (the player)
Thanks.
It was my first idea. So I made some tests with this method (cf link in my previous post). Here is an old file with ImageRender and not ImageMirror.
This is quiet good, but when you are just before the portal, there is some bugs because of a high angle : the viewport position can not be exactly the same than portal position.
Furthermore, when the portal is on the ground, the camera turns.
Example : http://hostit.warrenberberd.org/dl.php?file=b5c1d18b13816cb470e2b167e91d18d8
The “ImageMirror Technique” requires a texture coordinate flip. This is because of the mirror effect: when you wave your right hand in front of the mirror, the “person in the mirror” appears to be waving his/her left hand.
It’s a very clever technique, and it doesn’t require a camera - the mirror is rendered based on position data, which can be arbitrary, rather than just “the camera”.
However, the implementation in that demo by warwickallison seems very sketchy:
Line 46, 47:
m1.transpose()
m1.invert()
These operations are unnecessary, because both are synonymous in this case, and so the resulting matrix is no different than the original.
There are a lot of other things that I would either take out, or write differently, but I’d rather just play with Psuedoform: http://www.pseudoform.org/
You could add some sensor objects,
or you assign different materials and sense for them.
That I wanted to do was to get the faces which are touching the portal and disable them of physic calculs when the player is in collision with this portal.
So the player should go trough the portal and appear in the other portal without visible transportation. But if it’s impossible with the BGE.
You could also use the object’s rayCast function, which requires Python. You can use that to identify the collided face.
Yes, it’s that I am searching ! But I thunk that this function worked like a RaySensor…
The “ImageMirror Technique” requires a texture coordinate flip. This is because of the mirror effect: when you wave your right hand in front of the mirror, the “person in the mirror” appears to be waving his/her left hand.
It’s a very clever technique, and it doesn’t require a camera - the mirror is rendered based on position data, which can be arbitrary, rather than just “the camera”.
Yes, I know that…
These operations are unnecessary, because both are synonymous in this case, and so the resulting matrix is no different than the original.
I don’t think so…The transposition and the inversion are different. The first one isn’t needed in 2.5 because the rotation matrix system is different, is tre transposition of the 2.49 rotation matrix system. But the second is needed because it do the invert action of th m1 original matrix. The goal is to get the camera position (or another object), and it coordinates relatives to the first portal (newmatrix = matrixportal1_mat), then pass these coordinates in the global base again but from the second portal (matrix = newmatrixinverted_portal2_mat)…(I don’t think I’m clear in my explaination…)
And have you seen my second blend ? I use ImageRender with cameras parented to portals, but it doesn’t work very well…
Newest blend :
They are different operations, but they produce the same results for all orthogonal transformations, hence my claim that they are synonymous in this case.
And again, I’m talking about the original demo by warwickallison: if you don’t believe me, just comment out those two lines, and you’ll see that the demo still works just fine.
As for your demo: I didn’t look at it - but I’m guessing that it’s a 15 MB mess, and I just don’t have the time to go through that.
You should try to follow the warwickallison demo until you get identical results -> you should be able to do that on your own, if you really understand what you’re doing.
You can just make the mirror a sensor object. With that any other object can just step through the mirror.
You might want to doublicate the “portaling” object. One goes in one mirror one comes out of the mirror.
After the first one completly crosses the mirror you can end it. It shouldn’t be visible anymore.
You can just make the mirror a sensor object. With that any other object can just step through the mirror.
You might want to doublicate the “portaling” object. One goes in one mirror one comes out of the mirror.
After the first one completly crosses the mirror you can end it. It shouldn’t be visible anymore.
It’s already a sensor object. But there is a wall behind the portal so objects can go trough the portal because of this wall. hat’s why I want to make this wall temporarly inactive in physic calculation. But not all the wall, just the wall where the portal is.
Warwick use boxes behind his portals but it’s not my goal…
As for your demo: I didn’t look at it - but I’m guessing that it’s a 15 MB mess, and I just don’t have the time to go through that.
They are different operations, but they produce the same results for all orthogonal transformations, hence my claim that they are synonymous in this case.
I though understand these transformations, but if in this case they are not the same, I don’t understand them…
You should try to follow the warwickallison demo until you get identical results -> you should be able to do that on your own, if you really understand what you’re doing.
It works, but only with one object because when I add some dynamic object, it pass through the ground when the cube go into the portal.
And is there a way to make the room ghost only for an instant thanks to Python ? I don’t think so after reading the doc, so I made maneuvering thanks to two objects : one for rendering and one for physic calculation which is set to scaling=[0,0,0] or [1,1,1]. But I don’t like this solution…
And I would like to make the room ghost only for the object in the portal, and not ghost for the other objects. Is it possible ?
