|
|
so i go a little bit carried away and write a new version of my hudpong script, with rtt capabilities. unfortunately this script doesn't seem to break rtt. at least in that case it seems to work. i figure that it has something to do with calling renderFrame() while rendering to a texture. which makes me question why the radar in the cockpit demo doesnt render right (it doesnt use renderFrame()). il have to try tomorrow to come up with another script that breaks rtt, so far it seems that only my cockpit demo manages to break it. there is a possibility that there is something wrong with my script, but that doesn't explain why 3.6.12 builds work fine with it and 3.6.13 screws up the textures. more investigation is in order. |
|
|
i wrote yet another rtt script and still cannot replicate the bug. what has changed with regards to rtt since 3.6.12? |
|
|
Not sure about RTT specifically, but 3.6.13 has go_faster and new HUD code. In a case like this, using the nightly builds to narrow it down might be beneficial. I will even make builds for certain revisions if it will help narrow it down, but someone who can reproduce it would need to do the testing. I might even checkout the cockpit mod myself to see if I can narrow it down some. |
|
|
works in 6626, but not in 6627 |
|
|
So we know it was a change made in the go_faster Antipodes 6 commit that was responsible. |
|
|
i think this bug can be closed, i just downloaded 7613 and my script runs fine now. dont know when this was fixed but it doesnt seem to be an issue no more. |
|
|
Closing as resolved/fixed :) |
|
|
hate to say this but i got my builds crossed, where i thought i was running a recent nightly somehow i ended up running 3.6.12. rtt is more broke than ever. this should render a camera view to texture and replace every texture on every ship in the game with it. scripting.tbl: #Conditional Hooks $Application: FS2_Open $State: GS_STATE_GAME_PLAY $On State Start: [ tex = gr.createTexture(512,512,TEXTURE_DYNAMIC) tex2 = gr.createTexture(512,512,TEXTURE_DYNAMIC) cam = gr.createCamera("spotcam") cam2 = gr.createCamera("topscam") ] $On Frame: [ ship = mn.Ships["Alpha 1"] if cam:isValid() and ship:isValid() and tex:isValid() then --make the camera do stuff cam.Self = ship cam.Orientation = ba.createOrientation(0,0,math.pi) --look at ship local oldTarget = gr.CurrentRenderTarget gr.CurrentRenderTarget = tex --backfill gr.setColor(0,0,0,255) gr.drawRectangle(0,0,512,512) --set camera gr.setCamera(cam) --draw scene mn.renderFrame() --reset camera gr.setCamera() --do other view gr.CurrentRenderTarget = tex2 gr.setColor(0,0,0,255) gr.drawRectangle(0,0,512,512) cam2.Orientation = ba.createOrientation(math.pi*0.5,0,0) cam2.Position = ba.createVector(ship.Position.x, 5000, ship.Position.z) gr.setCamera(cam2) mn.renderFrame() gr.setCamera() --unset target gr.CurrentRenderTarget = oldTarget --replace textures for j=1, #mn.Ships do local aship = mn.Ships[j] if aship :isValid() then if aship ~= ship then for i=1, #aship.Textures do aship.Textures[i] = tex end else for i=1, #aship.Textures do aship.Textures[i] = tex2 end end end end end ] $On State End: [ tex:unload() ] #end |
|
2011-09-05 07:19
|
brokertt.jpg (48,693 bytes) |
|
2011-09-10 00:50
|
texturereplacefail.jpg (116,788 bytes) |
|
|
got some new information and a new screenie. it appears that the issue is not so much about rendering to texture as it is about the uv space not getting scaled correctly at polygon render. what i did was i wrote a bit of script to draw all the render targets to the screen. (see texturereplacefail.jpg) the far right image is my custom radar display. on the assumption that something was going wrong with the uv mapping i decided to draw a bunch of random pixels over the area to see how they were dispersed on the upper right geometry with the radar texture. sure enough the same banding i encountered when i first reported this bug was occuring. i assume whats happening is that when the uv coords from the polygons are being multiplied by the image dimentions, that the dimentions are wrong, especially on the v axis. this may also explain why the renderFrame calls are not filling the whole image. |
|
|
also my svn repo is here in case anyone wants to debug the script further: http://nukedspace.fsmods.net/svn/trunk/cockpitdemo/ |
|
|
a small update: the banding seen in the first screen shot is not an rtt issue. the way i inserted the polygons into the models did not fly with the updated ibx system and this caused uv corruption. this is fixable in the model. i figured this out by setting up a new ship to use my rtt system. the 3rd screenie shows this. the issue from the second screen shot still happens. although the render target renders to the screen in a different place under the 3.6.14 rc1 build. it seems that 2 things are happening here: 1. render targets are either not being set or reset properly 2. on builds where render targets were being set correctly, there were scaling issues when the frame is rendered to the texture, where it would not fill the texture. here is yet another test script: ;rtt test script ;creates a rear view camera, then renders it to texture ;this texture is drawn to fill the green and blue box on the hud ;image should completely fill the box #Conditional Hooks $Application: FS2_Open $State: GS_STATE_GAME_PLAY $On State Start: [ tex = gr.createTexture(255,255,TEXTURE_DYNAMIC) cam = gr.createCamera("rearview") ] $On Frame: [ ship = mn.Ships["Alpha 1"] if cam:isValid() and ship:isValid() and tex:isValid() then --attatch camera to the ship cam.Self = ship --point camera backwards cam.Orientation = ba.createOrientation(0,0,math.pi) cam.Position = ba.createVector(0,0,-15) --set render target gr.CurrentRenderTarget = tex --backfill gr.clearScreen(0,0,0,255) --set camera gr.setCamera(cam) --draw scene mn.renderFrame() --reset camera gr.setCamera() --reset target gr.CurrentRenderTarget = nil --draw textures on hud x1,y1,x2,y2 = 8, gr.getScreenHeight()-tex:getHeight()-8, tex:getWidth()+8, gr.getScreenHeight()-8 --draw debug square first gr.setColor(0,0,255,255) gr.drawRectangle(x1,y1,x2,y2,true) gr.setColor(0,254,0,255) gr.drawLine(x1-1,y1-1,x2+1,y1-1) gr.drawLine(x1-1,y2+1,x2+1,y2+1) gr.drawLine(x1-1,y1-1,x1-1,y2+1) gr.drawLine(x2+2,y1-1,x2+2,y2+1) --draw primitives are still innacurately positioned, lol --now draw the texture gr.drawImage(tex,x1,y1,x2,y2) end ] $On State End: [ tex:unload() ] #end |
|
|
I think that I fixed this issue and another problem with post-processing which caused the current OpenGL framebuffer object to be reset to the screen instead of the RTT framebuffer which should be used. The first problem was because the scene gets rendered into a fixed size framebuffer texture of the configured resolution. When the scene gets finally drawn to the texture the scene texture which is the size of the screen resolution where the target texture is usually smaller than this. To fix that I added an U and a V scale variable which gets set in gr_opengl_scene_texture_begin (either to 1.0f when not doing RTT or to the correct UV values). I also added a check for the non-power-of-two texture sizes to make_render_target to add more freedom to render targets if it's possible. I added the patch to this issue. There are still problems when FXAA is enabled as something is going wrong there but I have no idea what is causing that. |
|
2011-12-21 19:04
|
rtt.patch (8,678 bytes) |
|
|
Please try again with the changes in revision 8108. FXAA used to rely on undocumented behaviour, which was fixed in that commit. |
|
|
No that didn't help it actually made it worse now there is also a top-down view of the screen rendered onto the texture: http://img502.imageshack.us/img502/8056/fxaabug02.jpg Without FXAA everything looks good: http://img59.imageshack.us/img59/3176/fxaabug01.jpg |
|
|
Fix committed in revision 8111. However, this disables FXAA when rendering to a render target, which I think is a minor nitpick that can be addressed later. |
- Anonymous
