Feature Request:: Move the 'centre' of viewports
Blitz3D Forums/Blitz3D Programming/Feature Request:: Move the 'centre' of viewports
| ||
| I've mentioned this before but I've just come across another place where my game could be improved if I could make where the camera looks offset from the centre of the viewport. A simple bodge would be to allow viewports bigger than the screen or at least let them clip off the edges. In my game, overlaid icons effectively move the centre of the view to a different spot than the actual centre of the screen. The only way I can fix this currently is have my icons in a panel and reduce the main viewport. This doesn't look as nice. Is this possible? |
| ||
| I don't really understand your request, but I feel it can be worked around. Could you elaborate? Have you tried two cameraviewports and multiple renders? |
| ||
| The camera looks at the middle of a viewport. I need it to look elsewhere. Two viewports will not acheive that. I'd have the camera looking at 2 different points instead of one. I don't think there is a workaround for this. |
| ||
| You're not describing the problem very well... I can't understand what you're aking for. "In my game, overlaid icons effectively move the centre of the view to a different spot than the actual centre of the screen." What the heck is that supposed to mean? I haven't got a clue. The only thing I can think of is that you want to move the vanishing point to some location other than the center of the screen. But I can't for the life of me figure out why you would want to do that. I wanted to do that myself at one time, but that was for a trick to speed up rendering. If that is what you want, then what you really need is the ability to render to a viewport larger than the screen, and the ability to render only a certain section of that viewport. So it would be like a viewport within a viewport. Then if you wanted to, you could render each corner of the screen seperately and they would fit together right, or you could specify the viewport is 2x larger than norma, but only render what is on the screen and thus the vanishing point would be in the lower right corner... it would in essence be a magnified view of what would normally be in the top left corner of the screen. But I still can't understand your whole icon description. Doesn't make sense to me. And maybe it would be a simpler implementation to just allow you to move the vanishing point rather than specfiying a viewport within a viewport. |
| ||
| The bottom third of my screen has a lot of icons. Where the camera 'looks' is in the middle of the screen. This means a 'featured' object in my game appears very close to where the icons are. I'd like this centre point (vanishing point yes) to be about 1/3rd from the top of the screen. If I make my main viewport just cover the top 2 thirds of the screen and reserve the bottom 1/3 for a panel then I get what I need functionally but it doesn't look nice. I want the main view to carry on under the icons. This is actually just one example in my game where I need this. |
| ||
| If the camera is pointing down the Z axis. Surely if you change it's Y component down then is should effectively move you object up. |
| ||
| I need the vanishing point to be off centre. I'm not sure if that's the correct term. If you have a sphere (for example) in your world and pointentity camera,sphere. That sphere will be exactly in the centre of the viewport. I need to change it so I can position the 'look at' point anywhere. |
| ||
| Uhhhhh, move the camera? |
| ||
| John, Some screenshots could be useful. |
| ||
| Moving the camera doesn't move the vanishing point from the centre of the screen... I've no idea if this is possible, though. I can't remember seeing this effect in anything else (although admittedly I can't quite picture what it would look like!)... |
| ||
| Blitz: Imagine taking the top half of the screen, and move it to the bottom. Then imagine that you can see stuff above the top of the screen. That is what it would look like. I still can't see why John would want to do this. You certainly would not want to walk about the world with this sort of camera view. The horizon would be near the bottom of the screen, and the top of the screen would show the sky almost directly overhead like a fish-eye lens. |
| ||
Will this help?:Const DEBUGON = True Const scrnw = 640, scrnh = 480 Const halfw = scrnw/2, halfh = scrnh/2 Const CURSUP = 200, CURSDOWN = 208, CURSLEFT = 203, CURSRIGHT = 205 Const WKEY = 17, AKEY = 30, SKEY = 31, DKEY = 32, GKEY = 34 Graphics3D scrnw,scrnh SetBuffer BackBuffer() Global campiv = CreatePivot() Global cam = CreateCamera (campiv) CameraViewport cam,0,0,640,280 cam2 = CreateCamera(cam) CameraViewport cam2,0,280,640,199 TurnEntity cam2,42,0,0 for f = 0 to 1000 cube = createcube() PositionEntity cube,(rand(100)-50)*4,(rand(100)-50)*4,(rand(100)-50)*4 EntityColor cube,Rand(255),Rand(255),Rand(255) Next SetBuffer BackBuffer() While Not KeyDown(1) elapsed = MilliSecs() UpdateWorld Flip False RenderWorld frames=frames+1: Text 5,5, fpscount: If MilliSecs()-render_time=>1000 Then fpscount = frames: frames = 0: render_time = MilliSecs() mouselook Delay 7-(MilliSecs()-elapsed) Wend End Function mouselook(mult#=0.3) mys = MouseYSpeed() If Abs(EntityPitch(cam)+mys) < 75 ; restrict pitch of camera TurnEntity cam, mys,0,0 EndIf mxs = MouseXSpeed() ; TurnEntity sky,0,mxs,0 TurnEntity campiv, 0,-mxs-(KeyDown(CURSRIGHT)*mult)+(KeyDown(CURSLEFT)*mult),0 MoveEntity campiv, (KeyDown(DKEY)-KeyDown(AKEY))*2.0*mult ,0,(KeyDown(WKEY)-KeyDown(SKEY))*1.5*mult MoveEntity campiv, 0,0,(KeyDown(CURSUP)-KeyDown(CURSDOWN))*0.5*mult MoveMouse 320,240 ; centre mouse cursor End Function |
| ||
| Sswift, No there's no fisheye or funny effects. Imagine if on a 1024,768 screen I set the viewport to: cameraviewport camera, 0,-256,1024,1024 The top portion of the image would be clipped off screen. The remaining image is EXACTLY what I want to see. The centre of the image would be 512 pixels from the left and 256 pixels from the top of the screen. |
| ||
| Look up ^^^. |
| ||
It would look something like this: |
| ||
| masterbreaker. Not sure what that code does (i get some cubes rotating as I move the mouse). I don't think what I want can be achieved in Blitz at the moment. |
| ||
| Wait... so you want the horizon to be near the top of the screen? Thatw ould be the reverse of the effect I just showed... with a lot of grass at the bottom instead. |
| ||
| Try it with something more sensible, a level or model or something. |
| ||
| I see what you mean swwift. Yes. Imagine you have a lot of icons in the top third of that image. The sky just serves as a nice backdrop to the icons while the main gameplay really occurs in the bottom 2 thirds which looks quite normal. That's what I want. |
| ||
| Yes, sswift. I want the reverse of that. |
| ||
| My code has done it upside down, I assumed you wanted icons at the bottom. Easy to reverse tho. |
| ||
| So I think I see what you are saying you want to do now. You want to have icons at the bottom of the screen. Now normally, that would cover the ground. And if the icons were half the height of the screen they would come up to the center of the player's view... the horizon. What you want to do is move the horizon upwards, so that it is like you are using a viewport that is just in the top half of the screen, but you want the bottom half of the screen to show the ground at the player's feet.. something that would be outside the normal viewport. Can you do this in Blitz currently? I don't think so. |
| ||
| MasteR: He did want the icons at the bottom. |
| ||
| Yes, that's exactly what I want sswift. Sorry it's hard to explain. I know it can't be done which is why I'm feature requesting. I COULD possibly do it by chopping a rendered image up. But I can't render to a buffer bigger than the backbuffer so that's not too practical. |
| ||
| My game isn't first person BTW. It's more a RTS view so the effects wouldn't be so extreme. |
| ||
| Well maybe if you render two screens, one with the camera rotated 90 degrees down, then you could copy the bottom 2/3rds of the first, and the top 1/3rd of the second, and then paste those over the backbuffer before you flip. That might do it. That's like rendering a skybox. But it might not be very fast. |
| ||
| I don't think that would work. It *might* joing up (like those panoramic pictures people take with lots of shots stuck together) but the perspective will be broken. That could be a cool idea for a special effect. |
| ||
| That is exactly what my code does above. Shame you dismissed it out of hand. I was merely offering a working solution using the tools we have, but what do I get? not even a thanks for trying. |
| ||
| I haven't dismissed it. I can't see what it does and you haven't explained how it works. I don't think what I want it is possible in Blitz. |
| ||
| I had alredy searched for a way to do that in blitz, with no luck. AFAIK there is *no* way to do it in blitz, which is really too bad. By example without it you can't do perspectively correct flat mirrors (except by using cube mapping, but 6 textures when you need just one...) The only way I can see right now to do it would be to hack blitz to access the transformation matrix...Probably better not to rely on that. |
| ||
| I said: try it with something sensible like a level or model. It creates a split view as described by sswift above: "Well maybe if you render two screens, one with the camera rotated 90 degrees down" - give or take. I was thinking that the edge and extremity of the effect might be masked if the lower portion is behind icons and the harsh edge is masked by the edge of the icons themselves. |
| ||
| I can only see one renderworld() in your code. How does it create a split view? |
| ||
| You only need one as long you don't hide/show any cameras and they aren't covering each other completly. |
| ||
| I see, two cameras. No that won't work for me. It doesn't even join properly in your example. |
| ||
| Could you just not set the cameraviewport to the size of your screen minus the height of your icons? (This is what Master Beakers code does) Or are your icons drawn in the 3D scene? |
| ||
| Big&, Yes. But I want the image to continue under the icons. |
| ||
| TurnEntity cam2,50,0,0 works better, but it will never be perfect. Can't say I didn't try. Maybe I can I interest you in a Blitz portal system? :) |
| ||
| Cheers Masterbeaker, much appreciated. Now can everyone jump up and down and wave? Perhaps Mark will notice this thread and implement this crucial, groundbraking feature. |
| ||
| You know as well as I do that its about as likely as winning the lottery, but good luck to ya. . |
| ||
| Jumping. Waving. I need it in order to do tileable renders, that I assemble to hi res images, used in print. |
| ||
| I think this is doable but requires the camera projection matrix to be offset, that is, if blitz has one. John, try emailing Mark. |
| ||
| Since you are the only person in the history of the world to request this, it probably won't happen. We can't even get a GetTextureBlend() command added. |
| ||
| So bitter. |
| ||
| I'll put in a word for you Halo. |
| ||
| I'd like to see this expanded on. The way I see it, it's part of the same command set. For example, you could do a lot of funky underwater effects or special effects. Orth, projection, zoom, cameraviewports etc.... It's a valid addition, but not quite as john puts it. It could be a lot less specific. I think you can scale the camera. Why not position / offset it also? |
| ||
| I think this is doable but requires the camera projection matrix to be offset More prceisely, this request equates to being able to shear the projection matrix. |
| ||
| What you're asking for would be useful for all kinds of stuff (e.g. rendering really large images in pieces), so it's actually darn useful |
| ||
| "More prceisely, this request equates to being able to shear the projection matrix." Perhaps a better feature request then would be a setmatelement command. Blitz has commands to get the transofrmation matrix elements, so why not commands to set them? That would allow one to perform a shear operation... Unless Blitz is doing something funny with it's matrices. |
| ||
| I've mentioned this before but I've just come across another place where my game could be improved if I could make where the camera looks offset from the centre of the viewport. I dont see the issue -- tilt the camera down a little and you'll get more terrain at the bottom, less sky at the top. Every screen point is a view vector with an associated vanishing point as valid as any other, the only thing about the camera vector is that it is centered on the screen. But there is no reason you cant arbitrarily say that any pixel on the screen is "center screen" after you cover part of the viewport with icons. Just tilt the camera down enough such that the desired features are at the desired "center screen". @korolis: "shearing the projection matrix" reads to me as "move the camera down" -- equally valid as a solution, you end up looking (according to the camera vector) at someones chest when you get close, but if the chest is center viewport, then the head is someplace higher, up in that uncovered area where its supposed to be :) The only difference is that moving the camera means the projection for the upper areas of the screen are like you are looking up at them, so I think tilting the camera down is better, since then the upper area of the screen still represents looking "level" from eye height with proper projection. |
| ||
| "shearing the projection matrix" reads to me as "move the camera down No ZombieWoof, you've missed the idea. Think of the camera as having your monitor surface floating in the 3d world in front of the viewpoint. This virtual surface is in "normal" situation perpendicular to the view direction, and centerd with it (the view direction intersects with the center of the monitor surface). Everything gets projected onto this surface and is then rendered in the viewport. When shearing the view matrix, you make this "virtual monitor surface" not perpendicular to the view direction any more, and/or not centered.Tilting the camera ( = rotating as I understand what you mean) won't change the fact that this surface is perpendicualr to the view direction. |
| ||
| ok -- try it this way Because of the projection, you are actually mapping the view on to a curved surface, the virtual lens of the camera, and each pixel represents a normal on that lens surface. I'm trying to say there is no preference for any given pixel over any other. taken as a subset of the viewport, the center of any subview is perpendicular to its direction of view, and all the surrounding pixels still represent diverging view vectors. I would think that between any 2 adjacent pixels, the shift in vector direction would be constant unless blitz is using an unusual projection matrix. Therefore, a rendering at a down angle of 1/6 the vertical angle of viewing frustrum would show the center 2/3rds of the un-tilted view in the top 2/3rds of the screen. tilt=rotate, in this specific case, pitch :) |
| ||
| Zombie, there is no workaround to achieve this. You can't do it by tilting the camera. |
| ||
| I'm not trying to do a workaround, I'm trying to demonstrate logically that you dont need a workaround, that adjusting the camera is sufficient to achieve what you asked for. I just loaded up one of my modelers (Poser in this case) and moved a mesh into the top 2/3rds of the viewport trying both camera translation and rotation. I'll correct myself, it looked better using translation, your milage may vary :) I wont claim the perfection of shearing, but I didnt see enough difference to bother about jumping through additional hoops. |
| ||
| It isn't. You don't seem to understand this. Whatever you do at the moment, Blitz is 'looking' at the centre of the viewport. |
| ||
| Well i probably don't really understand what you want to achieve, but i had a similar problem with one of my games and the solution was to introduce an additional camera target pivot and offsetting it from the main action so the cameraviewport would center correctly above the icons but still be background to the icons. VS |
| ||
| ARRRRGGGGHHHHH. |
| ||
| What's stopping you dropping the viewport idea altogether if that's indeed the problem? What I do is render my view as normal and then draw all the static object on top and using Entityorder to make sure they're all definitely drawn last and on top. Then just translate your static icons along with the projection matrix of the camera so it's as if they're never moving, if indeed I presume the second viewport of icons doesn't move. This is what I've always done in this situation where I want parts of the screen obscurred by static entities when the camera moves around for stuff like sprites, score and energy bars but don't want to use a seperate viewport to handle this. I'm sorry if I've missed the point completely. I'm slightly baffled myself :) |
| ||
| I'm not having problems with draw order. I'm not using two viewports. The situation described is just one example. This is something I would find useful in a number places in my game. |
| ||
| John, I'm pretty sure this isn't that useful,but heck here goes... In the docs there's a short listing for placing a 2d text object in a 3d space, under: CameraProject camera,x#,y#,z# Perhaps using projected x and y there's a way of moving all objects, using an offset to help move them out of the centre of frame and keeping them there all the time? I'm wondering if there's a way to utilise something like this for your request? I think perhaps I don't really understand the problem but Just a thought. IPete2. |
| ||
| I think it would be a nice addition to Blitz. The idea of having a viewport bigger than the window/screen could be usefull for other things as well... Currently I think the only way of achieving it would be to setup a graphic mode resolution of let's say 1024*768 and to view only a part of the render to the screen (eventually replacing it centered in the window) then fill the ramaining surrounding areas with black matte or images... Maybe a resizable window would work (don't have any experience with it in Blitz). What I did once was to have a camera render a "scan" of the space while rotating of 360°, I was just taking the central pixel line (vertical line if you are moving the camera on Y axis) copying it to a buffer and then processing next line but this was off course really slow even for low resolution. This was making a perspective correct 360° panorama. Just a few suggestions, no real solution. But again it would be a good addition to the blitz language. |
| ||
| John, I asked about this a while back and got the same type of responses. It should be easy to explain in theory but as you now know - not in practice. There is definately no current solution though. A simple SetCameraOrigin( xOffset, yOffset ) command would be welcome as far as I'm concerned. SG |
| ||
| Yes. Well at least this time a fair few people have understood. Cheers for trying to help everyone. Just to reiterate this cannot be done in Blitz at the moment so this is a genuine feature request - there is no workaround that works. |
| ||
| Is this I presume a problem that wouldn't occur if you were say coding the camera properties in another language like DirectX and OpenGL? |
| ||
| I think so. It's about having a bit more control. |
| ||
| I've just reread this topic. It seems to me you're trying to do clever things with the camera to manipulate the vanishing point to be off centre. Or that's what I think you're trying to do. Last week I was writing a camera class in OpenGL and I had to write my own functions to stop stuff being drawn outside of the camera view. (As I'm not sure if there is a command to do it for you) Couldn't you just set Blitz's drawing distance to maximum and then perform your own checks on your objects to decide whether they're drawn or not? Then you'd be in control of where the drawing is yourself and it wouldn't matter where or what your camera is doing. Tis a dirty hack with extra CPU overheads but it may help. |
| ||
| No that's not what I'm trying to do. |
| ||
| I think I can see a vein popping out of John's head from here :) |
| ||
| Ah well. Best of luck with it anyway. |
| ||
| This idea just occurred to me... perhaps Scaling the camera entity in the Y direction-if this is possible- (please bear with me) and then tilting the camera (pitching) forwards a touch. Combined with an upright pivot to ensure the camera moves correctly... |
| ||
| It. Can't. Be. Done. ;-) |
| ||
| Ahh well, been a fun coupla weeks since you first mentioned it! Good luck! |
| ||
| You can do it by copyrecting a portion to a texture then stretching and using the texture as the main display. Except it looks ugly, and is slow. |
| ||
| Wow, a whole day passed and noone corrected me :) What I said was incorrect (more precisely, the way I said it): the "virtual monitor surface" would still be perpendicular to the view direction, but the center of this surface would no be any more on this view direction. That is the view vectorwouldn't intersect any more the "monitor" center. So, this is the line from the view point to the center of the surface that wouldn't be perpendicular to the surface any more. Normal case:
-------------
|
|
|
o (view point)
What the request is about:
-------------
\
\
\
o (view point)This *cannNOT* be done with what we have in blitz right now (except - as said - by grabing a sub portion of a view port, wich is limited and a simple waste of rendering processing). Or please someone make me happy and prove me wrong :) Is this I presume a problem that wouldn't occur if you were say coding the camera properties in another language like DirectX and OpenGL? Precisely, as then you have acces to the projection matrix as well as the transformation matrix. Thus you can shear the matrix, no problem. |
| ||
| I'm not sure that's right. If I rendered a 1024x1024 image and then discarded the top 256 lines I have exactly what I want; but nothing is sheared. The angle of view is just the same. Both the viewpoint and the target have just been shifted in 2D. |
| ||
| What is all this nonsense about shearing and that it can already be done??? It is a very simple thing to do in DirectX and OpenGL, but it needs to be built into the language. Look at http://www.mvps.org/directx/articles/tilerender/ to see one way of doing it. BTW: Koriolis's drawing above is wrong. The camera Viewpoint/target line should still be perpendicular to the image plane. The image plane is just offset in screen XY coords. It is really very simple. [EDIT] More links: http://www.delphi3d.net/faq.php?question=all http://www.delphi3d.net/download/hiresshot.zip |
| ||
| Is it possible to set CameraViewport with negative values? Duh what a plank... I can check this myself hehe This doesn't give an error, but Ive not got any objects to actually view... Maybe this is it??? |
| ||
| Doesn't work. |
| ||
| Awww - thought it was a bit too simple lol! |
| ||
The command should be: CameraViewport camera,x,y,width,height [,offsetx][,offsety] |
| ||
| Yes please! |
| ||
| Yes thats perfect. |
| ||
| BTW: Koriolis's drawing above is wrong. The camera Viewpoint/target line should still be perpendicular to the image plane. The image plane is just offset in screen XY coords. Which is exactly what my (bad) drawing shows. Look at it again.Or rather, let me elaborate: you're talking about offseting the viewport relatively to the viewing vector, right? The normal case is:
-----=====================---------
+
+
+
+
o
o = view point
+++ = view direction
--- = view plane
=== = part of the view plane that correspond to the view port
Here the line from the view point to the center of the viewport is the smae as the line from the viewpoint to the center of the viewport.Now you want to offset the view port on the view plane:
--=====================-----------
\ +
\ +
\ +
\+
o
\ = line from the view point to the center of the viewport
Yes, the viewing vector is still (by definition) perpendicular to the viewport surface, *but* the line from the view point to the center of the vieport is *not*And *yes*, AFAICT you can do that by shearing the matrix. If I find anything proving me wrong I'll come back here and let you know. |
| ||
| Yes but the line from the view point to the centre of the viewport is now meaningless as nothing is looking there. |
| ||
I got myself wondering if it needs to be: CameraViewport camera,x,y,width,height [,offsetx][,offsety][,scalex][,scaley] in order to be able to do tileable screens? I think so... |
| ||
| What does the scaling do? Can't you scale with zoom? Or is it just easier to work with? |
| ||
| Yes but the line from the view point to the centre of the viewport is now meaningless as nothing is looking there I'd say it's precisely because the view direction is different from the line to the cneter of the viewport that you can say it's sheared...Well, it seems I'll have to find some doc to have a chance for what I say to be considered. But as I said I'll also claim it if I was completly wrong. |
| ||
| I'd just say the line is meaningless. |
| ||
| Scaling would allow f.ex: To render a 4096*3072 in screens of 1024*768: CameraViewport camera,0,0,1024,768,-(1024-1024/2),-(768-768/2),4,4for upper left corner of the 4*4 screens Maybe instead of scale, the last parameters could be the virtual viewports size: CameraViewport camera,x,y,width,height [,offsetx][,offsety][,virtualwidth][,virtualhight]Then it would be: CameraViewport camera,0,0,1024,768,-(1024-1024/2),-(768-768/2),4096,3072for upper left corner. |
| ||
| Thanks Peter for expressing all this so clearly. And yes this is definitely a useful feature for ALL kinds of things (producing giant rendered images using tiles, for one) |
| ||
| I hope everyone is still jumping up and down waving frantically? |
| ||
| http://graphics.cs.uni-sb.de/Courses/ws0304/cg/Slides/20040115_magnor_pervertextransformations.pdf "Perspective Transformation" part. It doesn't tell much, but simply put, if the optical axis (my "\" line) doesn't go through the center of the screen, just apply a shear that deforms the world in such a way that this optical axis is taken back to confund with the z-axis (my "+++" line) Or better, take this one: shear so that the direction of projection is parallel to the z axis It explains the standard way of doing clipping ("Clipping " part). As you see, it involves a shear ("shear so that the centre line of the view volume becomes the z axis "). One more: http://ironbark.bendigo.latrobe.edu.au/courses/gdc/bitgrp/lect/lect10/lect10.html -> "Note the shear terms A and B. These make the Direction of Projection line up with the z-axis." http://www.google.fr/search?q=cache:uMWAcHpj5GAJ:www.cse.ohio-state.edu/~hwshen/581/3d_viewing_all.ppt+%22z+axis%22+%22viewing%22+shear&hl=fr -> "And takes care the case that eye is not at the center of the view volume (shear)" These are certainly not the best sources, but I've searched enough. ------------------ Implementing the feature as an extended CameraViewport as Peter suggest would probably be the most handy way of doing it. ...juuuuumping... |
| ||
| *jumps up* Mark, I think this is a fine addition, and one I would personally use for effect realtime. I believe it rounds off Blitz's camera system nicely and plugs any glaring omissions. |
| ||
| Maybe upper left corner of the virtual viewport should default to offset = 0,0 ? Then to put the camera in the upper left corner of the virtual viewport, it would be: CameraViewport camera,0,0,1024,768,0,0,4096,3072and to the center of the virtual viewport: CameraViewport camera,0,0,1024,768,(1024+1024/2),(768+768/2),4096,3072 |
| ||
| JP, I tried to email you. Can you pls get in touch. Simon |
| ||
| Doh! Forgot to update my profile. Zed Two email is now dead. Emailed you Simon. |
   |