[Bobboau]

what is the current status of RTT and it's script related interfaces?

[WMCoolmon]

Both are implemented and should be working. However, something about RTT and scripting doesn't jive. Here's a test script for the unstable branch. You should see two boxes with the same image with them, but what you'll most likely see is a box on the left with a black square, and a box on the right with the image.

There's some discussion on the internal.

[attachment deleted by ninja]

[Bobboau]

to which I don't have access.
whats the jist?

[WMCoolmon]

Best summed up by taylor:

Got the memory errors fixed and gave it a test, but the RTT code appears to function properly.  This is with the Xt tree though, but the only RTT change that I could find was to fix a bug where anything created via RTT was upside down, so I assume that it should basically work in a regular stable build too.

It didn't actually draw at first though, but on the surface that appears to be some sort of scripting issue.  I changed the order things are done in the script to simply do the RTT box first and it showed up just fine.  In fact, so long as just the RTT part is done first it works perfectly.  Another issue was that the script was missing a clearScreen() in the RTT part, since without that the render buffer could be any color.

I've made the latter two changes he mentions in the script in my first post, though you can try playing around with the script and see if you can get it to do anything.

Here's the (non-fixed) test script for the stable branch.

[attachment deleted by ninja]

[Bobboau]

I wonder if it has something to do with not telling the render target to actually put the image onto the surface, I'm not sure if or what the equivalent in OGL would be but in D3D any time you want to draw something you need to remember to "present" it, it's basically telling the card you are done drawing 'put it on the screen now'.

but that's just the first thing that came to mind when you said it doesn't seem to be doing anything. probably has nothing to do with it.

[Nuke]

i for one would like to see script based rtt function properly.

[Bobboau]

Code: [Select]

I get
[code]
createTexture: Argument 3 is an invalid type 'string'; type 'enumeration' expected

------------------------------------------------------------------
ADE Debug:
------------------------------------------------------------------
Name: (null)
Name of: (null)
Function type: (null)
Defined on: 0
Upvalues: 0

Source: (null)
Short source:
Current line: 0
------------------------------------------------------------------


------------------------------------------------------------------
LUA Stack:
------------------------------------------------------------------

1: Number [256.000000]
2: Number [256.000000]
3: String [Dynamic]
------------------------------------------------------------------with that last script, I'm assuming this isn't a huge error.

[edit]never mind it should have bee TEXTURE_DYNAMIC but it still doesn't change anything[/code]

[Bobboau]

tell taylor that render targets are not non poer of two textures, if he looks at you funny tell him to look in function gr_opengl_tcache_set and ask him if the part where it set's "interface" bitmaps (around line 1477ish of glopengltexture.cpp in my fresh clean head copy) is also setting your script's texture to GL_TEXTURE_RECTANGLE_ARB when in fact it should just be leaving it the hell alone. this doesn't totally fix the problem but I have a feeling it might lead him towards it. I added a "&& !bm_is_render_target(bitmap_handle)" to the long list of exceptions and it seems to have at least shown the color I cleared the texture with, which is a step in the right direction.
it seems to be more related to the drawing functions you are using than the RTT it's self.

[Bobboau]

oh, wait, render targets are getting a u/v_scale of 0.0, that's probably not good

yeah, the onlt other pearl of wisdome I'm giveing out today is that inopengl_make_render_target the u and v scale needs to be set to 1.0 (or something)

[Nuke]

i assume once rtt is in, i could set a target to a texture and call render scene to get something such as a gun cam, and that it would cost a second pass for the frame. is it at all possible to include an lod option so when i call renderScene(), i can say to use lod 2 or 3. my turret script would be totally awesome if i could put some gun camera on the panel.

[WMCoolmon]

Code: [Select]

[quote author=Bobboau link=topic=51538.msg1041691#msg1041691 date=1200316309][edit]never mind it should have bee TEXTURE_DYNAMIC but it still doesn't change anything[/quote]

The last script is for the stable branch, so you'll have to change several things if you're working with HEAD.

I'll pass a link to this thread along to taylor, I have a vague idea of what you're talking about but I'm sure he knows better.

i assume once rtt is in, i could set a target to a texture and call render scene to get something such as a gun cam, and that it would cost a second pass for the frame. is it at all possible to include an lod option so when i call renderScene(), i can say to use lod 2 or 3. my turret script would be totally awesome if i could put some gun camera on the panel.

Probably, if nothing else you could always gimmick the detail setting for the duration of the gun cam. There are probably some other things that would be needed, like changing all the reset-render-target functions to set the render target to whatever it was when it started rendering the mission, but from what I know of the rendering process, it's eventually doable.

[Bobboau]

ok, after some EXAUSTIVE testing, I have come to some conclusions, it seems that when rendering to texture, the y coordinate seems to be inverted and translated down by 768 (the screen resolution). at least until you get a texture resolution of 512, which I just noticed doesn't follow this trend...

[edit]no, it still follows the pattern it just seems a texture of that resolution breaks the 2d drawing functions, buting the texture on an object it still renders properly[/edit]

[Nuke]

so essentially it works, its just the uvs are screwed?

[Bobboau]

it sort of works, if you have a RTT HUD scrip laying around give it a shot, but just in the RTT section (when you are drawing to the texture) any time you draw something instead of entering y enter 768-y.
as I'm sure you know all you need to do is make the texture, set it as the target, draw some stuff set the screen back as the target (by using empty parameters), then replace a texture (or all of them for testing purposes) with the RTT texture.

[Bobboau]

or at least that's how it's working on my system, given how this is a bug, it might not be behaving systematically across all systems.

but try out this scrip, it'll make a little psudo-pong moving graphic that never goes away.

[attachment deleted by ninja]

[Bobboau]

if you add

Code: [Select]

ship = mn.Ships["Alpha 1"]
if ship:isValid() then
--Assuming this is a Ulysses, set all textures to our new one
ship.Textures['fighter01-01a'] = tex
end

after the texture creation section of that script it'll replace the LOD0 texture of your ship (assuming you are flying a Ulysses, it'll probably crash out with an error otherwise, but that's not the point)
I'm sure you are already way ahead of me already, but I figured I'd put that in there to make sure it worked and post this just in case you couldn't remember how to override a model's texture off the top of your head.

[Bobboau]

oh, ****! I just remembered I'm the only one with an FSO build were this works (somewhat) properly!
eh... I'll upload a build as soon as I can get release compiled.

I hope I can do this before I have to get to work...

[Bobboau]

well while I wait for the compiler to do it's thing, here are a few screenshots of what I have in action

[attachment deleted by ninja]

[Bobboau]

http://freespace.volitionwatch.com/blackwater/fs2_open_r_bobboau_1-15-08_rtt.zip

just in time

[Nuke]

cool. i didnt expect you to get it working so fast or i would have written a script rather than play my nightly game of kingdom of loathing.

i can confirm that its working now. just need to come up with a better demo than drawing a blue square on my ship