OK, all I want to do is render my 3D scene to a texture and dump it back onto a 2D screen. But when I do, the origin of the 3D camera seems to jump to the right(or the grabbed texture dimensions are getting messed up).
It's one of those situations that you know something is wrong but cant see the reason why? :blink:
Please run this snippet at 640x480 windowed please and tell me if you get the same result?
SETCURRENTDIR("Media") // go to media files
GLOBAL screenID%, spriteID%
GLOBAL screenWidth%, screenHeight%
GETSCREENSIZE screenWidth%, screenHeight% // 640,480, windowed
screenID% = 0
spriteID% = GENSPRITE()
DEBUG IIF( PLATFORMINFO$("GLEX:glBindFramebufferEXT")=1, "FBOs supported\n", "FBOs not supported\n" )
CREATESCREEN screenID%, spriteID%, screenWidth%, screenHeight%
WHILE TRUE
USESCREEN screenID%
CLEARSCREEN RGB( 44, 44, 44 )
X_MAKE3D 1, 1000, 75
X_CAMERA 0,0,-100, 0,0,0
X_DRAWAXES 0,0,0
USESCREEN -1
X_MAKE2D
DRAWSPRITE spriteID%, 0, 0
PRINT "Rendering to texture", 0,0
SHOWSCREEN
KEYWAIT
CLEARSCREEN RGB( 44, 44, 44 )
X_MAKE3D 1, 1000, 75
X_CAMERA 0,0,-100, 0,0,0
X_DRAWAXES 0,0,0
X_MAKE2D
PRINT "Not rendering to texture", 0,0
SHOWSCREEN
KEYWAIT
WEND
Oh, as a side note, is anyone getting the message "FBOs supported" in the debug window?
Hello Bigsofty, this is probably a bug I guess? Or maybe something changed relating to 3d coords.
I tried it with GLB10 and it works fine as well as with GLB14. They both also show antialiase the correct way (imho).
GLB 15 and 16 showed the mismatch you stated.
I did not get the FBO error msg.
Thank for trying Erico, did the 3D cursor move when you pressed a key?
Also, did you get a "FBOs supported" in the debug console window?
A weird thing I did discover is that if I make the resolution to an even power of 2(256x256, 512x512, 1024x1024 etc.) it works fine. Which makes me think it could be something to do with the allocated texture size for the FBOs buffers? :S
Yep the 3d cursor moved.
No msg like that on the debug console.
And here with a 512x512 setscreen
Both are from the latest GLB STEAM version.
edit: a very wide shot ... it would not have anything to do with polyvectors right?
Thanks again Erico, some nice comparison pictures there! :good:
Purely guessing here but I don't think it has anything to do with 3D coordinates, or the camera being moved or even what you are trying to render. I think USESCREEN takes a snapshot of the screen and fits it on a texture that is not the same size of the screen, even though I requested it to do so. So when you try and paste the snapshot back onto the screen, it no longer aligns. I think it only does this if your screen dimensions are not an even power of 2. Which used to be a pre-requisite for fast texture access on older handheld devices. So I think it may be a feature from way back which now hinders desktop platforms today.
BTW you should see a message with in debug mode?
Edit: I had a quick look at the GLBasic FBO buffers creation code and suggested a fix... http://www.glbasic.com/forum/index.php?topic=11363.msg99945#msg99945
I ran it in v12.308 and nothing moved...
That's interesting, so earlier versions don't have this behaviour? :blink:
Changing the DRAWSPRITE line to assume that the dimensions have increased to the next ^2 (640=1024, 480=512) and adjusting the image position to compensate for the increased size, you can remove the XY discrepancy. And it fixes its position(although not the overall scale) accordingly, this kinda proves that the image has been resized upwards to the power of 2.
DRAWSPRITE spriteID%, -(1024 - 640)/2, -(512 - 480)/2
// DRAWSPRITE spriteID%, 0,0
Its kinda driving me nuts because I have full screen post-processing shaders working but GLBasic is internally messing the final result up unfortunately by changing the scale before I can access the FBO sprite.
Issue happening in v16.252
Use screenID% = 99 .... then it works
:)
v10 and 14 seems to work fine on my end, v15 and v16 have the strange behavior.
Quote from: MrPlow on 2019-Nov-27
Use screenID% = 99 .... then it works
Unfortunately CREATESCREEN ID%, ID% is limited from 0 to 31, so going above 31, is the same as -1, which is the backbuffer, so 99, is basically just normal rendering to the screen, not buffering it to a sprite. This can be illustrated by adding a CLEARSCREEN before the first X_MAKE_2D. If it was copied properly via an FBO it should still reside within the spriteID% which unfortunately it doesn't, and drawing the sprite should show the screen but as it was USESCREEN 99 (same as -1) , its simply drawing to the screen and not drawing/buffering it. :( TBH I'm kinda surprised it did not throw an error.
Its good to know that this was working at some point (version) so maybe its an easy fix for Gernot?
Lol!
I didn't know about that 0 - 31 limit for CREATESCREEN :)
:good:
Lol, you had me going for a bit, when I stuck in 99 and it looked like it worked, a quick... :O =D :o :(
I allowed number of screens equal to number of sprites.
Also, the bug with the wrong 3D viewport on a surface is fixed. I hope to update soon.
Great news, thanks Gernot! :good: