[JGZinv]

While the title might be a tad misleading, I was wondering about
the potential of using various methods to create a AI camera that could
be tasked to cover players or events - and send it's view to a surface
in game, or as a HUD object.

In the first example, think sporting events type coverage. In the latter, consider
support AI's or special cases where you need more than one pair of eyes.

I was thinking that perhaps the observer mode after you die so many times could
somehow be put to use, or specially setup craft - though I'm not sure what kind of AI
adjustments would be needed (or possible) so that you'd get them to watch at a certain
range - or focus on instances of more than one ship (ie combat).

The other thing is... with the animated texture options available, nothing really fits the bill
to do essentially live video. You can't build the files in real time.  Maybe something HUD related
would do the trick... similar to the various past projects on pilotable turrets or player controller rear
gunner positions perhaps... don't know.

Anyway, feel free to discuss... I've got a handful of uses in mind, but would like to hear more thoughts.

[m!m]

You could do it with scripting (the magic words ). You could create a camera that would show whatever you want, set it as active camera then set the CurrentRenderTarget to a texture you created and after rendering draw that texture to the screen using drawImage but I haven't tested that idea (but Nuke got it to work at some point).
But yeah, it seams to be doable

[Nuke]

You could do it with scripting (the magic words ). You could create a camera that would show whatever you want, set it as active camera then set the CurrentRenderTarget to a texture you created and after rendering draw that texture to the screen using drawImage but I haven't tested that idea (but Nuke got it to work at some point).
But yeah, it seams to be doable

i think you mean you can only do this with scripting. as i understand it there are no other means to do a render to texture operation through modding techniques. would be intresting if you could do this with a sexp and use custom gauges to display the texture on the hud as sort of a built in feature. i had render to texture working on things like guided missiles and sniper scopes an cameras for manually controlled turrets, among other features. had some issues making the script work after go faster came along. maybe i should follow that up and see if the problem still persists. the really annoying thing is that when i went back and tested it with a much lighter script, it worked, so i couldnt exactly back it up with a script on mantis. one build the script worked and the next it didnt.

i just did a test and the whole thing is borked now.

[JGZinv]

Hmm that's quite unfortunate. Seems there would be some potential.

I hadn't thought of weapon attachments for it... besides fin funnels anyway.

[Nuke]

Hmm that's quite unfortunate. Seems there would be some potential.

I hadn't thought of weapon attachments for it... besides fin funnels anyway.

actually i pulled the latest nightly and it seems to be working now. it would be very difficult to create a small library that lets fredders set up render a camera to texture with a few function calls with script eval.

[lostllama]

I was thinking of taking advantage of render to texture in order to mimic a rear-view mirror for my fighter model.

[Nuke]

I was thinking of taking advantage of render to texture in order to mimic a rear-view mirror for my fighter model.

quite doable. should be a feature in my cockpit script. im currently trying to make it dynamic where you can put in as many rtt textures and cameras as you want, though at some point performance goes bye bye. place camera at the center of the polygon, render to texture from it, use texture to simulate mirror. i do have a working rearview camera though, which replaces a texture on one of the mfds in one of my ships. still got to hammer out some bugs before it will work, right now 2 cameras are supported, but like i said im trying to make it dynamic.

just grab an old version off of my svn repo. not sure if it will work or not. also grab a recent nightly, since some builds break rtt in the script (you dont even need to know lua). see tables and model examples for how to mod the script. just remember its a work in progress and modding techniques to make it work in your mod are subject to change.

[JGZinv]

actually i pulled the latest nightly and it seems to be working now. it would be very difficult to create a small library that lets fredders set up render a camera to texture with a few function calls with script eval.

Did you mean "it wouldn't be very difficult" or did you actually intend to say there's still several set backs with the system as is?

[Nuke]

actually i pulled the latest nightly and it seems to be working now. it would be very difficult to create a small library that lets fredders set up render a camera to texture with a few function calls with script eval.

Did you mean "it wouldn't be very difficult" or did you actually intend to say there's still several set backs with the system as is?

i was half asleep when i posted that. but a simple script is all you need. you would call a function with the name of the camera to set it. then you can call a function (with no arguments) to render it to texture, then you call a 3rd function, with x and y to draw it on the hud. 

some issues with fred integration. seems the camera sexps automatically enable rendering to the camera. so you would have to set its position and then immediately reset the camera, then do your script evals to render it to texture and draw it to the hud. might be better just to do it all with script evals since this sounds like a hack.

[Aardwolf]

As far as the "AI" aspect... I'm picturing something like the unused player views in multiplayer games of Star Fox 64? i.e. a camera which picks something interesting to watch?

[Nuke]

As far as the "AI" aspect... I'm picturing something like the unused player views in multiplayer games of Star Fox 64? i.e. a camera which picks something interesting to watch?

descent 2 had cameras as a stock feature. you could get a rear view, a guidebot view, and a marker view, it was kinda badass. its what i based the camera system in the cockpit demo on.

[JGZinv]

As far as the "AI" aspect... I'm picturing something like the unused player views in multiplayer games of Star Fox 64? i.e. a camera which picks something interesting to watch?

Something along those lines, I'm not really familiar with SF 64 as I've not played it in years.

I'm guessing you'd have to set it up so when 2 or more players entered a radius of X amount, and then check if weapons were fired by some amount or time, then that
would be an indication that is a battle - then feed that to a "screen" for X amount of seconds before a new "feed" could take it's place.

[Nuke]

bad news, its seems that build that i thought was a recent nightly was in fact 3.6.12 final. somehow i got my builds crossed. rtt is more screwy than ever.

[Nuke]

my cockpit demo now supports a more dynamic way of handling render targets, meaning you can have as many displays as you want. of course there is a hardware limit of how many render buffers you can have, modern video cards support at least 8, mind you some of these are used by the game. one is used up by your frame buffer (maybe two), and there may be others used as well.  i figure your typical cockpit should use no more than 5 (1 instrument panel, 1 hud, 1 video display, and 2 mirrors).

i haven't fully implemented mirrors yet, thats gonna be fun, both to code and setup. they will take your main view info into consideration, so you can move your head around and use them to see behind you at varying angles. i smashed a bug with my gatling turrets (the one where they like to open fire immediately entering a game). though i think i (or one of my cats) introduced a bug in my multitargeting system. still need a way to configure the scripted gauges. still its worthy of me updating my svn repo with the working version.

i have yet another idea about drawing the entire hud to a render target. i need to dip into c again and create pre and post draw hooks for the hud, in the former you set a render target and adjust the fov of your camera so that the corners of the hud polygon intersect the corners of the view frustum (this sets up certain functions that the hud uses to draw things like lead indicators correctly). then in the latter you reset it to screen, the resulting texture should contain transparent hud info. unfortunately i cant get rtt to work in the alpha-supporting build at all. if the alpha build can be made to work i may just use hud polygons for important stuff like targeting features, without any c code.