Hard Light Productions Forums
Modding, Mission Design, and Coding => The Scripting Workshop => Topic started by: Bobboau on January 13, 2008, 06:31:58 pm
-
what is the current status of RTT and it's script related interfaces?
-
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 (http://www.hard-light.net/forums/index.php/topic,50602.0.html).
[attachment deleted by ninja]
-
to which I don't have access. :)
whats the jist?
-
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]
-
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.
-
i for one would like to see script based rtt function properly.
-
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]
-
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.
-
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)
-
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.
-
[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.
-
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]
-
so essentially it works, its just the uvs are screwed?
-
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.
-
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]
-
if you add
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.
-
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... :nervous:
-
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]
-
http://freespace.volitionwatch.com/blackwater/fs2_open_r_bobboau_1-15-08_rtt.zip
just in time
-
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 :D
-
heres a basic gun camera script. it has some issues though. first off something is wrong with drawImage(). scripting.html says:
drawImage(Image name/Texture handle, [x1=0, y1=0, x2, y2, uv x1, uv y1, uv x2, uv y2])
however for some reason it wants the 4th argument to be a bool when it should be x2. as a result i cant flip the image and so its upside down. also backgrounds are a little screwy. it works ok on some skyboxes, like ones with 32 bit tga textures, or ones with white backgrounds. anything with efficient textures wont work. using only a starfield you get trails like the image isnt cleared between rtt calls, dispite a black backfill to clear the texture between frames.
anyway here it is, its sorta cool. its hard coded to the medusa (or any ship with a turret01a), and will probibly crash the game otherwise. also find a good tga skybox.
;;render targets
#Global Hooks
$GameInit:
[
tex = gr.createTexture(256, 256 , TEXTURE_DYNAMIC)
cam = nil
]
$Simulation:
[
ship = mn.Ships["Alpha 1"]
if ship:isValid() then
tsub = ship["turret01a"]
end
if cam == nil then
cam = mn.createCamera("guncam")
end
if tex:isValid() and cam:isValid() then
gori = tsub.GunOrientation
gori.p = gori.p - math.pi*0.5
tori = ship.Orientation * (tsub.Orientation * gori)
cam:setOrientation(tori)
cam:setPosition(ship.Position + ship.Orientation:unrotateVector(tsub.Position))
mn.setCamera(cam)
gr.setTarget(tex)
gr.setColor(0,0,0,255)
gr.drawRectangle(0,0,256,256)
mn.renderFrame()
gr.setTarget()
mn.setCamera()
end
]
$Hud:
[
if tex:isValid() then
gr.drawImage(tex, 10, 400)
end
]
#end
another idea i had was a renderWireFrame() function. same as render frame, but does a faster line draw of the scene. this could be used to do combat scanners. i remember seeing a wire frame scanner in a star fury on an episode of b5, one of the things that can be done with it. another idea is to use it for a fog scanner. so you can have a wireframe overlay of where all the ships are in the nebula, dispitre the fact that they are invisible in the fog.
-
there needs to be a way to set detail level so you can put it to the lowest level before drawing the frame...
anyway, I know it still doesn't work properly all I did was prevent the low level poly drawer from thinking an RTT texture was a NP2 texture, and make sure the make texture function set the UV scaleing to 1.0. honestly I'm not realy trying to totaly fix this because I'd much more likely break a dozen other things, FS's bitmap manegment and drawing functions are loaded with all sorts of bizar interdependencies.
-
looks like the z buffer is shot as well. some loding would be nice, maybe that wireframe render, and perhaps an option to not render certain maps, backgrounds, and weapons (though weapons appeared to render from the gun camera). there are some color discrepancies as well, i tried drawing a red circle on top of the gun camera texture and it came out green. would also explain why dds backgrounds didnt render too well. none the less im impressed that it worked at all.
i should probibly write in an automatic frame skip option as well, where the number of frames skipped would depend on the framerate. for me it never dropped below 60, but that was in simple test missions. i figure skipping between 0 and 10 frames depending on how far away from 60 fps the game happens to be running. so anyone with a good gaming rig with fps to spare, can get a full frmerate gun cam, lower end machines would skip a frame for every frame 5 frames below 60. another idea is to come up with a way to not use the rtt code if the texture is not on the screen, like if its on the panel in the back of the ship (and only visible when flying gunner), or if the dot product between your view vector and the vector to the screen is low.
-
another problem i found is that all draw calls to the targeted texture seem to be additive, rather than replicative. like if i try to draw a dark grey rectangle on the texture, it will keep adding up to white. if i set it to zero it only adds zero, it doesnt set it. this also seems to happen with mission backgrounds when i do renderFrame(), while everything else seems fine. i can get around that by using a fully opaque skybox.
-
try useing gr.CurrentOpacityType (ALPHABLEND_NONE)
-
that didnt seem to work, it doesnt work as a function, but it works ok with an = (works meaning it doesnt crash). im still getting the same problem.
-
seems i can draw on top of any 32-bit tga texture without the alpha problem.
so far i got the pb sepulture with 3 working displays. i have the gun camera, which not only operates the turret but, if you fire an infyrno, you can also guide it. its almost exactly like the desert storm missile camera footage, cept its in color. im sorta stuck on a turret aiming problem. the turret essentially wants to fire in a direction other than where its pointing. i think somone said somewhere that the game keeps 4 matrices for the turret. problem is i only have access to 2 of them. i came up with the idea to store the orientations of the parts, and change them so that they can fire in another direction, then i reset their original orientation. it shows promise but i need to know how the game calculates its matrix for firing of turret mounted weapons.
i have a crude radar display as well. its just an orthographic projection of the ships on the xy plane, blips are represented with little circles. the radius depends on the distance, 10 - log(z), so it looks convincingly 3d. i might go as far as color coding the dots ot iff status. on the 3rd display i have a picture of some kittens. im just using this to print debug information. i thought about putting hud pong on it, but i think i need to rework and improve it.
im gonna post vids on youtube once i got this working on youtube. i might even release a demo vp that can be installed on top of nukemod '06, if i feel so inclined.
-
are the three displays on the actual ship geometry?
-
indeed. i had to create a new sub object for them. all i did was copy the faces from the panel in the cockpit model and stuck them into their own submodel. they sit a couple units over the originals. gave each screen its own texture and uv mapped it so that any texture would cover the whole screen. they really dont have textures, i just used some bogus texture names, panel1, panel2, panel3. this way if the rtt code does not work, the painted on screens can still be seen. i had planned to use invisible textures, but i wasnt sure they could be addressed individually. also all draw calls seem to be rendered in vertical mirror. i may work around this by flipping the uv space. also my 256^2 textures seem to think they are 200*185 textures :D
eventually i want to just use a single 512^2 texture, to which all panel gauges and cameras can be rendered to. cameras would need to be rendered to their own textures, then placed on the big texture with a drawImage() call. this way a panel template texture can be used when creating a ship. you can uv map the polies for the various elements to thatever section of the template you see fit. a section for radar and a section for video displayes, and smaller ones for individual gauges and other things like indicator lights.
im thinking about having 3 layers of surfaces in the panels, to make the gauges look realistic under various lighting conditions., an outter transparent layer, with glasslike textures, an inner layer which is a dummy pannel with glow but now shine or env. then a layer in the middle for rtt stuff. this is a good way to deal with screens. but id like to put some old skool analog gauges into some of my pirate ships, they can be done in almost the same way. i picked the sepulture because it already has working yoke and throttle animations, they use very little code so i dont see it being a huge problem merging that into the demo. so you will have a fully functional cockpit in a very short while (short in my terms can usually mean a few months :D ).
[attachment deleted by ninja]
-
SPACE KITTENS!!!!
...anyway....
nice work, though do keep in mind even thought this does sort of work, it's still got a lot of bugs, and any workaround you do will be invalidated eventually. also I get the impression from what taylor has said, that what I did wasn't suposed to fix it so there is probably more going on here.
-
this is mostly a slap together job, the turret and missile code were scripts i had written before, now they can be put to use and integrated now that i have the interface to do so. the radar took me about 10 minutes to get working. thing is this setup eats up 5 small textures. so far the performance seems good, but i doubt it would be good in a big mission.
my mod features are frequently invalidated. the first time was with gatling guns, but it turned out the newer system was better. it happens all the time when dealing with scripting, as the system itself is an ongoing development. then we have a new cockpit system, so those have got to be re-done, hopefully retaining all of the features scripting has made possible. most of my work goes to adding new features to old ships. i dont think ive modeled a new ship since the chimera, which was the main feature of nukemod 2006. if anything im giving the coders ideas and proof of concepts for improving the engine :D
-
So is there any possibility of getting a patch or commit of the RTT 'fix' in the unstable branch?
-
ive been messing around with rtt quite abit lately. merging it with the virtual cockpit scripts ive been working on. i found some intresting info out that might help pinpoint the scaling issues.
a 255^2 texture seems to have an accessable resolution of 205 * 192 when drawing an unfilled rectagle or text. the 0,0 coord seems to always be the top left corner. also the textures are flipped on y so i had to flip the uv space on the panel submodels to compensate.
filled rectagles seem to be off by a few pixels (which apears to be down and right about 2), circles seem to want to be drawn in a range of 164 * 144 (that being the bottom right corner), its just really strange behavior.
also to completely cover a 256^2 texture with drawImage, a texture of 205 * 192 (in a 32bpp format) is required.
if you do not fill in a texture with drawImage with a 32 bit texture, the texture will behave as if it has additive
blending.
if you render the frame on top of the texture, and you dont have a 32bpp skybox with no alpha, then the image
behaves as additive. i presume i can fix this by drawing a "background" first with drawImage and a 32-bit non-trans image
and then the frame on top of it. edit, i presumed wrong, without a 32-bit skybox, and overlaying over a fully opaque black texture, the additive behavior is still there.
any other draw calls after the "background" is drawn seem to work fine, save the coordinate scaling postion issues.
problems with using renderFrame() on a texture, aside from the additive glitch, is pretty much just what appears to be a busted z buffer. you can see some geometry through other geometry. its possible that this is being calculated after the call to renderFrame(), since im doing the rtt in the $simulation: global hook, instead of the $on frame: conditional hook, its possible that the z buffering is done between the hooks and it might be preferable to do the rtt in $on frame.
theres also that problem with the optional parameters on drawImage. where the bool is the in the 4th parameter, where your y2 coord should be. anything past that bool does not work. i think i mentioned this before. it might be a bug in scripting though. further investagation seems to be required.
another thing thats odd is the getScreenCoords() function is returning some really obscene numbers. ive seen it go as high as 8000 and even go negative. is this new behavior or a bug? it used to only go between 0,0 and 640,480 or 1024,768 (depending on video mode).
-
Nuke + My FS2Open RTS mod Question: When a message pops up, alpha-blended HUD rectangles change brighntess (possibly a blending mode issue).
Is there a lua function we can use to fix this?
Edit: Apparently this only happens on my version, not Nuke's. However, I can tell quite clearly that the blending function is changing between additive and alpha blending. Please assist.