Render to texture - what are the possibilities?

[slatts 1978]

in the mean time

something i tried today

http://i296.photobucket.com/albums/mm180/guitaro-man/arma2oa2011-06-1521-43-15-23.jpg

still gotta work on the colours, probably gonna remove the dark transparent outside

[Armoredfury193 10]

With the muffins and pie in the equation now, this is something BIS would be crazy not to consider.

[nodunit 397]

Muuuffiiins....

But yes this would be a great asset since the game is very infantry focused, it would be a huge swing and miss to ignore RTT on weapon optics and scopes. It could also make tank interiors come back into style since we could properly use the periscopes and any digital devices.

[Steakslim 1]

I'm sitting here trying not to think about when BIS is gonna give us another preview lol, because when they do, RTT will probably be working along with some other things (figure that's when they'd feel it'd be worth it to start showing things off after E3).

[Uberduderofdoomer 10]

ITS INCEPTION!!!!

No seriously, what I am wondering is how computer intensive it is. Would it effectively double workload if it rendered a picture of your screen on something? And what about rendering the reflection within the reflection ala aforementioned inception?

[max power 21]

It depends on what the parameters of the second camera are. All other things being equal (like no kind of weird instancing), if it's showing the same scene in the same detail, then I think it would double the workload. If it's showing the scene in less detail, or with less of a field of view, then it the workload would be not quite double. I'm sure that since the screens would be relatively small and / or have screen effects added to them, that they could probably get away with rendering less textures in less resolution with less detailed geo.

[EricM 0]

For mirrors, screen size is much lower so they could get away with lower mipmapping textures and lower Lods, lower shadow paramters and the assets should already be loaded in memory. Everything that is calculated on a per pixel basis (effects ?) would be also greatly reduced.

It's like putting your 3D resolution to 640x480 for instance, it's clearly not the same burden as rendering 1920x1200.

A commander post in warfare with 4 or 5 cameras for your troops + a map would be made of awsome

Edited June 16, 2011 by EricM

[Alex72 1]

Maybe 3-4 steps of settings quality for the mirrors/monitors. 1 with full quality and then downwards with lower LOD's and lower textures. A mix in between with high quality parts. Hopefully BIS manage to get this working well. :)

[max power 21]

For mirrors, screen size is much lower so they could get away with lower mipmapping textures and lower Lods, lower shadow paramters and the assets should already be loaded in memory. Everything that is calculated on a per pixel basis (effects ?) would be also greatly reduced.

It's like putting your 3D resolution to 640x480 for instance, it's clearly not the same burden as rendering 1920x1200.

A commander post in warfare with 4 or 5 cameras for your troops + a map would be made of awsome

But you are rendering in 1920x1200, you're just occupying a smaller percentage of the screen. I think that if you rendered a full scene in any game, then rendered that to a small texture, the overhead would be the same. Of course, I could be wrong. I think what's more important here is the camera's parameters.

[SaBrE_UK 0]

But you are rendering in 1920x1200, you're just occupying a smaller percentage of the screen. I think that if you rendered a full scene in any game, then rendered that to a small texture, the overhead would be the same. Of course, I could be wrong. I think what's more important here is the camera's parameters.

Just an idea: would it be possible (without huge performance impact) to render the scope view at the high resolution (not necessarily taking up the whole monitor's resolution), and then rendering the periphery at a lower resolution, which is then heavily blurred to make up for the fact it would look upscaled? This way the total resolution displayed wouldn't necessarily be that high, and the periphery is viewable as well as the detailed scope view.

However, I guess problems might be noticeable lag on going in and out of scope view, or noticeable transitions in the process.

[dysta 10]

I rather hope there's a true mirroring and optic manipulation based on global illumination, instead of rendering another 3D world on the texture.

[dm 9]

I rather hope there's a true mirroring and optic manipulation based on global illumination, instead of rendering another 3D world on the texture.

Lulz.

Real time ray tracing may not be far off, but a little bit too far for game-based rear view mirrors me thinks.

[roberthammer 582]

For the 3D scope - the RTT way will be big performance hit sadly

Edited June 28, 2011 by RobertHammer

[max power 21]

I rather hope there's a true mirroring and optic manipulation based on global illumination, instead of rendering another 3D world on the texture.

Global illumination is nothing like a mirror reflection. Global illumination is a way of lighting/colouring a scene based on some kind of emulation of (seemingly extremely large)photons. The geometry is then rendered using the information generated by that process. It has nothing to do with the camera. Ray traced reflections are concerned with what the camera can see, and are generated after the scene has already rendered the lighting, I think.

Just an idea: would it be possible (without huge performance impact) to render the scope view at the high resolution (not necessarily taking up the whole monitor's resolution), and then rendering the periphery at a lower resolution, which is then heavily blurred to make up for the fact it would look upscaled? This way the total resolution displayed wouldn't necessarily be that high, and the periphery is viewable as well as the detailed scope view.

However, I guess problems might be noticeable lag on going in and out of scope view, or noticeable transitions in the process.

It seems like if you're rendering a scene in some resolution that anything that's a part of that scene will be rendered in that same resolution. Textures that are rendered via camera are still rendered in that scene. I guess you'd need two scenes at once composited together to have two different resolutions.

Edited June 28, 2011 by Max Power

[liquidpinky 11]

For the 3D scope - the RTT way will be big performance hit sadly

For some of us it wouldn't be, if you are using say 200% render in game anyway then the scope part could remain unscaled with the periphery being scaled down as usual to your correct resolution.

Or look at it another way, would you rather have 8AA and no RTT scope or 4AA and have an RTT scope?

[Big Dawg KS 6]

For the 3D scope - the RTT way will be big performance hit sadly

And if it isn't a performance hit the alternative would be that it looks like crap & is unusable.

I expect (and hope) 2D scopes will remain.

[CarlGustaffa 4]

In TKOH, the RTT used for the mirror only works while inside the chopper. Outside, it's a standard environment (map) reflector. Does this mean RTT is only viable from within vehicles, or is it just only due to being an early implementation?

I'm kinda hoping that combat scopes with low magnification either become RTT or zoomed in 3D screen (like "zooming" into aimdot). Only high powered scopes, sniper scopes, would use the current overlay. Aimdots would get the benefit of a projection, while ACOGs etc get the current textured reticle approach. Would also love to see possibility to adjust dot and reticle brightness where appropriate. Well, it's a dream anyway :p Recently watched the new OFP game, and after consideration, I think I prefer those ACOGs over Armas. Downside is harder to use the optics BDC. Bah, I don't know. I just think the current ACOG makes the scope too good.

[maddogx 13]

In TKOH, the RTT used for the mirror only works while inside the chopper. Outside, it's a standard environment (map) reflector. Does this mean RTT is only viable from within vehicles, or is it just only due to being an early implementation?

Presumably the reflective material has only been applied to the internal view LOD, not to the external LODs. I don't see any logic in RTT not working at all outside of vehicles. :)

[max power 21]

I support what MadDogX says. Vehicle (or any other) resolution LODs are just visual shapes with materials applied to them. They can be anything. You could have a car that looks like a boat at a distance and looks like an airplane inside, or any mixture. I think that the devs just felt that the mirrors were a waste of computing cycles on the exterior LODs.

[liquidpinky 11]

Presumably the reflective material has only been applied to the internal view LOD, not to the external LODs. I don't see any logic in RTT not working at all outside of vehicles. :)

Until there are 20 vehicles parked within view of the highest LOD, all facing different directions. Enjoy your slideshow.

[dm 9]

Until there are 20 vehicles parked within view of the highest LOD, all facing different directions. Enjoy your slideshow.

This.

And beyond the initial 5 second "OMG this is KEWL" factor, what value do working mirrors on the external views of vehicles really add?

[roberthammer 582]

That RTT is only on Pilot View LOD - the RTT can be in external LODs ,but that would be only wasting Fps on that

[maddogx 13]

Until there are 20 vehicles parked within view of the highest LOD, all facing different directions. Enjoy your slideshow.

Well, that's a different kind of logic. Actually, perhaps the word "logic" was ill chosen. :)

What I meant was, there shouldn't be a technical reason for RTT to work only in the driver/cargo view LODs. Like Max Power explained, any LOD is just a shape with materials on it, so RTT should (theoretically) work anywhere, as long as the appropriate material is applied.

[roberthammer 582]

Btw Imagine the controlling the UAV and thx to RTT we can just look at Laptop screen :p

[papanowel 120]

Btw Imagine the controlling the UAV and thx to RTT we can just look at Laptop screen :p

Would be awesome.